ControlLogix - Periodic Task

[strauden]

Hi Guys,

I've got a problem with a ControlLogix 1756-l61 controller where Watchdog Fault - Periodic task overlap is causing problems.

However it appears that the Priority 1 task (which normally takes 5ms) which is our I/O task and does nothing but map some digitals and analogs is occasionally taking up to 500ms scan time (which is the watchdog limit).

My understanding is that nothing should interrupt the Priority one task (not using motion planner) and as such there is no way that the I/O task should take that long. Is this correct?
So it would appear that the CPU is due for replacement (10 years old) ?

Thanks for your time once again!

 

[PapaSmiff]

I'm not an expert but I found a source that indicates there is a task monitor tool in Studio 5000.

The Rockwell manual I was looking in was 1756-pm005_-en-p. Hope this helps.

 

[strauden]

Yea I used the task monitor tool to see the stats.
I know that the interval should be close to the period, around 50ms. And as it is priority 1, nothing should interupt it. And as it is simple the I/O task it should only take around 5 ms Scan Time.

Type = Periodic
Period (ms) = 50
Priority = 1
Watchdog (ms) = 500
Scan Time Max (ms) = 403.41
Interval Time Max (ms) = 450.006
Interval Time Min (ms) = 46.389
Overlaps = 12

 

[JeremyM]

If this is a simple buffering task, you shouldn't see scan times like that.

Remember, the scheduler in your setup will attempt to execute the periodic task every 50 ms, even if the task to be executed is the one executing. Sooo, for some reason, a subset of that task's executions are taking longer-than-usual and longer-than-tolerable (time-to-execute > period). This is the source of the overlap count.

Check the code for any loops, or perhaps a math-intensive CPT or subroutine call. Is this task also doing the analog scaling work?

Tentatively increasing the period of the task should reduce the overlaps, but it's only a troubleshooting method until you can get more deterministic scan times (if 50 ms periodicity is a hard requirement).

Edit:

Is there an event task being triggered, or another periodic of the same priority? The watchdog timer of any task is the total duration of said task, which includes the task's time to execute all its programs *as well as* the time to execute *interrupting* tasks' programs (a task's watchdog timer does not stop accumulating when the task is interrupted by another).

 

[strauden]

There is nothing in the Task except for a main task that calls four subroutines that have some MOV blocks moving analogs from and to their channel for AI and AO. And some contacts and coils for the digitals for DI and DO.
No scaling is done and no other calculations

There are no other Priority 1 tasks or event tasks that could interrupt it.

 

[PapaSmiff]

Going out on a limb here....

Try putting in -[AFI]- on your rungs (or subrungs), one at a time. Check the scan time each time to see if you made a difference. If so, you found your culprit. If not, try the next.

This is a weird one.

 

[strauden]

I can't do that because it's a live plant and the problem only occurs intermittently. Most of the time the tasks scan fine.

 

[Kev77]

How many other periodic tasks are you running in your program? What are the actual scan times of other tasks, even if they are a lower priority?

The way I understand it, if you have 2 tasks that have the same number it will process each task for 1ms, alternating until the tasks are complete. If you have other tasks at a lower priority, the higher task will complete then move to the lower priority. That being said, the starting point of the lower task is the end of the higher task.

So if you have a 5ms (priority 1) and 15ms (priority 2) task the total time for the 15ms task is 20ms. Maybe the total of all the tasks is too much.

Another option might be to use the GSV instruction and store the max scan times of each subroutine in a tag for troubleshooting. Then you can see which subroutine in the task is the problem.

 

[Ron Beaufort]

excerpts from your first two posts:

Watchdog Fault - Periodic task overlap is causing problems.

occasionally taking up to 500ms scan time (which is the watchdog limit).

Watchdog (ms) = 500

Overlaps = 12

maybe we're not all talking about the same things here ... let's go back to the basics for a second ... are you having WATCHDOG faults - which SHUT DOWN the system? ...

or ...

are you having TASK OVERLAPS – which might be somewhat "troubling" or "annoying" to witness on the monitor screen – but which nonetheless allow the system to actually keep right on running? ...

or ...

maybe BOTH "watchdog faults" and also "task overlaps" which would actually be TWO problems ???

and the easiest/best way to get help with this is to post your entire ACD project file (you'll have to zip it first – forum rule) ...

assuming that you're not allowed to post the program, can you post some READABLE screen shots of what you're seeing?

 

[Ron Beaufort]

an excerpt from your post #5:

There is nothing in the Task except for a main task that calls four subroutines

I don't mean to be "picky" – but here again we might not be speaking exactly the same language ...

technically, what is located "in the task" would be one or more PROGRAMS – not a "main task" as you've said ...

and technically, neither a TASK (nor even a PROGRAM) would "CALL SUBROUTINES" – normally a main ROUTINE would do that – usually by executing a series of JSR (Jump to Subroutine) instructions ...

and technically, that main routine would be located inside a PROGRAM – which you haven't mentioned at all in your description ...

in a nutshell ... TASK > PROGRAM > MAIN ROUTINE > SUB ROUTINE would be the normal layout sequence ...

again – I do NOT mean to be "picky" – but the problems that you're reporting are far beyond "normal" – so I'm just concerned that we're not fully understanding exactly what you're describing ...

and again ... seeing the entire ACD project file would be the best way to nail this all down ...

 

[JeremyM]

Curious: What's the RPI on the actual I/O? How many are there?

 

[Operaghost]

It may not be possible to post the entire .ACD file. But perhaps you could post a few pictures. I would like to see how your Tasks, Programs, and Routines appear.

What has me worried is the interval time that you posted. If you have an RPI of 50ms then the min and max intervals should be very close to that number. The fact that it is 400-450ms means something is preventing the Periodic task from running. That could be the task overlap which has it interrupting itself.

But it would be useful to see what is is your "Tasks" folder if you ar enot able to post the full .ACD file.

OG

 

[JeremyM]

A task overlap won't interrupt the current execution, the to-be-execution just doesn't happen until re-trigger.

 

[Operaghost]

If the task has a priority of 1 and no other task has a priority of 1 then it would appear as though the task is attempting to interrupt itself. Most likely there is a loop in the logic where the scan is getting stuck.

Each attempt at interrupting itself causes the overlap to increase while the logic is still caught in the loop until eventually the Watchdog timer expires and the controller faults.

What is causing the loop in the logic? We need to examine the logic and look for JSR, JMP, FOR-NEXT type instructions.

OG

 

[JeremyM]

Yes, each time the task is is triggered while running, the overlap count increments.

I read your post "something is preventing the Periodic task from running. That could be the task overlap which has it interrupting itself." to mean that the current execution is abandoned/interrupted by the latest trigger of the same task, which doesn't happen - the current execution must finish.

I'm hoping the OP updates this discussion with fresh meat.