[LinuxCNC/linuxcnc Issue#409] T command not handled correct with RANDOM TOOL CHANGE, very dangerous!!

#1 – gmoccapy 于 2018-02-18

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

#2 – rene-dev 于 2018-02-18

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?

#3 – gmoccapy 于 2018-02-18

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

#4 – gmoccapy 于 2018-02-18

@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

#5 – andypugh 于 2018-02-18

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.

#6 – gmoccapy 于 2018-02-18

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

#7 – rene-dev 于 2018-02-20

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. https://github.com/LinuxCNC/linuxcnc/blob/9e4641a816ab8fe4f6a09a48fac550cc8aef1dee/src/emc/rs274ngc/interp_convert.cc#L3578

#8 – SebKuzminsky 于 2018-02-20

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.

#9 – rene-dev 于 2018-02-20

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.

#10 – rene-dev 于 2018-02-20

this one: https://github.com/LinuxCNC/linuxcnc/blob/9d99a308bc59d1efb72c19535eace818cb4e51c9/src/emc/nml_intf/emctool.h#L23
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 convertsetuptool and converttoolchange.
what am I missing here?

#11 – SebKuzminsky 于 2018-02-20

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.

#12 – gmoccapy 于 2018-02-20

@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
CANONPOCKETSMAX 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/toolparse.cc, interpfind, 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 interpfind to get the correct pocket. In the german forum is a guy CNCWilli, 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

#13 – rene-dev 于 2018-02-20

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.

#14 – c-morley 于 2018-02-21

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

#15 – rene-dev 于 2018-02-21

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.

#16 – SebKuzminsky 于 2018-02-21

@rene-dev if you find a bug please open an issue, preferably with a link to a branch that adds a test that reproduces the bug.

We have folks who have been using that code for years without trouble, so these bugs you’ve run into must be off the code paths they all exercise.

#17 – SebKuzminsky 于 2018-02-21

I confirm that the “incorrect tool gets loaded” bug originally reported by @gmoccapy is present in both master and 2.7. LinuxCNC doesn’t crash, but it does incorrectly execute a tool change to T3, even though T2 was specified (presumably because T2 was already loaded).

#18 – SebKuzminsky 于 2018-02-21

The discussion in this bug has meandered far off from the original bug report. The bug has nothing at all to do with how the tool table is stored on disk, or how many tools LinuxCNC can handle.

This bug is a duplicate of #330. I am closing this bug, let’s have all further conversation (about this bug only!) in #330.

If you want to discuss changing how the tool table is stored on disk I’m open to that, but a bug report is not the place, let’s have that conversation on the dev mailing list instead.

#19 – gmoccapy 于 2018-02-22

Hallo seb,

just changing a few lines in iocontrol seem to have fixed the pocket handling part. We still have open, that we can not handle more than 55 tools, Have you tried the tool.tbl I posted. Try to load T70, you will get an error.

And the remap bug is still there. I will comment on that isue.
Thanks, for your help to solve the first part of the tool handling issue.

Norbert