Total delay time - How to calculate?

I am attempting to do a study on if RSLogix 5000 is a suitable control system for a project I am working on. Is there a way to determine the total time required (in milliseconds) it takes to:

Scan for a DI (I believe the lowest is 5ms? correct me if I am wrong?)
Execute a task - I realize this is best guess depending on the complexity of the task, assume a relatively simple task
Output comm on fiber to a slave PLC further down the line

Sorry if this is an amateur question, any help is appreciated. Thanks!

-ignus99

I am not a Rockwell guy, but I am quite sure that what you are looking for will depend more on the hardware used than the software.

I am more concerned with the scan times for RSLogix 5000, the physical hardware is another aspect that I am looking into... If I could get that information here it would save me more time, and I would be happy of course! But in the stages I am at right now, I am trying to nail down the software delay time.

Welcome to the forum.

What Russ means is that RSLogix 5000 is SOFTWARE used to program a broad and diverse family of ControlLogix and CompactLogix control platforms. Those platforms have widely varying performance characteristics. You have asked a question about the programming software that is irrelevant to the programing environment so we can't give you a good answer without more information. I can give you some generalized info but it may turn out to be wrong for some kinds of hardware.

On the CLX platforms IO updates occur at the RPI rate configured for that module and happen asynchronous to the PLC scan. A typical 1756 family input module can be configured with an RPI from 0.2 to 750 milliseconds to suit the needs of the system designer. If you use specialty IO modules, high speed input modules, or something from the 1769 IO family the performance will be different. Whether that is faster or slower I can't say without knowing what hardware you are using.

Programs are organized in tasks. A task may be continuous (and that means low priority and interruptable) or high priority and periodic, with the task execution rate determined by the programmer. A task can contain multiple programs and each program will consist of its own local tag variables and a main routine and subroutines. Typical programs will run in less than a millisecond although very long programs with lots of math can take several milliseconds.

What you have described can be performed on most CompactLogix and ControlLogix platforms in less than 1mS.

Communications to another PLC will be asynchronous to the program scan and take longer - its speed will be determined the transmitting and receiving comm hardware.

Without more information we cannot be more specific.

The ControlLogix family has a lot of flexibility in how I/O works and how tasks are executed.

The fastest mechanism for "screw to screw" I/O decision-making is to use an Event task triggered by an input module, with an Immediate Output command to an Output module. The ControlLogix 1756 backplane system is best for this sort of thing.

A typical ControlLogix DC input module like the 1756-IB16 has a 290 microsecond average Off-to-On delay, and it takes about 1 ms for the ControlLogix Event interrupt to switch to the Event Task.

So from "Input goes from OFF to ON" to solution of the Event Task's routine can be 2 or 3 milliseconds.

The "via fiber to a slave PLC" is a bigger variable. If this is a MSG instruction, that's going to require submission of data to the controller background task, connection establishment, data transfer across the wire.... that could take 10 to 200 milliseconds depending on what protocol you're using.

The CompactLogix controllers have longer scan times for their backplanes and don't support the Event task with I/O the way the ControlLogix does.

Tell us more about your application: it sounds interesting !

Without going into too much detail as I am unsure of the level of confidentiality the project is, sure!

We are trying to determine the feasibility of a shedding none essential loads in the event of disastrous conditions - essentially the loss of dual redundant power feeds for an oil field. When the backup gens come up and running, we need to turn non essential stuff off extremely fast to prevent overloading.

We are currently running ControlLogix hardware, so my assumption would be to keep with this. My plan was to have a master PLC controlling several smaller "slave" PLC's on each well site, using ControlNet for communication - my understanding is this is this is the fastest protocol available for Rockwell. The end devices would be then connected to the slave PLC's and shed accordingly.

In all honesty my background is more electrical than instrumentation, so I'm open to suggestions the instrument pros have.

Undervoltage trips on your non-essential breakers would be cheaper and quicker than any PLC.

And also, 99.9999% foolproof! There's always a .0001% idiot around to make life "simple".

tomalbright said:

Undervoltage trips on your non-essential breakers would be cheaper and quicker than any PLC.

And also, 99.9999% foolproof! There's always a .0001% idiot around to make life "simple".

Click to expand...

In 99.9999% of the applications, yes. But unfortunately, depending on the time of the day, the current production of various wells, and various other factors, some loads will be essential while others won't be. My life would in deed be much simpler if I could use undervoltage trips, alas that option was investigated beforehand and was unacceptable.

"We are currently running ControlLogix hardware, so my assumption would be to keep with this. My plan was to have a master PLC controlling several smaller "slave" PLC's on each well site, using ControlNet for communication - my understanding is this is this is the fastest protocol available for Rockwell. The end devices would be then connected to the slave PLC's and shed accordingly."


Since you are already running on a CLX platform and "fast acting" is your first priority, Produce/Consume over EtherNet/IP would be the "fastest" Peer-to-Peer or Master-to-Slave communication method.

ControlNet is a fairly "mature" protocol (ArcCAN)requiring nothing less than perfect media, however it has an unique feature which none of the "modern" protocols have accomplished yet : it is a Deterministic protocol. The Keeper of the ControNet network will always ensure that the NUT (Network Update Time) is IDENTICAL to the one set by the user at scheduling time. It could be installed within a redundant topology and will ensure constant data update rates.

EtherNet/IP, although establishing a lot higher throughput (100/1000 Mbps), relies on the Ethernet layer's rule of "first-come-first-served". Data cannot be "prioritized" but "upstream/downstream" of the connections' buffers (RPI-Requested Packet Interval).

To make a long story, yet again, a lot shorter, IMO,using upper tier media and managed switching together with the newer firmware revisions "Unicast Connection"
feature, EtherNet/IP could be considered as "the fastest" communication protocol between CLX class CPUs.