Forums.MrPLC.com: RPI as Related to Scan Time - Forums.MrPLC.com

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

RPI as Related to Scan Time Rate Topic: -----

#1
User is offline   Arun Opto 22 

  • Arun
  • PipPipPip
  • Group: MrPLC Member
  • Posts: 32
  • Joined: 03-February 09
  • Gender:Male
  • Interests:Professional: Automation, Instrumentation, Controls
    Personal: Music (Punk, Rockabilly, Vintage Jazz), Guitar, Golf, Basketball
  • Country:United States
    United States
I have a CompactLogix and some Remote I/O, which I am communicating to using implicit messaging over EtherNet/IP. I'm curious as to the relationship between scan time and Requested Packet Interval (RPI). In setting up my implicit messaging to the remote I/O I'm promted to put in an RPI, which I do (arbitrarily picked 200 ms). My question: I come from a Modicon background, and with Modicon PLCs you don't set an RPI. Bascially, remote I/O is serviced at the end of PLC scan. In Allen-Bradley, which "prevails"...RPI or the scan time? i.e. if my scan time is slower than the RPI or faster for that matter), then what happens?

Arun
0

#2
User is offline   TWControls 

  • Automation Therapist
  • Group: MrPLC Admin
  • Posts: 4,465
  • Joined: 03-October 05
  • Gender:Male
  • Location:Roanoke, Virginia
  • Country:United States
    United States
Scan time and RPI are completely unrelated. In simple terms as I admit I don't know the exact details...

Scan time, whether it be task, program, or routine is strictly the execution of the code and then a percentage of that time , determined by the System Overhead Timeslice, is allocated at the end of the main task for housekeeping such as being online and explicit messaging. It doesn't care if the I/O has been updated or not.

RPI is just what it stands for, Requested Packet Interval. Every 200ms in your case, the Compactlogix will request a new packet containing your I/O states. If your module fails to reply, then the module will fault. The program will continue to scan as if nothing has happened unless you program it to do otherwise. The only indication that something is wrong by default is that the I/O light will begin flashing
0

#3
User is offline   BobLfoot 

  • The Wizard
  • Group: MrPLC Admin
  • Posts: 3,152
  • Joined: 27-March 06
  • Gender:Male
  • Location:Southern Indiana
  • Country:United States
    United States
TW has answered you question quite well, but since you are stepping into the AB waters from Modicon I'll add a little to what TW said that may save you or someone grief in years to come.

The "Traditional AB PLC" and by this I mean SLC 500 and PLC 5 followed a rather simple and ridgid sequence of processing. it went as follows:
1. Resolve Inputs to the Data Table from I/O Devices for Local I/O and from the Remote I/O Scanners I/O Image table.
2. Scan the program Updating the Ouput Image Table.
3. Resolve Outputs from the Data Table to I/O Devices for Local I/O and to the Remote I/O Scanners I/O Image Table.
4. Perform Overhead Tasks - Online Monitor, Messages, ETC
The Remote I/O scanner worked on it's own scanning interval and updated I/O to and from it's Image table.

Then came the "ControlLogix" PLC. This was a dramatic departure from the "Traditional" approach. The Controllogix uses multiple processors internally and reads from and writes to the image table occur as needed throughout the program. The Program execution CPU cycle now pares down as follows:
1. Solve the logic. Updating Image Table as you go.
2. Perform Overhead tasks - Messgaes, Online, Etc.

It is therfore possible in a ControlLogix CPU for an Input to on at Ladder 5 and off at ladder 6 of the same scan.
BobLfoot

"Poor Planning on your part does not a crisis on my part make"
0

#4
User is offline   controlsdude 

  • Sparky
  • PipPipPip
  • Group: MrPLC Member
  • Posts: 69
  • Joined: 10-October 07
  • Country:United States
    United States

Quote

Then came the "ControlLogix" PLC. This was a dramatic departure from the "Traditional" approach. The Controllogix uses multiple processors internally and reads from and writes to the image table occur as needed throughout the program. The Program execution CPU cycle now pares down as follows:
1. Solve the logic. Updating Image Table as you go.
2. Perform Overhead tasks - Messgaes, Online, Etc.

It is therfore possible in a ControlLogix CPU for an Input to on at Ladder 5 and off at ladder 6 of the same scan.



Suggestions for Contrologix programs
Since the Image Table changes during scan time, I recommend you buffer the inputs in one file. Use the buffered inputs in your program. Now you have inputs that only change once during scan time.
Also have a seperate file where the outputs are qualified once in your program if possible. What I mean if you have a continuous task have outputs in one file and if you have an additional time interrupt task then have the outputs in one file under that task.

Now to understand how a motion, event, time, and continuous TASKS work with your IO and messaging I would suggest reading this very informative PDF from Allen Bradley.

Publication 1756-PM005B-EN-P - July 2008
Logix5000 Controllers Tasks, Programs, and Routines


Ths manual would get you up to speed and would explain what programs are executed in what order. Then you would have no doubts on how the processor works. Hope this helps.
0

#5
User is offline   Arun Opto 22 

  • Arun
  • PipPipPip
  • Group: MrPLC Member
  • Posts: 32
  • Joined: 03-February 09
  • Gender:Male
  • Interests:Professional: Automation, Instrumentation, Controls
    Personal: Music (Punk, Rockabilly, Vintage Jazz), Guitar, Golf, Basketball
  • Country:United States
    United States
Guys - Thank You. Excellent information.

Arun
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users