TX/RX control

[gunstr]

I have been using a modbus simulator for Windows PC via an USB RS485 interface. This is not working very well as the delay in those interfaces are too long. I was then thinking to use a Raspberry PI with a RS485 chip like MAX485 conneced directly to the UART as it would have much less delay.
When I was looking for a Simulator tool that could run on Linux I found this repo that looks nice. But using such an interface it's also necessary to control the TX/RX direction using a dedicated GPIO. Do you have support for that? I have not found anyting being mentioned in the documentation.

[serhmarch]

Hello. Unfortunately, ModbusLib does not have direct support for devices like the MAX485. It relies on the Linux OS layer to work with each serial device using a standard set of functions (read/write) in a unified way. To work with the MAX485, you need to create a separate program (in C/C++/Python) directly using the Raspbian interface for GPIO.

[gunstr]

Thanks a lot for a quick answer.
One option would be to use an RS485 circuit with auto direction - like the THVD1406. Are you aware if anyone have tested soeting similar with Modbus? I'm not sure if it will play well with Modbus timing requirements but maybe it could work...

[serhmarch]

If you think that problem is with timings on server (slave, simulator) side, you can download latest release for Windows and test it on existing hardware. ModbusTools server has parameter TimeoutInterByte (millisec, for port) which allows to set time between 2 consecutive bytes within single Modbus packet. It can be first simpliest step:
https://github.com/serhmarch/ModbusTools/releases

[gunstr]

The problem I have with PC/USB/Windows is that the roundtrip delay from request to respons I can see on the oscilloscope is more than 30ms. This severely limits the posssible throughput on the bus...

[gunstr]

I have now received an RS485 driver with auto TX/RX that I have connected to a Raspberry Pi. I have also successfully built the application and it's up and running. But I see a few problems I will need some guidance for how to fix. I have a modbus RTU network with one client and one server (both currently under development). My intention is to simulate a second server with this tool.

I have connected the RPi to the RS485 bus and I can see traffic. A few issues there but let's take that later.

The first question I have is how to configure the Modbus ID for the new device. In the library readme it is stated "Device contains settings for a single device (such as Modbus Unit Address, memory size etc)." but I cannot find the setting for the Device Address. Can you help?

[serhmarch]

You can try menu Port->Edit Device Reference or context menu for device within Project View

[gunstr]

Under Port I can see the menu "Add device ref..." and "Edit device ref..." - but when I click on any of those nothing is happening...

[gunstr]

I think I found the problem. You have to add the device reference first. I did the other way around and added a device first and then it was not attached to the port. I will create a new project from scratch and see if I can get it up and running

[serhmarch]

Device must be selected in the Project View list. Better to use context menu (right mouse button)

[gunstr]

Now up and running. So for future reference I can confirm that the library works well on a Raspberry Pi with an RS485 driver with auto TX/RX connected to one of the UARTs.

However, also with this solution there is around 50ms delay between RX and TX from this device on the physical bus. Looking at the ModbusTool log below the response is within 1ms why I believe the actual delay is related to Linux output buffering. Not sure if that can be resolved, maybe it is possible to flush the buffer after each modbus message is sent?

26.03.2025 23:41:02.178 'Port1' Rx: 01 03 00 01 00 02 95 CB
26.03.2025 23:41:02.179 'Port1' Tx: 01 03 04 00 00 00 00 FA 33
26.03.2025 23:41:02.253 'Port1' Rx: 0B 06 00 16 7F 00 48 94 0B 06 00 16 7F 00 48 94 0B 01 00 01 00 07 2C A2 0B 01 01 00 52 50
26.03.2025 23:41:02.254 'Port1' Error: Error(0x1000401): RTU. Wrong CRC
26.03.2025 23:41:02.378 'Port1' Rx: 01 03 00 01 00 02 95 CB
26.03.2025 23:41:02.379 'Port1' Tx: 01 03 04 00 00 00 00 FA 33
26.03.2025 23:41:02.554 'Port1' Rx: 0B 06 00 16 7F 00 48 94 0B 06 00 16 7F 00 48 94 0B 01 00 01 00 07 2C A2 0B 01 01 00 52 50

