Tool table issues

I would normally post this in the other user interface section that pertains to Labview UI' but this effects more that just those who link into LinuxCNC using its built in network ability via NML commands.

Labview is very useful, not only can it be programmed and configure as a user interface but it also has the ability to to display and analyze data in a user friendly format. In this particular case I used it to see what is happening inside of the emcStatus buffer. In particular what the increase from 56 tool to 1000 tools that was done this year in April. This caused some problems that have been a bit more difficult to spot. I shared some information of what I found on the developers list but I did not get a warm fuzzy feeling there.

There has been a considerable amount of discussion in the past about upgrading the tool table and the way tool data is handled. If you make a change in src/emc/nm_intf/tool.h and recompile and watch the compilation printout you will see that it links into a whole lot of files and thus appears tool data distribution seems to overly complex. I suspect that it does this because so many files access the emcStatus buffer and thus the status buffer was convenient for all tool data when tool files were small.

I mentioned the above because I think that the increased the size to the tool max pockets form 56 to 1000 is that he emcStatus buffer now has to handle moving a lot more data around and it is running out of time to do so as I outline below.

All my tool changes are manual and via R8 collets. My present tool file has four tools for engraving and drilling front panels. So I used that configuration to do some tests on how the tool table and Canon Max Pockets affects data stored in the emcStatus buffer and also how that affect data transferred from the status buffer during a peek operation.

So to start Cannon Max Pockets is set to 5, to allow for tool number in spindle and the 4 tools. And collect data transferred via a peek to a remote that captures the status buffer data via Labview. LinuxCNC debug shows the number of bytes transferred which agrees with what the remote received and decoded. Prior to sending the status data linuxCNC send out a message of 20 bytes to tell the remote how much data will be transferred. The trasfered data includes the status header and start of status data flag.

Length per tool line = 256 characters which ends up at 100 bytes per tool in status data size

The below chart: Max Pockets, Data Bytes sent, Actual bytes of status data

Pockets Bytes Actual Status
5, 4240, 4188 This is tool data bytes for 4 tools and intire emcStatus buffer data
105, 14220, 14188
205, 24220, 24188
305, 34220, 34188
405, 44220, 44188
505, 54220, 54188
605, 64220, 64188
705, 74220, 74188
805, 84220, 84188
905, 94220, 94188
1005, 104220, 104188

Now considering that 4240 bytes are all that is needed for emcStatus in this configuration we are moving 99980 extra bytes of data around just for tool table data which contains no data, its all zeros.

This equals 23.58 times the amount of data required for normal emcStatus data. I think that it is absolutely insane to stuff this data into the emcStatus buffer and some development systems would likely flag it as such. The tool table as a "whole" has no business being in the emcStatus buffer when it becomes this big. It was workable with a size of 56 but it is not suitable with the present size of 1000.

I have tested this and found that 705 tool pockets is the most that can be handled due to internal linuxCNC timing issues. After that linuxCNC starts producing improper data packets which gets mixed in with good data packets. If other processes take up some cpu time the 705 number may be to high.

A potential temporary work around which takes memory management into consideration for most individuals, Read the tool table size, automatically adjust tool and status buffer size in NML file and automatically set, Max pockets based on actual number of tools in tool file. The tool file could be further read with each line length value adjusted individually and automatically. This will also decrease number of bytes required.

Tool files don't change unless modified and reloaded so there is no need to store all the tool files static values in the emcStatus buffer.

My guess is that few would argue that passing around a 1000 tool list that you don't need is a problem.
Unfortunately like all these hard problems, there are very few with the skills, knowledge and time to fix it properly.
So then we get the most direct action to fix an immediate problem.
In this case I agree maybe we should limit the tool list lower to say 500 and see if that fixes the immediate problem.

Chris

I really am at a loss to understand how it was deemed OK to increase the tool table to 1000.
An increase to 257 was mooted in this thread
forum.linuxcnc.org/38-general-linuxcnc-q...n-tool-table?start=0

And a how to add 257 tools was published on the eusurplus wiki.
www.wiki.eusurplus.com/index.php?title=Useful_linux_commands
At least 257 makes sense as it is based on a byte boundary,

There was also a discussion which I can't find that flagged caution becasue of memory constraints or something if you extended the number of tools. I guess Johannes has found out the hard way what happens when limits are exceeded.

My recommendation would be that a pull request be created reducing the limit to 257 in line with earlier discussions pending a reworking of tool handling altogether.

One thought i had was if emcstatus tools were moved to a seperate structure and emcstatus contained a tool count and a pointer to that buffer. then there could be seperate NML message that returns the tool table if required in a paged way. This is not unusual with APIs using JSON. eg. give me 50 tools starting from tool #51

This issue reeks of sloppy/lazy programming eons ago that never has been reworked.

Yesterday I did some pulls to keep my development version up to date and noticed that my concerns over how the tool table is used in linuxCNC is being addressed with some new additions to the git linuxCNC tree.

/linuxcnc/tree/dgarr/tool_nml
/linuxcnc/tree/dgarr/tool_mmap

tooltable internal data: refactor w30

working on clang scan-build complaints
this branch is force pushed, rebased at d452817 and also e469adb

In looking at this a bit it looks like the entire tool table array will no longer be loaded so this work will likely be the solution of the tool size problem that has caused me nothing but grief size it was expanded from 56 to 1000 tools back in April of this year. Plus one extra slot for tool in spindle tracking for a grand total of 1001.

I went ahead and downloaded the dgarr branch, compiled it and installed my x1Mill info into the configs folder so that I could control my milling machine with gmoccapy 3.0.9.1. This allowed my to home the machine and then jog to known positions so that decoding of the raw emcStatus data that my Labview status peek process would send back to it via its network TCP connection.

I'm extremely happy with the results. The number of bytes that the emcStatus buffer has to handle has been greatly reduced and there is no bad data being sent even though the number of tools is set to 1001. Actual size of status data that is transferred via a peek request is now at 3636 bytes which gives 3584 actual data bytes after removing the the header and sync start pattern.

The below shows the data transfers being completed, 20 byte peek request acknowledgement which also has the number of bytes that will be sent. Note that command serial numbers will not agree between the pictures because the pictures were taken at different times.



The next picture show the receiving end which is my Labview panel that handles the connection and collecting the status data and routing that data further for decoding by its location in the status data and conversion of pointer values. The status data itself shows a lenght of 3584 bytes near the bottom right and near the top left and down a bit it shows that the buffer supplying this data is the emcStatus buffer.



The picture below shows that at offsets 1088, 1096 and 1104 is the main position data that is displayed for X, Y and Z axis.

I was reviewing some of the information printed out in my terminal window during linuxCNC start up for this new tool format and found the following at the start of the list that were added by dgarr branch.
Starting LinuxCNC...
(time=1606184063.691686,pid=20671): Registering server on TCP port 5005.
(time=1606184063.692440,pid=20671): running server for TCP port 5005 (connection_socket = 3).
20677 IO: TOOL_MMAP yes emc/iotask/ioControl.cc
IO: EMC_STAT size= 10272
IO: EMC_IO_STAT size= 696
IO: EMC_TOOL_STAT size= 224
IO: CANON_POCKETS_MAX = 1001