Forums.MrPLC.com > Problem Restting The Counters In A Micrologix 1200

BadgerGuy

Feb 1 2006, 10:58 AM

I added a reset to four of my counters but when I press reset, the counter resets to 1 and not 0 how can I get the counter to reset to zero?

Thanks

jstolaruk

Feb 1 2006, 11:06 AM

Use the cross-reference feature to find any and all pieces of logic that deal with that counter. Some other code is strobing it to count. If need be, post your program here and someone will be able to point it out.

hakko808

Feb 1 2006, 11:12 AM

Check to make sure your counter presets are at 0 and not at 1.

Ron Beaufort

Feb 1 2006, 11:13 AM

smart money says that this post will help ...

Alaric

Feb 1 2006, 12:01 PM

If you reset a counter with the RST and the counter rung is true, it will immediately upcount the next scan. Be sure to see Ron's excellent explanation that he linked to to understand why this is the case.

The quick and dirty solution is to go ahead and program a oneshot on the counter rung. Or you could structure your logic to avoid the situation.

TWControls

Feb 1 2006, 12:51 PM

Or you can move a zero to the ACC instead of doing the reset. The counter will not increment if enabled

keesoon

Feb 1 2006, 02:11 PM

If I move a "0" to the acc, the bits(DN,EN. etc.) change state?

TWControls

Feb 1 2006, 02:24 PM

The CU bit will not go to zero like it will with a RES instruction

According to Ron Beaufort in a previous post

QUOTE

What is the difference between resseting a counter and moving a zero to the accumulated value?

the RES drives the Accumulator to zero ... and ... it also writes zeros to the status bits (CU, CD, DN) ...

this "resetting" of the status bits explains why you were getting the "false" count when using the RES ... specifically, the next time the processor scans the rung and finds the rung TRUE, it checks the CU bit to see "have I already counted this?" ... since the CU bit was OFF (by way of the RES action) then the processor assumes that the TRUE condition of the rung has not yet been counted ... and it adds one to the Accumulator ...

the "MOV of zero" solution for the counter's Accumulator does not "destroy" the "been-there-done-that" information that is stored in the counter's CU bit ... some programmers use a CLR (Clear) instruction rather than an MOV ... you'll get the same results with either method ...

I've also seen other programmers who stick with the RES instruction (possibly because the technicians understand it better) and then put an OSR (One Shot) after the "count this" input ... in most cases, this will also solve the "false count" problem caused by a "count this" input which stays on during a counter reset ... it looks kind of "fishy" to see an OSR in front of a counter ... but once you understand why it's there, it does make sense ...

BadgerGuy

Feb 1 2006, 03:27 PM

QUOTE(TWControls @ Feb 1 2006, 03:24 PM) [snapback]27796[/snapback]

The CU bit will not go to zero like it will with a RES instruction

According to Ron Beaufort in a previous post

QUOTE

What is the difference between resseting a counter and moving a zero to the accumulated value?

the RES drives the Accumulator to zero ... and ... it also writes zeros to the status bits (CU, CD, DN) ...

this "resetting" of the status bits explains why you were getting the "false" count when using the RES ... specifically, the next time the processor scans the rung and finds the rung TRUE, it checks the CU bit to see "have I already counted this?" ... since the CU bit was OFF (by way of the RES action) then the processor assumes that the TRUE condition of the rung has not yet been counted ... and it adds one to the Accumulator ...

the "MOV of zero" solution for the counter's Accumulator does not "destroy" the "been-there-done-that" information that is stored in the counter's CU bit ... some programmers use a CLR (Clear) instruction rather than an MOV ... you'll get the same results with either method ...

I've also seen other programmers who stick with the RES instruction (possibly because the technicians understand it better) and then put an OSR (One Shot) after the "count this" input ... in most cases, this will also solve the "false count" problem caused by a "count this" input which stays on during a counter reset ... it looks kind of "fishy" to see an OSR in front of a counter ... but once you understand why it's there, it does make sense ...

I understant the rung is infact true in start up.
Could I make the counters value -1 at first?

thanks

TWControls

Feb 1 2006, 03:29 PM

If the rung is true the ACC will be 1 on a RES and 0 on a MOV 0 to ACC

Alaric

Feb 1 2006, 04:08 PM

QUOTE

I understant the rung is infact true in start up.
Could I make the counters value -1 at first?

thanks

I believe that the pre-scan sets the counter CU bit when the program first runs at startup. This is supposed to keep an upcount from occuring if the rung is true on the first scan.

If I'm wrong and the prescan is not setting the CU bit then you can specifically set it using the S:1/15 first pass bit just before you execute the CTU instruction. This will prevent the upcount and if the CTU rung is false then the CU bit will be automatically reset so everyting will be ready on the second scan. This is a superior solution because if the rung is ever not true on the first scan then you are stuck with a -1 in the ACC.

Don't be afraid to manipulate the CU bit in your ladder. Understanding it and manipulating it when required can significantly increase the usefullness of counters in many applications.

For example you can build self-aligning sequencers and for-next loops with counters by manipulating the CU bit.