The server I have configured is given Address 0x01. @serhmarch Do you have any idea why the traffic to and from the other server on the bus (address 0x0B) is generating an error? It's good to have all traffic in the log but I would rather expect the actual content to be ignored. Is this a bug maybe?

[serhmarch]

Hard to say is it bug or not because input packet is analizing from start to end (including last 2 CRC bytes) and then lib is making decision to handle input packet or not.

Maybe to prevent such behaviour you can reduce Timeout interbyte for Port settings RTU mode to break a long sequence of bytes into appropriate individual packets

[gunstr]

I do not really understand what is the definition of the Timeout (inter byte) setting but when I decreased that from default 50 to 5 I could see on the oscilloscope that the response to messages were sent faster (around 8ms). From the result it seems more related to interframe delay an not so much inter byte (or character) timeout?

That change alone did not solve the problem, but when I also increased the interframe silence interval on the client and the other server on the bus from the standard 1750us to 10000us the log looks better and the communication between the nodes are working as it should.

Why both those changes are required is unclear but as you can see in the log below all traffic on the bus is now correctly broken down into frames and what is most important all frames with destination to the ModbusTool server (ID=01) is recognized and responded to.

Another reflection to the log is that the timestamp difference between the RX and TX for node 01 is 0ms although I could clearly see that the actual response delay on the bus changed from 50ms to 8ms when I changed the Timeout (inter byte). So the delay is probably not related to the OS buffering as I thought as the library settings obviously can impact the delay.

27.03.2025 10:53:19.621 'Port1' Rx: 01 03 00 01 00 02 95 CB 
27.03.2025 10:53:19.621 'Port1' Tx: 01 03 04 00 00 00 00 FA 33 
27.03.2025 10:53:19.641 'Port1' Rx: 0B 06 00 16 7F 00 48 94 
27.03.2025 10:53:19.653 'Port1' Rx: 0B 06 00 16 7F 00 48 94 
27.03.2025 10:53:19.665 'Port1' Rx: 0B 01 00 01 00 08 6C A6 
27.03.2025 10:53:19.677 'Port1' Rx: 0B 01 01 00 52 50 
27.03.2025 10:53:19.678 'Port1' Error: Error(0x1000102): Incorrect received data size

The reported Error for the response to the "ReadCoils FC" I think is not correct but it does not impact the overall functionality. Just as a test I changed the respons from the "0B" server to also include the start address of the coils and then the Error disappears. But as far as I can see in the Modbus specification the FC01 response should include the byte count and data only and no start address.

Anyway, I have something that works for now and once I replace the ModbusTool simulator for the "01" server with a real node I hope I can revert to the standard 1750us interframe silence.

@serhmarch Thanks for your support and maintaining this amazing tool.

[serhmarch]

Inter-byte timeout is a timeout between 2 consecutive bytes in a frame, after which the frame is considered complete and is passed to the next (higher) level for parsing (i.e., this is the same interval as 3.5 character periods in the RTU mode standard, but this interval can be configured in the program).

Unfortunately, modbus lib analyzes all incoming traffic, so sometimes it floods the log.

[gunstr]

What is the value of the setting referring to - is it milliseconds or characters? The 3.5T should be fixed to 1.75ms for speeds >19200kbps so to follow the standard should that settiing be 1.75 then as my bus speed is 115200kbps?

I was a bit puzzled by the default value of 50 when I created the port. I now found out that I can revert to the standard 1750us inter frame silence for the other nodes if I set the Inter-byte timeout to 1 (the GUI does not allow me to set it to 1.75).

It's good that all traffic is analyzed and logged, that is just perfect for debugging. But the actual error that was reported I beleive should not really be there as the respons as far as I can understand is correct.

