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.