Niagara_Kepware Modbus TCP strings

I seem to be having great difficulty getting a string variable to work between Niagara and KEPWARE Modbus TCP. All other variables work fine.
In decoding the OPC communications I get the following TX and RX:

Here are 2 string OPC tests that both returned an E1 value that is NOT ASCII code?

This is the TX and RX data for 400029.16L
1/8/2013 2:26:02.803 PM TX: 00 9B 00 00 00 06 00 03 00 1C 00 08
1/8/2013 2:26:02.814 PM TX: 00 9C 00 00 00 06 00 03 00 1C 00 08
1/8/2013 2:26:02.839 PM RX: 00 9C 00 00 00 13 00
1/8/2013 2:26:02.839 PM RX: 03 10 57 51 00 00 59 54 E1 00 00 00 00 00 00 00 00 00

This is the TX and RX data for 400027.32L

1/8/2013 2:32:09.902 PM TX: 00 9E 00 00 00 06 00 03 00 1A 00 10
1/8/2013 2:32:09.908 PM RX: 00 9E 00 00 00 23 00
1/8/2013 2:32:09.908 PM RX: 03 20 00 00 00 00 57 51 00 00 59 54 E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Values 400022 to 400032 all return a GOOD Quality, but only 400029 returns 2 correct characters ( QW )for the String Constant “QWERTY”.

Greetings, so the thing that you need to know it that in this driver the end of the string is the first null byte (0x00) that it gets in the returned character/byte array. So for the request for data for address 400029.16L the response to the request is as follows:

A B C
00 9C 00 00 00 13 00 03 10 57 51 00 00 59 54 E1 00 00 00 00 00 00 00 00 00

The value at point A is the number of bytes in response 16.
The value at point B is the first byte which is a Q.
The value at point C is the null character that terminates the string.

For 400027.32L the response is as follows:

A B C
00 9E 00 00 00 23 00 03 20 00 00 00 00 57 51 00 00 59 54 E1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The value at point A is the number of bytes in the response, 32.
The Value at point C is the termination character 0x00 so the string is determined to be blank.
The value at point C is the start of the string but it is never looked at because the termination character is reached.



I would expect the read of 400027.32L to have additional leading bytes because you are requesting the read to start there.

The question is way is Niagara adding 2 null bytes into the middle of your string. The Kepware Modbus driver is working as it is expected to.