Timer question

[Garyhlucas]

I've noticed that a timer keeps running after it reaches it's preset if the rung stays on. Seems like a waste of resources updating the timer if it is done.  Specifically I have system power up timers that delay programs from starting immediately on power up. Do I need to do something different?

Thanks,

[franji1]

You might look at the TMRA - Accumulating Timer.  It WILL stop timing when the ENable leg goes low, but will NOT reset (there is a separate/second input leg for the reset behavior in TMRA).

[BobO]

I've noticed that a timer keeps running after it reaches it's preset if the rung stays on. Seems like a waste of resources updating the timer if it is done.  Specifically I have system power up timers that delay programs from starting immediately on power up. Do I need to do something different?

Thanks,

I guess it depends on how you define 'done'. The way they are implemented, they accumulate time independently of setting the preset output. That gives you the option of using external logic to set additional presets, or to manipulate the accumulator or preset externally.

For something like that, I would generally use a timed initialization stage. Timer logic won't be invoked at all after you jump out.

[Garyhlucas]

Okay,
That all makes sense. Just never noticed it in other PLCs.

[BobO]

Okay,
That all makes sense. Just never noticed it in other PLCs.

We're probably weird, but we kinda like it that way.

[ATU]

Keep updating those timers, I like it that way.
If you want to reduce scan time, put each timer in a stage and then jump out of the stage when the timer is done.
It completely removes that timer from the scan.

[deep6ixed]

Scan time is an issue?  I'll be honest, I've never had an issue with scan time on any PLC program I've ever written.  And the Do-More is crazy fast so Im sure I wont start having issues.

Now if the Do-More ever switches to the Async Inputs like the AB MicroLogix, Im going back to the DL series.  I say that because on my trip to another plant the PLC engineer was showing me some new upgrades and I couldn't understand how the PLC updating inputs anytime in a scan was better... "So you have to write a block of code to do what our PLC's do naturally?  And this is better how?"

[Controls Guy]

Yeah, that's always been my feeling about asynch I/O as well, but I suspect it's a side effect of the However-Many-PLC's-You-Want-In-The-Rack nature of the CLX.  If there are multiple PLC's that have to be served the I/O, then the rack (or the modules) probably needs to do the pumping.

So if that's the case, then it's not so much that it's "better" as it is that AB had no other idea how to make it work.

[BobO]

I am not familiar with AB's implementation, but I am absolutely against allowing I/O to change asynchronously to the logic scan. While implementing an I/O-centric feature in the new platform, we were faced with the possibility of the input state changing while executing the scan. We made changes to ensure that couldn't happen.

Rest easy...Do-more won't go there.