RSLogix RPI philosophy...

Hey... been a while, huh?

Anyway, I’m trying to come to terms with some of that wonderful technical writing (NOT!) that comes from AB. Specifically, I’m trying to get my mind around how and why RSLogix does its’ asynchronous I/O updating in the way that it does.

I’ve gone through several RSLogix manuals but I cannot find a decent explanation of how all of the various RPI’s work together. Also, how the RPI’s, the NUT and the Controller Scan-time are related... if at all. I do recall that there is a limiting relationship between the RPI and the NUT... can you explain what it is and why it is the way it is?

Is it the case that the network essentially manages itself? Does the process controller download a list of modules, along with RPI’s, to a network controller?

For a given set of dissimilar RPI's, sooner or later they will coincide. That is, given one RPI of 30 msec and another of 90 msec, every third time that the 30 msec RPI is activated it will do so at the same time as the 90 msec RPI. How is that managed?

If a particular RPI value is less than half of the controller scan-time then doesn’t that simply cause multiple copies of the same data to be transferred within the same scan? What’s the purpose of that? Is there some sort of advantage?

I read that the NUT forces a network update at the specified time. Does that mean that ALL inputs are updated to the controller, and that ALL outputs are updated from the controller to the various output modules?

Is there a way to force a NUT at the end of a controller scan?

When output data is transferred from the controller to a particular output module, doesn’t that data show up across the entire network? If so, what is the purpose of the “ECHO”? Is it just to verify that the correct data was received?

I've seen samples of module RPI's but they did not include an explanation as to why one value was better than another. It seems that the more I read about it, the more confusing it all becomes.

Terry Woods said:

Hey... been a while, huh?...

Click to expand...

Yep, welcome back I don't have any idea about your question but just wanted to say HI... Hi Terry

Does this mean we are going to see the really good deep threads


(2)

I presume that you're investigating ControlNet, because you mentioned the Network Update Time (NUT), a term unique to ControlNet.

My favorite publication for understanding ControlNet with Logix is the "ControlNet Modules in Logix 5000 Control Systems", publication number CNET-UM001.

But it doesn't specifically answer your general question about how NUTs and RPIs and the controller scan work together. I teach that in my classes on Logix architecture, so I can do some summarizing here.

The NUT is the "cycle time" for the ControlNet. Every node on the ControlNet gets a slot of time to transmit data during that interval. Exactly how much data and what the data format means is part of the "ControlNet Schedule", which is calculated by RSNetworx for ControlNet.

The fastest you can run any Requested Packet Interval (RPI) is one NUT.

You can also run RPI's at any binary multiple of the NUT (x2,4,8,16,32,64,128). If the NUT is 5 milliseconds (the default), you can run RPI's at 5, 10, 20, 40, 80, 160... and so on.

What happens when the RPIs coincide ? The ControlNet schedule determines that. But I gotta go run to catch a plane...

Hi Terry
Also if you are not only talking only about controlnet and I hope Ken will correct me if I am wrong but in a control logix there are two memory/processor areas. 1 area is dedicated to IO and the data is pushed into that area by the actual IO modules at the RPI. The scan time of the PLC has nothing to do with when this data arrives. The data is then transferred to the main memory area/processor where it is available to the program. The data I think is again pushed into the processor area by the IO processor so that it can arrive at any stage of the scan.
I may be totally wrong on this but it is my understanding of how it all works.
Regards Alan

Welcome back, Terry!

Ken Roach gave a great explanation of RPI and NUT.

I sense you are looking for a comparison of how to program in the asynchronous I/O environment?

If you want to simulate the synchronization to a PLC program scan, then the most common practice is to copy the I/O image to user memory at the point(s) in your programming that make most sense.

It is common practice to copy all inputs at the beginning of each main program cycle, and copy the outputs to the actual output data points at the end.

That frees you from dealing with the chance of a change of an input value during sections of code that need a stable value to work with. Then you can write code much like you would for a SLC or PLC-5 with a synchronous I/O update.

Working with input and output images directly requires a different approach to ladder logic construction, but has speed advantages. Controllogix gives you more felxibilty in rung construction, but I typically go with the extra copy instructions to keep neat, veiwable ladder logic.

The speed of controllogix is so good that the extra copying barely adds to the CPU load...

Paul