27.03.2025 10:53:19.665 'Port1' Rx: 0B 01 00 01 00 08 6C A6 
27.03.2025 10:53:19.677 'Port1' Rx: 0B 01 01 00 52 50 
27.03.2025 10:53:19.678 'Port1' Error: Error(0x1000102): Incorrect received data size

[serhmarch]

But the actual error that was reported I beleive should not really be there as the respons as far as I can understand is correct.

Yes. You're right. This

27.03.2025 10:53:19.677 'Port1' Rx: 0B 01 01 00 52 50

is the answer from another device (and it is correct) but lib consider it as request and then try to parse it and find out that it is incorrect as request (but correct as response). A lot of work is needed to change such behaviour so I need to think how to do it at first.

[gunstr]

is the answer from another device (and it is correct) but lib consider it as request and then try to parse it and find out that it is incorrect as request (but correct as response). A lot of work is needed to change such behaviour so I need to think how to do it at first.

Of course, as a "sniffer" there is no way to distinguish between TX and RX - did not think about that...

For a better understanding I would appreciate if you can also comment on the the Timeout (inter byte) settings questions:

I do not really understand what is the definition of the Timeout (inter byte) setting but when I decreased that from default 50 to 5 I could see on the oscilloscope that the response to messages were sent faster (around 8ms). From the result it seems more related to interframe delay an not so much inter byte (or character) timeout?

What is the value of the setting referring to - is it milliseconds or characters? The 3.5T should be fixed to 1.75ms for speeds >19200kbps so to follow the standard should that settiing be 1.75 then as my bus speed is 115200kbps?

[serhmarch]

Timeout interbyte is time (in milliseconds) between 2 consecutive bytes when processing input network packet.

When device is startint to listen port it is waiting for first byte(s) of the input network packet.

If byte(s) arrive within Timeout first byte time (millisec) it is begining to listen next byte(s) of the packet but with new timeout: Timeout interbyte.

If next byte(s) of the packet is arriving within Timeout interbyte time this byte(s) are considered to belong to the current (processing) packet and are added to the current buffer of packet. Then the process of waiting for the next bytes starts over for the same Timeout interbyte.

This process continues over and over until will be no more bytes within Timeout interbyte. Then the input packet is considered complete and is passed to higher level for further processing.

Modbus protocol specification is more complicated and have 3 intervals:

• [0:1.5T] - byte(s) belong to the current packet;
• [3.5T:inf) - byte(s) belong to the next packet;
• (1.5T:3.5T) - error;

Modbus Tools behaviour is simplier (tib - timeout inter byte):

• [0:tib] - byte(s) belong to the current packet;
• (tib:inf) - byte(s) belong to the next packet;

[gunstr]

Thanks for the explanation.

So the Modbus Tool does not currently distinguish between T1.5 and T3.5 as per the standard, probably not a big limitation. What I saw when playing around with the setting is also that whatever number is set for Timeout (inter byte) seems to be used on the RX side as a Timeout and also as a delay on the TX side to set the "response delay". This is correct as a "minumum response delay, but at least in my installation I got a default setting of 50ms that led me to think that the setting was more intended as a TX delay simulation.

A suggestions for future improvements - it could be good to set the interframe timeout in microseconds to allow configuration according to standard 1.75ms. Or maybe just a checkbox to use delay according to standard irrespective of the bus speed and use T3.5 for low speeds and 1.75ms for datarates above 19.200kbps and use the numeric setting as a manual override for test purposes. Possibly also a separate setting for TX delay to emulate slow responding servers.

I now have a much better understanding of the library and thanks again for your awesome work and great support.

[serhmarch]

You can try new version.

Unnecessary error messages should disappear.

[gunstr]

Great, thanks a lot. I will for sure try the new version but it will take a few weeks until I have access to that lab setup again.

[gunstr]

Took a little longer than expaced but now I have upgraded to the latest release and can confirm that the responses from other devices are logged correctly without any error.

Thanks a lot, it's an amazing tool you have developed!

[serhmarch]

Thank you. I'm glad to see that the program is useful.