I recently started using the latest master so that I would get to far behind some of the additions and changes that may have been made without my usual renaming to RMC vice EMC. Thus I'm working with a unmodified master. Everything is working fine with the TCP command NML interface but not so much for the status one that peeks at the emcStatus buffer 2. With the latest version of master there is data sent to the remote that was not requested an is not part of the emcStatus data and is also not part of the data that linuxCNC sends back immediately after sending its status request acknowledgment
The unknown data that is sent back is actually 6 separate data transmission that replace the normal status data but in a format that is unknown and this data does not send an acknowledgement to my status request of any kind. A acknowledgement to a status request is required since it has the command serial number of the command that requested the data, along with buffer number it was sent to and the amount of data bytes that will be sent right after the acknowledgment which is the actual status data from the emcStatus buffer. The acknowledgment message has a length of 20 bytes.
The 6 data burst that are being transferred with unknown data and intended use are typically, 74308, 74276, 74204,74204, 74220 and 280356 bytes long but the number of bytes will vary., A search within this unknown data does show that some does contain the emcStutus sync word of FFFF FFFF FFFF FFFF FFFF FFFF which is present at the head of the status data itself but the position of this within the unkow data varies all over the place and status data is either invalid invalid or incomplete. This problem did not exists in the early version of master I was using which does not have a lot of the RTAPI items that appear to have been added. This unknown data does appear to be sent a fixed intervals that follow the status request rate to some degree.
The below picture as shows the captures of data sizes while remote status requests are send to buffer 2. When Ok is displayed the data bytes match what linuxCNC says it is sending in the acknowledgement message allowing status information to be properly decoded.
The below is a picture of the TCP Labview code that I use in the decode process with some added displays and notes for clarity. The code in upper right is doing the capture work. Length of the current and actual emcStatus data is 103716 bytes and size changes overtime due to updates within linuxCNC and it is thus important to decode the status reply acknowledgement message so that the proper number of bytes can be read by the next TCB buffer read to keep everything in sync.
The picture below display the contents of the false, bad unknown data case. This case is required for now to purge any data from the TCP buffer because the type of data and its content are unknown. Any data sent to the status port by linuxCNC is read and after 5ms has passed the length of data there is determined and stored in the loop on the upper right in the picture above for evaluation. The maximum size of the data allowed to be read is 500000 bytes which is sufficiently large to insure the data is not truncated before the length is determined.
These transfers of unknown data are very likely merging with the actual status replies by attaching themselves to the actual emcSatus buffer data.head or tail in a haphazard way.
I have posted some information like this on the developers net but one has come forward yet to explain exactly what this unknown data or where it is coming from. From what I can see it is just big blocks of all hex zero's. What makes this somewhat more difficult to track down is that not many people use the data that is normally available via the TCP server, even when there is no remote configured in the NML configuration file.
I do Thank Rod for his comments on the developer net.
