T command not handled correct with RANDOM TOOL CHANGE, very dangerous!!

[gmoccapy]

I checked on recent master:

• Open sim / axis / random_tc.ini
• home machine
• in MDI enter T2M6
• Watch iocontrol.0.tool-prep-number and iocontrol.0.tool-prep-pocket both are 0 after the change
• in MDI enter T12 tool and pockets are set correctly
• in MDI enter T3 also sets the infos correct,
• now in MDI Enter T2M6 : CRASH!!!!

You will be asked to enter tool 3!!!!! instead of Tool 2!!!!
This will for sure cause a crash or damaged part with an auto tool changer!!!

Norbert

IMHO Issue 330 is also related to this one!

[gmoccapy]

There is another error related to random tool changer:
Open simpockets.tbl ans change first line from T3 P0 .. to be T3 P2 ..
save the file and start sim / axis / random_tc.ini

You will get an error naming you are using a negative tool number in your gcode file, but IMHO that misinformation is related to the tool handling of random tool changer, because it does not find a pocket 0 in the tool table.

Norbert

[rene-dev]

is there anyone using random tool changers? they seem to be very buggy.
maybe it should all be removed and all handled in the remap?
is it not a problem that both linuxcnc and the gui write to the tooltable?

[gmoccapy]

It would be helpfull, if someone who knows, could document how the tool stuff is handled in LinuxCNC.
As far as I found out is is spread all over the code and sometimes it uses toolTable.toolno to check for the tool and on other part of the code toolTable[pocket].toolno.

IMHO: the complete tool handling need a bigger rework. Unfortunately I do not understand what I am doing, but at least trying and crying.

What I have seen till now, random_toolchanger is not helping at all, but complicating the tool handling.

Norbert

[gmoccapy]

@rene-dev

IMHO only the GUI should be allowed to handle the tool file, not linuxcnc.
LinuxCNC should have a documented API to the tool handling and that one must not run in relatime!

Norbert

[andypugh]

It isn’t possible to make the clean split you envisage. G code can change tool offsets and the motion planner needs to know the current tool dimensions. So you need at the very least an interpreter-level version of the data and a sub-set of the same data in the real-time layer. And then you need to write-back the data at the right instant.
I did do a large re-write of the tool handling several years ago, but I don’t think anyone ever tried it. And I would also expect to have kept all existing bugs and introduced new ones.

[gmoccapy]

OK, I understand,

but that would only need to be done for the current tool. And the API could change the data at non realtime level for tools not in the spindle, right?

Norbert

[rene-dev]

I think andy is talking about G10 L1, L10 and L11. those write to the tool table.
but yes, for normal operation interpreter only needs to know about the current tool.
I think this is the only non-gui part that writes to the tooltable.

linuxcnc/src/emc/rs274ngc/interp_convert.cc

Line 3578 in 9e4641a

int Interp::convert_setup_tool(block_pointer block, setup_pointer settings) {

[SebKuzminsky]

There is no tool information in the real-time part of LinuxCNC.
Things like TLO and cutter comp happen in the Interpreter, in non-realtime. What comes out of the Canon layer and goes to the real-time Motion controller has had all necessary tool information baked into it already.

[rene-dev]

ah, ok. I was wondering about that.
I know the interpreter does not run in rt.
so whats the strange limit with max toolnumbers then?
I thought it was some limit in the shared memory?
if its only in the interpreter and in the gui, it should not be too hard to replace everything with a proper tool management, like andy started in his branch.

[rene-dev]

this one:

linuxcnc/src/emc/nml_intf/emctool.h

Line 23 in 9d99a30

#define CANON_POCKETS_MAX 56 // max size of carousel handled

it seems to be used all over the place. I dont completely understand how everything works.

so the user edits the tool table via the gui. thats gui stuff.
the interpreter only uses the tooltable via convert_setup_tool and convert_tool_change.
what am I missing here?

[SebKuzminsky]

The tool count limit is due to a limitation in the size of the shared memory primarily between the non-realtime components "Task" and "IO". It could probably be increased without too much effort, I'd think (but I've never tried).
I think tool changers with more than 56 pockets are pretty rare, but I think it's a good idea to support even rare hardware, if it doesn't negatively impact common hardware.

[gmoccapy]

@SebKuzminsky

The pocket limit is not the problem, but linuxcnc limits the tools too. What about having 200 tools, you will never be able to use tools 56 to 200, as LinuxCNC will tell you they are not in the tool table, even if they are in the tool.tbl file!

to increase the tool amount you need to edit two files, i.e. 256 tools:

/configs/common/linuxcnc.nml
change:
emcStatus from 16384 to 33792
toolSts from 8192 to 33792

and /src/emc/nml_intf/emctool.h
CANON_POCKETS_MAX to 257

That does run on my machine without any problems, but that is not the clue.
The problem is that the pockets are handled consequently and not as they should as own member of toolTable.pocketno, as tool 13 must not be in pocket 13, you can place that one also in pocket 5.

My changer has 24 pockets, but I have about 50 tools in SK30 holders, measured and ready to use.
If I use several tools, I am used to place them in the order they are needed in the code, as that does save a measurable amount of time, so sometimes I would like to place tool 35 in pocket 2.

With actual LinuxCNC that can not be done, as reaching T35 M6 will try to pick the tool from pocket 35 instead of pocket 2. I could rename the tool to be tool 2 in pocket 2, but that way I need to edit also the g-code file witch has come out of my lovely cam. I try to maintain cam and LinuxCNC tooltable synchronized.

I have found a solution with a python script as work around to the LinuxCNC bug, but that is a very individual way to solve my issue.

IMHO we need to do the work to get tool handling and tool table to work as it is done on industrial controls.

@rene-dev
the tool stuff is all over the code, just see /RS274/tool_parse.cc, interp_find, interp_convert, sai/saicanon and a lot more.

just try on command line being in src dir
grep -Ril "pocket" ./

All this code must be checked. I have unfortunately not pushed my last changes to my test branch, but IMHO I need to fix interp_find to get the correct pocket. In the german forum is a guy CNC_Willi, who has solved the pocket issue for himself, he will send me the patch so I can review that one.

It would be a great help, if someone could paint a diagram of the tool handling in LinuxCNC, that way I would be able to check exactly that part.

Norbert

[rene-dev]

Im looking into changing everything to sqlite.
@gmoccapy can you look at what it takes to change gladevcp/tooledit_widget.py to use sqlite?
there also needs to be a standalone version of that, otherwise axis users wont be able to edit their tools...
I use this script to convert a tooltable to sqlite: https://pastebin.com/Xx1XQtdV
its based form @andypugh s branch...
linuxcnc only needs the fields in there, but it would be good if the gui could show additional fields.

[c-morley]

@rene-dev gladevcp's tooledit_widget could be changed to use any API available. It can run standalone with little changes. It would be very nice to easily add other info to display, independent of the motion controllers needs. Currently there is a hack to show wear offsets for instance.

[rene-dev]

Im still figuring out how everything works together. there is a lot of toolchange related stuff in the interpreter, and in iocontrol. It looks like pocket numbers and random toolchangers are very buggy, and dont work like they are supposed to be.