JSR and timers

Micrologix controller, I need to add a timer in a subroutine, can any help me understand how the timer in the subroutine reacts? Will I stay in the subroutine while the timers times or do I scan once thru the subroutine? Any help would be greatly appreciated.

Scans once through the subroutine. A Timer doesn't really "time" in real time. It tracks previous clock vs current clock and calculates elapsed time. So each time through the subroutine, the timer updates the elapsed time (Accumulated). If you quit calling the subroutine before the timer accumulates, it would stop in place.

cornbread said:

Micrologix controller, I need to add a timer in a subroutine, can any help me understand how the timer in the subroutine reacts? Will I stay in the subroutine while the timers times or do I scan once thru the subroutine? Any help would be greatly appreciated.

Click to expand...

You do not have a grasp of how PLCs in general work.

The user code is "scanned" continuously, no instruction will ever stop the code being scanned.

Each time a rung of logic is scanned, it is evaluated, the output instruction(s) are executed, and the scan continues.

As already stated, a TIMER isn't actually a timer, it is simply an instruction that compares the current PLC clock to the previous time it was scanned, calculates how much "time-periods" to add to the accumulator value, updates the accumulator accordingly, stores the current PLC clock data (internally), then tests to see if the accumulator value is greater-than, or equal-to, the preset value. If it is, it sets the .DN bit.

Because of the way TIMER instructions work, it will always be possible (especially with a fast TimeBase) to see a .DN timer with the .ACC greater than the .PRE, because it wasn't scanned at the time the timer preset would have occurred. The explanation above also tells you that TIMER instructions can never be "accurate".

daba said:

.......The explanation above also tells you that TIMER instructions can never be "accurate".

Click to expand...

Now, that said......Back away from the cliff. Timers are accurate enough in most cases that they are very commonly used. There is some inherent error involved as daba mentions, and also accumulating error but we won't get into that.

If you need precision timing, then timers aren't a great solution. There are other options called interrupts that are better. They are more complicated and are more limited on the MicroLogix than on the more powerful Logix 5000 controllers.

If I need an output to energize for ten seconds and I don't care if it is 10.00 or 10.05 seconds, then I am good with a timer. Look at your controller scan time, lets say it is 25 milliseconds. Worst case, your ten second timer would be off by that amount of time. If that is acceptable then a timer will work just fine.

OG

Operaghost said:

Now, that said......Back away from the cliff.

Click to expand...

I was nowhere near the edge - notice that I put "accurate", not accurate.

I have seen timer misuse, or should that be abuse, many times.

On one occasion I came across a Logix5000 application that had a timer with a preset of 25 (that's 25mS), in an application with a scan time of about 45mS. The programmer was having a hard time understanding why his timer wasn't doing the job...

I'm hoping my explanations help others in the proper, or best, use of timer instructions.

At least my post generated some interest, many thanks.

Maybe obvious but worth mentioning anyway -- this is a good reason to pay attention to the performance of your program, or rather pay attention to your scan time. E.g. if I have a lot to do, I try to spread it out over consecutive scans so that scan time is minimized. I'm a big fan of using round-robin scheduling on the MLs.

In Logix 5000 you can get microseconds from the clock (and use that instead perhaps), but the RTC in the ML goes in 2 second increments, so your only option is to keep your scan time to a minimum if you want relatively accurate timing on short duration timers.

Epy said:

In Logix 5000 you can get microseconds from the clock (and use that instead perhaps), but the RTC in the ML goes in 2 second increments, so your only option is to keep your scan time to a minimum if you want relatively accurate timing on short duration timers.

Click to expand...

There is a 16-bit free-running clock S:4 incremented at 100uS intervals. It keeps options open....

daba said:

There is a 16-bit free-running clock S:4 incremented at 100uS intervals. It keeps options open....

Click to expand...

Just thinking out loud, what good would a free running clock do for timing? You still need logic to evaluate the value of the register, and that has the same scan time limitations as a timer. In otherwords, any compare statement to S:4 would still be subject to error due to scan time.

daba said:

There is a 16-bit free-running clock S:4 incremented at 100uS intervals. It keeps options open....

Click to expand...

I stand corrected, thanks for the tip. Might use that.

daba said:

I was nowhere near the edge ......

Click to expand...

My apologies daba. I was intending to tell cornbread to back away from the edge, not you. Just in case you scared him/her on using timers. You were spot on with everything you said and I take no exception to any of it.

Sorry, I should have been clearer as to whom I was speaking.

OG

cornbread said:

Micrologix controller, I need to add a timer in a subroutine, can any help me understand how the timer in the subroutine reacts? Will I stay in the subroutine while the timers times or do I scan once thru the subroutine? Any help would be greatly appreciated.

Click to expand...

It will depend on how the subroutine is being called. If there is an unconditional rung calling the subroutine, Ie: (1)-------- JSR, then the timer will function as expected. If the subroutine is only being called as needed Ie: (1)----| |------- JSR, then you will run into issues with the timer bits not reacting when you think it should due to the processor not updating those bits unless your subroutine is being called.


Wubba.

There is no "depends". The scan will not stay in the subroutine until the timer completes.

As described above by daba, the subroutine is scanned once and then the scan returns to the main routine. Then on the next scan the process runs again. If the rung with the JSR is still true then it jumps to the subroutine again and the timer adds the elapsed time to the accumulator. If the rung containing the JSR is false then we do not jump to the subroutine and the timer remains frozen at its last value. It does not reset, it does not continue timing.

OG

Operaghost said:

There is no "depends". The scan will not stay in the subroutine until the timer completes.

OG

Click to expand...

That is completely and technically correct, and I didn't mean to imply that the processor will stay in the subroutine until the timer finishes. However, if the subroutine is unconditionally called from the main routine, then the timer will function in the same manner as it would if it were on a rung in the main routine. The timer and it's associated bits will be updated once per scan. I took the OP's question to relate more how the timer and its associated bits will function in a subroutine, and as such, it depends on how the subroutine is called.


Wubba.

I wonder how long the debate will continue before cornbread acknowledges the efforts made to answer his question ....

The 'debate' will continue forever as long as someone believes that the instructions are 'magic'. That somehow 'real' counter or timers exist which are doing their magic 'counting' or 'timing' apart from being an instruction which implements specific rules at specific points in the code execution. The best comparison is hardware 'high speed counters' which may operate irrespective of the ladder logic scan.

If too literal a comparison is made with a control structure of actual relays and counters which are doing their thing independent of other contacts and coils then the misinterpretations will occur.

The best we can do is state that PLC ladder logic is an crude imitation of real world relay logic. It has many advantages and disadvantages compared to physical objects. For example, the idea of a 'race condition' is totally different between the two methods of control.