GE-IP Rx3i 8022 Warning when copying Byte Array to Word memory

I have a CMM2 (Serial I/O) card in my system that talks to a device that utilizes Byte oriented messages EG a typical message I would send would be like:

Byte 0 - Header
Byte 1 - ID
Byte 2 - Command
Byte 3 - (0x00 Padding)
Byte 4 - Checksum LSB
Byte 5 - Checksum MSB

I currently have the CMM2 transmit buffer defined in %AQ as a Word array, as you can't define a Byte array in %AQ memory.

But it is more natural to construct these messages as a Byte array - so internal to my code I build the message in a Byte array and then copy it to the Word array transmit buffer*. However even though this works, this technique throws up an 8022 Type Mismatch Warning in Machine Edition (even tough the correct number of bytes are being copied), and it is this warning that I am trying to eliminate**

I have tried every combination of Move, Array Move etc that I can think of in order to fool ME but to no avail. The only options I seem to have left are:

1. Define the transmit buffer directly in discrete memory (I,Q,T,M etc)
2. Create some horrible looping code that packs/unpacks data between Word and Byte arrays

Is there any thing else that I am missing that could solve my problem and eliminate this 8022 Warning?

---

* Byte arrays can be defined in discrete or symbolic memory, but symbolic memory byte arrays causes a totally different issue due to the packing of data in memory. If you attempt to copy word data to symbolic byte array you get a "Warning 8297 BYTE arrays are not packed in non-discrete memory" which means data is not correctly copied (and yes I did try it!). As such, in order to work I have to define Byte arrays in discrete memory (I,Q,T,M etc)

** I aspire to producing code with zero warnings (especially the 8022 Type Mismatch) in machine edition as I have found more than one coding error by tracking down the source of such errors.

Would it not be easier to set up a WORD array for the message string? Using the same values as your BYTE array but using a WORD array you can combine the six words into your three WORD message by:
Message_WORD 0 = WORD 0 + (256 * WORD 1)
Message_WORD 1 = WORD 2 + (256 * WORD 3)
Message_WORD 2 = WORD 4 + (256 * WORD 5)

Steve Bailey said:

Would it not be easier to set up a WORD array for the message string? Using the same values as your BYTE array but using a WORD array you can combine the six words into your three WORD message by:
Message_WORD 0 = WORD 0 + (256 * WORD 1)
Message_WORD 1 = WORD 2 + (256 * WORD 3)
Message_WORD 2 = WORD 4 + (256 * WORD 5)

Click to expand...

That is something I considered but there are some more complex messages where that sort of thing gets in the way of the logic of building the message. This especially comes into play when I am processing responses which have Byte oriented data in them that I have to parse out based on a Byte location within the Rx buffer

I just found the solution to eliminating the warning with the copy.

With a WordArray of 6 words starting at %AI1 and a ByteArray of 12 bytes starting at %I1 the trick is to do a "Move Bool" of 96 from WordArray[0].X[0] to ByteArray[0].X[0]

This trick of explicitly referring to bit addresses within the Word and Byte source and destination addresses seems to suppress the 8022 warning

I would create two subroutines or function blocks called "Byte_to_Word" and "Word_to_Byte". Use the first to assemble your message as I described above after having created the message using a WORD array. Use the second to extract the bytes from a received message into a WORD array.

Steve Bailey said:

I would create two subroutines or function blocks called "Byte_to_Word" and "Word_to_Byte". Use the first to assemble your message as I described above after having created the message using a WORD array. Use the second to extract the bytes from a received message into a WORD array.

Click to expand...

And then that boils down to coding efficiency. What you are suggesting means that you have to manually implement each copy to/from the arrays - either by explicitly doing as you showed or via a loop construct and keeping track of indices.

For a fixed length buffer (and using the addressing trick I -re-remembered) I can achieve the same data transfer with a single PLC instruction - which I expect will be more performant.

I'm not going to argue over which way is "better".