Visual RS-485 Grounding and Termination Differences

RS-485 bus grounding and termination seems like a magical rite at times. Some people get lazy with the details because buses often work even when done incorrectly. I had some untwisted, shielded AWG22 lying around, so I used it to show a quick comparison between bus wiring in a controlled environment. I used a single MS/TP BACnet controller and 120 Ω termination resistors. The cable is of inconsequential length and I don’t have any weird equipment near my desk, so the electromagnetic noise should be minimal.

Shielded, Grounded Reference, No End-of-line Termination

This is with a single controller and a tiny cable length. The only effects we see with a lack of end-of-line termination is higher amplitude signals (~7V peak to peak) and capacitance in the cable resisting voltage changes as you can see at any of the “corners” that get rounded off.

Shielded, No Reference, Terminated Shielded

Grounded Reference, Terminated

The terminated version of the same waveform is shown above in two versions: with RS-485 grounding and no reference. Peak-to-peak amplitude is about 4.5 V. Strangely, it looks like there might be more noise in the example with the grounded reference which is not all that implausible considering there are no big noise sources around besides the ancient electrical system in this building. It’s not a big enough difference to take seriously, though.

Note that the waveform is inverted – that’s just because I had the probes the other way. Sorry about that!

Please note that this is a simple look on a desk in a residential area. All of the important things to do with RS-485 buses really show up in larger systems with real electromagnetic noise. The lack of noise in these captures is not similar to real-world applications. I wanted to have this as a baseline for reference. If you want to see what happens when you don’t ground your bus when you need to, check out this post!

Modbus Is Hard, Then Tedious

Modbus is one of the simpliest protocols you’ll find in the field. It’s the closest protocol “to the metal” of the chip on a controller since it often just directly exposes the controller’s memory. There’s no point discovery here; there are no point names or descriptions to help you integrate. All you have are datasheets and fat-finger data entry. There are hardly even data types.

The labour involved with Modbus integration can be high since point configuration is so tedious. When working with a Modbus controller it is very important to have accurate documentation of its:

  • addressing convention,
  • register layout,
  • and data formatting descriptions.

Some controllers start their addresses at 1, others start at 0. Your front end will have its own convention that you’ll have to match up accordingly (off by one errors are pretty common). The register layout will show you the addresses of the data you want. The data formatting descriptions will tell you about the data’s “endianness” and data types; the modbus protocol is just a binary data storage and retrieval protocol, it doesn’t know what a integer or a floating-point number is and it’s up to you to interpret the results.

Modbus can be seen using RS232, RS422, RS485, or IP for connectivity. People frequently make the mistake of assuming one of the above when they hear a device is Modbus. If it’s RS422 and you didn’t plan for that, you’re going to have a bad time.

When getting documentation for the above from a vendor, make sure you get them to help you interpret it! Most communication cards that come with equipment are generic and apply to multiple applications, which means that much of the data available on those data sheets is meanless for your particular application. They should be able to go over the list and highlight points that actually will mean something in your case.

Once you’ve set up a modbus integration it’s robust and fast. Adding new points shouldn’t be too hard either. It’s the initial stages of poring over data sheets and the trial and error of data types that’s the hard part. Once you’ve integrated two systems over modbus once, you should be able to replicate that integration anywhere with relative ease depending on the tools you’re using.

I’ll update this post with links to more detail, especially around data types which are the trickiest part. I’m working on some straightforward real-world examples that should make it a bit clearer.

A Case Study on the Importance of RS-485 Grounding

RS-485 grounding is frequently missing from commercial automation installations. It’s especially egregious when you are using your shield as your signal reference, because that reference is now noisy as heck. The shield’s job to collect interference. It’s up to you to make sure that interference goes somewhere.

The Case Study

I was looking at the RS-485 (MS/TP BACnet) buses for variable frequency drives (VFDs) terminated on a BACnet/IP gateway today. Devices on this bus kept going offline and online periodically, so a bus issue was the first thing to look for. Below is what one conductor of the RS-485 bus looked like by itself on my oscilliscope:

VFDs are noisy. It doesn’t help that the bus cable goes through these before they terminate in the low-voltage side:

It’s going to pick up a lot of that interference from these high voltage things.

The cable is twisted pair and shielded, so interference on one conductor mostly cancels out the interference on the other one. Here’s what they look like together, and what a controller would see:

Much better, but that’s still very bad. This is because this cable is shielded, and the shield was terminated at the BACnet MS/TP to IP gateway in the VREF terminal. This is the reference “ground” that the A and B conductors are measured with respect to. The shield is going to pick up interference along the bus run, because that’s what it’s for. The interference is going to drain to this reference and throw off the voltage of the bus signal.

Here’s what the shield looks like by itself:

As you can see, I am measuring spikes greater than 1.7 V on the shield. This will throw off our measurement of A and B by the same amount, causing frame errors.

The Solution

Since this is a shield, I wired it like you’re supposed to. Let the interference drain to earth ground:

Now the combined signal looks like this:

Much better. Still, now I’m not using anything for a reference. Ideally the bus cable used would have a free conductor, but it doesn’t. I could earth-ground it too and do the same at all the VFDs in the field, but I don’t want a thunderstorm to blow up controllers. It works much better now, so I think I’ll just leave it as is. Not too happy about it, but not the worst outcome.

The Bus Problem Superweapon: The Oscilliscope

I had the opportunity to troubleshoot an MS/TP BACnet bus using my Rigol DS1052E oscilloscope. Oscilloscopes are much more useful for bus diagnostics than a multimeter. Although they don’t tell you where the problem physically is, they can immediately confirm that you are in fact looking at a bus fault instead of a software problem and also identify when it is corrected.

The Problem

The bus in question appears to have a short. Communication does still work, but it takes a long time to poll points or override them. I presume there’s a lot of error-correction and trying in the background making up for the bad bus on the platform I’m using here (Tridium AX).

You can’t really tell there’s a problem from the software side besides the slowness and some strange errors about frame errors printed in a log. With the oscilloscope I can see immediately that there is a problem and I know what conductor the problem is on. That doesn’t exactly solve it for me, but it’s a clear indication at least which has a clear, tedious solution.

Investigation

The picture above is a good-quality frame. There’s a bit of rounding from capacitance, but it shouldn’t interfere with communication as it’s quite minor. The square wave signal is clear and the peaks are consistent. I took this sample in the middle of the problem bus with the ground clips for both my probes on the reference conductor. I told my oscilloscope to invert one of the channels, and I am displaying above the addition of both. That’s essentially what an RS-485 transceiver will do in your controller.

The above is not a good frame. It’s not that clear that it’s bad. You can see a bit of capacitance, you can see that the peaks are not that consistent, and maybe a bit of noise. The total amplitude is lower than with the good one. I was surprised to see this result on the bad side of the bus, so I looked at the channels separately. Then, I saw what is clearly a problem – here’s one of the conductors (A or B) of the bad side of the bus:

Yeah, that’s not a square wave signal. That looks like a signal that wants very much to stay near to ground. I.E., this wire is shorted to ground somewhere. Given that this is an underfloor ventilation system and we have a lot of wires bell-tied to struts we get a lot of damaged cables when people are over-zealous with pulling.

I’ll update as I investigate!

The Solution

Yup, that conductor was shorted to the shield which is grounded. This is a floating floor system, and the bus is cable-tied to struts under the floor. It looks like someone pulled a little too zealously. Very easy to repair.