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

Reply via email to