Jump to content



Photo
- - - - -

RPI as Related to Scan Time

  • Please log in to reply
4 replies to this topic

#1 Arun Opto 22

Arun Opto 22

    Arun

  • MrPLC Member
  • PipPipPip
  • 32 posts
  • Gender:Male
  • Interests:Professional: Automation, Instrumentation, Controls
    Personal: Music (Punk, Rockabilly, Vintage Jazz), Guitar, Golf, Basketball
  • Country:United States
    United States

Posted 19 February 2009 - 11:37 AM

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

#2 TWControls

TWControls

    Automation Therapist

  • MrPLC Admin
  • 4532 posts
  • Gender:Male
  • Location:Roanoke, Virginia
  • Country:United States
    United States

Posted 19 February 2009 - 12:48 PM

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

#3 BobLfoot

BobLfoot

    The Wizard

  • MrPLC Admin
  • 3161 posts
  • Gender:Male
  • Location:Southern Indiana
  • Country:United States
    United States

Posted 19 February 2009 - 01:32 PM

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"

#4 controlsdude

controlsdude

    Sparky

  • MrPLC Member
  • PipPipPip
  • 69 posts
  • Country:United States
    United States

Posted 23 February 2009 - 09:49 AM

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.

#5 Arun Opto 22

Arun Opto 22

    Arun

  • MrPLC Member
  • PipPipPip
  • 32 posts
  • Gender:Male
  • Interests:Professional: Automation, Instrumentation, Controls
    Personal: Music (Punk, Rockabilly, Vintage Jazz), Guitar, Golf, Basketball
  • Country:United States
    United States

Posted 26 February 2009 - 08:47 AM

Guys - Thank You. Excellent information.

Arun




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users