Structured text FOR loop in Controllogix

(for when OP gets back to this PLC)

What are the values of x and y when the watchdog fault occurs?

What data type is Lamp?

What are typical scan cycle times for the y:=1 to 10 case?

What are typical scan cycle times for the y:=0 to 15 case?

I would have expected to get the watchdog fault 500 mS after calling the ST routine, not after several seconds of running. It makes me wonder if the fault is due to some sort of stack pointer overflow, as you would get if on subroutine called another. which called another, which called another, etc until the calls reached the limit that the system can keep track of.
That was one I frequently threw at the attendees of my PLC training class sessions as a cautionary tale about conditional subroutine calls. I used it because it was one of my personal self-inflicted wounds earlier in my career.
A long shot, but are all the extra semicolons in the second version really there and if so, could they be a contributing factor? I don't know the rules covering their usage in Rockwell's ST implementation, but is there a possibility of them being misinterpreted?

Steve Bailey said:

I would have expected to get the watchdog fault 500 mS after calling the ST routine, not after several seconds of running.

Click to expand...

Agreed. @Steve Bailey's stack overflow scenario is another possibility.

Another unlikely possibility would be that the 16*500 passes of the inner loop per scan cycle averages nearly, but just under, 500ms***, and it takes several scan cycles, plus some stochastic noise, before the we get scan cycle that finally triggers the watchdog timeout.

*** or whatever the watchdog timeout is; do we know what that is for OP yet?

But I think @Steve's first comment is the most likely explanation: the code is logically correct and is not an infinite loop; rather it is a finite loop that simply takes too long.

Perhaps the simplest diagnostic would be aat the start of the function to reset a TON, then aat the end of the function to measure (estimate) how long the function takes, and then vary the duration of the inner x loop e.g. 1 TO 10 instead of 1 TO 1000, then 1 TO 100, etc.

You could also move the second MyTimer call to just before the END_FOR of the outer y loop**, then when the watchdog triggers a fault, you would have a rough idea, from y and MyTimerElapsedTime_ms, how long each pass of the outer loop was taking.

** or even that of the inner x loop, but that would significantly affect the duration of the inner x loop.






TL;DR

I.e. the outer loop takes too long to complete and exit, so the watchdog timer simply times out while the loops are still running during a single scan, which timer faults the PLC.

I am not saying it's good code (e.g. ELSE Lamps:=Lamps; is a useless statement)

One pass of the inner FOR x := ... loop has least three operations: the x:=x+1 statement; the increment of x at the END_FOR; the test of x against 1000 at the END_FOR. There is probably another for the FOR statement (a label?). So that is 2000 operations per inner loop (4 operations/pass * 500 passes per inner loop), or 32000 instructions per outer loop. So if each operation takes an average of 15µs, that is 480000µs or 480ms to complete the loops and a 500ms watchdog timer would not trigger a fault*. But at 16µs per operation the loops would take 512ms if allowed to complete, but a 500ms watchdog timer would interrupt the loops and the scan cycle, and trigger a fault.

* I am ignoring the rest of the code executed in each scan: the calling JSR; the y loop; the test of the Lamps value; etc.

drbitboy said:

So if each operation takes an average of 15µs, ...

Click to expand...

I just looked at this document, and typical instructions times are of order 0.01-0.1µs, with a few around 1µs, and nothing near 15µs, so this is an unlikely explanation.

I have tried the PLC this morning (L55) and when switching on the fault happend within 2 to 3 seconds. Here is the fault:

=========================
07/01/1998 23:45:16
(Type 06) Watchdog Fault
(Code 01) Task watchdog expired. May have been caused by an infinite loop, a complex program, or a higher
priority task.
Task: MainTask
Program: Main Program Routine: 999_AK
=========================

After clearing the fault and switching back to run the program ran for about an hour before faulting, then after resetting again it ran the rest of the day!
No changes made to the routine. I can only guess that somehow the timing is very close to the watchdog limit with the extra loops in the code.

I have now rectified any problems by learning to use the 'TONR' to utilise the delay before incrementing the Lamps tag.

Thanks everybody for you assistance, at least now i know something to watch out for if i need to implement a loop to perform some real operations.

Obviously my response should have been that the fault was YESTERDAY, but had not faulted when i got to it this morning. I have changed the program TODAY to use the TONR.

The PLC is 1756-L55A 1.4

CRMCC said:

Obviously my response should have been that the fault was YESTERDAY, but had not faulted when i got to it this morning. I have changed the program TODAY to use the TONR.

The PLC is 1756-L55A 1.4

Click to expand...

Not to be overly pedantic, but the revision is not 1.4, even though the label says that. They might as well not ever put the revision on the label because it will never be what the label says, at least not by the time it is running a program. 1.x is a boot firmware, all controllers must be flashed to a proper firmware rev. It's been quite a while, but I think the max version that those support is 16.x? Easy way to tell what rev is simply by what major software rev you are using when you are online with it.

Have you checked what the scan time is?

Edit: I put your exact 2nd script in a L55 running v16.022 FW, the max scan time is 72ms. Nowhere near the default watchdog. Can you post your program here? I think it needs to be zipped.