Hello,

I have been involved in a project which uses Modbus TCP to distribute data between a Compact PLC (Master) on its own network, a Momentum base with ethernet top hat adapter on its own network and a Quantum PLC/Citect machine on their own network. These three seperate networks are linked via 3 wireless units, 1 being the master unit (compact PLC network) and the other two being client bridges (linking the Momentum unit and PLC/Citect). This works fine except even though the signal strength is excellent at all times when I use my "ethereal" packet sniffer there are a lot of lost Modbus TCP packets/Retransmits/Packet queues out of order on the wireless network, which causes #COM on the Citect and triggers watch dog type alarms between the two PLCs.

I have tried the following:

Multiplex MSTRs so that they don't cause ethernet conflicts.

Slowed down all poll rates on the three networks so thats the traffic is reduced.

Slowed down the wireless links to 5.5 mbs (worth a try).

When I plug into the Compact PLC network directly (with my laptop)and run Concept/Citect, the comms are fine with no lost packets at all.

There seems to be an issue when the packets are converted to wireless.

Is this a common problem with Modbus? Is there a special wireless router needed to do this?

Any help on this subject would be greatly appreciated.

Thanks guys.

 

How hard is it to run the wires? This might be the simplest solution. Copper has a proven history while wireless is just being established as the "next best thing" but you have to wonder...

~Ken

 

Sounds like another good reason for not using wireless for a critical link. To me it sounds like a few packets are getting dropped on the floor because of noise or contention or whatever. TCP takes care of this by retransmitting and a capable node should handle this behavior gracefully. But if buffer space is limited or the interruptions are too long things get hairy.

Also with wireless you might get the same packet picked up by both nodes, by one node or by the other node. And if they do some routing they will try to help out and forward the packet which may well arrive out of order, delayed by the processing and retransmit time of the units. If you are writing a letter to your aunt or surfing the web this wouldn't be a big issue.

But if your device can't handle out of order packets or gets confused by getting the same packets twice you get results that are less than desirable. You will need some more sophistication someplace in the picture, either through something running a more resilient TCP layer or nodes that can be configured not to forward packets. The problem with most consumer gear is that nobody really knows
what the thing is doing, that is, it is not documented or configurable for
things like this. Pro gear might or might not be and is expensive.

You can probably dig and find out exactly what's happening and write software to work around it on Linux with source for the networking code, but then you have to have a box to run it on. Your best bet may be to look at point to point RF gear which doesn't broadcast in the strictest sense of the word. That way you might lose packets but you wouldn't gain them.

Regards
cww

 

I don't know whether this applies to your situation, but I worked on a project where we were using a Compact PLC with an NR&D CNOE module to send/receive data over Modbus TCP. We were using some remote I/O modules and a secondary master (in our case an HMI). We were having trouble with the remote I/O outputs not triggering when expected and discovered many ethernet packets being lost. We worked with NR&D and found they had some bugs in their software which they resolved with a firmware update (http://www.niobrara.com/). However, this firmware update only resolved some of the problem. The remaining problem seemed to point toward the CNOE module only being a half-duplex ethernet module. We believe the problem was with the HMI polling the PLC and the PLC polling the remote I/O, the CNOE module couldn't handling simultaneous sending and receiving.

Our solution was to get rid of Modbus TCP for our remote I/O and use a secondary bus protocol. I doubt that helps you, but if you're using a half-duplex Modbus TCP module, maybe you can change your configuration so you only have one master.