Think zeromq is used for message passing, found only a few functions. Interestingly enough in one of the example https://zeromq.org/languages/c/ they send using TCP/IP which is the same protocol NML use. I get the impression zeromz is message oriented while TCP/IP is an endless stream of data.
Anyone looked into the code of Machinekit? > If the machinekit fork was so good as far as making the information more > structured why did that fork not get adopted into the main stream? Is it > just that for existing installations, that already work, the attitude is why > change? > John > > > > > -----Original Message----- > > From: N [mailto:[email protected]] > > Sent: February-17-20 12:38 PM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] [Emc-developers] Looking to make hex offset list > > for NML status shared memoryr > > > > > 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
