Report by Exception in Modicom PLCs?


Thread Starter


I am from the Elec SCADA industry where data is sent to the SCADA Master in a report by exception basis (e.g. the data has changed X%).

I am now in Water working with PLCs where all the data is sent back to the Master software every communication scan collects every point.

The net effect of this is that it takes probably 10 times longer to scan all the devices as necessary. And it takes a long time for controls to happen because of the wait to scan all the station PLCs.

1. Is there a way to convert my SCADA modbus data retrieval to report by exception?

2. Are there algorithms for ladder logic to calculate the change by exception?

Any thoughts on this are welcomed.

G Brown
Like almost all protocols, Modbus is strictly client/server (or master/slave). You poll the server for data, and it answers. Very few protocols do things differently because it adds a lot of complexity for little or no benefit in most applications.

You described it as "Modbus", but is that Modbus/RTU over RS-232? Modbus/RTU over RS-485? Modbus ASCII over radio? Modbus/TCP over Ethernet? Also, how is the hardware arranged? All of this makes a big difference; probably a bigger difference than "report by exception" would.

Also, how many of the control loops are you trying to speed up? All of them? One or two? What is your target. There needs to be some sort of benefit to this. Making a control loop "faster" isn't going to help if the process you are controlling is inherently slow (water systems can be like that).

Also, is the bottleneck actually the communications network, or is it the communications hardware? A lot of process control hardware can be very slow to respond regardless of what protocol you are using. If the process itself is very slow then fast communications can add a lot of expense with no benefit.

Furthermore, what is your data model like? If the data is constantly changing anyway, then there is always an "exception" present to report on. "Report by exception" only helps under very special circumstances. It helps when your data changes only occasionally and your bandwidth is very limited.

What helps more often is to find ways to make the communications operate in parallel. There are different ways of dealing with that, depending on the factors which I have mentioned above.

So, can you provide us with more details?
Ok, Maybe I come from an environment of complexity, because we would never send back all the analog data on the next scan if it was the same data. I have seen many SCADA specs that require report by exception methodologies, it is very common in the Elec Utility Industry.

We use all the communication technologies, Modbus serial over radio at 1200 bps, Modbus+ 485 and Modbus/TCP it all depends on the path available. Obviously my issue is Modbus over 1200 bps radio.

While data is always changing, it isn't always changing by very much and doesn't need to be reported immediately.

In the report by exception that I am familiar with, the absolute value of the difference is integrated over time and that creates the trigger for whether that data is being sent back on this scan. Because of the time integration, even data that barely changes will be reported back regularly. The key is that the noise of a 1-bit analog change doesn't fill your data path on every scan, but maybe every few scans.

It takes well over 60 seconds to scan all the PLC stations, while very little has changed, in my experience for the number of stations here, In a report by exception system, I could scan them all in 6-10 seconds and still pick up all relevant data.

Maybe PLCs and the Modbus protocol just doesn't support this easily and I will have to live with it. I was just checking here to see what would be said on the subject.

There is nothing much which you can squeeze out of 1200bps. This is a very low bandwidth, and it is not related to what communication protocol you may be using.

I believe that your network design may not be optimum!!

However, without enough data about the network and the related/peripherial devices, nothing much can be said.

There is much you can do in the PLC Application programme to enhance the communication, or you may install a solid state OPC Server between your PLC and the field devices.

You also can make a sub-PLC to function as Data Gathering System.

You need to re-think about your current situation and how to enhance it, taking into consideration the capability and the limitation of your existing network and how to enhance it too.

Do not blame it on the communiction protocol in use.

I also may suggest that you get some professional in this line of business, to study and implement the necessary changes to make your network more efficient.

As another person has mentioned, there is only so much performance you can squeeze out of a 1200 bps radio. With radio links though I believe that "report by exception" is typically handled by the radio system itself. That is, the radio just sends the changed data. It can do this if the radio can use its own protocol over the air, and just translate to and from Modbus at either end.

I can't recommend any particular radio model for this, but I would suggest checking to see if your radios already have this feature but it just isn't turned on. Radio links are one of the common places where this sort of thing is implemented.

If your radios don't have this capability, then another way of dealing with it is to reverse the client and server relationships between the field devices and the SCADA system. That is, the field device becomes the client (master) and the SCADA system becomes the server (slave). Or, you might have to insert a proxy in between the two if the SCADA system doesn't have that degree of flexibility. The field device then only has to send such data as it thinks appropriate. The device connected to the field radio would have to be programmable though, such as a PLC. You would also have to program in a check to see if the radio link is still operating (a "heartbeat" signal). This "do it yourself" method can be a lot of work though, so you have to ask yourself if it is really worth it.

