John, Some of the increase will be due to the addition of state tags data structure to emcmot_status_t; See https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/motion.h and https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/state_tag.h
Also I think the number of entries in the tool table has been expanded significantly but I don't use it so can't advise further. Rod Webster *1300 896 832* +61 435 765 611 VMN® www.vmn.com.au On Sun, 25 Oct 2020 at 13:34, Johannes Fassotte < johan...@automationassist.com> 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 > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
