Gene , I use my labview based network interfaces for all my remote work
into linuxcnc. I put most of my info in the regular forum at:
https://forum.linuxcnc.org/41-guis/36920-labview-ui-project-for-linuxcnc
I'm not familiar with the tool you are using so can't comment on that
but I'm sure that it cannot encode NML commands to request status data.
To test for this you must send a properly formatted NML peek status
request to linuxCNC from a remote to the status buffer using the proper
port. If you don't do that then you will not see anything since no data
transfer has been requested. The commands sent must also update its
serial number with each command or the linuxCNC TCP server will shut
down due to errors or buffer overflows. This will also occur if the
wrong number of bytes are sent since that would cause confusion on the
linuxCNC end and will cause delays in any response back and sooner or
later a server shutdown which will require a linuxCNC restart.
There has to be a good sequence of status request commands sent before
being able to see the pattern for the bad intermixed data I described.
Thus you have to send your properly encoded NML status request commands
and then pull the data out of the linuxCNC buffer rapidly since these
are send to you in very rapid succession. Using wrong byte values for
messages sent by linuxcnc to the remote will cause serious trouble
shooting problems. Every thing must be correct.
One of the problems with the unknown data is that number of bytes is not
constant and I suspect that they may be arrays in real time that contain
nothing but NML encoded zeros. If this data is not displayed in hex
those zeros will likely not be seen. These zeros likely represent an
initialized array with no data written into it and only sized.
I'm not sure at all if real time is really needed for anything related
to tool table data since changing a tool is turtle slow to start with.
If there is little bit of data that real time needs from a tool it
should be able to be routed to real time without affecting the normal
NML buffers.
Tool table data should be able to be requested by using transfer methods
like that in place for emcStatus request commands from a remote, which I
have described in the past, but not from the normal emcStatus buffer.
Request for tool status can easily be routed to a different buffer by
the remote to access a buffer dedicated to tool status data only.
Does real time really need to know everything about a 1000 tools at
once, or is just one at a time enough to satisfy it?
What values for each tool does real time actually actually use for
machining and not for moving tools around?
I Hope this helps.
On 11/4/2020 9:31 PM, Gene Heskett wrote:
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
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
