@robharp感谢您的错误报告（并感谢@gmoccapy通过#409引起我的注意）。我确认这个问题发生在 2.7 和 master 上。

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?

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

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.

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

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

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

@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).

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

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.

@andypugh no idea. It’s terrible that we have two iocontrols. We should clean that up, merge them or something.

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.

-SebKuzminsky

correct me if i am wrong but i through option 1, is what the code is meaning todo as it now, but it fails to do it correct when you prep a different pocket/tool but DO NOT do the change (m6), then it fails to internaly handshake.. as on a random i tend to prep a pocket early normaly on drive on line. this is where i found the issue when i restart or rerun a tool g code section as the next pocket is preped but not needed as such..

so i think a quick fix to fix this issue if someone knows the workings better.. or
maybe it would be better to leave such taskts to the intergrator to make the design on what todo, just present them with the correct info to decide on which is already there i belive..

the IOv2 i looked over quick, and it looks to be alot better throught out for all changers in question. as it also allows one to prep a pocket while doing motion which you can not do right now, i dont know why but its not possible as motion is halted untill you do a preped signal hand shake..
V2 has abit of error handaling too from what i see.. i would love to see it merged in..

iocontrol 2 can be used by changing io to io_v2 in the ini.
The biggest difference is the hal pin handling, as the pins can be connected to digital and analog io, so you have a lot more freedom on a remap procedure.

Seb, if each tool number has the same pocket number as the tool, all is ok, just test with

