We are commissioning a tank level radar project and we are having some intermittent modbus failures (no slave response) when we poll more than one device on the loop. We can talk perfectly to each individual device if only polling that one device. but when we try to talk to all 5 devices on the loop with PLC (quantum 584 through a converter) master polling, the first device in line (daisy chain) has no issues at all but the rest show intermittent failures (lack of slave response about 25% of the time, this varies slightly for each device). The line terminations have been respected and the grounding configuration appears to be OK. Any help at all would be appreciated.

 

You might want to try a datascope and see where you are dropping packets.

Regards
cww

 

I don't have a datascope but I do have an update. We tried such things as increasing the wait time for slave responses and time between polls with some success.

In a move of desperation we went from 9600 bps to 1200 bps and we have not seen a single error in a few thousand scans, although a little slower data update then ideal it will work.

I wish we could claim success but it still bugs me why the 9600 baud rate didn't work. Any follow up replies / ideas would be great. Thanks...

 

Better to share your overall configuration. What Modbus protocol was selected (TCP or RTU)? and Did you proper setting the converter configuration?

 

Please verify what you mean by master polling. Are you addressing each slave and sending a query or are you sending a broadcast message (address 0)? Slaves should not respond to a broadcast message.

 

They are all E & H tank side monitors attached to tank top radars. We are communicating directly to the tank side monitors each with it's own unique address that we had to configure into it. They are all polled in sequence. We are running 2 wire RS485.

While troubleshooting the circuit we isolated just 2 monitors. So in this case all we had was the PLC to RS485 to RS232 converter then out to these devices. We have termination resistors at the converter and at the second tank.

While having only 2 devices on line the first would communicate perfectly but the second would have many slave failures. We tried taking out the termination resistors and tried different grounding configurations with no luck. (engineers for the project only specified a single shielded twisted pair out to the field and to each device therefore all we have to work with for grounding is the instrument tech cable shield and the drain wires).

Hope this helps to keep the ideas coming. Thanks again...

 

What I would look for is a timing problem. It could be at either the Master or the Remote.

Remember that with a "two wire RS485" (there is no such thing as you have discovered) that communication in both directions takes place on the same two wires. Ignoring potential common mode issues because there is a "weak" ground the remaining problem almost certainly has to do with the timing of who" is really in control of the signals on the wires.

Look for configuration parameters regarding "on" and "off" delays. Make sure that the "slaves" turn off their drivers after an answer before the "master" sends out its request to the second slave. If not, the second slave will not be able to "hear" the master's request and will not answer.

Could be other issues but I would bet on a timing problem.

 

Are the devices, including your converter, 2-wire or 3-wire 485? I am assuming that the cables daisy chain from the converter to the last device. Connect all the shields together, but to earth at one end only. What kind of messaging does the PLC use? Does it wait for a response to a query before it queries another device?

 

Jerry, good point, I'll check the driver config but I would think the default should be reasonable in this regard. If incorrect would this still apply when I slow the baud rate down?. Remember, slowing down the baud rate fixed the errors.

