Labview UI project for Linuxcnc

history for linuxcnc.nml:
last commit: github.com/LinuxCNC/linuxcnc/commit/b51ef8cc3

####################################################################

Note that you can specify a *custom* emc_nmlfile in your ini file as:
Ref: github.com/LinuxCNC/linuxcnc/blob/master...c/task/emcsvr.cc#L60

Example usage in test suite:
github.com/LinuxCNC/linuxcnc/blob/master...linuxcncrsh-test.ini


To identify the default emc_nmlfile (configs/common/linuxcnc.nml):

Thanks for the info.

I have in the past used many of my own NML configuration files. The NML configuration file it self is not the problem that I have noticed. It just reflects that there were changes made inside of LinuxCNC that required several buffer sizes to be increased by a large amount in recent masters. There have been a number of changes in the past that increase buffer size but never such a large one.

It is not possible to lower the values to the values used in the past, NML will complain that there is insufficient space for the data to be placed within them.

I think that 09/20/2020 is just a bit past the start of development work that may have introduced the problem I'm trying to get resolved.

I forgot to add that many of the git functions are not available for trouble shooting when working with downloaded linuxCNC master zip files.

I really am at a loss for you. I went through some of the commits back until 2.8 became the release version. I could not see any changes in the commits that might cause this bug of yours. Dewey has shared the commit where the tool table was increased. That and state tags fully explains the data structure size increases.

Chris mentioned the use of git bisect. You could start at the last known good git and roll forward until the error was found. But that assumes it really is a LCNC issue. Unfortunately, you need to get really specific to the commit if you are going to get any changes made. I'm not really sure that anything has been done. This is at the core of Linuxcnc and many years old so I don't think it would have been changed. Particularly when the comments in the source say in some files that a wise developer will not attempt to change anything!

I will dig in more to see if I can find a hint of where this is coming from. I have compared most of the files that comprise the heart of LinuxCNC more than once and have found nothing that jumps out as being the potential cause. It is possible that this is being caused by a addition that is not part of linuxCNC itself but compiled with it and executing on its own to get status info when it sees requests for status.

I do not use git much for anything other than using it for a occasional master clone. Other than that I work with the zip versions of master but those are not listed as being available by specific commits. If they are available somewhere then I sure would like a link to their location to fill in the my summer 2020 file gap when other things had priority.

I have back tracked this problem to 7 April 2020 and commit b51ef8c to "increase max tools from 55 to 1000" and that this has caused a problem from that forward up to the current master. It is also the cause of the very large increase in NML buffer sizes.

Part of the commits on 7 April 2020 and in order from bottom to top

Bad: commit/f3e971d426a55cd472910eaf659bef1ef969f5c1
Bad: commit/b51ef8cc3c560b6c44d095814988a3f972bc0763 <<<<<
OK: commit/1f516f2b0dcdb7d34b6c55e675c41a6cbca3f595

Today I backed out commit b51ef8c and recompiled the current master and reset the buffer sizes in linuxcnc.nml to bring those back to a more normal values as below.

emcStatus 17488 which is 1024 more than the actual size needed.
toolCmd 1048
toolSts 8192

Commit b51ef8c changed src/emc/nml_intf/emctool.h
#define CANON_POCKETS_MAX 56 to 1001 // max size of carousel handled.

1001 lines of data each with a length of 256 characters is a considerable amount of bytes. It does not even handle any potential updates that may include tool pictures.

Struct of canon_tool_table itself has seven items right now, toolno, pocketno,emcpose offset, diameter, frontangle, backangle and orientation.

The speed of which this data is required is a determining factor on how this data needs to be stored and handled. Since tool changes are not high speed there is really no reason to store any more tool data than required. Reading the tool file itself, which in effect is actually stored memory should have more than enough speed. With solid state drives data access speed has also improved allowing faster access rates than before. This reduces the need to copy data to other locations in a attempt to reduce the time required to access the desired data.

After bringing this back to pre 07 April 2020 conditions for the configuration with 56 tool slots it sends 9216 bytes of status data to port 5005 when status data is requested by the remote with the current master. No data transfer errors to the remote occur now.

I think that the method used to handle tool data needs to be reviewed and improved.