Nano10 RS-485 Modbus termination

[gxmpersonal@gmail.com]

I am working on an energy monitor project where a Nano10 is monitoring solar production and energy usage.

Most of the data and control is coming from ModBusTCP talking to a Schneider inverter. But we also need to know the power being used by loads back in the main panel. So we added a pair of ModBusRTU power monitor boxes. I tested them with their supplied app from a PC and they were reading the power and accurate to my measurements. So I wired them into the RS-485 port on the Nano10 PLC. I was not getting any replies from either power monitor. I even tried them one at a time with no luck.

When I connected a fairly long line to get the RS-485 data into my PC, I saw that the app was using function 04, so I modified the code to use 04 with the SETSYSTEM command, and also added SETPROTOCOL to lock it to ModBus mode. And it worked. Everything seemed perfect.

I disconnected my monitoring cable and worked on the code for a bit and after a while, I saw the data return from the power monitors quit again. I am only running 9600 bps over 6 feet of wire, and I have 150 ohm terminating resistors at both ends. When I connected the monitoring cable back up, it started to work again.

I think the power monitors are either very picky, or they may even have a slight offset. Any noise on the RS-485 buss must be causing framing errors. The U-485 adapter I am using for monitoring at the PC appears to be adding bias resistors to the line. So when that is connected and powered in the USB port, it all works. I am adding bias resistors in my system now. I probably would have caught this a lot sooner if it had quit as soon as I disconnected the monitoring cable, but it didn't, it stayed working for over an hour for sure.

I did quite a bit of looking online and even in here to find anything about unreliable ModBus RTU connections, and I finally found a TI article talking about biasing the network to ensure a stable state when the bus is not being driven. I hope this post can help others from having the issue I  had.

[support]

Thank you very much for sharing your experience which we are sure will benefit other users.

Some RS485 devices do require biasing on pull-up and down on its RS485 port to work properly. In most low speed and short cable applications the Nano-10 PLCs would not require biasing and it is likely that the power monitor is the party that requires biasing on its RS485 bus line.

Actually in Chapter 15.5 of the Nano-10 User Manual (please download from https://triplc.com/documentations.htm) there is a section describing the RS485 that also suggest using biasing resistors for more robust communication, as shown in the screen capture below:
 

[garysdickinson]

I have connected many Modbus devices to Nano-10s. 

If you are working with 6' of cabling at 9600 BAUD there is no need for termination resistors. Trust me on this.

I wouldn’t mess with the cable pull up/down resistors either.  The RS485 transceivers on the nano-10 are designed to bias the RS-485 bus so that the signal wires will not drift, when no device is transmitting, to a voltage that would be mistaken for the start of a character.  This is probably not your problem, either.

OK. What should you try?  I’ll give you a hint.  RS-485 is NOT a 2 wire interface.  All of the RS-485 transceivers must be referenced to a common signal ground to operate reliably.

I have worked with several devices that use an electrically isolated RS-485 interface. Many of these devices are 3 phase motor controllers sometimes called "inverters".  The RS-485 port on these devices are electrically isolated from both the high voltages as well as the 24V DC logic supply.

If your device(s) have isolated RS-485 ports, then you MUST connect the signal ground of your isolated port(s) to the “-“ power supply input of the Nano-10.  This is the third wire for RS-485.

If you are using a USB/RS-485 dongle there is a good chance that the RS-485 port will behave as if it is isolated.  I always connect the signal ground on the dongle to the Nano-10 power supply "-“. If your dongle does not have a signal ground connection then you should buy one that has this connection.

Regards,

Gary Dickinson

[gxmpersonal@gmail.com]

Thanks for the input. I had worked with RS-485 quite a bit in the past, but this was my first time setting up a new link in a few years. I never had a problem like this before. Most of the gear I used in the past had chassis ground referenced ports and with just a simple termination resistor at each end, we never had data issues on the buss. I am sure the issue is with the power meters and not the Nano10. Maybe they suffer from some offset, noise, or other issue, I can't be sure without digging into the circuit, but I can be sure that having the data lines fail safe biased cured my problem. Now that I am getting every data request, I am not going to dig deeper into them. They are cheap, and if this project works out well, we may upgrade to better components.

This time, I spent about 3 days messing around with the two power meters and the Nano10 trying to get reliable data. The part that made this hard to diagnose, was that when I would try to monitor the buss, it would start to work. The Nano10 port never seemed to have a problem, but the power meters just were either not seeing the requests, or the request was invalid due to a data reception error. When I first connected the buss tot he PC to monitor it, I was using the cheap RS-485 adapter that came with the power meters. This USB to RS-485 device supplied a mild bias, with just a pull down on the D- lead. It only has two terminals for the buss, and no signal ground lead. It worked ok when connected to just one power meter, but was not completely reliable with the 2 connected. The U-485 adapter that I purchased with my Nano10 made the buss completely reliable as soon as it was connected to the UBS port. Looking at my scope, I it appears to be providing bias to both data lines. Even with only the D+ and D- connected, it was instantly rock solid.

The power meters do have isolated ports. There is a tiny switching power supply to power the 485 interface chip and a pair of optocouplers to get the data from the logic to and from the interface chip. I did not measure any leakage current from the line measuring side to the interface side. I agree, the isolated port was part of the problem, but it was not the only problem. I did try tying the negative power supply of the Nano to the signal ground of the isolated port, but that did not cure the situation. Termination only across the two signal wires also did not help, but once the buss was biased, the data became rock solid.

The power meters even have the interface 0v signal ground and 5 volt available on the terminal block with the data D+ and D- data pins. That made it very easy to just add the resistors there on the unit at the end of the data buss. In normal operation, my data buss is only 6 feet. At 9,600 bps, I did not expect any issues with data. The two power meters are in a common box, with just a few inches of wire between them. The CT's to measure the current are remoted to the breaker panel. I did not want to place the electronics in the breaker panel and run the data in there. I only have the signal ground connected at one of the power meters, the other one only has the 2 data wires connected, at this time, and it is responding to every query and no data errors. I thought I might need to tie the signal grounds, but it has not shown to be an issue at all.

[garysdickinson]

Very good work at sorting the RS-485 communications.  This is a very old communication scheme and you have done some old-school trouble shooting.

The issue with the need to bias the RS-485 lines makes perfect sense. I have been lucky in that the external devices that I have worked with all used modern RS-485 Transceivers that didn’t require the biasing circuitry.

Gary d