ASCII Characters Reversed When Using FINS

[gunnaraherman]

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.

 

 

[Mark-]

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 September 8, 2016 by Mark-

[panic mode]

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 

 

 

[gunnaraherman]

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.

[Mark-]

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.