What is RPI in a Logix 5000 System?

When you add an I/O module to a Studio 5000 Logix Designer project, you define the RPI, or Requested Packet Interval, for the I/O module. In this edition of Learn Logix, we will learn what RPI is and how the RPI configuration affects the behaviour of a Logix 5000 system.

What is RPI?

In a Logix 5000 system, I/O values are updated asynchronously with the execution of the application code. This is different to many other PLC systems where the value of inputs are updated at the start of the scan cycle, the application code is executed, and the value of outputs are updated at the end of the scan cycle.

The rate at which the values of the points for a specific I/O module is updated is determined by the RPI, or Requested Packet Interval, configuration for the module. The RPI for a module can be configured in the Connection tab of the Module Properties dialog box.

In the example below, the RPI for my 1756-IB16D input module is 20.0 milliseconds.

This means that every 20 milliseconds, the module sends the status of its points to the controller using a multicast message on the backplane.

How Does RPI Affect Application Logic?

Because the value of inputs are updated asynchronously from the PLC scan cycle, the same tag can have a different value at different points in the application code.

For example, imagine that we have an input module with an RPI of 20 milliseconds. We have connected and Photoelectric Sensor to this input module and created an alias tag for the input point called Photo_Eye.

Our PLC cycle time is 50 milliseconds. This means that the status of the Photo_Eye input will be updated 2.5 times in every scan.

In our application code, we check the value of the Photo_Eye tag at Rung 100 and Rung 400 of a Ladder Diagram routine. Since the cycle time of the PLC is higher than the RPI of the module, we may see that the tag has a different value depending on when we check it in the cycle. We may also see that it is time to split our routine up, since 400 rungs is way too many rungs for a single routine :)

A Note on Output Modules

It is worth noting that output modules behave slightly differently than input modules in a Logix 5000 system.

By default, output modules are updated more frequently than input modules. Physical outputs are updated immediately after the execution of an output instruction, at the end of the execution of a task, and when the RPI interval elapses.

If you want, you can disable the updating of output tags at the end of a task execution in the configuration for the task. We will look at task configuration in a future edition of Learn Logix.

How Do I Avoid Asynchronous Updates?

Many PLC Programmers don't want the inputs and outputs used in their Studio 5000 Logix Designer project to update asynchronously from the PLC scan cycle. In applications which do not require high-speed I/O, logic can be easier to develop and debug when inputs and outputs are updated synchronously with the PLC scan cycle.

To force your I/O tags to update synchronously with the PLC scan cycle, it is a common practice to map all of your inputs to local or controller tags in a routine at the beginning of a scan cycle and to map local or controller tags to outputs at the end of the scan cycle.

By using this strategy, the status of input points are updated once at the beginning of the PLC cycle and the physical outputs are actuated at the end of the cycle.

For smaller projects, another more modern approach to synchronously handling I/O is to use input and output program parameters since program parameters are updated synchronously with the program. In applications with one task and one program, this is a good way to manage I/O updates.

Wrap Up

In this edition of Learn Logix, we learned what the RPI, or Requested Packet Interval, is in the context of a Logix 5000 I/O module. We also learned how the RPI configuration for a module can affect your application code and talked about a basic strategy to mitigate the effects of the RPI configuration of a module.

Understanding RPI is important since low RPIs can cause some strange looking behaviour in larger applications and since I/O update times can be critical in high speed applications.