For Modbus/TCP over Ethernet, the protocol shouldn't be a bottleneck. If there is any problem there, it is an application software (SCADA) problem, not a Modbus problem. The client (master) should be polling all the servers (slaves) in parallel, not one at a time sequentially. If done properly with the right software, polling time can be under a millisecond. Of course a slow server (slave) can take much longer than that to respond, but one slow server wouldn't hold up the whole network.

If the client (master) is polling the servers (slaves) one at a time, then one slow server (slave) can hold everything up. But again as I said above, this is a problem with the application software (SCADA system) design, not the Modbus protocol.

For Modbus/RTU over RS-485, the most straight forward solution is to break up the larger RS-485 networks into smaller networks so that the application can poll the networks in parallel. You can install Modbus/RTU RS-485 to Modbus/TCP Ethernet gateways to assist in this. Each RS-485 network would connect to a gateway, and then the SCADA system would poll the networks in parallel via Ethernet.

As for a 60 second scan time versus a 6 second scan time, you have to remember that a water system may not need to be as fast as an electrical system. A reservoir level usually can't change much in 60 seconds. Any system design is a compromise between cost, simplicity, and speed. What the right trade off is will depend on the particular application. I imagine that it would be different for water versus electric power versus an assembly line.

Normal polling systems emphasize low cost and simplicity. They also have the advantage that they will usually integrate well with computer systems as they follow the same conventions as most other protocols.

Report by exception protocols are usually intended to conserve bandwidth on very constrained networks. Radios are a prime example of this, as well as certain types of very slow wired media. However, you usually have a more complex system (although that might not be readily apparent), and have to give up a lot of flexibility. Also, these sorts of protocols are usually application specific. With the wrong sort of data they can end up generating more traffic than a conventional polling system.

I hope this has been clear enough. This is actually a pretty complicated area and there are a lot of points that I haven't even mentioned.
You are welcomed G Brown,

I only wish that I could be of more help to you.

But Industrial Communication issues are normally of sophisticated/complicated nature.

I have been working in this field since 27 years, and believe me, every project I have worked on was entirely a "new" project.
What I am trying to say here is "there is no copy & paste" or a "ready-made" type of solution in this line of business.

One last word, if I may add, try to make the network(s) as simple and as straight forward as you possibly can.

Good Luck

I am also originally from an industry where update times are a little more critical (industrial process and assembly automation) but I now work in the water industry. I am currently working on an Allen Bradley based radio system using DF-1 half duplex and I was wondering about the same thing (report by exception). Wouldn't it be possible to program the local RTU to look for exceptional changes in certain values and then set a trigger bit? If you are using a PLC as a polling master, you could then poll these individual trigger bits from each remote site to build a list of sites that require further attention and maybe a full scan of all values from only the remotes with their trigger bits set. I believe that Bristol Babcock claims to support this type report by exception in their controllers but, I am also told that this is essentially vaporware. Any opinions?

Yes, it is possible to use one bit as a flag to indicate that data has changed since the last poll. However, there are limitations to that.

One problem is that whether or not it actually helps depends a lot on the details of the application and the data of interest. It only helps in applications where transmission bandwidth is very restricted, any other delays are minor in comparison, and there is a lot of data which only changes occasionally. Under other circumstances, it can take almost as long to read the "change" flag as it does to simply read all the data. If you end up having to do a full read frequently, this method can actually end up being slower than simply doing a normal poll.

Another problem is that it isn't compatible with multiple masters. With Modbus/TCP, you can have any number of masters on the same network all reading the same field I/O. To make the "change flag" concept work with multiple masters the slave would need to track changes separately for each master (i.e. have session management).

Where it *might* work is on the radio links, provided:

1) The field devices each have a very large number of registers which must be monitored.

2) None of the data changes very frequently.

3) There is only a single master in the system which can read the radio connected devices.

4) The slave can be programmed to flag its own data changes.

5) The system is otherwise fairly quick, and it is just transmission speed which is the problem.

It is worth mentioning though that some people have systems where only a few data registers are read routinely, but additional registers are read as required. For example, a few registers or coils may be used to monitor normal operation, but additional registers or coils may be monitored in the event of a fault.

The problem with this approach is that scanning is slower just when you may want it to be fastest (during a system upset). It does help though if you are trying to conserve bandwidth for cost reasons (if you are being charged by the byte), or if you can be reasonably sure that you won't have upsets in multiple systems simultaneously.

This doesn't really answer your question, but FWIW... If your AB processors and RsLinx support it, there is a newer DF1 protocol called DF1-Radio Modem, which should use less network bandwidth than DF1-Half Duplex. It eliminates the ACK/NAK transmissions, and may provide additional efficiencies.

There are others around here, though, that can probably give more/better insight into whether DF1-Radio Modem would be more appropriate for your application.

- Jim.
From what I remember about DF1, if you get rid of the AQ/NAQ then you have the same cycle as ordinary Modbus. So if you are already using Modbus, there is no advantage to switching to DF1.