I wanted to follow up a bit on my last msg regarding this with some
debug and a bit more additional info.
The below are the typical responses I get from LinuxCNC when status
requests are made from my remote UI.
I added some ( ) comments to some lines for additional clarity along
with some spaces between each automatic status request.
(time=1603662496.783341,pid=3200): Socket opened by host with IP address
10.10.20.1.
Ok we are connected so here we go.
(time=1603662496.842952,pid=3200): read 20 bytes from 4 (status request
from remote was received)
(time=1603662496.842977,pid=3200): TCPSVR request received: fd = 4,
serial_number=1, request_type=1, buffer_number=2
(time=1603662496.843004,pid=3200): rcs_sem_post(688129) called.
(time=1603662496.843248,pid=3200): wrote 20 bytes to 4 (status request
acknowledge back to remote)
(time=1603662496.843304,pid=3200): wrote 103800 bytes to 4 (status data
sent to remote)
(time=1603662496.907978,pid=3200): read 20 bytes from 4 (status request
from remote was received)
(time=1603662496.908000,pid=3200): TCPSVR request received: fd = 4,
serial_number=2, request_type=1, buffer_number=2
(time=1603662496.908027,pid=3200): rcs_sem_post(688129) called.
(time=1603662496.908292,pid=3200): wrote 20 bytes to 4 (status request
acknowledge back to remote)
(time=1603662496.908348,pid=3200): wrote 103800 bytes to 4 (status data
sent to remote)
(time=1603662496.972850,pid=3200): read 20 bytes from 4 (status request
from remote was received)
(time=1603662496.972873,pid=3200): TCPSVR request received: fd = 4,
serial_number=3, request_type=1, buffer_number=2
(time=1603662496.972902,pid=3200): rcs_sem_post(688129) called.
(time=1603662496.973146,pid=3200): wrote 20 bytes to 4 (status request
acknowledge back to remote)
(time=1603662496.973192,pid=3200): wrote 103800 bytes to 4 (status data
sent to remote)
(time=1603662497.017987,pid=3200): read 20 bytes from 4 (status request
from remote was received)
(time=1603662497.018011,pid=3200): TCPSVR request received: fd = 4,
serial_number=4, request_type=1, buffer_number=2
(time=1603662497.018038,pid=3200): rcs_sem_post(688129) called.
(time=1603662497.018268,pid=3200): wrote 20 bytes to 4 (status request
acknowledge back to remote)
(time=1603662497.018305,pid=3200): wrote 103800 bytes to 4 (status data
sent to remote)
This sequence continues forever with increasing serial numbers unless
stopped manually or due to an error, and will attempt to reconnect
forever unless stopped due problems as I have metioned that shuts down
the LinuxCNC TCP server. That will not come back alive without a manual
restart.
As can be seen the first thing sent back to the remote is a
acknowledgment with command serial number,
like this in hex: 0000 0001 0000 0002 0001 9578 0003 ECA0 0000 0000
0000 0001 is command serial number, and 0000 0002 is the buffer number
Following the acknowledgement is the 103800 bytes status data transfer
which also has a header and sync pattern of FFFF FFFF FFFF FFFF FFFF
FFFF, status data top starts immediately after this pattern.
For a bit more clarity the below shows a small portion of a print out
and shows the fathom extra data bytes.
Only the 103800 byte ones are valid emcStatus data. The rest is data
that is causing major system confusion
making it very difficult to even maintain a connection between LinuxCNC
and the remote to capture this data.
The below also shows that some "byte" values of this strange data are
piling up in the TCP buffer due to delays in the ability to pull in
whatever data this is due to delays caused by errors. These thus show
getting closer to a buffer overflow condition which would shut down the
TCP server within LinuxCNC. I decided not to capture the 20 Byte status
byte acknowledgement in the below list. Not sure why each start of the
unknown data is 74460 bytes versus 74440 bytes in the following. It
could be a 20 byte acknowledgement to one of the status requests that
was not able to be read due to errors and was thus left in the TCP buffer.
74460, 74440, 74440, 74440, 74440, 74440, 270080, 113660, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
74460, 74440, 74440, 74440, 74440, 74440, 270080, 113660, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
74460, 74440, 74440, 74440, 74440, 74440, 270080, 113660, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
103800, 74460, 74440, 74440, 74440, 74440, 74440, 270080, 113660,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
74460, 74440, 74440, 74440, 74440, 74440, 270080, 113660, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 74460,
74440, 74440, 74440, 74440, 74440, 233580, 150160, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 74460,
74440, 74440, 74440, 74440, 74440, 236500, 147240, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 74460,
74440, 74440, 74440, 74440, 74440, 270080, 113660, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 74460,
74440, 74440, 74440, 74440, 74440, 270080, 113660, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 74460,
74440, 74440, 74440, 74440, 74440, 270080, 113660, 103800, 103800,
103800, 103800, 103800, 103800, 103800, 103800, 103800, 103800
Using NML processes xemc or emc give the same result so emcStatus seems
to be affected as a whole,
as does just using local instead of remote.
This problem does show that you can't move data around that may not make
sense to something somewhere. And of course doing so is guaranteed to
cause problems. I do believe that LinuxCNC is lacking the capability to
read NML data as an actual remote might to explore if this kind of
problems exist. Perhaps remote use requirements were overlooked when
this particular change was made in master of around 10-14-2020.
Hopefully pointing out this particular issue will help with development
work to resolve this issue.
I do not understand all this fully yet but I assume that this will
change will be here is some form and thus it will need to be modified to
be compatible with actions similar to a normal emcStatus request from a
remote as I outlined by the debug info near the top of this message to
pull in just the data that this change is scheduled to provide. Those
are my thoughts.
Best regards to all developers
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