T1 P1 D4.500000 Z-2.667780 ;4.5 mm 3 flute cutter
T2 P5 D25.000000 Z-17.295477 ;25 mm cutter
T3 P4 D7.500000 Z+1.229786 ;7.5 mm 3 flute cutter
T4 P3 D4.000000 Z-10.256000 ;4 mm Drill
T5 P2 D5.000000 Z-10.254000 ;5 mm Drill
T6 P10 D6.000000 Z-11.120000 ;6 mm Carbide burr
T7 P9 D6.500000 Z-14.589000 ;6.5 mm HSS burr
T8 P8 D12.000000 Z-14.458000 ;Cutter with 2 faces
T9 P6 D16.000000 Z-16.527474 ;Cutter with 3 faces
T10 P7 D165.000000 Z-12.112000 ;Facer with carbide inserts
T11 P11 D10.000000 Z-14.258000 ;Centering drill
T12 P12 D4.000000 Z+13.214000 ;3d taster elektronisch
T13 P13 D13.000000 Z-14.388000 ;3-Schneider Schaftfräser
T14 P14 D10.000000 Z-12.256000 ;3 Schneiden Stufenbohrer 5.5 auf 10
T15 P15 D10.000000 Z-14.888000 ;Bohrer TiN beschichtet
T16 P16 D12.500000 Z-14.583000 ;Stufenbohrer 6.8 auf 12.5 - 3 Schneiden
T17 P17 D6.500000 Z-14.254000 ;Stufenbohrer 4.2 auf 6.5 mit 45 Grad Übergang
T18 P18 D4.000000 Z-16.595000 ;Schaftfräser 4 Schneider
T19 P19 D11.000000 Z-15.235000 ;Bohrer
T20 P20 D50.100000 Z-16.235000 ;Messerkopf 4 Platten
T21 P21 D7.800000 Z-14.587000 ;Bohrer poliert
T22 P22 D16.150000 Z-18.253000 ;Messerkopf Zweischneider
T23 P23 D3.300000 Z-14.254000 ;Bohrer poliert
T24 P24 D12.020000 Z-14.256000 ;Fräser nachgeschliffen, nicht beschichtet
T25 P25 D4.500000 Z-2.667780 ;4.5 mm 3 flute cutter
T26 P26 D25.000000 Z-17.295477 ;25 mm cutter
T27 P27 D7.500000 Z+1.229786 ;7.5 mm 3 flute cutter
T28 P28 D4.000000 Z-10.256000 ;4 mm Drill
T29 P29 D5.000000 Z-10.254000 ;5 mm Drill
T30 P30 D6.000000 Z-11.120000 ;6 mm Carbide burr
T31 P31 D6.500000 Z-14.589000 ;6.5 mm HSS burr
T32 P32 D12.000000 Z-14.458000 ;Cutter with 2 faces
T33 P33 D16.000000 Z-16.527474 ;Cutter with 3 faces
T34 P34 D165.000000 Z-12.112000 ;Facer with carbide inserts
T35 P35 D10.000000 Z-14.258000 ;Centering drill
T36 P36 D4.000000 Z+13.214000 ;3d taster elektronisch
T37 P37 D13.000000 Z-14.388000 ;3-Schneider Schaftfräser
T38 P53 D10.000000 Z-12.256000 ;3 Schneiden Stufenbohrer 5.5 auf 10
T39 P54 D10.000000 Z-14.888000 ;Bohrer TiN beschichtet
T40 P55 D12.500000 Z-14.583000 ;Stufenbohrer 6.8 auf 12.5 - 3 Schneiden
T41 P56 D6.500000 Z-14.254000 ;Stufenbohrer 4.2 auf 6.5 mit 45 Grad Übergang
T42 P57 D4.000000 Z-16.595000 ;Schaftfräser 4 Schneider
T43 P58 D11.000000 Z-15.235000 ;Bohrer
T44 P99 D50.100000 Z-16.235000 ;Messerkopf 4 Platten
T45 P59 D7.800000 Z-14.587000 ;Bohrer poliert
T46 P60 D16.150000 Z-18.253000 ;Messerkopf Zweischneider
T47 P61 D3.300000 Z-14.254000 ;Bohrer poliert
T48 P62 D12.020000 Z-14.256000 ;Fräser nachgeschliffen, nicht beschichtet
T49 P63 D4.500000 Z-2.667780 ;4.5 mm 3 flute cutter
T50 P64 D25.000000 Z-17.295477 ;25 mm cutter
T51 P65 D7.500000 Z+1.229786 ;7.5 mm 3 flute cutter
T52 P66 D4.000000 Z-10.256000 ;4 mm Drill
T53 P67 D5.000000 Z-10.254000 ;5 mm Drill
T54 P68 D6.000000 Z-11.120000 ;6 mm Carbide burr
T55 P69 D6.500000 Z-14.589000 ;6.5 mm HSS burr
T56 P70 D12.000000 Z-14.458000 ;Cutter with 2 faces
T57 P71 D16.000000 Z-16.527474 ;Cutter with 3 faces
T58 P72 D165.000000 Z-12.112000 ;Facer with carbide inserts
T59 P11 D10.000000 Z-14.258000 ;Centering drill
T60 P12 D4.000000 Z+13.214000 ;3d taster elektronisch
T61 P13 D13.000000 Z-14.388000 ;3-Schneider Schaftfräser
T62 P14 D10.000000 Z-12.256000 ;3 Schneiden Stufenbohrer 5.5 auf 10
T63 P15 D10.000000 Z-14.888000 ;Bohrer TiN beschichtet
T64 P16 D12.500000 Z-14.583000 ;Stufenbohrer 6.8 auf 12.5 - 3 Schneiden
T65 P17 D6.500000 Z-14.254000 ;Stufenbohrer 4.2 auf 6.5 mit 45 Grad Übergang
T66 P18 D4.000000 Z-16.595000 ;Schaftfräser 4 Schneider
T67 P19 D11.000000 Z-15.235000 ;Bohrer
T68 P20 D50.100000 Z-16.235000 ;Messerkopf 4 Platten
T69 P21 D7.800000 Z-14.587000 ;Bohrer poliert
T70 P22 D16.150000 Z-18.253000 ;Messerkopf Zweischneider
T71 P23 D3.300000 Z-14.254000 ;Bohrer poliert
T72 P84 D12.020000 Z-14.256000 ;Fräser nachgeschliffen, nicht beschichtet

T1 will be OK , T2 not and try a T70 M6

Norbert

sorry, I do not know why inserting the code does destroy the file

@gmoccapy I edited your comment and replaced the “`” characters with the sequence: “~~~~~”

Just as lets-step-back-question; why does linuxcnc need to know about the pocket position at all?
Obviously, it was easiest to implement them together originally but looking now maybe it’s time to change that.
AFAIK linuxcnc needs to know information about the current tool and thats it.
The tool changer needs to know pocket position/tool number for sure.
The GUI needs to know pocket position/tool info for sure.

Does IO-control-v2 allow for encapsulating the details of pocket position?
Could we write a control component for each style of toolchanger and with remap that would allow users to build what they need if outside that? Isn’t that why IO-control is loadable in the first place?

In this way we could make sure random and non random tool changing works while allowing expanded tool info details, and any weird toolchangers.

@gmoccapy The reload-tool tests I just wrote use a tool file like the one you pasted, where the tool numbers differ from the pocket number, and the pocket numbers differ from the “index” in the tool file, and all the numbers are out-of-order. And those tests pass fine on 2.7 and master. So I’m still unable to reproduce the problem you’re describing.

I see that you’re using local modifications to LinuxCNC. Try to reproduce the issue on a stock version, and open a new issue for it if so.