Back: Modbus

Modbus Report-By-Exception (RBX)

The formal Modbus spec is strictly half-duplex ... the Master sends requests or commands to the Slave; the Slave answers those requests without embellishment or additions or adjustments. The slave is not permitted to say "This info is more important so I'll send it instead ...". The Master has no formal way to indicate to the slave "I want to know about these 10 values ... unless something more important has changed" and so on. If your slave device has 2 serial ports, of course you can configure one as a slave port and another as a master port. If you only have a single serial port, you need to consider some for of RBX.
- LynnLinse LynnLinse

Q: How do other protocols handle Report-By-Exception?

  1. A common SCADA RBX method - which supports half-duplex media if required - is for the Master to have a general "tell me what's up/what's changed" query. The slave uses configured knowledge to select and order data changes based on relevance and importance. So the Master receives as response a list of data values which have changed. DNP3 and IEC870 support this form of RBX (Modbus does not!)
  2. An alternative method in some PLC - again assuming a half-duplex media may be required - is for the slave to have a special RBX response that can be returned in place of normal responses. The user configures a limited amount of data and uses ladder-logic to activate the RBX. The next time the Master does a read query for any data, it will receive the RBX response instead. The Master must acknowledge this RBX data, and only then does the slave return the initially requested response. Omron HostLink uses this form of RBX (Modbus does not!)
  3. A traditional half-duplex peer-to-peer design - such as AB DF1 Half-Duplex - kind of turns the Master/Slave relationship on its head. When the Master sends a request to the slave, the slave doesn't answer immediately. The Master is forced to poll the slave periodically for a message, and the slave has the option to return a pending response or a new request. For any response, the master needs to examine the destination address in the header and possibly forward (relay) that command to another slave. So in reality, this is really a peer-to-peer system where the master is the ultimate slave, working to shuttle message for the many peers. (Modbus does not support this!)
  4. "Manual RBX by status register" is the most common Modbus-supported way to handle RBX. The Master rapidly polls a small, information-rich block of status and data registers. Some of the status registers indicate the need to poll other larger blocks of data. The Master is programmed to examine the status bits, and ONLY read the other larger data blocks if a bit indicates relevant data changes or for a general refresh of values.

Q: What RBX does Modbus support?

While the protocol doesn't directly support RBX, most Modicon PLC users are at least aware of the XMIT ladder logic programming block. XMIT can be configured to act as an event-trigger Modbus master request. It allows the PLC to do an unsolicited WRITE of data up to another "slave". Many third-party RTU devices also support something like this, yet surprisingly few computer-based "master tools" support it.

When triggered, the XMIT looks to see if the targeted comm channel (likely the serial port) is busy. While Modicon documents a way to use RS-485 RTS/CTS wire pairs to "request" the line in a multi-drop RS-485 ... but for most situations this just means that no new request is arriving from the Master and no response is pending to be returned to the Master. Basically, if the serial port is idle ... then XMIT can go ahead and use it. XMIT sends a normal Modbus request, and waits for a normal Modbus response.

In the world of SCADA with slow (or costly) communications and slow process changes, the idea that the serial channel to a remote RTU is idle much of the time is not unthinkable. For example, a waste-water management system may only need to talk to a lift-pump station every 3 hours or once a day ... that is *IF* the lift-pump station is able to issue RBX during failures that occur between these rare cyclic polls. In fact, this is the ideal place to consider the XMIT style "Report-By-Exception" since 99+% of the time the serial line to the RTU is idle.

Q: What is required to have basic Modbus RBX?

To make this work as simply as possible, the Modbus/RTU slave device requires:
  1. Be the sole slave device on a preferably full-duplex media such as RS-232 or 4-wire RS-485
  2. Use a known, predefined slave address (which is true of all Modbus/RTU slaves)
  3. Have the ability to act as Master based on triggers from ladder-logic
  4. Able to sense a collision - when the remote Master is talking or starts to talk during the RBX
  5. The outgoing "Master or RBX request" must be aimed at a slave OTHER than this slave's predefined slave address. So for example, Modbus messages seen on this serial wire shall be slave address == 1 if this is a remote-master-to-this-slave transaction, and slave address <> 1 if this is a slave-as-master-to-remote-slave transaction

Now that we have a slave capable of RBX, we need a matching Master setup, ONE of the TWO following:
  1. Either a Master which understands unsolicited Modbus/RTU requests
  2. Or some form of Modbus IP-to-Serial Bridge which can "split" the serial Modbus/RTU RBX conversation into 2 channels, in which case remote Masters and Slaves are unaware of the RBX and mixing of Modbus/RTU behavior.
