Posted 8 Sep 2016 Hello, I am using an NJ301 PLC with an NA series HMI. I am communicating to the PLC via FINS protocol using the DotNet FINS UDP application by Jay Anthony found under the downloads section. I am finding that when I write a string to an address, the bytes order are reversed. For example, I am writing the string 'Test' to variable 'FINS_String', which is a String data type at memory address D20. My FINS command is the following: 010282001400000254657374 0102: Write 82: Data Memory 001400: Address 20 0002: Write 2 words 54: T 65: e 73: s 74: t The value that appears on the HMI and in the watch window is 'eTts'. If I write 65547473 (eTts) as my command, it appears correctly as 'Test' on my HMI. I debugged the application and I see that the byte array is being sent in the correct order, so I'm not sure what the matter is. I can't imagine that to pass a string through FINS protocol the hex values need to be switched every time. Any help would be appreciated. Thank you for your time. Share this post Link to post Share on other sites
Posted 8 Sep 2016 (edited) Hello, From what I recall the order is "Test". I do know other PLCS are low-high byte when using words for characters. For FINS we support: Format Description 0) Default 1) 2 characters per word, character order high, low – default ABCD 2) 2 characters per word, character order low, high BADC 3) 1 character per word, character in high byte 4) 1 character per word, character in low byte 5) 4 characters per longword, character order ABCD 6) 4 characters per longword, character order DCBA Are you looking at the memory in the PLC or on the HMI? Edited 8 Sep 2016 by Mark- Share this post Link to post Share on other sites
Posted 9 Sep 2016 6 hours ago, gunnaraherman said: I debugged the application and I see that the byte array is being sent in the correct order, so I'm not sure what the matter is. please don't tell me you are unaware of: https://en.wikipedia.org/wiki/Endianness this should be part of every computer science curriculum Share this post Link to post Share on other sites
Posted 12 Sep 2016 After looking into the issue and Endianness, it appears that was the issue. Thank you for shedding light on this issue. I'm rather new to PLC's and was unaware of it. Share this post Link to post Share on other sites
Posted 12 Sep 2016 1 hour ago, gunnaraherman said: I'm rather new to PLC's and was unaware of it. It is not a PLC issue. It is a CPU and/or protocol issue. Years ago a colleague and I were working on a project that included communications between two devices. The CPUs were from different manufactures (Motorola and Intel). His was low-high, mine was high-low. Several years later, the another collaboration only his was high-low, mine was low-high. Share this post Link to post Share on other sites