ControlNet Produced and Consumed Tags


Thread Starter

Jerry Buthmann

I have encountered a difficulty using Produced and Consumed tags over ControlNet. Our customer has a network of 7 Controllogix PLCs connected by ControlNet and Ethernet. We were using message instructions over Ethernet to pass data from one PLC to another. We considered converting to Produced and Consumed tags over ControlNet to improve performance. When using Produced and Consumed tags, the consuming PLC must have the producing PLC entered in its IO configuration. IO configuration changes must be performed off line and then downloaded.

Here is the problem. The Controllogix processors are not all the same model. If one were to fail the replacement may be a different model or firmware revision. To make the produced tags work it would require revising the “consuming” program in each PLC off line and downloading. Then the ControlNet network would have to be re-scheduled.

This application is mission critical. Putting a single PLC in program mode for more than a few minutes is a problem. Putting all PLCs in program mode to reschedule the network during production would be a catastrophe.

Rockwell does a good job of marketing its product features but unfortunately the Devil is in the details. As in this case, they need to be more mindful of the shortcomings of their designs and build in more tolerance for the consequences of failure. Designing the products to allow these changes to be made on-line would be solve a lot of problems.

Has anyone encountered a similar experience? I am interested in any comments the PLC community may have.

Trevor Ousey \(lists\)

G'day Jerry,

We had a similar experience on one line with 13 processors, we were at that stage using version 12 firmware in 1756-L1, L55 and a L61 processor. We ended up using a standard UDT with a Bool array of 64 and a DINT array of 64, placing the same UDT in all processors and then creating the produced/consumed tags.

Even with this structure we still took 8 hours of firmware upgrades to 12 and tag creation, and using a CSV to create the Aliased tags. Then had another 4 hours of troubleshooting to see why some didn't work, and network loading issues. This network was for peer to peer so we found that the default rack optimisation was on caused severe loading, even when we were changing the NUT and RPI. Problem is to change it you have to delete the module and add a new one to the tree.

As for scheduling, during a chat with our state manager for Rockwell some time back, he thought that RSNetworx V5 would be able to schedule online with out taking the processors out of run, I now have V7 but have yet to check if it is capable of it yet. Hopefully he wasn't thinking of the merge function.

But a positive is that the network has never crashed, slowed or had one problem, and we also use have Wonderware Intouch use the network.

If you can get past the initial pain of scheduling ControlNet it is a very stable network.

Trevor Ousey
I have not encountered the problem you are referring to, but I do know with the CLogix there are firmware problems galore. This rolls over into motion, sercos, etc.

I also feel that their (AB/Rockwell) motion is way below par. The updates are way to slow for real motion applications... see the following quotes from their literature:

"To rearm the MAR instruction, the rung must change from false to true. The rate at which this logic functions depends on the following:
1) Program scan time (measured in mSec, increases as logic is added)
2) Motion task course update rate (measured in mSec, multiplies as number of axes increase)
3) IMPORTANT The MAR instruction execution may take multiple scans to execute because it requires transmission of a message to the motion module. The Done (.DN) bit is not set immediately, but only after this message has been successfully transmitted.
4) Important Note. The Coarse Update Rate setting will usually influence the nature of the motion to some degree, usually by a very small amount. Where the desired motion is therefore critical this point should not be overlooked."

The list could go for days, they have extremely good marketing skills for selling this junk. And the biggest thing they push is that “it is done in one software package”. I am a real engineer and if it takes two software packages to build a real control system for a real machine, I will use two software packages. And I will always prefer doing the motion separate as long as AB does motion the way they do it now. Maybe one day they will have a true motion controller, but then again if they do it will probably be released before it is actually finished.

If you look at the PowerFlex family it appears that it was built around a lot of afterthoughts, but if you ask them it is the best thing since sliced bread.

I would recommend or prefer: Emerson/CT, Parker/SSD Drives, or Delta Tau Drives/Motion Controls.
My opinion is that the producer/consumer model RA pushes is fine for the hardware level, but where it is exposed to the application programmer for user program utilization, it is a trap:
1. The produced/consumed connections consume CNet bandwidth.
2. The produced/consumed connections are made "behind the curtain", who will be able to re-make them once broken?
3. The produced/consumed connections are limited.
4. The tools to troubleshoot produced/consumed connections are inadequate (this just back from a project making a connection from 5/03/SCNR to
ControlLogix - yuck).

The answer is simple: Use CNet with MSG instructions, organize your communications, time it and keep track of the success/failure status (acting on it if required).