Modbus on RS-485: a frame without data

Hi all,

I'm hoping there are some Forum members with Modbus RS-485 troubleshooting experience who can help me. I consider myself pretty good with RS-485 and with Modbus but this has me stumped.

I am troubleshooting communications between an Emerson DeltaV and multiple ABB protective relays on an RS-485 network. I am fairly confident in the physical layer; the wire is the correct impedance, the terminating resistors check out OK, and most importantly the waveforms look pretty square and clean at 19200 baud.

One serial module seems to "work fine", though I've been brought in after the fact and the working channel may have a lot of errors masked by occasional successes. The next serial module over stopped working entirely. The Statistics inside DeltaV explorer suggest that it is scanning but getting 100% error responses.

I'm using a Fluke 125 ScopeMeter to troubleshoot, and I can capture some entire Modbus packets that I can decode correctly, though I cannot tell if they from the Master or from a Slave. I definitely don't see typical "poll, then response" traffic that I see on the functioning channel.

What's mystifying me is what I've started to call the "burp".

It's an RS-485 signal that is of the proper voltages and of a specific length, but it's of the same voltage as an RS-485 "1".

I see a valid Modbus packet shortly after the "burp" but I can't tell if that's another Poll from the master or if it's somehow a response to the "burp".

The "burp" (now it's starting to look funny to call it that) is 4.16 milliseconds in length.

With 10-bit framing (8/N/1), 8 bytes = 80 bits = 80/19200 = 4.16 milliseconds. So it's the same width as an 8-byte frame, which would be the same as a simple Modbus RTU poll with an address, function, 2-byte offset, 2-byte value, and 2-byte CRC.

Am I just being a total newbie and missing something; Modbus doesn't use "break pulses" or "all 1's", does it ? There is no Start bit on this frame, so it can't be some kind of strange 255/255/255/255/255/255/255/255 value.

A picture's worth a thousand words, so here it is:



Any suggestions or experience with this sort of thing would be appreciated.

The 'break' pulse shouldn't be there

Isn't the break pulse generated by the Emerson Delta V? Slaves shouldn't speak unless spoken to. The problem with RS-485 is that only one device can be driving the bus at the same time. This isn't too different from DeviceNet or Profibus DP. At this point I would be looking that the RTS and CTS signals. This may be difficult if the serial devices are surface mounted. Normally when we are debugging we can look at code being executed from the inside. It is hard debug with just a fluke scope.

I agree that the slave device shouldn't speak unless spoken to, but what if that *is* the slave device trying to transmit ?

The next step is to disconnect all the slaves and see if this strange "frame" still shows up.

I am jonesing for the RS485/USB sniffer from FrontLine Test Equipment but I'm the Gulf of Arabia and it would take a too long to get one. I'm not sure that any analyzer could even show this "burp", but at least it would let me see the other data.

Ken,

If you're a newbie then there's little hope for me. Thanks for posting that question as I've had trouble with both modbus RTU and DeviceNet recently and look forward to the discussion.

Andy

When idle, why are the data+ and data- the same?

They are not at right level.
See this.
http://en.wikipedia.org/wiki/EIA-485#Waveform_example
Your signal doesn't look like this. Your signal doesn't look like anything I have seen before

It's not so unusual for Idle to be at about .7 volts, but it's definitely outside my experience for the data voltages to be way up high. There's probably some equipotential or common-mode problems on this network that I don't understand yet. The master, the slave, and the repeaters are all made by my competition.

I was using a dual-channel ScopeMeter with the common referenced to the shield wire. I'm going to see if the system drawings show a grounded shield or not, and try taking captures relative to the actual ground.

I've read in Profibus documents that the "proper" way to measure RS-485 is to do a single-channel measurement between Data A and Data B, since that's the way the nodes do it.

Here's what the actual differential voltage between A and B looks like for the same event.

A clue !

I've learned that some of the slave devices are ABB variable frequency drives, and those are simply daisy-chained over twisted pairs and terminated with an ordinary 150 ohm resistor at the end.

Some of the slave devices are Feeder Breakers, and those ones are connected using an EIA485/fiber-optic converter and a fiber optic "starcoupler", ABB product RER-125.

I haven't determined yet whether the troublesome network has fiber optic devices or copper devices.

My wild guess right now is that the fiber optic device is getting a slave reply over fiber but is somehow just putting the EIA485 side in an "OFF" state the whole time.

I'm going to go try to figure out exactly what's on this network

Always... no, never....forget to check your references

After a late night and a full morning they finally told me that when they were having all failure on the channel that the fiber optic multiplexer had been powered off.

That would have been pretty useful information.... last night.

This certainly doesn't explain this weird data pulse. But I guess that's going to remain a mystery for another day.

The word "bias" comes to mind. I'm too deep in doo-doo to find my notes at the moment, but I, too, suspect that the all positive range of your data stream is not kosher.

I seem to recall that B&B electronics (somewhere in Illinois) has an RS-485 "Guide" that has a couple pages on biasing.

I recall solving a "bias" problem some years ago by putting a resistor from ground to one side [(+) or (-)] of the 485 link.

I'll look later, Ken. Gotta run.

Dan

I'm not sure on the modbus standards but the voltage levels don't look right to me trying to find a good article on expected waveforms for the modbus standard but I do know if this was profibus it would be way off

danw said:

The word "bias" comes to mind. I'm too deep in doo-doo to find my notes at the moment, but I, too, suspect that the all positive range of your data stream is not kosher.

I seem to recall that B&B electronics (somewhere in Illinois) has an RS-485 "Guide" that has a couple pages on biasing.

I recall solving a "bias" problem some years ago by putting a resistor from ground to one side [(+) or (-)] of the 485 link.

I'll look later, Ken. Gotta run.

Dan

Click to expand...

I think this is the app note that Dan was talking about.
http://www.bb-elec.com/bb-elec/literature/tech/485appnote.pdf

http://www.lammertbies.nl/comm/info/RS-485.html#diff

this link has the electrical characteristics of Modbus should be in a range of 7 to 12 volts

If you have a 485 adapter, why not just use a program such as MDbus and capture the whole messages. It will be easy to find the issue then.

A data analyzer won't explain a "frame" with no data in it. In fact, I doubt this anomaly would even have shown up on an analyzer. The good traffic would have, of course, and that's where I could have probably distinguished Master from Slave traffic.

I actually don't have an RS-485 interface handy that will give me a passive way to listen to this network; my only network "sniffer" is an RS-232 unit and this system is pure RS-485. I'm a little out on the edge of the Empire right now and making do with the toolkit at hand. A FrontLine Test Equipment USB/485 sniffer is on my Christmas list.

RS-485 will work way down to differential voltages of 600 millivolts or so; I think the -7 to +12 volts are maximums that can be handled by the ICs.

I really like the B&B and Lammertbies links; I also enjoy the Maxim IC and TI documents on RS485 transcievers.