Modbus RTU

Hi,

My company are producing their own controller for their alarm system. It has a lot of ports with different types of interfaces. One of them is port for Modbus.
We use Modbus towards different external systems. On one project we are supposed to use Modbus RTU with 25 Modbus RTU slaves. They are all Siemens slaves, a few frequency drives, but mostly Simocode starters.
It is unusual for us to use this many slaves. We usually only have one node that we receive and write all the data for. So point to point and not multidropped slaves.

The problem we are having is that we experience packet loss. We have tried all sorts of tweaking and we are currently changing cable. The customer is installing a two-wire profibus cable. Previously it was just a two wire twisted cable.

I doubt this will resolve anything, because to me it seems as if it is something wrong in the messages that are being transferred. As if our Modbus format is not compatible or something with the slaves.

Regardless if this is the case, how do parties usually resolve interface issues if it is something detailed in the payload of the Modbus messages that is causing issues. I know that if there is an issue with noise etc. it can be traced using scopemeters, but what if there are protocol differences because of different vendors? How can those be pinpointed?

Thanks for any answers!

Do you lose entire replies or part of them, if it is the first thing may exist some problem with the synchronization request-reply, if it is the second one it could be that you try to use a baud rate too high, or there is some noise problem, or perhaps there are missing terminal resistors at the ends.

A transmission through two wires is half-duplex, it can not transmit and receive at the same time and therefore each time a request is sent it must wait to receive the reply before sending another request.

Some of the replies work, so there is some communication. However, there are packet losses on some of the slaves. It seems a bit random. We scoped the communication and from what I saw the pulses looked smooth so it doesn’t look like signal issue. We detect packet loss if we don’t get replies to request within a certain time

What's the physical layout? A single wire daisy-chain?

Typically, one would try to isolate certain part of the network and see if the issue can be isolated while using a modbus master simulator then go from there.

Modbus RTU can't send new query before old one is timeouted or reply. (half duplex).
Is this taked to account on master side.

ModbusRTU makes use of silence periods to determine end of packets and also used to clear receive buffers. Some devices adhere very strictly to this and may ignore a packet because it cleared the buffer prematurely from the silence.

Does you system honor the 3.5 and 1.5 character of silence rules?

Make sure your modbus rtu network is terminated correctly.

The master does wait for reply from each node according to a set timer. In the meantime it tries to request from other nodes.

I’m not sure about silence time, since I’ve never heard of it before.
Do you think issues like that can occur when the master is not from same vendor as the slaves?

We have checked network both with and without end resistors. No difference.

An RS485 network is supposed to be able to support up to 32 devices before you need a repeater. At 26 devices you're getting close to that limit. If your termination isn't optimal or the impedance of the drops is off, your network may not support the maximum number of drops.
Also, your total cable length can't exceed 4000 feet.
You may need a repeater.

1. Is there a signal ground wire as well as the A/B driver lines? Not a shield, but a 3rd signal ground wire?

2. The polling rate of the master on a multidrop daisy chain with many slaves can only be as fast as the slowest slave's response.

The master almost always has an adjustable time-out delay, which is the wait-for-a-reply period before a poll to the next slave is initiated. Have you increased the time-out period to see if that allows a slow responding slave to gets its message out in time before the master sends again?

3. Steve Bailey speaks from experience. If it were my network, I would put an isolating repeater half way down the line and see if the situation improves.

1: No, there is no 3rd wire signal ground, although we did test with this but no improvement of the packet losses. Makes me question, if modbus is 485 and sometimes used with A/B and signal ground, why does profibus not ever use a third wire signal ground when it’s also 485?

2: Yes you’re right, and we have tried to change this parameter up to 100ms. Did not improve anything either.

3: The closes node with issues is only approximately 60 feet away, so I don’t see the need for a repeater.


Thanks for all your comments

Oh, this is a classic problem.

With 98.4% certainty your problem is that you haven't installed any bias resistors.

In a point to point configuration 4 wire configuration the transmitter on both the master and the slave are driving the bus into a known state.

In a multidrop configuration nobody is driving the bus between requests and replies. The RS422/RS485 drivers are in tri-state mode. That means the bus is in an unknown state. That makes it extremely sensitive to interference so you will get lots of ones and zeros which will trick the receivers into looking for messages which don't exist and miss the ones that do exist.

Bias resistors will put the A/B side into a known state. One resistor will pull up one wire to +5V and the other will pull it down to 0V. With the standard termination resistor in the middle.


Image from http://www.ni.com/support/serial/resinfo.htm

Quality RS485 converters have these bias resistors already installed for multidrop so you don't have to put them externally.
Actually, your company should have had them as well on your modbus. It's a hardware design mistake to not include them on a multidrop configuration.

Pete.S. said:

Oh, this is a classic problem.

With 98.4% certainty your problem is that you haven't installed any bias resistors.

In a point to point configuration 4 wire configuration the transmitter on both the master and the slave are driving the bus into a known state.

In a multidrop configuration nobody is driving the bus between requests and replies. The RS422/RS485 drivers are in tri-state mode. That means the bus is in an unknown state. That makes it extremely sensitive to interference so you will get lots of ones and zeros which will trick the receivers into looking for messages which don't exist and miss the ones that do exist.

Bias resistors will put the A/B side into a known state. One resistor will pull up one wire to +5V and the other will pull it down to 0V. With the standard termination resistor in the middle.

Image from http://www.ni.com/support/serial/resinfo.htm

Quality RS485 converters have these bias resistors already installed for multidrop so you don't have to put them externally.
Actually, your company should have had them as well on your modbus. It's a hardware design mistake to not include them on a multidrop configuration.

Click to expand...

Thank you for that information.
I will try adding this to the network.
We sometimes use 485/485 or 232/485 Phoenix contact converters. I will check if those have these internal resistors for the balancing.

Any idea if there are devices to purchase for specifically this balancing purpose?

this is boxed model, but wih couple resistors and 5vdc suply you can do same

https://www.phoenixcontact.com/online/portal/fi?uri=pxc-oc-itemdetail:pid=2313944&library=fifi&tab=1

And of course, you have allready tested with 120ohm resistors on both end of bus.

what I have noticed, if there isn't bias when needed any of querys don't work

Thanks,

I have this one available,

https://www.phoenixcontact.com/onli...k=P-08-13-02-02-01&tab=1&selectedCategory=ALL

and from schematic of circuit it looks like the balancing is installed internally.