Some time ago, we explained how to query a MODBUS sensor with a Yocto-RS485-V2. But in some cases, you may want to monitor the measures which transit through a MODBUS communication without sending anything on the RS485 bus. It's also possible, and this is what we are going to explain today.
Principle
The principle of a passive listening on an RS485 bus is similar to snooping on an RS232 line that we explained in a previous post. But as an RS485 line is a bus and not a point-to-point communication, you don't even have to use an adapter such as the RS232-Snooping-Adapter: you only have to connect the Yocto-RS485-V2 in parallel on the RS485 bus that you want to monitor, and as long as you don't ask it to send commands, it only monitors the activity without influencing the communication between the other devices on the bus. Simply check that you actually disabled the line terminator on the module by setting the little switch to the OFF position.
The Yocto-RS485-V2 can monitor an RS485 line without impacting communication
Automatic analysis of the communications
If you know that the traffic on the RS485 uses the MODBUS protocol, you can configure the Yocto-RS485-V2 for it to spontaneously decode the messages transmitted on the bus and to provide the results through the genericSensor functions, as if itself had performed the query. This enables it, for example, to send the observed values to a web server with a simple HTTP callback. The automatic task edition wizard enables you to do this easily if you know the number of the queried register that you are interested in:
Defining a listening task for a MODBUS input register
If it doesn't work on the first try, it's probably because the device performing the query isn't querying the register that you expect or uses another MODBUS command. To solve this problem, start by checking in the status window of the Yocto-RS485-V2 that it actually sees the communication going through and that the messages are clearly identifiable, as below:
Trace of a MODBUS communication
In the definition of your task, go to the Use a custom protocol option to see the messages that the previously defined task expects to receive. In our case, we obtain this:
Messages corresponding to the defined task
We see that the messages expected by the automatic task correspond well to the traffic on the bus, which doesn't surprise us as the task works well. By referring to the MODBUS specification, we can easily decode the messages of type "read single input register".
In case of problems, it may happen that the register number is not the one you were expecting, or that the device performing the queries uses a MODBUS command to read several registers in one go. In this case, you can easily modify the listening task accordingly. In case of doubt, send us a message at support@yoctopuce.com and we will help you...
Particular case: chaining several Yocto-RS485-V2
It's important to note a specific use of snooping. Some customers asked us whether it was possible to use a Yocto-RS485-V2 to autonomously query about 20 MODBUS sensors and to post the measured values on a web server. However, the Yocto-RS485-V2 has only 10 genericSensors, which limits the number of registers that you can read and post autonomously.
The first solution that comes to mind is to use two Yocto-RS485-V2 which each query half the sensors independently from one another. But we can guess that in some cases this could cause collisions on the RS485 bus.
The correct solution consists in using two Yocto-RS485-V2, but to initiate all the MODBUS queries from one of the two modules. However, this module only analyzes and publishes in its genericSensors the answers provided by the first 10 sensors, while the second Yocto-RS485-V2 uses the snooping technique to analyse and post the answers provided by the next ten sensors. Thus, all collision risk is avoided. And this solution can be expended for even more sensors if needed...
