CompactLogix Task scan time vs Program scan time

[chantecler]

Hi,
I modified the structure of a program (let’s call it app) in a CompactLogix 1769-L30ER due to high variation in the output times. I mean the eight outputs should be alternatively on for 250ms periods but I was getting up to 20% variations.
Originally the app consisted of a single continuous task with one main program with two routines.
To make the story short, I divided the app into two periodic tasks with one program each with one routine each. The resulting behavior is highly satisfying.
I’m obtaining these readings from logix designer
Task 1
Period 1ms
Priority 4
Watchdog 500ms
Max. measured scan time 0.520ms
"Std." measured scan time 0.120ms
Interval times [0.630 to 1.370ms]
Program’s max scan time 90us
Program’s "Std" scan time approx. 55us

Task 2
Period 40ms
Priority 10
Watchdog 500ms
Max. measured scan time 0.740ms
"Std." measured scan time 0.400ms
Interval times [39.700 to 40.300ms]
Program’s max scan time 90us
Program’s "Std" scan time approx. 70us

My question is: Why Task 2 uses 0.400ms while the only program in it uses only 70us?

I also have these processor settings:
System overhead 10%
Reserved unused overhead time slice for system tasks
And also reduced the 3 I/O module RPIs from 20.0, 20.0, 5.0ms to 5.0, 0.5, 0.5ms
I’m not quite clear about this.

Thank you

 

[drbitboy]

Is it possible that "Std." means "Standard Deviation?"


Lies, damn lies, and statistics

 

[cardosocea]

Hi,
I modified the structure of a program (let’s call it app) in a CompactLogix 1769-L30ER due to high variation in the output times. I mean the eight outputs should be alternatively on for 250ms periods but I was getting up to 20% variations.
Originally the app consisted of a single continuous task with one main program with two routines.
To make the story short, I divided the app into two periodic tasks with one program each with one routine each. The resulting behavior is highly satisfying.
I’m obtaining these readings from logix designer
Task 1
Period 1ms
Priority 4
Watchdog 500ms
Max. measured scan time 0.520ms
"Std." measured scan time 0.120ms
Interval times [0.630 to 1.370ms]
Program’s max scan time 90us
Program’s "Std" scan time approx. 55us

Task 2
Period 40ms
Priority 10
Watchdog 500ms
Max. measured scan time 0.740ms
"Std." measured scan time 0.400ms
Interval times [39.700 to 40.300ms]
Program’s max scan time 90us
Program’s "Std" scan time approx. 70us

My question is: Why Task 2 uses 0.400ms while the only program in it uses only 70us?

I also have these processor settings:
System overhead 10%
Reserved unused overhead time slice for system tasks
And also reduced the 3 I/O module RPIs from 20.0, 20.0, 5.0ms to 5.0, 0.5, 0.5ms
I’m not quite clear about this.

Thank you

Those watchdogs seem pretty useless, no?

There's a reason that manufacturers tell us to use periodic tasks... we just think we know better because "it's always been done this way".

 

[chantecler]

Is it possible that "Std." means "Standard Deviation?"


Lies, damn lies, and statistics

I should have name it "Avg", it's just the number I see most, no calculations involved

 

[chantecler]

Those watchdogs seem pretty useless, no?

There's a reason that manufacturers tell us to use periodic tasks... we just think we know better because "it's always been done this way".

Thank you. Those are the default values, I really don't ever change them. I believe those are the maximun time the controller will wait for a task to trigger before faulting. I'm going to check that out.

Has it anything to do with my original question?

 

[Operaghost]

A task has overhead for it to execute. One of the overhead items is when the task completes it will update all physical output modules. Output modules automatically get updated at their RPI rate AND at the end of ANY task (unless that task has disabled I/O updates). Plus of course there is time required for the task to perform an interrupt and then to return after the logic has executed.

So even if the max scan time of your only program is 90us, there is overhead on top of that which you see reflected in the task max scan time.

With the need to alternate outputs every 250ms, why isn't there a task set to 250ms?

And to clarify, the watchdog timer begins timing when the task starts, and automatically resets when the task completes. If the watchdog timer reaches the setpoint, the controller will fault. This usually happens when a loop occurs. Your task #1 with a 1ms interval has had a max scan time of .52ms which means it is not far from reaching a point where it will interrupt itself, creating a loop which would cause a watchdog fault.

OG

 

[chantecler]

Operaghost, thank you very very much!!!

 

[drbitboy]

I’m obtaining these readings from logix designer


Task 1
Period 1ms
Priority 4
...

Max. measured scan time 0.520ms
"Avg." measured scan time 0.120ms

Task 2
Period 40ms
Priority 10
...

Max. measured scan time 0.740ms
"Avg." measured scan time 0.400ms

+1 for OG.

Speaking of overhead,

• The 1ms Task 1 is at a lower priority than the 40ms Task 2.
• So approximately every 40 (40ms/1ms) executions of Task 1, the Task 2 will be called to execute,
• and Task 1 at Priority 4 may be interrupted and wait for Task 2 at Priority 10.
• Which will add the scan time of Task 2, typically 0.400ms, to the scan time of Task 1, typically 0.120ms,
• Which may in turn explain why the Maximum scan time of Task 1 is 0.520ms = 0.120ms +0.400ms.

I wonder if you waited long enough if there would be a longer scan time of Task 2, e.g. the max of 0.740ms, and that Task 1 Max scan time would jump to 0.840ms, even closer to an overlap.

 

[Operaghost]

You accidentally switched up the priorities in your example. Task1 with priority 4 is a higher priority than Task2 at a priority of 10. Lower number is a higher priority. But spot on about one task interrupting the other. It would just be Task1 interrupting Task2. Thank goodness they aren't the same priority!

OG

 

[drbitboy]

You accidentally switched up the priorities in your example. Task1 with priority 4 is a higher priority than Task2 at a priority of 10. Lower number is a higher priority. But spot on about one task interrupting the other. It would just be Task1 interrupting Task2. Thank goodness they aren't the same priority!

OG

Whoopsie, thanks! I should have read this first. That makes it over 50% likely that Task 1 will interrupt - or delay the start of - any Task 2, for a typical scan time of Task 2, assuming uniform distribution of Task 2 starting over any ms.

 

[chantecler]

Hi,

Task 2 consist of:
- A 1000 mSec heartbit to monitor comm between two controllers
- Some calculations that could be done only one time because they never change (unless you modify a parameter from the HMI)
- And a I/O status report (via produced/consumed tags) from one controller to the other which has an HMI on a different network.

I didn't design the application, I'm only making it work.

 

[kamenges]

CompactLogix PLCs also have an I/O task that starts at priority 6. With RPI driven I/O I'm not sure exactly what this task does or when it does it but, with 6 being less than 10 the way it is, it will interrupt the priority 10 task if and when it runs.

Keith

 

[chantecler]

CompactLogix PLCs also have an I/O task that starts at priority 6. With RPI driven I/O I'm not sure exactly what this task does or when it does it but, with 6 being less than 10 the way it is, it will interrupt the priority 10 task if and when it runs.

Keith

Thanks,

I know, I chose Task 1 priority higher than I/O task and Task 2 priority lower than that of the I/O task on purpose

I'm not clear about the comm task, neither its priority nor the time it uses