Tool table pocket has no meaning without RANDOM_TOOLCHANGER

[ArcEye]

Issue by machinekoder
Wed Mar 29 18:24:57 2017
Originally opened as machinekit/machinekit#1195

---

Citing from the docs:

Note that unless you set the `[EMCIO] RANDOM_TOOLCHANGER=1` parameter,
tool and pocket number are identical, and the pocket number from the
tool table is ignored. This is currently a restriction.

This makes the pocket value and especially the prep_pocket value of iocontrol pretty useless for real-life applications.

It should not be hard to fix this problem. However, I wonder if something is already depending on this behavior?

[ArcEye]

Comment by machinekoder
Wed Mar 29 18:26:54 2017

---

To fix this problem it would be easy to add another value to the tool table that saves the real pocket id and to use this value in iocontrol. I don't think we need to change anything internally.

[ArcEye]

Comment by ArcEye
Thu Mar 30 07:48:47 2017

---

I am unclear what the problem is specifically.
What machine do you have, that requires to use the pocket value, that is not classed as a RANDOM_TOOLCHANGER?

I have written several custom realtime toolchanger components in the past, along with custom versions of iocontrol, so have some knowledge.

If you want to use the prep-pocket signal for something other than what it was intended for, on the basis that 'nobody uses it', that is an entirely different proposition.

You might be far better off writing a version of iocontrol that does what you want from the outset.
That way the appropriate version can be selected in the ini file and everything that worked previously continues to do so.

[ArcEye]

Comment by machinekoder
Thu Mar 30 16:53:16 2017

---

Citing again from the documentation:

'RANDOM_TOOLCHANGER = 1' - This is for machines that cannot place the tool back into the pocket it came from. For example, machines that exchange the tool in the active pocket with the tool in the spindle.

In this mode, the pocket ID is equal to the tool table index and only one tool can be located in one pocket. Without RANDOM_TOOLCHANGER the P<n> values from the tool table is ignore and a new pocket number which is equal to the tool table index is used.

For my application, the tool table should store a list of tools and the pocket (or position) ID references the location in the tool rack. However, the tool table also contains tools which are not loaded into the tool rack. This means there might be duplicate pocket ids in the tool table which disqualifies the RANDOM_TOOLCHANGER mode. On the other hand, the pocket ID needs to be used to select the tool from the correct rack position in the tool changer.

Of course, I could write a tool changer component that loads the pocket ID from the tool table file based on the tool table position (which is reported instead of the pocket ID). I just wonder if this behavior is intended or if this is something that has not been implemented (as stated in the documentation). If the current behavior is correct, then there is no need to change anything.

[ArcEye]

Comment by ArcEye
Fri Mar 31 08:28:38 2017

---

http://linuxcnc.org/docs/2.6/html/code/Code_Notes.html#_toolchanger_abstraction_in_linuxcnc
is probably more current than the one in our docs from 2013 or whenever and makes no mention of
features being unimplemented.

I think you are saying that for instance, you have a rack for 12 tools, but actually have 2 interchangeable racks so have 24 tools.
When rack 2 is fitted, pocket 2 will actually contain tool 14 not 2.

If the order is fixed, each tool can have a unique pocket number and the correct pocket position physically can be determined by :
if(pocket > 12) pocket -= 12 ;
But you could do that from the tool number as well.

Don't know how that fits?

If there can be random substitutions of tools in different pockets, I can't see an alternative to tool table updating and using pocket numbers for the actual tool selection.

Tool changers and tool tables have long been a vexed subject in Linuxcnc.
Very few people even have an ATC, let alone a side arm chain conveyor for instance, so industrial machines with large numbers of tools were catered for only on two models and it affected next to no-one.