There may be some helpful info in this thread on the forum <https://forum.linuxcnc.org/41-guis/36920-labview-ui-project-for-linuxcnc?start=10 <https://forum.linuxcnc.org/41-guis/36920-labview-ui-project-for-linuxcnc?start=10>>
> On 17 Feb 2020, at 10:35 am, Johannes Fassotte > <johan...@automationassist.com> wrote: > > Can anyone give me some information on how to pull out the actual shared > memory location offset for each item as it is written to status by NML and > what is used as its reference point? Any help will be greatly appreciated. I > can deal with values but pointers and converting them are a real problem for > me. > > I have found the offsets required for quite a few status items using my > remote UI development tools but I would like to generate a complete offset > list of all NML status items on the NML side and pass those offsets to the > remote UI for decoding use. > > This is my status peek process from my remote UI. > From my remote Labview based UI I peek into status with my NML status peek > command and I receive back a 20 byte status request verification. > > Almost immediately I get back the actual raw copy of the shared memory status > data which is 9280 bytes long. > > Breaking these raw 9280 hex status bytes down: > The first 20 bytes is status prefix (not used for now). > Next 12 bytes is a sync pattern of (FFFF FFFF FFFF FFFF FFFF FFFF). > The next 9248 bytes is the actual raw status data. > > To decode the raw status data I use an offset value starting right after the > 12 byte sync pattern as a zero reference point. The 12 byte sync pattern must > be decoded properly as part of the logic before any further decoding is > allowed. > > Sample offsets: > As an example hex offset 1068 with a decoded length of 72 bytes contains the > actual position data for all axis. This is then broken down in 8 bytes > increments to get the position value for each axis. > > As another example a hex offset of 95 with a decoded length of 12 bytes gives > the current line number. > > Since I'm dealing with a raw copy of the status shared memory I hope to be > able to find a quick way of pulling out the offsets used my NML itself to > help decode all of the stored vales properly. I have decoded quite a few > values now just by looking into the raw received status data but the process > has been very time consuming. > > I can see some issues with the serial numbers contained in the status raw > data: > The peek command also updates the command serial contained in the shared > status memory and also updates what I believe to be the total command count > accumulator in the shared status memory. This makes it difficult compare old > shared memory values to new shared memory values since these two are always > changing and thus need to be filtered if doing an old to new compare of > actual status data changes and not triggered by the constant serial number > changes. > > > > _______________________________________________ > 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