Hello, I have been attempting to use the BUF_TO_BYTE block to copy an array from an IN_PORT to another array. I also want to be able to flip the endianess of the IN_PORT array. However, regardless of what value BUF_FORMAT is, the same result shows up in my destination array. For a simple test, I set up a 4 byte test array with the value 0x12345678. Regardless of the state of BUF_FORMAT, my resulting array is always 0x12345678, vs the 0x78563412 I would expect when changing the endianess. Both arrays are BYTE arrays. Any ideas on this? Thanks, Mark[attachment]Screenshot 2021-03-09 093125.png[/attachment]
Mark, I’m sure someone from Phoenix can explain the internals, but from experience I suspect it is to do with the elements. Attached is an image which shows that the block works as expected if you buffer to a DWORD (which has endianess ??) compared to an array of bytes (bytes don’t have this and although 4 byte array = dword, the function may not take this into account). This is pure speculation based on experience. but maybe you can buffer to DWORD and back to the array again.
Thank you Andrew, for testing this. I hadn’t gotten around to testing this element type yet, but this is exactly what my colleague was thinking as well. I also agree, however, the endianess would typically involve memory locations, so to me, regardless of the element type, it should still swap the bytes correctly. They even mention in the help file that it works with bytes. I’m hoping someone from Phoenix can clarify.
I think Andrew’s explanation is correct. Mark is also correct that when you search for BUF_TO_BYTE in the help system, the result seems to indicate that the BUF_FORMAT parameter affects the behaviour of the BUF_TO_BYTE function block. However the same help page is used for all the BUF_TO_* function blocks, so I suspect that the writers simply neglected to mention this difference with the BUF_TO_BYTE function block. I will confirm this with the PLCnext Engineer support team and, if necessary, raise this as a documentation issue.
I can confirm that BUF_FORMAT parameter has no effect when using the BUF_TO_BYTE function block, and that this is the intended behaviour. I have asked that this be made clearer in future versions of the PLCnext Engineer documentation.
Thanks for the clarification, Martin.