Global Counter/Timer reset

Hello all

Logiix designer 5K

Been looking around ( not in the right places ) haven't been able to locate an AOI or other instruction for a global reset for counters and timers

Is there such an animal? An where would such an elusive creature be hiding.

Read this
Logix5000 Controllers Program Parameters

And this
Logix5000 Produced and Consumed Tags

Then this
Logix5000 Controllers I/O and Tag Data

And checked the sample code library at RA

Then googled it to death.

Any thoughts?

Any and all appreciated

What do you mean by Global reset? Do you mean all instances of any Timer, reset them with a single instruction? Obviously there is the RES instruction for single timers and counters. I suppose if you created a single array for all your timers, you could do an FLL of the array to clear/reset all timers.

I see what your saying.

Ill give that a try and see if I can get it to work.

Thanks for the time Robert

If your all your timers are TON then a N.C. Bit in series with the timers will reset them. Toggle the bit on to reset and back off to start timing. Just Use the same bit for all. Of course this method will not work for counters. I have never tried to use the FLL instruction on a timer array so I am not sure of the outcome. If you can change the .ACC of the counters to zero this will reset the .DN bit . I don't think changing the .ACC on a timer to zero will reset the .DN bit.

cwal61 said:

..... If you can change the .ACC of the counters to zero this will reset the .DN bit

Click to expand...

That is not correct... The .DN bit is set whenever a CTU or CTD instruction is scanned if the .ACC value is greater than or equal to the .PRE value. This occurs even if the rung is false. Many people use counters as pure counters, and don't bother to put a preset value in (leaving it at zero), so clearing the .ACC or RESetting the counter will not clear the .DN bit.

cwal61 said:

I don't think changing the .ACC on a timer to zero will reset the .DN bit.

Click to expand...

You are correct on this, once a timer is "done" (.DN bit set), any changes to the .ACC, or even the .PRE values have no effect on the .DN bit

John Morris said:

Hello all

Logiix designer 5K

Been looking around ( not in the right places ) haven't been able to locate an AOI or other instruction for a global reset for counters and timers

Is there such an animal? An where would such an elusive creature be hiding.

Click to expand...

For timers, specifically TON instructions, you can reset a group or collection of them, by programming them inside an MCR zone.

Make the starting MCR rung false, all the following logic is scanned as if the power-rail is false - this will reset TON instructions.

For counters, there is no way to reset them without a coded RES instruction, so you would need to provide these in code for the counters you need to reset...... And if you are going to do that, you might as well RES the timers you want to reset as well, and not use the dreaded MCR

thanks daba, But if the counter has a preset greater than zero. Will changing the ACC to zero reset the done bit? Also can you clarify if the FLL will work on a Timer or Counter Array? I thought it would only work on SINT,INT,DINT and Real.

cwal61 said:

thanks daba, But if the counter has a preset greater than zero. Will changing the ACC to zero reset the done bit?

Click to expand...

The .DN bit is set by the processor (assuming a CTU or CTD instruction is scanned) whenever the .ACC >= .PRE, totally regardless of their actual values, positive, zero, or negative. So yes, if you have a positive preset, and set the .ACC to zero, it will be less than the .PRE, so the .DN will go off.

cwal61 said:

Also can you clarify if the FLL will work on a Timer or Counter Array? I thought it would only work on SINT,INT,DINT and Real.

Click to expand...

No, it won't. FLL belongs to the same family as COP and CPS - raw data byte copiers. You would need to use a FAL instruction cycle through timer or counter .ACC members.

Ah the irony.

Actually I'm using the counters as timers. I created a one second "tick timer" use to advance the counters. Soon as the line goes true it starts counting in one second intervals

They can be paused and restarted. The outputs are more predictable, and they usually won't go haywire on ya.

I only use the timers is to do an end of cycle logic clean up for half a second or so.

I did create a reset bit and pulled in all the counter (RES). It seems to work reliably.

In some of the other languages I have used, the counter blocks have a reset built into the logic.

Adapt and overcome ey!

Thanks everyone.

John Morris said:

Ah the irony.

Actually I'm using the counters as timers. I created a one second "tick timer" use to advance the counters. Soon as the line goes true it starts counting in one second intervals

They can be paused and restarted. The outputs are more predictable, and they usually won't go haywire on ya.

I only use the timers is to do an end of cycle logic clean up for half a second or so.

I did create a reset bit and pulled in all the counter (RES). It seems to work reliably.

In some of the other languages I have used, the counter blocks have a reset built into the logic.

