I wanted to post a update on this since I have isolated the source of
unknown data being intermixed with my status requests data sent via the
tcp buffer to my remote. This unknown and not requested data completely
disrupts the normal flow of status data at 6 times in a row and this
sequence repeats at itself at regular intervals.
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 point forward up to and including the current master. It is
also the cause of the very large increase and what I think is an
unreasonable increase in NML buffer sizes. I had not done much
development work this summer and thus this issue was not noticed until a
recent update.
It seems to me that a regular file or small database is more than
sufficient for a tool table with a choice depending on if pictures are
wanted or not. I see absolutely no valid reason for messing around with
NML buffer sizes to handle the tool table. I think that the best thing
to do is to develop a more suitable way to handle the tool table and
backing commit b51ef8c out.
The below commits are in order from bottom to top and are part of
those made on 7 April 2020.
Bad: commit/f3e971d426a55cd472910eaf659bef1ef969f5c1
Bad: commit/b51ef8cc3c560b6c44d095814988a3f972bc0763 <<<<<
OK: commit/1f516f2b0dcdb7d34b6c55e675c41a6cbca3f595
Changes such this one do need to be looked at from the network side and
the internal side of linuxCNC.
I hope that you will find this helpful.
Best regards to all developers.
On 10/24/2020 7:33 PM, Johannes Fassotte wrote:
There are changes to the NML configuration file Master that concerns
me a lot.
From the NML configuration file at the start of 2.9 pre0
B emcStatus SHMEM localhost 16384 0 0 2 16 1002 TCP=5005 xdr
B toolSts SHMEM localhost 8192 0 0 5 16 1005 TCP=5005 xdr
Present 2.9 pre0 I use
B emcStatus SHMEM localhost 170000 0 0 2 16 1002 TCP=5005 xdr
B toolSts SHMEM localhost 131072 0 0 5 16 1005 TCP=5005 xdr
Such a large change in file size indicates a major change in the
method of how some data is handled. I assume that it is associated
with a change to txt based data which would need a great deal of space.
I have no info on why such a large change in buffer sizes is required
in current master. All I know is that these changes are causing
problems with use of the remote TCP process that I use to status with
and have used successfully for almost a year using the early 2.9 pre0
master.
The remote status requests commands I send now using the ~10-14-2020
master
gives me the usual 20 byte status request acknowledgement as in the
past. Then 10380 bytes of actual emcStatus data, and then at perhaps 1
second intervals a very large block of data is sent by linuxCNC to the
TCP buffer that was not requested by my remote. It is mostly what I
think is header or a bit of data followed a very large number of bytes
of all zero's data.
In using the current master for my development has made it impossible
to decode the status buffer data remotely when unknown data gets
transferred into the TCP buffer that the remote process has not
requested. This kills TCP status server due the confusion it causes
which build up error until its shuts down. Command serial numbers
start getting confused with data being in the wrong place and its all
downhill from there.
Here again is a size comparision of NML configuration file of the
original 2.9 pre0 which works fine to master on about 10-14-2020
B emcStatus SHMEM localhost 16384 0 0 2 16 1002 TCP=5005 xdr
B emcStatus SHMEM localhost 170000 0 0 2 16 1002 TCP=5005 xdr
To me such a tremendous increase in size would seem to indicate an
intention to store and send a lot of text formatted data. I could be
wrong but when there is a lack of info there has to be a lot of
running around in circles and guessing. And based on this leads to the
below.
Status buffer Msg data 122464 bytes
Tool Msg size 112888 bytes
I also noticed that the size of the actual emcStatus data has
increased from 9280 bytes to 10380 bytes
which would seem to indicate added status data. This being the second
increase that I recall.
Thus far I have been using the xemc process for status data with this
latest version of master but will set up a separate status process to
see if that gets rid of the undesired data transfer that occurs at
about 1 second intervals. xemc is linked into a lot of internal
processes within linuxCNC and it is likely that one of those
is causing the problem I have attempted to explain. I recalled today
that I have seen issues with xemc being used in the past for local
functions such as polling and not strictly used just for
communications with a remote over a network connection.
Please supply some info on what these Status buffer and Tool Msg's
contains so I can possibly develop a process
to utilize these if they are really meant to be used across a network
and if this will be on a separate status buffer.
Rule 1: Never send data to a remote that was not specifically
requested, authorized or subscribed to.
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
