Hello All! I am new to this forum but have been doing a lot of reading and there are some very smart people posting here. I figured I would throw this one out there to see what comes up.

I have been in the industrial controls and automation industry for 20+ years and works with many different Modbus devices over the years. I recently got a YSI IQ SensorNet 284 controller for a client with the intent of communicating to it via Modbus RTU with a Productivity 1000 PLC. We have done Modbus RTU successfully to many different devices in the past with this PLC.

We setup the 284 on the bench to do some initial testing and establish communications. Initial tests were being done from a laptop running ModScan, Modbus Poll, KepServer, etc. We tried several different USB to 485 converters, ones we use in the field all the time, but could not establish communication. We tried connecting the 284 to the PLC and could not get Modbus to work their either. We also tried some older 232 to 485 converters and they would not work either. We then tried an old moldy Microflex USB to 485 converter and it worked great! To add to the mystery, the Microflex converter would not work with other Modbus RTU devices that we have in the shop - thermostats, meters, sensors, etc. Probably why it was sitting on a shelf collecting dust!

Why is this? Why does Modbus RTU communication this YSI 284 controller only work when it is connected through the Microflex USB to RS485 converter? What I know about the Microflex converter is that it does not have a 120 ohm termination resistor, it does have the A and B lines biased with 1.2k resistors, and the actual 485 chip is a MAX 13487. Some of the other converters we have can have these features (bias, terminator) turned on and off but it does not seem to make a difference.

Any ideas would be much appreciated!

- Reuben

 

From your details and tests, this appears to me to be an electrical issue. My first two thoughts are either grounding (i.e. RS-485 common-mode (0V) reference) or something to do with termination/biasing.

Starting with grounding, are you wiring your RS-485 connections using 2 wires or 3 wires (+, -, and ground reference)? The IQ SensorNet controller may be non-isolated, meaning its RS-485 circuitry's ground reference is common with the power supply. In the IQ's manual, if using line power, it specifically states to cut off the ground wire of the power cable, so the IQ would not be grounded. Assuming the IQ uses the neutral line as its ground reference, this could be what's causing the issues you're seeing, as that neutral wire could be fluctuating in voltage compared to the other RS-485 equipment, especially if you're not wiring a 3rd wire for the ground reference. Does it make any difference if you use your USB to RS-485 adapters on a laptop that is running on battery power only?

For termination/biasing, does the IQ have built-in termination? You may be able to determine this by using a multi-meter and measuring resistance across the + and - terminals when power is off. If you have an oscilloscope, you should easily be able to tell if this is a termination/biasing issue based on where the signal levels are and the voltage swing of the + and - lines with respect to the ground reference (assuming you know what the IQ actually uses as its RS-485 ground reference). You need to ensure that the differential voltage (voltage of the + signal with respect to ground minus the voltage of the - signal with respect to ground) is greater than 1.5V when either of the devices is transmitting, and that the RS-485 differential idle voltage (when no device is transmitting) is greater than 200mV, as a voltage difference less than that is a violation of the RS-485 spec. You could, alternatively, measure the differential idle voltage using a voltmeter when no devices are transmitting. However, a voltmeter cannot be used to accurately measure the voltage swing when the devices are transmitting.

Since you have both a working setup and a non-working setup, you should be able to compare the two scenarios while measuring the signals with an oscilloscope. One word of caution though, if at all possible, use a battery-powered oscilloscope or one that can be USB powered from a laptop running on battery power. Otherwise, connecting the oscilloscope can change the ground reference of the equipment you're trying to measure.

 

To reiterate one of Jschulze's points: I've had issues with USB/serial converters communicating depending on whether the laptop was plugged into AC power or not.

This kind of issue is why I like Ethernet over serial; Ethernet is, by design, isolated.

I have to admit that I've run into exactly the same thing, but my curiosity has never welled up to the point where I wanted to figure out exactly why the bad boy converter doesn't work like the others. Please keep us in the loop if you make the effort to discover the cause.

 

Another, although less likely, cause of what you're observing could be that the IQ SensorNet's RS-485 circuitry is partially damaged - either transmitter damage, unable to sufficiently drive one or both of the RS-485 lines, or receiver damage, where the device is presenting a very high load (partial short circuit) onto one or both of the RS-485 lines causing the other RS-485 device to be unable to sufficiently drive the overloaded bus.

Similar to the latter scenario, too many termination resistors installed (for example, adding a resistors when the devices already have internal termination enabled) or too low of biasing resistors installed (under 375 ohms) can also overload an RS-485 bus.

 

Thank you both for your thoughts and comments.

The 284 is running off of 24vdc and is does not have anything connected to the ground terminal. All of the tests with a laptop were with the laptop running on battery. I don't think there was any issue with grounding. The test to the PLC was done with only 2 wires - A and B.

I hate to say it but this looks like an RTFM issue. I think my tech just overlooked the section in the manual where it says if you have parity set to "NONE" then stop bits should be 2. We had stop bits set to 1. I think once we had the initial communication issues, we just started trying multiple different converters and hoping that we would find one that works. We never went back to the fundamentals and confirmed that the port settings were properly configured.

Not sure why the Microflex converter worked with stop bits set to 1 but it does. It also works with stop bits set to 2. All of the other converters, including the PLC, only work with stop bits set to 2. Honestly, I can't think of a device we have connected to in the past that required stop bits be set for 2. I have seen plenty devices that needed parity set to none or even or odd but no stop bits = 2. Termination resistors didn't make a difference either. On/off, one end or both ends, all variations worked. Now granted this test is only over a 5' cable at 19.2, if the cable was a few 100 feet and the baud rate was much higher the resistors might be required. We will see once the device is actually installed in the field.

Thanks again!

 

Thanks for the update. So the issue was simply selecting the wrong number of stop bits (1 versus 2) in the communication settings.

Did you confirm again that the Microflex converter works with 1 stop bit to rule out the possibility you had simply selected 2 stop bits when using that converter?

If so, I suspect the reason this converter works with only 1 stop bit may be due to the MAX 13487's "AutoDirection" feature (details can be found in the datasheet https://www.analog.com/media/en/technical-documentation/data-sheets/MAX13487E-MAX13488E.pdf). Essentially, the transceiver automatically generates the RS-485 Driver Enable signal from the Data Input and current state of the A and B lines. This is different from almost all other RS-485 transceivers, where there are dedicated Data Input and Driver Enable inputs.

The effect of the above, is that when the MAX 13487 drives the bus, it may continue driving the bus for a period of time after it has finished transmitting a character. Assuming this additional drive time is greater than one bit time, this would be no different than a device transmitting 2 stop bits (as the stop bits are sent last). From a receiving standpoint, a receiver configured for 1 stop bit will always be able to successfully receive a character that was transmitted with 2 stop bits (the extra stop bit simply looks like an idle bus). This would explain why this converter, and only this converter, works with only 1 stop bit although the 284 requires 2 stop bits.

 

Good thinking jschulze. I noticed that the Microflex used the MAX13487 chip and the other device used either a regular MAX485 chip or "mystery" chip. I'm just not smart enough on a chip level to understand all of the stuff on the data sheet. I did read most of it though! The Microflex does work when set for either 1 or 2 stop bits - 284 is always 2 stop bits.

Thanks again for the follow up and useful info.

 

One word of caution with that Microflex converter, assuming my theory is correct. I would be wary of using it for any BACnet MS/TP communication or testing, as MS/TP is very timing critical and has a specified maximum drive time.

 

Thanks for the advice. I plan to stay away from BACnet in any fashion in the future! Not good for industrial automation.