On Wednesday 04 November 2020 23:33:51 Johannes Fassotte wrote: > 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.
Please describe how you are observing this, Johannes. I perhaps am not doing it right, but logged into any of my machines with ssh -Y, I am not observing anything unusual in the status reports I can pull up while running linuxcnc -l so as to see that machine on my screen here in the house. > 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 Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene> _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
