Modbus/TCP Server problems

[plcnut]

I have a system with 4 Datalogic Matrix 300 scanners. Each scanner is set up as a client with my H2-DM1E's IP as the server address. I set each of the scanners starting Modbus registers and lengths so that they are each dumping into blocks of MHR registers. This all works good.

The problem:
If the scanner is idle for more that 30-60 seconds (I have not put an actual timer on it), then I have to trigger the scanner three times before I get any data in the MHR register for that scanner. The serial connection is spitting out the data every time, and the Datalogic software sees the data every time, but the PLC gets nothing. I have come to the conclusion that it 'may' be on the PLC end.
I have not been able to find any way to view Modbus errors from the scanner end...

The PLC is set for:
-Enable Modbus/TCP server 'checked',
-Maximum Concurrent Sessions: '4',
-Client Inactivity Timeout: '60',
-TCP Port Number: '502'.

Any ideas?

[BobO]

Wireshark?

[BobO]

...and if it wasn't clear, by "Wireshark" I meant "Get me a Wireshark trace and I'll be happy to analyze it and tell you what might be going on". 

[plcnut]

I spent a few hours with Wireshark trying to get a trace. It appears my switch (an un-managed Netgear) is cutting all the comms. I guess it is doing its job too well for tracing... I tried putting my PC's IP into the scanner, and then I can get an occasional call from the scanner, but nothing that seems helpful, because it can't get a response.
I have now installed a MODBUS Server on my PC, so hopefully tomorrow I can get you a trace.

[Controls Guy]

Netgear has a switch family that you can configure for port mirroring.  I think the 5-port version is a GS105E (if that number is correct, the "E" is important; there is a non-E version that's cheaper and doesn't mirror).  I picked up one at Staples for under $80.  That's what I use when I want to get a Wireshark and neither device is a PC.

[plcnut]

Thanks CG.
I will ask IT if they have any managed switches that may allow mirroring.

[BobO]

I can't remember what the specific part number is, but several of us have mirroring switches as well. Critical for non-PC to non-PC Ethernet comms.

[plcnut]

Here are 2 traces I gathered this morning with a Modbus Client on my PC (the client is not set up properly, but it does communicate).
The first trace is what happens when I scan something after the scanner has been idle for a couple of minutes.
The second trace is what happens when the scanner has not been idle.

I am going to try too get a mirroring switch today so I can get a trace with the scanner talking to DM.

BTW "AG108" is the barcode data.

[plcnut]

We didn't have a switch, so I have one on the way...

[BobO]

It's kinda strange. The client sends the request and then immediately tries to freshen the socket, appears to succeed, but the DataLogic device doesn't return a response. A bit over two seconds later, the client opens a new connection, sends a new request, which is answered.

If I had to guess, the DataLogic device has dropped the phone without actually hanging it up...meaning...the server function has been shut down on the socket, but the socket hasn't been freed at the stack level.

[plcnut]

The scanner is the Client (@ .26). The PC just has a Modbus Slave application running on it (@ .50).

[plcnut]

The Datalogic setup screen:

[BobO]

Ah...so it it.

The behavior is still the same. The socket is stale and the server isn't responding. The DataLogic resets it, but doesn't issue a new request until two seconds later, and it does so on a new socket.

If there had been multiple minutes between comms to Do-more's Modbus/TCP server, we would have already timed out and dumped the connection. You can extend that, but the problem is still the same...the DataLogic device isn't doing anything to keep the connection fresh, it then sends a command, gets no response, and opens a new connection. I would think that for something like a scanner, which I would expect to have fairly infrequent comms, the preferred implementation would be to open the socket, transact business, then close the socket. Barring that, some form of keep alive would be prudent.

I have a nice little force-the-socket-closed hack in Do-more's stack to catch the condition where the remote connection gets closed unexpectedly. It wasn't pretty, but it was necessary to prevent this exact situation.

[plcnut]

We have been doing more testing, and it appears that there are some problems with the way that Datalogic has implemented the protocol. Maybe I am doing something wrong in setup, but won't know until Datalogic calls me back.

[BobO]

Could be more than one problem.

Without seeing a trace of Do-more to DataLogic comms, all I can do is guess, but I know for certain that we will terminate the connection after 60 seconds of no comms. If they don't catch that and close the connection, and try again on the closed socket, it'll time out.

In your PC-based server, it appears that the server layer has checked out, probably due to inactivity, but the socket is still active. That may be a problem in it's own right. Reagrdless, it does appear to me that DataLogic is expecting the connection to still be active after minutes of silence, and many servers will have already dropped the connection by then.