BRX as Protocol Converter

[Controls Guy]

I have a  potential project involving replacement of several programmable power supplies with a competitive product, while leaving some of the original units.   Both current and new products are Modbus RTU over 485, but one product has a lot more capability and naturally the register maps, encoding and so on are significantly different.

So the BRX can obviously easily do the protocol conversion from Product 1 Comm Language to Product 2 Comm Language, but multiple units per machine are being replaced, so the slave/server port needs to know that it's Node 8 as well as Node 9 or whatever unless I have one port per unit and wire them in parallel ( ).   I doubt that there's any way to do that with the internal or SERIO ports configured for Modbus RTU Slave.    Plus, there's no provision for mapping the register ranges to different spots in the controller.    Modbus is fairly easy to parse (I wrote an AB driver  ), so I could set the slave port to program control and parse it internally, but just wondering if there's any cleaner way.

Thanks!

[franji1]

I have a  potential project involving replacement of several programmable power supplies with a competitive product, while leaving some of the original units.   Both current and new products are Modbus RTU over 485, but one product has a lot more capability and naturally the register maps, encoding and so on are significantly different.

So the BRX can obviously easily do the protocol conversion from Product 1 Comm Language to Product 2 Comm Language, but multiple units per machine are being replaced, so the slave/server port needs to know that it's Node 8 as well as Node 9 or whatever unless I have one port per unit and wire them in parallel ( ).   I doubt that there's any way to do that with the internal or SERIO ports configured for Modbus RTU Slave.    Plus, there's no provision for mapping the register ranges to different spots in the controller.    Modbus is fairly easy to parse (I wrote an AB driver  ), so I could set the slave port to program control and parse it internally, but just wondering if there's any cleaner way.

Thanks!

Multiple Slave IDs along with duplicate Modbus Memory accesses to supposed "different" slave devices, you are definitely best off to Roll Your Own "Custom" Modbus Slave protocol driver.  I believe a general Modbus Slave program has been done by somebody out there (at least the general handshake and FC processing) - your FC processing will be much more elaborate since you will be mapping various Slave IDs to different areas of "memory" based on that specific Slave ID, oh along with forwarding the data or requesting the data from the "actual" slave.

[franji1]

Is it one Master for all the existing slaves - or is there one master for 2 or 3 here, and another master for 3 or 4 there, etc.?  If there's multiple Masters, you will need multiple serial ports (one for each Master).  Other questions arise if that's the case.

[Controls Guy]

No, single master per bus.   Multiple masters per bus or trying to do this with one DM for several busses would be a nightmare (plus creating a single point that can fail multiple machines).   Would NEVER NEVER do that.

How do most people recognize command packets?   I think the official documented way is a silent interval equal to a certain number of character intervals, but that seems awkward on a DM Program Control port.   There shouldn't be a consistent terminator character because of the checksum, and the commands will vary in length, so fixed length doesn't work.    The only thing I can think of is to watch the value of .InQueue and when it plateaus for X number of ms, assume that's the whole command, grab the packet and analyze it.   Is that the consensus?

[franji1]

The only thing I can think of is to watch the value of .InQueue and when it plateaus for X number of ms, assume that's the whole command, grab the packet and analyze it.   Is that the consensus?

The Framers of the Modbus/RTU Protocol Specification believe that time is a perfectly fine framing mechanism - especially with modems and repeaters in the mix - NOT! (pun intended).  ***EDIT*** So, YES, that sounds like a good enough "framing" algorithm.

Any chance your lone master supports Modbus/ASCII?  That would be a little easier.  Or Modbus/TCP or Modbus/UDP, although you would still have to roll-your-own since our Modbus/TCP Server does not provide the Master packet's embedded slave id.

[Controls Guy]

Any chance your lone master supports Modbus/ASCII?  That would be a little easier.  Or Modbus/TCP or Modbus/UDP, although you would still have to roll-your-own since our Modbus/TCP Server does not provide the Master packet's embedded slave id.

Well no.   That's the point, to be transparent to the server.   Already both products are RTU, so if I could make changes to the server, that would be simpler than switching to ASCII or TCP.