Hello,

we are in the development of electronics. We use Modbus to communicate between the PLC of our customers and our devices.
On some sites we have the problem that the communication is not very stable, and of course our customers are blaming us. But because this only happens on some sites we think that the most problems are caused by distortions or wrong cables (wrong diameter, not shielded, no twisted pair....)
The sites are spread worldwide, so it is not possible to go on site and check everything with Oszilloskop and/or Laptop.
Is there some kind of device which I can connect inbetween, which shows me for example how many telegrams are corrupted, how many are correct. Or any other information about the communication Quality?

A appreciate every information. Thank you in advance.
Best Regards
Vincenzo

 

Hello and welcome to Control.com!

One potential cause for the issues you are describing is a software bug or unhandled/unexpected fringe-case condition or timing condition that your Modbus driver does not handle correctly. However, these communication issues may actually be caused by lack of a proper RS-485 0V reference between all RS-485 devices on the bus.

Many RS-485 integrators, and even manufacturers that make RS-485 products, do not fully understand the common-mode electrical requirements of RS-485 networks. It is possible that an oversight in your device's RS-485 design is the cause of, or a contributor to, the issues some of your customers are seeing.

If you can provide a link to your device's product page or post a user's manual, or similar, that details the electrical connections for your product, I can review it for any common mistakes or potential issues. If possible, please also provide details on your RS-485 circuitry and how your customers wire their RS-485 network to your devices. Details such as whether or not your RS-485 circiutry is isolated, what other components or connections your RS-485 transceiver's 0V ground is referenced to (e.g. power supply neutral or ground, I/O common, etc.), what RS-485 connections you instruct your customers to make to your device (e.g. only 2 wires to + and - vs. 3 wires to +, -, and a 0V reference), how your device is powered (e.g. DC vs AC) and whether the power circuitry is common with the RS-485 circuitry or other circuitry that a user interfaces to. If you'd prefer to keep this information off the open forum, feel free to start a private conversation with me by clicking on the dialog boxes icon between the magnifying glass (search) and bell (alerts) icons on the right-hand side of the Control.com header on the top of this page.

On the topic of Modbus analyzers, almost all serial analyzers are going to require a computer to use, so if you are unable to have your customers use a laptop on site to troubleshoot the issue, I'm afraid you most likely won't be able to capture and analyze the traffic. But assuming you can have your customer put forth some effort into working with you to troubleshoot the issue, here are some serial analyzers you could use.

IFTOOLS MSB-RS485-PLUS
https://www.iftools.com/analyzer/index.en.php
https://www.iftools.com/shop/index.en.php

This hardware and software solution from IFTOOLS provides a comprehensive serial analyzer. Although, because of this, there is a little bit of a learning curve. In addition to capturing the traffic, though, it can also analyze the signal levels of the RS-485 signals. If your priority is to have a rock-solid analyzer and not have to worry about whether issues you are seeing are really there or are actually due to the analyzer itself (e.g. software performance, incorrect setup, etc.), then this is the one to use.

IO Ninja Serial Monitor and Modbus Analyzer Plugin
https://ioninja.com/
https://ioninja.com/plugins/serial-monitor.html
https://ioninja.com/plugins/modbus.html

This analyzer software can use any standard USB to RS-485 adapter. Although, they do have their own "Serial Tap" hardware for improved performance: https://ioninja.com/hardware/serial-tap-pro.html.

Electronic Team, Inc. Modbus Sniffer Software
https://www.eltima.com/modbus-sniffer.html

Another serial analyzer software tool that can use a standard USB to RS-485 adapter.

Wireshark Serial Adapter
https://github.com/jzhvymetal/WiresharkSerialAdapter

This is a free, community-provided tool that requires only a standard USB to RS-485 adapter. But as such, there is a bit more setup that must be done to ensure everything is configured properly and is capturing correctly. If this is not done properly, you may have inconsistent results that could have you questioning whether it's an actual issue on the bus or if its an issue with the tool. However, everything is conveniently shown in the README on this project's GitHub page and it does work well after you've configured all the appropriate settings.

You can take a look at this post to see the settings I've used successfully:
https://control.com/forums/threads/...-only-temporarily-with-plcs.55067/post-224393

ICC Mirius
https://www.iccdesigns.com/protocol-gateways/66-mirius.html

Full disclosure: This is my product. I am the RS-485 specialist at ICC and one of the engineers that designed and supports the Mirius. As such, I've encountered hundreds of Modbus RTU installations and have seen and fixed all manner of RS-485 communication issues.

