Two weeks ago, we presented an improvement of the Yoctopuce API enabling you to easily observe what happens on a serial line with a callback. Obviously, we hurried to integrate this in our ModbusTool application, which is now able to display the data that go through a Modbus line.
You may have guessed it, but the apparition of the registerSnoopingCallback() function is in fact related to ModbusTool and here is what really happened at Yoctopuce:
Team member 1: Not bad, this ModBusTool, but it would be even better if it could listen and decode Modbus packets.
Team member 2: Maybe, but it would be easier to code with a snooping callback system.
Team member 1: I dare you!
So, there is now a new "Snooping" tab in the ModbusTool interface which describes all the messages transmitted on the bus, that is
- The message timestamp
- The direction, that is whether the message was sent by the Yoctopuce module selected in section 1 of the interface, or by another device connected to the bus.
- The complete message, in hexadecimal
- The address of the Modbus device in question.
- The decoded message, which should allow you to understand what happens on the bus at a glance.
The new interface with snooping and decoding of Modbus packets
There are however a few limitations that you need to be aware of:
The message timestamps are not necessarily very accurate: they are based on the elapsed time measured between two consecutive messages. For technical reasons, Yoctopuce modules encode this value in 8-bit floating notation. Thus, the higher the number, the less accurate, and the maximal value that we can encode is 60 seconds.
As of now, only Modbus functions 1 to 6, 15, and 16 are decoded, that is:
- 0x01: Read Coils
- 0x02: Read Discrete Inputs
- 0x03: Read Holding Registers
- 0x04: Read Input Registers
- 0x05: Write Single Coil
- 0x06: Write Single Register
- 0x0F: Write Multiple Coils
- 0x10: Write Multiple Registers
If you know of a device using the others, we would be rather interested :-)
The Modbus protocol dates from 1979 and it shows: this protocol is not as clean as a modern protocol. There are ambiguous cases for which it's not easy to guess whether a packet is a command sent by the Modbus master or an answer. A typical case is function 5 which enables you to write a coil, the device confirms the operation by sending back the exact same packet. When the transaction is performed from the Yoctopuce module used by ModbusTool, we can get help from the transaction direction, but in the case of a pure listen where ModbusTool only observes transactions performed by third party devices without intervening, it's not possible to determine if the transaction is a request or an answer.
An ambiguity example of the Modbus protocol
Support of network hubs
While we were at it, we added the possibility to use a remote YoctoHub. To do so, you only need to run the executable in command line with the hub IP address as a parameter. You can find a confirmation of the used address in the ModbusTool logs. If you want to use a YoctoHub or a VirtualHub with IP address 192.168.0.12, for example, you must type:
C:\Program Files (x86)\Yoctopuce\ModBusTool\ModBusTool.exe 192.168.0.12
Using a remote hub
In the end, rather than distributing ModbusTool on the sly on the blog, we finally decided to make a proper installer and offer it directly on our tools page.
Now you know everything.