Labview UI project for Linuxcnc

cmorley wrote:

I would suggest using git bisect to (hopefully) find the commit that caused it.

Chris

You could also try V2.8 which is before the conversion to Python 3 was pushed.

Below are some values from the 03/06/2020 master and 09/20/master NML configuration files.
Somewhere in between these dates is when this problem occurred based on the zip files I have on hand.

What ever caused the below buffers size increases to get linuxCNC to run after compiling appears to be the problem. These very large changes indicate that there were major changes being made that effect emcStatus and toolSts buffers which I my opinion is causing compatibility issues.

# Top-level buffers to EMC for the 03/06/2020 master

---

B emcCommand SHMEM localhost 8192 0 0 1 16 1001 TCP=5005 xdr queue confirm_write serial
B emcStatus SHMEM localhost >>>> 20480 0 0 2 16 1002 TCP=5005 xdr
B emcError SHMEM localhost 8192 0 0 3 16 1003 TCP=5005 xdr queue

# These are for the IO controller, EMCIO
B toolCmd SHMEM localhost 1024 0 0 4 16 1004 TCP=5005 xdr
B toolSts SHMEM localhost >>>> 8192 0 0 5 16 1005 TCP=5005 xdr


# Top-level buffers to EMC for the 09/20/2020 master

---

B emcCommand SHMEM localhost 8192 0 0 1 16 1001 TCP=5005 xdr queue confirm_write serial
B emcError SHMEM localhost 8192 0 0 3 16 1003 TCP=5005 xdr queue
B emcStatus SHMEM localhost >>>> 170000 0 0 2 16 1002 TCP=5005 xdr

# These are for the IO controller, EMCIO
B toolCmd SHMEM localhost 2048 0 0 4 16 1004 TCP=5005 xdr
B toolSts SHMEM localhost >>>> 131072 0 0 5 16 1005 TCP=5005 xdr

The value 170000 is more than the 123904 or so actually required to run at the moment. But that has no effect on the issue as long as sufficient space is available for the data. However making buffer sizes up to 8 times present values does not give me good feelings at all. Is there any info available as to why such large changes were required in current master and details what all this space is going to contain?

The total size of the emcStatus data sent to the remote in the 03/06/2020 time frame of master is 9196 bytes. And has no issues with unknown data attaching itself to data transfers and thus the my false cause in my code I posted before is never executed. This is not the case for the 09/20/2020 version which has the increased buffer sizes. To me it appears that the unknown data transfer issue and the increase in buffer sizes are related in some way. I'm inclined to suspect that data is being moved around in a way that is not totally correct by the change that caused the buffer size increases and that remote access was never considered. Thus if this data is going to be routed to a remote it needs to have handshaking items like remote status request for accessing the emcStatus buffer. Perhaps it should even have have its own buffer to prevent conflicts.

LinuxCNC master dated as being 03/06/2020 version reports the below when running and talking to the remote status process.

(time=1604228111.357099,pid=2543): TCPSVR request received: fd = 5, serial_number=7204, request_type=1, buffer_number=2
(time=1604228111.357123,pid=2543): rcs_sem_post(360449) called.
(time=1604228111.357182,pid=2543): wrote 20 bytes to 5
(time=1604228111.357209,pid=2543): wrote 9196 bytes to 5

The unknown added data that attaches to or is sent with status request in the later masters never reports their presence like in the line directly above which makes me suspect that they are real time driven. It show up at regular intervals in burst of six in a row.

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.

Attached is a bit of info on the TCP based StatusMain.vi that handles getting status data from linuxCNC and gets the staus data ready for further processing. Immediately after connecting to linuxCNC it asks for the name of the buffer it connects to for verification. If happy it will then proceed with status requests at a programmable interval, spit the data into its basic types and hand the status data off to be further processed and distributed. In the future it may also contain some code that pulls in the status buffer pointers which is currently in a separate process in my CommandMain.vi which is undergoing some cleanup work.

After running into the difficultly with data arriving via the TCP network connection that was not associated with the true emcStatus data I was able to run without errors again. The picture below shows that 108618 status request were sent and no errors were captured by one of this sub vi's which is not shown. It also shows that it successfully decoded the status buffer name on the first command that was sent to the status buffer. The latest master transfers 9216 status bytes of total status data, 20 bytes in its header, 12 bytes in its sync word, and then 9184 bytes of actual status data. This data is sent via the normal status write statement in emcmaintask and can be displayed as transmissions takes place as soon as the remote connects by using debug on the linuxCNC end of the link.

I run the Labview code on a Windows machine right now but it should work equally when when compiled to run on Linux.

Here is a picture for the StatusMain.vi with its front panel active to allow for monitoring values.



Below is what is the block diagram of the StatusMain.vi. It is event driven and when idle it updates the internal timers that do the status update requests in its command generator. The case structure, which includes System: Idle has 9 actual layers for its different functions. The event structure within it has 4 layers to handle the events that get the ones in the case structure active.




One of the great benefits of doing this type of status decoding is the ability to see issues with linucCNC development work problems that are not readily detectable with present debug or test functions. I really like Labview and I'm willing to share my code as progress is made if anyone is interested in helping to do development work. A labview - Python - linuxCNC interface is a posibility.

Hi I have been following your work and it is very interesting, you mention you can share your code, please let me know how can I get it.