If you use the Unit ID in the MBAP header as the RTU destination address when bridging messages from Modbus/TCP to RTU, how should 0 be handled?

Should 0 be used to bridge a broadcast message, or should the request be routed to the local device and handled by the bridge module itself?

If the unit ID is not used, it will typically be set to 0. This means that a request from an unknowing client that just wants to read or write registers on the bridge module may be interpreted as a bridged broadcast.

I feel it is safer to not allow bridged broadcasts.

Has anyone else run into this issue? If so, what is the common feeling on how it should be handled?

Thanks!
Perry

 

This is one of the original puzzles of MB/TCP - pre-public (pre-bridge) specs said to just set the Unit Id to 0, so the entire first wave of MB/TCP drivers forced this to 0 without option for any other value. The MB/TCP to MB+ or MB/RTU bridges required users to be able to set this to something other than 0. Many drivers did silly things like ask you to enter the dest IP as 192.168.1.23,10 to set the Unit Id to 10.

All of my firmwares have automatically mapped a MB/TCP Unit Id of 0 to a MB/RTU slave id of 1. Remember to reset the id to 0 when bridging the
response to MB/TCP. This is what the user intended 99.9% of the time.

Then I have a user setting called something like "Enable Broadcast (Y/N)" with the default No - if users enable this, it allows Unit Id of zero to be treated as broadcast. Yet in the tens of thousands of Modbus devcies I have out there, I have never heard of anyone doing anything meaningful with a Modbus broadcast.

Best Regards

Lynn August Linse, [email protected]
IA Firmware Specialist, Digi Int'l (www.digi.com)

 

Actually Perry, I didn't answer your 2nd question. Zero should NEVER be used for a valid node. So no, you should not assume MB/TCP messages to address 0 are for the bridge. If the bridge needs an address, give it one like 255 or 247 and allow the user to change it to another address if required/desired.

Considering all the OPC/DDE drivers out there that make it easy to send MB/TCP with Unit Id 0 and hard to set it to anything else, 0 is a common "default" for the first few messages a new user sends. That is why the auto-map of 0 to 1 was born in the first bridge to hit the market (done by me while in Singapore) - it eliminated a tech support call from almost every new user!

The auto-map of 0 to 1 is how the Schneider Electric/Modicon CEV, the DigiOne IA RP, and the Lantronix DR1 all behave, so I can safely say that is how the vast majority of the installed base of MB/TCP to MB/RTU bridges in the field work. Doing likewise in your product would simplify your support & customer's ease of use.

(Perry - you still at Pyrimid?)

Regards - Lynn August Linse, [email protected] IA Firmware Specialist, Digi Int'l (www.digi.com) 26741 Portola Pkwy, Suite #1E-242 Foothill Ranch CA 92610-1743 USA
Ph: 949-916-1524 or 949-212-5802

 

Makes sense. We looked at the docs for Schneider's TSX bridge as well - looks as you described.

Thanks Lynne!

Yep, still at Pyramid!

Perry