In addition, the Master must have the ability to pause slightly (say 50-100msec) between each new request to allow the RBX slave to detect the line as idle.

Q: What are the low-level driver algorithms required?

The algorithm used by the Master serial driver is actually very simple:
  • Receive a full Modbus message
  • If the first byte (or address value) does EQUAL expected slave address, then this is a response to one of our previous requests
  • If the first byte (or address value) does NOT equal expected slave address, then this is a new request being issued by the RBX slave

The algorithm used by the Slave serial driver is equally simple:
  • Receive a full Modbus message
  • If the first byte (or address value) EQUALS my slave address, then this is a new request our me to answer
  • If the first byte (or address value) NOT equals my slave address, then this is a response to one of my previous requests
  • (Remember - we are defining the RBX-suitable slave as the ONLY slave on the line, so the slave should NOT be seeing other multi-drop traffic addressed to other slaves).

Note that you don't really require any goofy port "modes". I have seen users struggle with Modbus RTU products that control the RBX by a single NormallyOpen (NO) contact. When OPEN, the serial port is in slave mode. When CLOSED, the serial port is in Master mode. While in theory this seems workable, it in effect forces the ladder logic which triggered the RBX to hold the "mode" to RBX until the Modbus RBX message is handled, then release the mode. The problem I repeatedly see is the RTU can become STUCK in RBX/Master mode during unforeseen error situations and BLOCK all normal slave behavior. If your RTU is 120 miles away, this is bad news. Using the algorithms above, your RTU can return to "slave mode" the instant the RBX master request is sent - the response can be easily distinguished by the first byte <> the RTU's slave address.

Those of you who've implemented AB DF1 Full-Duplex may recognize this algorithm style, as the lowest level DF1 serial driver does a similar "split" of traffic based on the 0x40 "Reply Bit". Messages with the Reply Bit is 0 are passed to the new request handler; messages with the Reply bit is 1 are passed to the response handler. So in reality, the RBX function within a Modbus/RTU slave which is the ONLY slave on the serial line can ALWAYS be active. It creates a psuedo-full-duplex driver for Modbus. So don't create a "mode" where RBX is active and monopolizes the port, instead you should have a boolean configuration for:
  1. Multi-Drop = TRUE, then RBX is disabled and the low-level driver discards messages where first byte (slave address) <> our own address since they are either a request to or response from another slave.
  2. Multi-Drop = FALSE, then RBX is enabled and the low-level driver treats messages where first byte (slave address) <> our own address as potential RBX responses. Once passed to the RBX handler, the RBX handler will discard the message if no response is expected.

Q: What is an Example Reference System (with Modbus Bridge as Splitter)

This is actually a very powerful concept and can spawn a new generation of Master and Slave tools which function more like Peers. IP networks are inherently full-duplex and peer-to-peer, so all that is required is a Modbus/TCP-to-RTU bridge that can act as a splitter. As shown below, this magically enables the Modbus/RTU slave to function with RBX and interact with remote off-the-shelf Modbus/TCP Masters and Slaves.
rbx_example.jpg

Example Modbus/TCP Master Polls to RTU

  • A normal SCADA or OPC Master issues a Modbus/TCP request Unit Id #1 at the IP of the Modbus Bridge
  • The Modbus/TCP request travels through the segments of the IP network
  • The Modbus Bridge received the request, sees to route it to serial port 1, sends as Modbus/RTU serial
  • The RTU detects a message starting its slave address of #1, treats a new request
  • The RTU returns required Modbus/RTU response
  • The Modbus Bridge reforms as Modbus/TCP and returns the response to remote Master

Example RTU RBX Writes to Modbus/TCP Slave

  • The RTU detects the serial link as available and issues a write to slave #2
  • The Modbus Bridge receives the request to slave #2, looks this up in a routing or index table and knows to reform as Modbus/TCP and send to the central Modbus/TCP slave (perhaps a master or concentrating PLC)
  • The Modbus/TCP request travels through the segments of the IP network
  • The Modbus/TCP slave received the request, and returns the required response
  • The Modbus Bridge returns a response as-if from Slave #2
  • The RTU detects the response and considers the RBX a success.

Q: Are such Modbus Bridge as RBX Splitter on the Market?

It should come to you as no surprise - given this Wiki page - that the answer is yes. Info:Digi