(https://pps2.com/images/smf/mmint/comm_error.png)
Recently I was involved in the troubleshooting of multiple Modbus networks that were identical in devices, distances, programming, configuration, and termination resistance, but on some of the networks, there would be no communications.
Interestingly, when a Modbus test program (VBA Comms) replaced the existing Modbus master on the non-functioning network (using the same line driver used by the SCADA master), all the devices talked!
(https://pps2.com/images/smf/mmint/VBA_comms_good.png)
This pointed to something being wrong with the SCADA master.
But before you jump to that conclusion, allow me to complicate things by performing another test.
In this test the existing SCADA master was reconnected, but "known good" Modbus slave devices from functioning networks replaced the Modbus slave devices on the non-functioning network. The existing SCADA master was able to talk to them fine!
(https://pps2.com/images/smf/mmint/replaced_devices_work.png)
So, in the first case, it appeared that something was wrong with the SCADA master, but in the second, it looks like something is wrong with the slaves.
- VBA Comms as SCADA master
All slave devices worked on all networks
- Existing SCADA master
Some slave devices worked with all SCADA masters
Some slave devices would not work with any SCADA masters
What is going on?
The problem was believed to be (but not expressly confirmed as of this date) that the signal levels on the "bad" network was right at the ragged edge of being detectable at the slave devices.
Then why did the laptop running VBA Comms always work?
The belief is that the SCADA master, that master's line driver -- which turned out to be self-powered from current provided by that SCADA master -- and the slave device internal loading impedance all played a role.
The Rest of the Story232 to 485 converters that don't require external power supplies are less expensive and easier to install than converters that require external power. The "self-powered" units operate by extracting voltage from one of the 232 pins that is expected to be high (e.g. DTR pin (https://en.wikipedia.org/wiki/RS-232#Limitations_of_the_standard)) and use this signal to not only power the line-driver's electronic circuitry, but also to have enough left over to send a 485 signal (with sufficient amplitude) down the 485 network to all the connected devices and termination resistances.
Since 485 networks require signals greater than 300 mV and since most 232 ports provide more than 5-12 volts, normally there should be no problem.
The problem occurs when the 232 source voltage is current limited, or must provide current for other loads (which might vary, contributing to the maddeningly intermittent nature of this problem).
If the line driver electronics draws too much load, or if the load impedance of the network is too low, or if the sourcing 232 device voltage (or available current) varies, the voltage on the 485 network can be too low to be detected reliably by the other 485 devices. Recall that any voltages less than 300 mV (i.e. between -300 mV and +300 mV) are undefined in the 485 spec (https://en.wikipedia.org/wiki/RS-485).
Undefined voltages will result in symptoms such as "framing errors" on received messages.
For short networks (<1000 feet, 300m end-to-end), one quick fix is to remove one or both termination resistors. Removing the termination resistances will reduce the load on the biasing circuit in the line driver (232/485 converter) and the signal levels will increase, potentially fixing the problem, as it did in this application. Because of the intermittent nature and how long it took to resolve, the customer couldn't spend any more time performing "post-fix" voltage checks, so we are not sure how close to the 300 mV we were before and how much margin we had after.
If this happens to you and in the case you are using the Modbus MINT as a network slave device, you can detect this framing error problem by interrogating the "Table 6" registers within the mMINT using the VBA Comms (http://pps2.com/smf/index.php/topic,29.msg39.html#msg39) tool. The smoking gun is an increase in the number of
UART framing errors reported.
- Connect your computer running VBA Comms (http://pps2.com/smf/index.php/topic,29.msg39.html#msg39) as the Modbus master on the "bad" network.
Verify able to communicate to the mMINT.
- Press the "Send Reset" button found on the mMINT tab in VBA Comms (http://pps2.com/smf/index.php/topic,29.msg39.html#msg39).
This will reset all the error counters to zero (assuming you actually originally had good communications from VBA Comms (http://pps2.com/smf/index.php/topic,29.msg39.html#msg39) to the mMINT in the first place!)
(https://pps2.com/images/smf/mmint/reset_mmint_diag_regs.png)
- Disconnect VBA Comms (http://pps2.com/smf/index.php/topic,29.msg39.html#msg39) and reconnect to the existing Modbus master that can't talk to mMINT. Let it attempt to poll for a while (collect about 20-30 flashes on the Modbus Rx light on the mMINT).
- Disconnect the Modbus master and reconnect VBA Comms
- Press the Re-Read Diags button.
(https://pps2.com/images/smf/mmint/framing_errors.png)
- What values are the highest value?
If "UART framing error" is a large value, and assuming you have selected the proper bit rate in this program to match that of the master and the slaves, then likely the networking biasing issue is to blame. As mentioned above, if the network is short (<1000 ft, 300 m), remove one or both termination resistors as a possible work around
The proper fix is to use a line driver that can output sufficient signal. If the 232 device you have connected the line driver to cannot provide sufficient current, then substitute the line driver with one that is separately powered.