Timed interupts in Studio 5000 vs. 500.

From what I can tell the STI timed interrupt in 500 is a real hardware interrupt, correct me if I'm mistaken. I currently use this for exact averaging calculations or PID timing as it jumps to my interrupt routine every time the STI clock expires.

So, the periodic tasks in Studio 5000 seem to be a software interrupt queue or stack where the priority can be set? I'm trying to think of possible errors I can unknowingly induce when needing exactly timing logic when Studio 5000 is stacking/queuing event priorities.

Example: Let’s say a particular periodic task named code1 has a priority of 1, a I/0 tag event task named code2 has a priority of 2 and another periodic task named code3 has a priority of 3 exists in our little program. Thus, we have,
code1 = periodic task = priority =1
code2 = event task = priority 2
code3 = periodic task = priority =3

When code3 triggers and is mid execution, code2 just so happens to trigger which causes the plc to jump to code2. While code2 is in mid execution, code1 just so happens to trigger, causing the plc to jump to code1. Not until code1 finishes will it return to code2 and will return to code3 after code2 finishes. Is this correct as explained in the documentation, or are priority numbers separate from I/O event tasks and priority event tasks where I/O event tasks take priority over periodic and vica-versa?

I'm trying to read all the documentation I can find but I can’t find anything on the studio 5000 PLC processors and if they have modern processor capabilities such as multithreading. Are up to two events simultaneously threaded though while the main program executes on another thread or is it still the same where each piece of code is executed one by one.

Periodic Task execution is synchronised to the system clock.

Event Task execution is triggered by the event configuration becoming true.

When the required interval for a Periodic Task is reached, the periodic task will execute, suspending any other task that has a lower priority.

Sounds simple ? Not so...

Logix5000 covers a range of platforms, and they behave differently.....

On ControlLogix ()1756-xx) processors, I/O data transfer is handled within the "System Overhead Time Slice", which cannot be deferred.

On CompactLogix, I/O exchange is handled in a system task that has a priority that can be over-ruled (I think it's priority 3, but am prepared to be corrected).

None of the Logix5000 series of processors (and by that I mean the firmware they run) are capable of multiple threading. Perhaps that is yet to come (Version 40 perhaps ?). The users code is 100% single-threaded. The "Continuous" or "Cyclic" task has the lowest priority, and will always be suspended while a higher priority task executes.

You can make the O/S run multiple tasks "simultaneously" (not including the "Continuos Task") by giving them the same priority value, but that just creates a situation where the O/S switches between the tasks every 5000uS, i.e. "time-slicing" them, but it needs saying that this is not the same as multi-threading.

The following two Rockwell documents may help:

Logix5000 Controllers Tasks, Programs, and Routines
(2 MB PDF)

Using Event Tasks with Logix5000™ Controllers
(0.8 MB PDF)

can you not read the value of the free running counter and calculate the amount of time that has elapsed since the last time the logic was executed and use that as delta-t in the PID?

V0N_hydro said:

can you not read the value of the free running counter and calculate the amount of time that has elapsed since the last time the logic was executed and use that as delta-t in the PID?

Click to expand...

In theory, this sounds like it should work, except that the integral and derivative terms are accumulative over many iterations of the instruction, not just one, so these values will be unreal.

Thanks daba for the informative reply and thanks Mispeld for the links. This really helps me out. Cheers!

on to programming some awesome stuff.