Highland, I think they are 2 wire? Although the repeater manufacturer shows a termination for a third wire (labeled ground) and also a spot for the shield. This also is confusing. We have played with the response time delay and polling delay settings in the PLC bridge mux. The PLC sends the request, the bridge mux will wait for a prescribed time (we'll say 1 second) then shows an error if no response. The PLC does not poll again until it either receives the response or an error. It then waits for the polling delay time we also set before asking the next tank monitor.

 

Your statement "In a move of desperation we went from 9600 bps to 1200 bps and we have not seen a single error in a few thousand scans, although a little slower data update then ideal it will work." typically indicate cable problems. The most common are locating the terminating resistance in the wrong place (refer to your vendor documentation for this), wrong resistors for cable (must be matched to your cable's characteristic impedance), or your cable is too long. If none of these are the case, you might consider changing out you 485/232 converter. Some of the cheaper ones may not be up to the task if you have a good distance to go (choose an isolated one based on good engineering practice for this type of installation).

William (Bill) L. Mostia, Jr. PE
Sr. Consultant
SIS-TECH Solutions, LP
Any information is provided on Caveat Emptor basis.

 

As I explained on another post a laptop with an RS-232 serial port can be used to monitor RS-485 traffic.

Connect Rx of the laptop to the negative RS-485 line and pin 5 to ground.(connected to the positive line all you see is garbage).
For RS-232 I never try to remember which pin is Rx and which is Tx, I just measure the voltage from pin 5, Tx is the one with voltage, Rx is close to zero.

As someone else pointed out it sounds like the slave may be tying up the line by not switching off its driver quick enough.

 

Thanks Roy. Yes I have been talking to the devices through my laptop using modscan 32 though a portable converter, however if I'm not monitoring the errors everything looks OK. Modscan does not show an issue. Knowing the reliability is questionable is why I've had to lower the baud rate.

 

> Thanks Roy. Yes I have been talking to the devices through my laptop using
>modscan 32 though a portable converter, however if I'm not monitoring the errors
>everything looks OK. Modscan does not show an issue. Knowing the reliability
>is questionable is why I've had to lower the baud rate.

Because you have a wiring problem.

 

The PLC is perhaps polling a subsequent device a small bit too fast, increasing the error rate.

The Modicon PLC should have a line-turn delay (I forget what old ModSoft called that), which you could set to 10msec or 25msec. This will slow down each new request, which might allow line noise (reflections) to dissipate, which might reduce the probability the slaves have a CRC error on the new request.

- LynnL, Digi.com

 

The symptoms you describe sound like a classical transmission line impedance mismatch. Connecting an oscilloscope to check the waveforms would be a great way to verify your wiring.

RS485 is designed for 120 ohm transmission lines so the cable you use should be twisted pair wire with a characteristic impedance of 120 ohms. Sometimes its hard to get 120 ohm cable so you may have to opt for 100 ohm - then your terminating resistors should be matched to the cables impedance.

Each time there is a break in the wire (at each slave, or anywhere the wire is nicked, or at each terminal block) there is an impedance discontinuity that causes an incident wave to reflect back up/down the wire. By slowing your baud rate down, you allow the incident waves more time to travel up and down the wire until they fully dissipate and every slave then sees reasonable waveforms. When you run faster baud, there is so much incident wave energy traveling up and down the wire that it all turns into a big mess.

Modbus / RS-485 does not handle a star topology well at all. Every stub (tap into your slave) of any length causes a large amount of incident wave energy: your stubs must be short to avoid this effect.

So the ideal wiring configuration of RS-485 is a wire to each slave (with no stub or tee), then a wire that goes directly from that slave to the next (again with no stub or tee). All the way to the final device that has a terminating resistor matching the characteristic impedance of the twisted pair wire.

 

Concerning the transmitter.

Poll delay: delay between two polls.

Silent Time or Write delay: will be the amount of time between the reception of a slave message and a new request. This is important for SLOW Slave (the slave need more time to process is buffer). Below the sequence description:

1) The master send a request to a specific slave 01 : Q01

2) All slave receives the request : the message Q01 are in each slave buffer.

3) Slave 1: OK, this is for me. Slave 1 take a time to process his buffer. Then generate a answer. During the same time, the other slaves do the same and will clear the buffer. No problem until now.

4) Slave 1: transmit the Answer A01 to the Master but also to each other Slaves.

5) The master (more powerful than the little slave devices) will analyze the buffer and will transmit the request to slave 02 without any delay (no silent time): Q02.

6) At this time: Slave 2 have the answer from Slave 01 and the Request Q02: A01 + Q02. Slave 2 will not understand this message and won’t answer.

7) At that time, Slave 2 doesn’t answer and the Master will wait the timeout before a new request. As the timeout is about 2000ms, every Slave have enough time to clear his buffer.

8) Request Q3 will be send and Slave 3 will answer to the master.

Solution: For slow Slave, the master need to wait a time after the reception before sending a new request to the slave.