> 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.
From the zeromq documentation I think Machinekit use: On the wire, ZeroMQ messages are blobs of any size from zero upwards that fit in memory. You do your own serialization using protocol buffers, msgpack, JSON, or whatever else your applications need to speak. It’s wise to choose a data representation that is portable, but you can make your own decisions about trade-offs. > 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. At the top you claim "Internally the data is represented by a tree of structures." and this is also what I found in stat_msg.hh file. I do not think this change between versions. It is common to have some kind of structure, CANopen and TCP/IP or UDP/IP have it. I do not think these structures are supposed to change between version or different compiles. _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
