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
