PIDE's in periodic tasks RSLogix 5000

[mellis]

This is true for high speed PID loops with few ms loop update time
Most of applications of PID are for heating and filling applications with loop update time from 0.1 sec and higher
It will be nothing wrong if this task interrupted or executed with slight time deviation (less that 1%)

I agree that most temperature and level loops are pretty immune to this. But, update time is not the only factor for a loop to be susceptible to timing jitter. A loop with an update time of 500ms can be very picky about timing if it has a large amount of integral action. My experience in this area is with liquid blending flow control loops with integral settings around 0.01 sec/repeat. They definitely prefer stable timing.

 

[mellis]

A separate but related question.

Assume I have 5 periodic tasks I want to run. Further assume I want them all to run on 10msec interrupt times. Is the logic engine smart enough to stagger the scheduling so I only get one periodic task run every two milliseconds or does it queue them all up and run them at once? One way will have a much more significant impact on scan time than the other.

Keith

First, since you are running these tasks every 10ms, they have to be short. Let's say they are each 1ms. Does it really matter to the lower priority tasks if they get five 1ms slices every 10ms or one 5ms slice every 10ms? Either way, the lower priority tasks get the same amount of time to run. Both arrangements have the same impact on scan time.

Check out page 4-7 in the ControlLogix Processor Common Procedures manual for a nice graphic showing how periodic tasks interrupt lower priority tasks. Drawing a similar diagram for your own programs can be very helpful to visualize how the tasks will interact. And especially how that poor lowest priority continuous task is going to behave. The scan time can be a very poor indicator of how often the continuous task executes.

I view the continuous task not so much as "the task that runs as fast as it can" (although that is an accurate statement) but more as "the task that gets the crumbs dropped by the other tasks".

 

[kamenges]

This was more of a theoretical exercise than anything. I have yet to run into any issues with this.

However, rdrast's suggestion makes the most sense to me. That provides very controllable response and guarantees that any given pass won't have excessively long processing times.
Fundamentally I do agree that putting everything in periodic tasks and running them on appropriate schedules is the way to go. I haven't done that yet myself but it makes alot of sense.

Thanks for the in fo.
Keith

 

[TConnolly]

Benny, I one other suggestion that is related but slightly off topic.

Are the 13 scrubbers identical of at least functionally nearly identical? If so I suggest you create a UDT for each scrubber to enable some object oriented programming and save some coding. That UDT will contain all the control tags for a single scrubber. Include the PIDE tag in the UDT. Now create thirteeen tags (thirteen virtual scrubber objects) that are of the new UDT type - one for each scrubber.
Now you can write a single subroutine to handle all 13 scrubbers. Because FB does not pass instruction tags very well you will need to move the PIDE to a ST routine. If you feel more comfortable with ladder you can use it to MOV the sp and pv values to the scrubber.pide tag, then execute just the PIDE instruction ST. If you use this method you will have to execute under one task, one program, and the main routine will just call the subroutine 13 times.

Just a thought to save some coding.

PM me an email address if you need to see an example.