On 17/02/2020 18:15, Johannes Fassotte wrote:
I'm reviewing currently available documentation from the NIST on how a remote user is fed status information. From what I can tell based on my experiments is that the raw data file is sent to the remote for decoding and that the remote is able to do that without issues for the entire status data set.
Yes, that is correct.
Thus Im thinking that the location of each item withing the data set is stable for a particular configuration. If structure lengths are changed or new ones are added via a update then NML has that information available within itself and it should be able to be pulled out for use by a remote user to allow proper decoding of the raw status data it receives.
The status messages don't contain any type or size information. They are just anonymous blobs of data. Both the source and the destination have to be using the same specification or bad things happen. This is one of the things the Machinekit project wanted to fix.
Internally the data is represented by a tree of structures. Only the compiler knows exactly how those structures translate to actual memory. One change to one structure will affect the positions of all of the data after that structure. Generally everything in LCNC is compiled at the same time using the same specifications so it does not matter. If you start mixing versions or trying to reverse engineer that blob you are very likely to end up with something that breaks very easily. I ran into this problem when I made a Linux version of my Scanything application. It's distributed separately from LCNC so I ended up distributing it with a bunch of modules built from common LCNC releases. If none of those modules match your specific LCNC version it tries to automatically build a new module based on your version. Of course this only works if it can find the header files for your build.
Les _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
