Awkward behavior in M6 Remap for T0M6
- GuiHue
- Topic Author
- Offline
- Premium Member
Less
More
- Posts: 103
- Thank you received: 36
25 Apr 2020 21:28 #165579
by GuiHue
Awkward behavior in M6 Remap for T0M6 was created by GuiHue
Hi everyone,
I have recently migrated to an ATC spindle setup with a rack tool change. The entire process is modeled using a M6 remap.
The entire code I am talking about can be found here:
github.com/GuiHue/myfenjalinuxcnc/blob/m...cros/rack_change.ngc
Situation 1:
Machine startup; no tool in spindle,
T16M6 --> Machine gets T16 from a specified pocket
T11M6 --> Machine drops off T16 (lines 55 to 112 in code linked above; Specifically: drops the tool, raises Z, shuts off various valves, clears Z and moves XY away from pocket (line 102 ff)) and gets T11
==> no problem
Situation 2:
Situation 1:
Machine startup; no tool in spindle,
T16M6 --> Machine gets T16 from a specified pocket
T0M6 --> Machine travels to pocket of T16
-Till line 86 everything seems to be ok (tools is being released; Z is raised slowly)
- The program seems to stop right here. It does however not trigger the alarm in lines 88-91
- The check messages, e.g. lines 95, 112, ... are all send to the terminal
YET: The spindle stops above the pocket, the M65 commands from lines 98-101 are not processed (the valves remain open, air is send through the spindle).
This only happens when changing to T0.
What am I missing?
I have recently migrated to an ATC spindle setup with a rack tool change. The entire process is modeled using a M6 remap.
The entire code I am talking about can be found here:
github.com/GuiHue/myfenjalinuxcnc/blob/m...cros/rack_change.ngc
Situation 1:
Machine startup; no tool in spindle,
T16M6 --> Machine gets T16 from a specified pocket
T11M6 --> Machine drops off T16 (lines 55 to 112 in code linked above; Specifically: drops the tool, raises Z, shuts off various valves, clears Z and moves XY away from pocket (line 102 ff)) and gets T11
==> no problem
Situation 2:
Situation 1:
Machine startup; no tool in spindle,
T16M6 --> Machine gets T16 from a specified pocket
T0M6 --> Machine travels to pocket of T16
-Till line 86 everything seems to be ok (tools is being released; Z is raised slowly)
- The program seems to stop right here. It does however not trigger the alarm in lines 88-91
- The check messages, e.g. lines 95, 112, ... are all send to the terminal
YET: The spindle stops above the pocket, the M65 commands from lines 98-101 are not processed (the valves remain open, air is send through the spindle).
This only happens when changing to T0.
What am I missing?
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
Less
More
- Posts: 19373
- Thank you received: 6485
25 Apr 2020 21:34 #165581
by tommylight
Replied by tommylight on topic Awkward behavior in M6 Remap for T0M6
Just checked some of my configs using tool changers, none of them use tool 0 or pocket 0.
I might be wrong, but what is tool 0 should not exist.
If you have 16 tools in the rack and you have tools from 0 to 16 in the tool table, that makes 17 tools !
I might be wrong, but what is tool 0 should not exist.
If you have 16 tools in the rack and you have tools from 0 to 16 in the tool table, that makes 17 tools !
Please Log in or Create an account to join the conversation.
- GuiHue
- Topic Author
- Offline
- Premium Member
Less
More
- Posts: 103
- Thank you received: 36
25 Apr 2020 21:53 #165582
by GuiHue
Replied by GuiHue on topic Awkward behavior in M6 Remap for T0M6
Hi Tommy,
I should elaborate further:
I have created a work around for the toolnumber/ pocketnumber dilemma in linuxcnc by using a global variable to store the last used pocket. I have a tooltable with approx. 80 tools. Only those that are used at the time are in the rack style tool changer which itself only has seven pockets. The lowest toolnumber is 11, anything with an assigned pocketnumber <= 7 is considered to be in the rack, everything higher is dealt with differently.
This implies, that T16 may be in pocket 3.
My understanding was that T0 effectively tells linuxcnc to drop of the tool and to not pick up a new one.
What vexes me is that the code linked above works fine when I want to drop of T16 (in the defined pocket) and to then pick up T11 at another pocket. When T0 is called, the code behaves funny, although at the referenced lines there is no making use of information about the "new tool" (Example 1: T11 in Pocket 2; Example 2: T0)
Maybe I should try handling T0 as a specific cases using conditionals...
I should elaborate further:
I have created a work around for the toolnumber/ pocketnumber dilemma in linuxcnc by using a global variable to store the last used pocket. I have a tooltable with approx. 80 tools. Only those that are used at the time are in the rack style tool changer which itself only has seven pockets. The lowest toolnumber is 11, anything with an assigned pocketnumber <= 7 is considered to be in the rack, everything higher is dealt with differently.
This implies, that T16 may be in pocket 3.
My understanding was that T0 effectively tells linuxcnc to drop of the tool and to not pick up a new one.
What vexes me is that the code linked above works fine when I want to drop of T16 (in the defined pocket) and to then pick up T11 at another pocket. When T0 is called, the code behaves funny, although at the referenced lines there is no making use of information about the "new tool" (Example 1: T11 in Pocket 2; Example 2: T0)
Maybe I should try handling T0 as a specific cases using conditionals...
Please Log in or Create an account to join the conversation.
- GuiHue
- Topic Author
- Offline
- Premium Member
Less
More
- Posts: 103
- Thank you received: 36
01 May 2020 18:19 #166350
by GuiHue
Replied by GuiHue on topic Awkward behavior in M6 Remap for T0M6
Made some progress.
In my macro I used M2 in various conditionals (e.g. drawbar did not open) to quit the macro. As it turns out, this sort of interferes with my pretty much everything. I have since replaced the various M2 with
O101 return [999]
(or other Onumerbs when required) and now T0 works the same way as everything else...
In my macro I used M2 in various conditionals (e.g. drawbar did not open) to quit the macro. As it turns out, this sort of interferes with my pretty much everything. I have since replaced the various M2 with
O101 return [999]
(or other Onumerbs when required) and now T0 works the same way as everything else...
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
- tommylight
- Away
- Moderator
Less
More
- Posts: 19373
- Thank you received: 6485
01 May 2020 19:05 #166355
by tommylight
Replied by tommylight on topic Awkward behavior in M6 Remap for T0M6
Again, thank you very much for reporting back, might come in handy.
Please Log in or Create an account to join the conversation.
Time to create page: 0.094 seconds