Adapt and overcome ey!

Thanks everyone.

Click to expand...

Why do you think you need "half a second or so" to reset anything...

You've already done your resets from the "cycle logic" not running, isn't that enough ?

I have a half dozen actuators that need to be retracted at the end of the last cycle so the tool can be retracted.

I hold the reset long enough to get an "all clear" from the end of stroke limits.

I have other "in process" bits in several subroutines and use the reset to clear those as well. Clear the registers holding the tool dimensions, Clear latches in my output routines.

I hold it just a little longer just to make sure. Call me old fashion. I'm still new to 5K

daba said:

The .DN bit is set by the processor (assuming a CTU or CTD instruction is scanned) whenever the .ACC >= .PRE, totally regardless of their actual values, positive, zero, or negative. So yes, if you have a positive preset, and set the .ACC to zero, it will be less than the .PRE, so the .DN will go off.



No, it won't. FLL belongs to the same family as COP and CPS - raw data byte copiers. You would need to use a FAL instruction cycle through timer or counter .ACC members.

Click to expand...

You can FLL a timer array....However, it would probably clear out the .PRE which is not wanted. So, yeah, FAL would be better. The FLL help actually has a TIMER as a destination in the examples.

Curiosity got me, so I quickly tested in emulate....FLL 0 Timer[0] 10 will clear out all the bytes of a timer array, but as expected will erase the presets as well. Interestingly, FLL 0 Timer[0].ACC 10 also compiles and executes, but only clears out the first index.ACC of the array. Where it's writing 0's to the other 9 bytes is anyone's clue...only tag in my test program (test of type Timer[100]), doesn't generate any errors.

Let me explain my motives for the original post.

Scenario is: Operator walks up to the machine. He's already turned it off going thru the safety barrier. Machine freezes. ( Kinda like turning on the lights and spookin a possum )

Since there is a tool inside the machine, he has to acknowledge the alarm, put the machine in local control, then presses the rest, the machine should take a HOME position, open covers, retract all actuators and present the tool for removal.

In other languages I have found an easy way to make this happen. 5K has all the tools, I just have to identify them all.

I checked all the RA and AB resources and google, thought I would run it through here for one last shot for an easy way to configure it.

Thanks again for your time.

robertmee said:

You can FLL a timer array....However, it would probably clear out the .PRE which is not wanted. So, yeah, FAL would be better. The FLL help actually has a TIMER as a destination in the examples.

Curiosity got me, so I quickly tested in emulate....FLL 0 Timer[0] 10 will clear out all the bytes of a timer array, but as expected will erase the presets as well. Interestingly, FLL 0 Timer[0].ACC 10 also compiles and executes, but only clears out the first index.ACC of the array. Where it's writing 0's to the other 9 bytes is anyone's clue...only tag in my test program (test of type Timer[100]), doesn't generate any errors.

Click to expand...

FLL 0 Timer[0] 10 is actually an instruction that will attempt to fill 120 bytes of memory.

This is because the instruction calculates the number of bytes to copy from the Length specified (10) multiplied by the size of the destination data-type - In this case a TIMER is 12 bytes. The instruction will "self-terminate" if there is no more destination tag or member to fill. COP and CPS work the same way.

FLL 0 Timer[0].ACC 10 will calculate the number of bytes to fill as 40, (since the destination is a 4-byte DINT), and start filling at the specified member of Timer[0], and will continue filling 40 bytes from there, ending at Timer[3].ACC

The attached picture shows this in operation, and from this,and an experiment using Timer[0].PRE as the destination, I deduce that the order of the Timer data storage elements is Control BOOLs (will occupy a 32-bit word), .PRE, then .ACC

If you incorrectly specify the length for a FLL or COP, as already stated, they will self-terminate at the next tag boundary, which makes it as safe as it can be. However, if the destination tag array is part of a UDT, FLL, CPS and COP instructions will continue into the next UDT elements !!

Daba, before posting, I did the exact same experiment as you did above, except using the .ACC as the target.

Timers[1], [2] and [3] were unaffected by FLL 0 Timers[0].ACC 10, so your assumption
"FLL 0 Timer[0].ACC 10 will calculate the number of bytes to fill as 40, (since the destination is a 4-byte DINT), and start filling at the specified member of Timer[0], and will continue filling 40 bytes from there, ending at Timer[3].ACC"

is contrary to what I saw in Emulate....are you running in Emulate or an actual processor? What version (I'm v20)? It seems odd that in the tag browser, the order of elements of your timers is different than mine too.