How to create delay in continuous task?(RSLogix5000)

[Salman S.]

I have a RSLogix5000 project that I need to test for various program sizes, in order to validate its robustness. I want to introduce delay in my continuous task, such that it increases the time taken to complete one scan.

Is there a way to do this without creating a lot of dummy instructions? I am using ControlLogix for this project.

Any suggestion is much appreciated.

 

[Ron Beaufort]

see if this idea helps ...

http://www.plctalk.net/qanda/showthread.php?p=6351&postcount=20

 

[Salman S.]

Hey Ron thanks!!

I haven't tested it out yet but conceptually it should work. Pretty confident it will, so thanks in advance.

 

[daba]

I do this a lot when training, to simulate a larger program...

I use a FOR instruction to execute a (sub)routine a large number of times. Use a DINT as the looping variable, and you can introduce huge delays by making the target very large.

You don't need to put any code in the called routine, the overhead of calling it and returning from it can create a substantial simulated scan time.

One of the things I use it for is demonstrating that "Toggle Bit" from the programming software does actually work, and highlighting how program scan affects what you actually "see", either on the programming software display, or in other places of the code.

 

[robertmee]

If you don't want to create another routine to call, a large FAL or FSC instruction might do the trick also.

 

[daba]

If you don't want to create another routine to call, a large FAL or FSC instruction might do the trick also.

That necessitates creating array tags for the instructions to work with - my solution is simpler, and doesn't need any tag memory, it takes me but a few seconds to set up, as i do it live in class.

And it's easier to change the simulated "delay" just by editing the target value in the FOR instruction, which I think the OP would prefer....

 

[robertmee]

That necessitates creating array tags for the instructions to work with - my solution is simpler, and doesn't need any tag memory, it takes me but a few seconds to set up, as i do it live in class.

And it's easier to change the simulated "delay" just by editing the target value in the FOR instruction, which I think the OP would prefer....

No arrays are needed at all? FAL or FSC instructions don't require any array...Granted, the most common use is doing arithmetic operations or compares on an array using the .POS of the FAL/FSC, but it's not necessary....you can do a complex math computation into the same tag over and over on the FAL, and for the FSC you could do 1 =2 if you wanted.

Not sure why one or two tags (one control and one destination tag for FAL, just one control for FSC) would be any more memory than an entire routine.

But hey, no need to argue about which is better....Just different ways to skin a cat that's rarely skinned in the practical world.

 

[Salman S.]

Thanks for the alternative suggestions Robert and daba. I am always open to different suggestions as it helps me broaden my understanding.

On a side note, I already used Ron's suggestion.

Will try the other methods out later. Thanks again.

 

[Salman S.]

I just wanted to clarify one more thing. Based upon my understanding, a higher priority periodic task interrupts the continuous task whenever a set time elapses. However, would the scan time for the continuous task pause, while its waiting for processor?

If you further breakdown my query, in order to avoid faulting should the watchdog timer for continuous task account for periodic tasks too? Obviously, if it doesn't halt, the answer to my query would be no, the timer runs. I assume it does run since I faulted my controller doing so, hence I wanted to confirm my findings.

I hope I am not being too inquisitive.

 

[Ron Beaufort]

would the scan time for the continuous task pause, while its waiting for processor?

yes - the execution of the continuous task will "hold in place" until the periodic task gets finished ...

in order to avoid faulting should the watchdog timer for continuous task account for periodic tasks too?

that would be ONE way of handling the problem - but the larger question would be "why is your periodic task taking so long to finish?" ... in other words, you probably need to take some corrective programming action to trim down the length of time required for the periodic task ...

I hope I am not being too inquisitive.

not at all ... that's why we're here ... bring it on ...

 

[Ron Beaufort]

just another thought that MIGHT be helpful ...

a TON is not really a "timer" the way most people think that it is ... instead it is a timer "instruction" - which tells the PLC processor to "service" or "update" the timer "structure" which exists in the processor's memory ...

so ...

technically speaking, the "timer" will not advance/run/increment its accumulator - except for when the processor executes/scans the TON rung ...

in simpler terms, if the TON instruction isn't being scanned/executed, then the timer's accumulator will not run/advance in the memory/background ...

the ideas in the following link might be helpful if you'd like to follow up on this subject ...

http://www.plctalk.net/qanda/showthread.php?p=77865&postcount=9

 

[Ron Beaufort]

and something tells me that you might be interested in the idea covered in the following link too ...

http://www.plctalk.net/qanda/showthread.php?p=376167&postcount=61

specifically, a periodic task can interrupt the "continuous" task EVEN PARTWAY THROUGH A MATH CALCULATION instruction ...

 

[Salman S.]

Sorry, you misunderstood my query, mainly due to the way I phrased it. I thought the watchdog timer follows the scan time, hence I specifically asked with regards to scan time. Based on your response I assume the scan time freezes but watchdog timer keeps ticking. Is that correct?

that would be ONE way of handling the problem - but the larger question would be "why is your periodic task taking so long to finish?"

I am delaying it purposefully to test if its affected by the scan time of the periodic task.

I basically want to confirm which of the two following cases is correct.
Case A: The watchdog does indeed stop, so each scan of the continuous task can take way beyond the WD timer.
Case B: WD time must account for all delays in other periodic tasks

I am already aware the controller stops middle of any operation during an interrupt and returns to it once the higher priority task is processed, but thanks for the additional links. Always good to learn new things.

 

[daba]

Sorry, you misunderstood my query, mainly due to the way I phrased it. I thought the watchdog timer follows the scan time, hence I specifically asked with regards to scan time. Based on your response I assume the scan time freezes but watchdog timer keeps ticking. Is that correct?


I am delaying it purposefully to test if its affected by the scan time of the periodic task.

I basically want to confirm which of the two following cases is correct.
Case A: The watchdog does indeed stop, so each scan of the continuous task can take way beyond the WD timer.
Case B: WD time must account for all delays in other periodic tasks

I am already aware the controller stops middle of any operation during an interrupt and returns to it once the higher priority task is processed, but thanks for the additional links. Always good to learn new things.

The task watchdogs are not timers that can be frozen during interrupt (higher priority task) processing. This is similar to the way TON, TOF, and RTO instructions are processed as explained by Ron. There are no physical timers associated with watchdogs, it is all done with computation. A task execution time is derived by comparing its recorded start time with the current system time, so you can't halt or pause it's progress.

When any task starts, its "start-time" is recorded, and while the task is being executed a test is done (presumably in the "System Overhead Time-Slice", or "housekeeping" period) to determine how long the task has been "active". So, if "current-time" - "start-time" > "watchdog" then the task has exceeded the allowed watchdog time, and the processor will declare a watchdog fault.

Therefore, Case B in your post is the correct assumption.

 

[Salman S.]

Thanks for the clarification Daba. Main issue was my misconception of watchdog timer's correlation with scan time, which is non-existent.

All the pieces are in place now.