Tool precall bug random tool changers only

[robharp]

This only happens on a machine with random changer turned on(from setting ini value). machins with a non random do not see this bug

when running pre called tools on a program or MDI command but you do not follow it with a M06 , the next time you run a Txx and M06 line, if the tool call is the tool already in use/spindle then the M06 is performed when it should not be. putting the wrong tool into the spindle and the program will continue to run..

if you do not run pre calls then this bug is not seen. but defeats the object of random with pre calling.

Here are the steps I follow to reproduce the issue:

run this problem
N1 g91 g28 z0
N2 t1 m6
N3 t2 g90 g00 g43 h1 z100. (abort here or after it)
N4 g04 p20.
N5 g91 g28 z0
N6 t2 m6
N7 m30

if you run this program, abort on line 3 or 4t, then re-run from N1, the tool 1 will be changed for Tool 2
the T1 & M6 should be skipped as we already have T1

on a non ramdon tool changer machine this bug is not seen running this same program

checked on current stable 2.7.11 & 2.8-Pre, above happens

[SebKuzminsky]

@robharp thank you for this bug report (and thanks to @gmoccapy for drawing my attention to it via #409). I confirm that this problem happens on 2.7 and master.

[SebKuzminsky]

On a non-random toolchanger machine (such as sim/axis/axis), when you ask Interp to prepare the currently loaded tool by running Tn, IO sets iocontrol.0.tool-prep-number and iocontrol.0.tool-prep-pocket to the requested tool's tool number and pocket number, then does the iocontrol.0.tool-prepare/iocontrol.0.tool-prepared handshake. But then when you M6 nothing happens - IO does not do the iocontrol.0.tool-change/iocontrol.0.tool-chaged handshake. Similarly, if you run Tn M6, then run M6 again, the second M6 does not cause a tool-change/tool-changed handshake. This is all very reasonable behavior.

I'm not sure what the correct behavior is for a random toolchanger machine. I can imagine two options:

1. Prepare the tool by setting iocontrol.0.tool-prep-number to the requested tool number and iocontrol.0.tool-prep-pocket to 0 (since the tool is already in the spindle), then doing the tool-prepare/tool-prepared handshake. A subsequent M6 must take no action.
2. Take no action when Tn asks to prepare the tool that's already in the spindle.

Option 1 is the most similar to the non-random toolchanger behavior, but I think my preference is for option 2. It seems like option 2 makes it easier to implement a random toolchanger correctly, since it doesn't have to special-case pocket 0.

Thoughts? Comments?

[SebKuzminsky]

I just pushed a branch that reproduces this bug (and verifies that non-random toolchanger machines do not have this bug): https://github.com/LinuxCNC/linuxcnc/commits/reload-tool-330

[gmoccapy]

Hallo Seb,

unfortunately you are not right with your opinion, that non random tool changers does not have this bug!

How toolchange should/must react:
If interpreter does find a Tn it should set iocontrol.0.tool-prep-number to n and iocontrol.0.tool-prep-pocket to the corresponding pocket. Than set iocontrol.0.tool-prepare and wait for iocontrol.0.tool-prepared to become True. After that, finding a M6 should set iocontrol.0.tool-change and wait for iocontrol.0.tool-changed to become True. Now the interpreter need to do a sync and continue executing the code. This is independent of being a random or non random tool changer.

How it does work actually:
The interpreter find a Tn and set iocontrol.0.tool-prep-number to n and iocontrol.0.tool-prep-pocket to the index of the array of toolTable, not to the corresponding pocket!!! Thats why I told to test to put i.e. tool 3 in pocket 5 and check iocontrol.0.tool-prep-pocket it shows 3 instead of 5. So the changer will try to get tool 3 from pocket 3, but in that pocket there might be an other tool. => CRASH.
Now add to ini of the same config RANDOM_TOOLCHANGER=1
you will get an gcode error, that a negative toolnumber has been used.
That does happen, because not tool has pocket 0
This situation can not be handled with random tool change flag, as that would take T3 from pocket 5 and change the pocket to be 0. So how do I know the place to put that tool back in its assigned pocket?

So we have several bugs in the tool change routine.

Please take in account three different tool change situations:
1. manual tool change:
We do not need to take any notice of pockets, as only the tool number is relevant

2. Rack Tool Changer
We need to inform to remap the correct pocket number and the current pocket number, as a user might have more tools than pockets. At actual state a user must place tool 5 in pocket 5 to be sure to operate, but that does need to edit all gcode files to have the different tool number. On a real machine you will just pull out T3 from pocket 2 and place T10 in that pocket. In your tool.tbl you just change the pocket number for tool 10 to be 2, but that does not work at this development state. We need also the pocket information to place the tool back in its correct pocket, as reported in an other bug report, that is not handled correct in remap. There might be several tools sharing the same pocket! That is not uncommon, even being not 100 % save.

3. Random tool changer, i.e. carousel with changing arm
Here the behavior is different. Finding a Tn will set iocontrol.0.tool-prepare and also iocontrol.0.tool-prep-number and iocontrol.0.tool-prep-pocket will be set, the changer movements will start moving of the carousel to position n. The gcode is still in process. Thats why we place the Tn command earlier in the code to save time. The changer can move the needed tool to the changing position, while the tool in spindle cuts material. If the selected tool is in position we get a iocontrol.0.tool_prepared signal from the changer. Later the interpreter will find a M6 command and set iocontrol.0.tool-change. The interpreter does stop working and the tool will be moved to the changing position. Now the tool in spindle will be removed from the spindle by the changer arm. The arm will turn 180° and place the prepared tool in the spindle, after that iocontrol.0.tool-changed will be set. The interpreter does a sync, and the new toll begins to cut material. At the same time the changer will place the old tool in the free pocket and wait for a new Tn command.

If you compare all 3 situations you will find out, that we need to handle the pockets correctly and not use a index of an array in any circumstance. IMHO we do not even need to distinguish non random and random tool changers, as that must be done in the remap or comp file the user uses. There are too many differences between one and the other random non random tool changers, so we will not be able to take care of all situations. IMHO the interpreter or iocontrol should never modify the tool table, except if it is caused due to gcode commands changing offsets. The pocket should never be changed from the interpreter, that is part of the tool-changer or the GUI!

chain changers of modern machines do have 200 and more pockets!

Seb, are my comments understandable?

Norbert

P.S. I am not a friend of discussing this kind of bug with possible new behavior on dev-list. I have reported several problems on that list, tried to begin a discussion, but it newer showed any result. just see my posts about the tool number limit. That is why i am trying myself to solve that cases. But this are just work around for my own machines, that will not flow back to the community. IMHO that is a shame. All the above mentioned can be solved with a 100 line python script and 3 additional hal pin, but who will understand that. I think we should work all together and find a clean solution for the three "bugs" at ones (tool limit, pocket handling and wrong reporting to remap). So I am a friend of the sqlite solution rene-dev proposed.

[gmoccapy]

I just checked Bug 330, bug 400 and bug 409 do refer to tool change problems

[SebKuzminsky]

I'm not seeing the behavior you describe. I'm doing my testing on 2.7 with sim/axis/axis. Its tool table looks like this:

T1 P1 Z0.511 D0.125 ;1/8 end mill 
T2 P2 Z0.1 D0.0625 ;1/16 end mill 
T3 P3 Z1.273 D0.201 ;#7 tap drill 
T99999 P99999 Z0.1 ;big tool number 
T4 P4 Z0 D.005 ;Added 20131029 

Preparing T99999 (by running T99999 in MDI) results in these iocontrol pins, which I think is correct:

Owner   Type  Dir         Value  Name
     6  bit   OUT         FALSE  iocontrol.0.coolant-flood
     6  bit   OUT         FALSE  iocontrol.0.coolant-mist
     6  bit   IN           TRUE  iocontrol.0.emc-enable-in <== estop-loop
     6  bit   OUT          TRUE  iocontrol.0.lube
     6  bit   IN          FALSE  iocontrol.0.lube_level
     6  bit   OUT         FALSE  iocontrol.0.tool-change ==> tool-change
     6  bit   IN          FALSE  iocontrol.0.tool-changed <== tool-changed
     6  s32   OUT             0  iocontrol.0.tool-number
     6  s32   OUT         99999  iocontrol.0.tool-prep-number ==> tool-prep-number
     6  s32   OUT         99999  iocontrol.0.tool-prep-pocket
     6  bit   OUT         FALSE  iocontrol.0.tool-prepare ==> tool-prep-loop
     6  bit   IN          FALSE  iocontrol.0.tool-prepared <== tool-prep-loop
     6  bit   OUT          TRUE  iocontrol.0.user-enable-out ==> estop-loop
     6  bit   OUT         FALSE  iocontrol.0.user-request-enable

There's also this iocontrol parameter, maybe that's what you're thinking of?

Owner   Type  Dir         Value  Name
     6  s32   RO              4  iocontrol.0.tool-prep-index

[rene-dev]

I think part of the problem is a mix of pockets and tool numbers, just like there used to be the mix of joint and axis.
tool-prepare should be called pocket-prepare.
none of the toolchanger hardware, comps or remaps ever deals with tools, they only handle pockets.
and the interpreter never deals with pockets, only with tools.
in the code there is a wild mix of tool and pocket numbers, and they are often confused.
for example here:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L3597
its called pocket number, but its not. the offset should come form the tool, not the pocket.
its actually the array index, which are the fake pockets, which are made up during loading of the tooltable.
also, the tool struct does not even contain the pocket number.
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/nml_intf/emctool.h#L26-L33

[SebKuzminsky]

@rene-dev you're right, that is confusing.

We have three different ways to identify tools: the tool number (what the g-code uses), the pocket number (what the toolchanger uses), and the index into the internal tool table array (what most of the internal code uses).

[andypugh]

Is iocontrolV2 any better? (I have never even figured out how to select it)

[rene-dev]

iocontrol is only a very small part of the toolchange related stuff.
there is some in the gui, and some in the interpreter.
you use it by specifying it in the ini, as io.
but I dont know what the differences are.