A modbus rtu slave should not response on a broadcast message #153

Closed
jwittebo opened this Issue Oct 18, 2013 · 3 comments

Comments

Projects
None yet
3 participants
@jwittebo

Following the spec http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf section 2.1 In Broadcast mode, the master can send a request to all slaves. No response is returned to broadcast requests sent by the master.

Unit test 2/5 Reply after a broadcast query should fail if there is an response.
If all slaves do a response (which is about at the same time) there are collisions in rtu mode.

Update of the libmodbus library is required.

@ghost ghost assigned stephane Jan 28, 2014

mhei added a commit to mhei/libmodbus that referenced this issue Sep 27, 2014

Do not reply on broadcast requests (fixes #153)
According to the Modbus specification
(http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf, section 2.1)
a Modbus RTU master can send a broadcast to all of it's slaves. This
broadcasts can only be write requests as otherwise collisions could
occur, eg. on a RS-485 bus.

When receiving such a broadcast, the slave should process the request as
usual, but must not reply anything, neither a normal response nor an
exception reply in case of an error.

Adjust the unit test for this case, too.

Signed-off-by: Michael Heimpold <mhei@heimpold.de>

mhei added a commit to mhei/libmodbus that referenced this issue Dec 1, 2014

Do not reply on broadcast requests (fixes #153)
According to the Modbus specification
(http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf, section 2.1)
a Modbus RTU master can send a broadcast to all of it's slaves. This
broadcasts can only be write requests as otherwise collisions could
occur, eg. on a RS-485 bus.

When receiving such a broadcast, the slave should process the request as
usual, but must not reply anything, neither a normal response nor an
exception reply in case of an error.

Adjust the unit test for this case, too.

Signed-off-by: Michael Heimpold <mhei@heimpold.de>
@karlp

This comment has been minimized.

Show comment
Hide comment
@karlp

karlp Dec 9, 2014

Contributor

I know it's spec compliant to do this, but I like using this. When I have only a single device connected, I don't have to go looking up what it's slaveid settings are, and it just works using slave id 0. Much as I don't want modbus_set_slaveid() to reject the reserved range from 247+, I'd still like to be able to respond on broadcast if I want.

Contributor

karlp commented Dec 9, 2014

I know it's spec compliant to do this, but I like using this. When I have only a single device connected, I don't have to go looking up what it's slaveid settings are, and it just works using slave id 0. Much as I don't want modbus_set_slaveid() to reject the reserved range from 247+, I'd still like to be able to respond on broadcast if I want.

mhei added a commit to mhei/libmodbus that referenced this issue Feb 13, 2015

Do not reply on broadcast requests (fixes #153)
According to the Modbus specification
(http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf, section 2.1)
a Modbus RTU master can send a broadcast to all of it's slaves. This
broadcasts can only be write requests as otherwise collisions could
occur, eg. on a RS-485 bus.

When receiving such a broadcast, the slave should process the request as
usual, but must not reply anything, neither a normal response nor an
exception reply in case of an error.

Adjust the unit test for this case, too.

Signed-off-by: Michael Heimpold <mhei@heimpold.de>
@stephane

This comment has been minimized.

Show comment
Hide comment
@stephane

stephane Feb 18, 2015

Owner

@karlp what do you think about something like that:
https://github.com/stephane/libmodbus/tree/compliance

Owner

stephane commented Feb 18, 2015

@karlp what do you think about something like that:
https://github.com/stephane/libmodbus/tree/compliance

@stephane stephane closed this in e10ee2d Feb 18, 2015

@karlp

This comment has been minimized.

Show comment
Hide comment
@karlp

karlp Feb 18, 2015

Contributor

the compliance masks look like a pretty decent compromise to me, thanks.

Contributor

karlp commented Feb 18, 2015

the compliance masks look like a pretty decent compromise to me, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment