Broadcast behavior

[hacst]

Hi. First a big thank you for this great tool. It is very powerful.

I am currently trying to emulate an existing Modbus RTU server whose client sends all commands using the broadcast unit 0 while the server responds from unit 1. When using ModbusTool Server allowing device id 0 will give me a response from that. Luckily the real device still accepts this, but ideally I want to replicate the original behavior. So I was wondering whether there would be a way to instead recognize 0 as broadcast and respond from 1.

My understanding is that servers are not supposed to respond to broadcast messages to begin with. However this seems to not be an uncommon pattern if it is known that only one server is on the bus. That way you do not have to bother with finding out the proper device id.

Maybe adding the standardized broadcast behavior with an option to allow responses anyways might be a way to go here? I already peeked at the code a bit but was wondering what would be the best way to add this to the tool or if there is even interest in doing so. Or maybe I'm completely on the wrong track and this stuff should be done in scripting?

[serhmarch]

Hello. Very good question about broadcast address.

In case of single Modbus TCP server (with IP address and port) unit/slave address is useless but some devices require to use hardcoded 0 in unit/slave address field of Modbus TCP network packet.

Need to think how to deal with broadcast address.

[serhmarch]

Its ok. I understood.

[serhmarch]

Already done.
But I'm going to make binary release this weekend so if you want to get software faster you can try to built it from sources.

[hacst]

That was quick. I tried the new version. As far as I can tell broadcast reads are now standard compliant and now longer get answered. I can also still get the old behavior by switching it off on the port. So far so good and a great addition. Have you given any thought about the non-standard behavior I was aiming to emulate? The original master issues a broadcast (unit 0) read and the slave responds from its address (unit 1). As mentioned I think it is not something they just came up with just for this device even though it is non standard. Fully understand if you consider it to exotic to directly support though. Maybe something possible to achieve through scripting?

[serhmarch]

Broadcast request is not intended for any response. It is indended for write/set some parameters/bits/registers (not for read, not for any response).

Modbus network is build on RS-485 physical interface (only 2 wires) in most cases.

Master/client initiate request and set unit/address for Modbus parcel and put it into the network. Many slaves/servers are listening the network and when one of them recognize that unit/address is indended for itself it parses the parcel and respond, other devices is simply ignoring the parcel.

So if all devices in the network are recognized broadcast address and will try to respond simultaneously it would be a disaster because they interfere each other and client simply will get a noise instead of response.

So broadcast is only one direction request.

Sorry but I have no idea in what case your proposal can be useful. If you think in such way you can define original address of the device then there is a such tool as Modbus Scanner, that have been already implemented in ModbusTools client.

[serhmarch]

And about scripting. It provides access only for internal device memory so you can't use some kind of filters/hooks or something to control network process.

[hacst]

As I mentioned I am not making up this behavior. It is an actual device being sold by a big vendor behaving and being used this way. I am trying to faithfully emulate that in a testbench setup. While investigating I have also read about others using this pattern if they know only one device is on the bus so they do not have to bother with addressing. Not sure how common it is in practice and as it violates the standard I fully understand if it is not something interesting to support in modbustools. Thank you again for you effort and the great tool.

[serhmarch]

Ok. I'll think about it. If it will be not very difficult to implement I will do something.

[serhmarch]

The original master issues a broadcast (unit 0) read and the slave responds from its address (unit 1).

I thought about it, but unfortunately it requires reworking the interface of the ModbusLib library subproject. So for now I'm putting it off for the future.

[hacst]

I understand. Thank you for your consideration.