Example: Pointer to Publish Modbus data members with Loops

[Mike@Forshock]

While loops are not always (read: never) performance efficient, they can certainly help with rapid development.
When first moving to the DoMore, the separation of the Modbus (Comm Server) from the Internal memory was a little bit to get used too.
To help with more contiguous, structured data that had more than a single heap item (think 8, 16, 32, etc. memory blocks) for userdefined structures with multiple individual fields. Creating a block of Publish/Subscribe members proved to be very time consuming and was not conducive to changes in structure field additions or subtractions.

THe example here is a structure of an item we call "ANALOG_stc" (simplified for example, but our full structure has just under 40 fields and fills about 30 modbus words)
We have a memory block of 32 (0-31) using the structure referenced as "ANALOG"
Using a single point (V100 in this case) we create loop from 0 to 31 with a step of 1 (0,1,2,...31)

Within the Bottom of Scan routine we publish our members.

In this loop we create an offset (V110) for the Modbus Register. In our case we dedicate 40 Modbus words for each structure, providing some overhead for future usage. We start our words at MHR101 (400101).
Within the Publish we reference the pointer for the memory structure, modbus offset and offset for each word.
DoMore allows for pointer offset up to 63 (Pointer+63).
In this manner we only need 4 Rungs to publish 1280 words of Modbus data and can modify a single line of the Publish instruction to work with the 32 structures.

Disclaimer: No warranties for code.  Use at your own peril! All bugs, errors, spelling & grammar mistakes, inefficiencies are included for FREE! You're welcome. 


If anyone has a more efficient method, please share.

[franji1]

An alternative implementation is to lay out the UDT to match the MHR memory layout needs exactly.  Then just use MEMCOPY of the specific UDT element on top of MHR memory (or from MHR to the UDT element).

The UDT editor provides a "Memory Layout" report tool to help visualize how the members would sit in RAM (i.e. copied on top of or from MHR memory).  You have complete control of the specific bit, byte, word, and dword positions of every structure member.  Most of the time you don't care about this, since the data is internal to the PLC.  However, when sharing it across other devices, it may be helpful to layout the structure members to match some defined layout.  This is very common in embedded systems, where you would define a C structure to match a pre-defined layout of a "control block".

If there is any byte or word swapping needed, you could do that before or after on an as-needed basis using specific SWAP instruction(s), in lieu of PUBLISH and SUBSCRIBE.

[Mike@Forshock]

Thanks for the suggestion, may be worth investigating the performance differences.

[franji1]

Thanks for the suggestion, may be worth investigating the performance differences.

One caveat - Within UDTs, WORDs must be WORD aligned.  DWORDs must be DWORD aligned.  Otherwise you have to piecemeal it using PUBLISH/SUBSCRIB like you describe.