Modbus RTU on GE micro versamax and Kepware

Hi,
I am trying to communicate with a GE Micro-Versamax PLC.
My configuration is as follows:
- Digi SP one connected to the RS-485 port of the PLC
- Kepware Server using Modbus driver with "ethernet encopsulation" enabled

I am trying to communicate with the PLC and get most of my Tags defined in Kepware working properly.
Some of the Tags however does not work properly (all of them are registers). Their data is not updated and their condition is BAD.
When trying to diagnose the problem using Kepware diagnostic tool I receive the following line when trying to retrieve data from one of the bad registers:

17/12/2008 18:48:33:693 TX: 01 03 00 69 00 01 54 16
17/12/2008 18:48:33:771 RX: 01 03 02 7F FF FF D8 34

Which means the Kepware requests a single register (16 bit) starting at address 0x69. The answer though is 24 bit long (one and a half registers !?!).
This happens for all read requests for this specific register (and quite a few of its friends...).

When trying to use an HMI software like Cimplicity, I receive no error and the data is displayed perfectly.
I also tried using Modscan utility and got these results for the same register aforementioned:
TX: 01 03 00 69 00 01 54 16
RX: 01 03 02 7f ff d8 34

Which means the data I receive in Kepware is somehow distorted...

Anyone has a clue or experienced this kind of behaviour?

Thanks in advance,
Assaf

I have experienced similar behavior with the Kepware Modbus TCP driver, perhaps the issues with modbus tcp extend into encapsulation as well. I reported my issue to technical support and it has been passed from there to software development. Kepware technical support may be able to help with your problem or you may be waiting quietly for a software update like me.

Thanks for the reply Brendan.
I have also spoken to Kepware tech support and they blamed GE for this. They said the GE modbus is not compliant with the standard.
After I ran the tests with Modscan and Cimplicity, it was obvious that the problem is with Kepware.
I did finally manage to workaround this problem by disabling ethernet encopsulation and using the RealPort created by the DIGI software.
That way, the Kepware "thinks" its communicating using a serial port and does not connect directly to the DIGI via TCP.
I will still demand some answers from Kepware because their recommendation is to connect to DIGI via ethernet encopsulation.
Assaf

The diagnostic that you are showing from kepware is a raw capture of what is coming into the Etherent socket from the Vesramax. The repeated byte is an error. The server is working correctly in ignoring this packet as it is bad.

I suspect that the Versamax is configured to tread certain brak chacter as DLE's and repeats them to mark them. Since this is not part of the Modbus Spec the Modbus driver would not have built in support to handle this. Try setting the Versamx to Modbus Ethernet to Mdobus serial mode rather thean Chanracter passthrough mode. The versamax should remove the additional bytes then. Als luck would have it you can set the Modbus serial driver to use Modbus TCP headers so you will not even have to change the project.

Thanks for your reply.
The assumption that the Versamax is not configured well or that the data that is being sent is incorrect is inaccurate.
Looking at the results of the Modscan utility you can see that the data is constantly sent with no error whatsoever.
Using Cimplicity with the same configuration and receiving correct data also support the assumption that the data sent from the PLC is correct.
Adding to all these facts the fact that Kepware works very good using DIGI's RealPort makes it almost 100% positive that the problem here is Kepware's Ethernet Encapsulation method for communicating with the DIGI.

coul,d you do a wire shark of the same transaction process and send the capture to our teck support with my attention. They will get it to me. The wire shark capture will tell us if there is a an extra character in the packet or not.

I can take this to our engineering team if there is no extra data in the packet as proof that we are doing something incorrectly.

I would like to point out that Ethenrent Encapsualtion is working a bit differently than the real port software is although that doesnot necessarily mean that waht we are doing is correct or incorrect.