Modbus/TCP Server problems

[plcnut]

Even when running the Modbus slave on my PC, it takes 2 scans before I can get a code into the client if the scanner has been idle.
Still can't get to tech support at Datalogic...

[BobO]

If you bump up the idle disconnect time on the DM1, does it still fail there?

[plcnut]

I have attached one more trace just to show what is happening with a working Modbus slave.
There are 3 scans in this trace. One scan, and then a pause, and then 2 successive scans (AG108 is the data).

This is using a Matrix 300 that has been reset to factory defaults, and then the imaging calibrated, and the only other settings I changed was enabling the Modbus Client, and setting the Modbus addressing.

[plcnut]

If you bump up the idle disconnect time on the DM1, does it still fail there?

The fail is directly tied to the DM1 timeout setting. I will see if I can figure out something with Datalogic. Their documentation for Modbus covers less than one page in the manual.

[ATU]

Not sure how the Datalogic side works, but what if you did something to keep the link active? Either read or write data that is constantly changing, like a heartbeat pulse?

[BobO]

Then I'd say it is what I suspected; DataLogic isn't handling the disconnect. Bad form, but I understand the issue having solved it for Do-more.

The biggest issue I see is that they don't appear to be making much of an effort to retry the operation when it fails. That might fly in the scanner world, but it would be sternly frowned upon in control.

[BobO]

Not sure how the Datalogic side works, but what if you did something to keep the link active? Either read or write data that is constantly changing, like a heartbeat pulse?

DataLogic is the master.

[plcnut]

I know there is a heartbeat setting for the Datalogic, but I really don't want the overhead on my network if I can get by without it.

[ATU]

Most of those transmit once a second or maybe you can set it? I doubt it would affect anything and you can monitor it in the DoMore to check the integrity of the link. Keeping data going through the port may keep it open. Try it.

[plcnut]

Spent all morning with Datalogic tech support. There is a problem with their implementation of Modbus TCP. Also, the heartbeat will not work on Modbus (it is supposed to, but it is broke). They do have a TCP Data Socket that I am going to try to use until they get me a Firmware update.
Thank you guys for the support!

[plcnut]

Are their any monitoring bits/registers in DMD that I could look at to see the status of the Modbus server?

Also, what are the dangers in setting the Modbus server's timeout to 2 hours?

[plcnut]

I got a new switch so I can mirror ports now
Here is a sample trace between DMD and Datalogic. The barcode data that is being sent is 'AG108'.

[plcnut]

I am learning to use Wireshark, and am trying to cut out the extraneous data in the trace files. Here is the latest that records everything to and from my H2-DM1E and the Datalogic from power-up until I make several scans (notice the first scan was a no-read).

[BobO]

Key parts of the trace:

1. DataLogic (DL) does an odd thing at the start. He sends out a gratuitous ARP, which essentially announces to the network that he 10.0.0.26. He then issues 4 ARP requests for the PLC in 2us. Not hurtful, but odd to burst off 4 requests without waiting for a reply.
2. Upon receiving the first response from the PLC, he opens a connection.
3. After about 1 minute, the PLC closes it due to inactivity, and DL ACKs him indicating that he at least saw the close request.
4. 15 seconds after that, DL sends a Modbus write.
5. DL immediately follows it with a connection close and a RST/ACK...doesn't wait for a response. It feels like the socket is goofed up at this point.
6. PLC says, huh? (resets the connection)
7. 6 seconds later, DL opens a new connection and successfully speaks Modbus.

Basically, he gets flustered when the server drops the line on him. He eventually recovers, but doesn't appear to retry the failed comm.

[plcnut]

I have implemented Datalogic's Data Socket protocol instead of Modbus. It is working great!
THANK YOU Host for giving us these great protocol development tools!!!

I will continue to work with Datalogic on getting their Modbus protocol working, and will update this thread with the results.