Protocol extensions for multiple Modbus/RTU Masters

J

Thread Starter

Julie

Greets,

I am getting ready to start design of an HMI product. I have two possible design points, both of which I plan to do (Modbus Master or Modbus Slave ...), but I'd like to know if anyone has seen an extension to the Modbus/RTU protocol which would allow a Master to pass control to a Slave.

The scenario I have in mind would be "some device" which functions in the usual manner as the Master, polling Slave devices, and doing its thing. It would periodically "do something" that would indicate to a Slave (my HMI device running in this "hybrid" mode) and that Slave would then be able to operate as a Master until it was done, then it "did something else" which signaled to the Master that the Master was in control again.

I know how to design the protocol myself, I'm just trying to be lazy and use something that someone else might have designed already.
 
J

Jerry Miille

You have some interesting ideas and I can see applications where they might be very useful.

BUT, please do NOT, in any way reference the name Modbus because if you do this, it is no longer Modbus.

You can name it any thing else you want and you "might" even get away with stating that you use "Modbus formatted messages" but I would really discourage that as well. No other Modbus compatible device on this earth will be able to support your proposed functionality.

That kind of talk will only generate confusion. For example, look at the Danload 6000 Preset. It makes the claim that its messages are Modbus compatible (and they are) but only a few, custom designed "Modbus" devices can talk to it!

Jerry Miille
 
I've never worked with Modbus Plus, but I understand that it supports multiple masters via token sharing.

The proposed operational scenario sounds to me like two Masters sharing a token, the one who holds the token acts as master, the one who lacks the token is silent (or maybe functions as a slave while the other has the token?).

Restated scenario:
Master 1 does its thing. At some point, 'it does something' (passes a token) to "indicate to a Slave" (I'll call this 'Slave Master 2', Julie's HMI). Slave Master 2 operates as a Master until it is finished, then it "does something else", which is handing the token back to Master 1 to signal that the Master is in control again. Go back to the beginning and play it out again.

Maybe you should talk to the Modbus Plus people because it sounds to me like they might have designed this already or maybe Modbus Plus is close enough to what you need that it will work.

David
 
B
Search Unitelway protocol (used by Telemecanique) and look at the spec. It is typical Master Slave but it also permits a slave to contact another slave through the master. Slave A to Master...Master to Slave B.

It should give you some ideas on what to do.
 
> You have some interesting ideas and I can see applications where they might be very useful.

I knew you would ;)

> BUT, please do NOT, in any way reference the name Modbus because if you
> do this, it is no longer Modbus.

There may be some issues with Modbus trademarks, but there's nothing about what I described that makes it "no longer Modbus".

Modbus includes a number of function codes that are reserved to vendors. If I ... use one ... I can make up messages that do whatever I want them to do. Since, so far as I know, nothing in the Modbus specification says the Master can't "change", there should be nothing which prevents what I've described from =being= Modbus.

Now, there might be some RS-485 issues, but since Slave devices already respond from other-than-the-head of the bus, there should be nothing keeping a device from acting like a Master in the middle of the bus.

> You can name it any thing else you want and you "might" even get away with
> stating that you use "Modbus formatted messages" but I would really discourage
> that as well. No other Modbus compatible device on this earth will be able to
> support your proposed functionality.

Actually, they all can -- a Modbus slave wouldn't have the slightest idea it wasn't being queried by the "other Master" on the bus.

The whole purpose of defining something in terms of backwards compatibility with "something else" is to preserve the investment in "something else" while getting all the benefits of "something new".
 
L

Lynn August Linse

PLC have done such 'role assignment' for years (decades?), and you tend to find them fragile where they get 'locked' up into modes for minutes at a time where either bOTH ends think they are Master or both ends think they are slave.. Read up on the Modicon MSTR block. This also only works if the Modbus is lightly used, with lots of idle time.

You didn't say if these are RS-485, RS-232 or Ethernet devices. If you have a full-duplex connection, so RS-232 or RS-485 4-wire, then you can do it more simply with multiple slave address.

Say slave #1 is the slave as slave, and slave #2 is the slave as Master (again - only works in a full-duplex, point-to-point design). The following logic applies:

If the 'true' slave sees a message come in as #1, it knows this is a new slave request for it. If the 'true' slave sees a message come in as #2 (or N<>1), then it knows this is a response to past master request it sent.

If the 'true' master sees a message come in as #1, it knows this is response to a previous slave request. If the 'true' master sees a message come in as #2 (or N<>1), then it knows this is a new request being sent by the slave-as-master.

(Interestingly enough, this is the documented behavior which Rockwell uses with serial DF1 Full-Duplex or Radio-Modem - it is how for example a SLC5/05 'bridges' DF1 to/from Ethernet)

Most Digi 'Modbus/TCP to RTU' bridges support this logic, which allows for example a small serial HMI+PLC combo which might be remote units in a waste-water lift station. Normally they receive Modbus/TCP requests to slave #1 via cellular or DSL, which the Digi maps to Modbus/RTU. Yet if they wish to 'write' a Modbus data (push data as an alert), they just write to for example slave #2, and the Digi bridge detects this '2<>1' and maps this to a different outgoing Modbus/TCP socket to a remote host which accepts the write-as-slave. The remote MB/TCp devices are 100% ignorant of this trick, but the HMI+PLC combo must permit this behavior to be disabled.
 
Top