Although the Mirius is primarily a RS-485 protocol gateway (converting between protocols such as Modbus RTU and BACnet MS/TP), it does have a serial capture feature built in. We have a tutorial video that shows how the capturing is done in conjunction with our ICC Configuration Studio software:

We also have another video detailing how to analyze the Modbus RTU traffic in Wireshark:

The Mirius could be a good choice if, in the future, you intend to allow your product to be connected to other PLC's or control systems that support protocols other than Modbus. And if you find yourself needing a gateway often, you may be interested in incorporating a protocol gateway chip directly into your device by using our PicoPort communication module (https://www.iccdesigns.com/single-chip-modules/30-picoport.html).

 

Hello jSchulze,

wow, thank you very very much for your answer.
This post gave me a lot of information and an perfect overview on the tools.
I need a little bit time to review all the links. And I think we can improve a lot with the information about the ground connection. This was something we hadn't in mind.
Unfortunately I cannot give you our scematics to review (companys law)...
But you helped me already. Thank you very much.

Best regards
Vincenzo

 

You're welcome. I'm happy to help.

I completely understand about company policies for schematics, however, that's not actually what I was asking for. Any publicly available documents for your device(s), such as a user's manual, installation guide, wiring diagram, etc. would be sufficient to achieve an understanding of your product and theorize possible issues that could arise when installing it into an RS-485 network.

Regarding RS-485 and grounding, here are some helpful references for you to review.

Why 3 Wires?
Here are some quick FAQ-style references explaining why the RS-485 common-mode reference is important.
https://store.chipkin.com/articles/rs485-cables-why-you-need-3-wires-for-2-two-wire
https://www.csimn.com/CSI_pages/RS-485-FAQ.html

RS-485 and Grounding
Here are some in-depth articles on the topic of RS-485 and grounding.
http://robustdc.com/download/index.php?file=AN005.pdf
https://www.hobbielektronika.hu/forum/getfile.php?id=172881

RS-485 Design Guide
This is a more comprehensive design guide from Texas Instruments for RS-485 that covers a lot of useful information for engineers designing RS-485 products.
https://www.ti.com/lit/an/slla272d/slla272d.pdf?ts=1770374593879

Recommended Device Wiring for RS-485 Networks
Although this is an addendum to the BACnet specification, since BACnet MS/TP runs on RS-485, it applies equally well to Modbus RTU. This is one of the most straight-forward publications I've found showing recommended device wiring for different circumstances.
https://www.ashrae.org/File Library...s Addenda/135-2008/135_2008_y_for_posting.pdf

 

Well, obviously a hardware solution is much more efficient due to its speed.

However, I made a software analyzer for Modbus RTU.

It won't indicate the signal quality, but you can find out, for example, where the problem is originating. For instance, the master sends and the slave responds; you can know if the master asked the question, if the question arrived, if the slave responded, and how long it took.

For you, the "Merged" table would be more interesting.

I made a simple example video with 2 simulators.

Note: Converters (USB/485) with FTDI chips are showing poor performance in the software, while the CP2102 or CH340 show good performance.

It's free, for Windows and Linux.


If you want to try it, it's available here.
https://github.com/ortegahernandes/ScanBus-BR-Simulator-Modbus/releases/latest


If you want to know more about:
https://github.com/ortegahernandes/ScanBus-BR-Simulator-Modbus

 

I recently updated the previous version of the Sniffer, which practically only worked with USB/485 converters that used CH340 chips. Now it should work with other chips (CP2102, FTDI (FT232rl, ...)).

 

Hi Vincenzo, unstable Modbus communication in the field is unfortunately very common, and you’re right that cable quality (proper twisted pair, shielding, correct termination, grounding) is often the real cause. Since you can’t visit every site with an oscilloscope, the most practical approach is to use a passive, inline Modbus/RS-485 analyzer/logger that can count valid frames, CRC errors, timeouts, and retries, providing solid data to show where the issue lies.
If you’re considering a firmware-based logging solution, here’s an active open-source Modbus RTU implementation and tools you may find useful on GitHub:
https://github.com/stephane/libmodbus
And for a related hardware reference, here’s the industrial RS-485 gateway project that shows how industrial serial communication can be monitored and managed:
https://www.pcbway.com/project/shareproject/Industrial_RS485_IoT_Gateway.html
Using an inline analyzer, along with proper termination and shielded twisted-pair cabling, usually makes it much easier to determine whether the instability is wiring-related or device-related.