Counter and one-shot

flekica

Member
Join Date
Jul 2004
Posts
2
Is the use of one-shot necessary when trying to accurately increment a counter?
What if you move acc value FROM that counter to some integer location?
Will it cause counter to increment on the next scan in logic remained true?
What am I missing?

I'm talking about AB PLC5 and SLC5 processors.
Thanks
 
No you don't need a one-shot. A counter by it's nature will act like a one shot, will increment or decrement when the logic preceeding it goes from false to true regardless of how long it is on.

As far as moving data from the counter (.acc) to an integer, no it will not disturb the accumulated value. However you can write from an integer into the accumulated value and change it.

hope this helps
 
One thing to watch out for is what happens when the counter is reset while the input is true.
With 1774, PLC2, and ControlLogix the counter 'resets' to 1. I can't recall the actions of PLC3, PLC5, and SLC.
Reason is that the reset instruction clears all control bits, allowing the counter to see a transition on the CU bit on the next scan.
 
No. The input does not need to be a "one-shot".

A counter is triggered to increment or decrement by the "transition" of the input control-bit from OFF to ON.

Any method you can think of to cause the transition to occur will cause the counter to count-up or -down.

The act of "reading" an accumulated value has no effect on the accumulated value.

If you "copy" the value from the accumulated register to a V-mem location, you are doing nothing more than taking a snap-shot of the accumulated value at that time.

As long as the counter is still enabled, the original value is still in the accumulated register and it is still subject to being incremented or decremented by the input control-bit transtion from OFF to ON.

If you disable the counter, even if the input control-bit is still on after the last transition, then the accumulated value is reset. In some PLC's that means that the accumulated value goes to zero. In others, the accumulated value is reset to the preset value.

Both methods are equally adequate. You simply need to know how your counter works.

If you then re-enable your counter, with the input control-bit still ON, then... depending on the particular brand of PLC, the accumulator might or might not show a one-count change.

The counters in some PLC's ignore the input control-bit if it is ON when the counter is enabled. These counters look for OFF-ON transitions after they are enabled.

The counters in other PLC's will respond to the input control-bit immediately. These counters assume that the input control-bit was OFF while they were asleep... whether it was or not. This is not a problem if you are aware of the way your counter works. The work-around is simple.

It is easy to verify the way your counter works. Simply create the situations that test the questions.

To get a real good feel for how this stuff works, you should try to Be the Computer! The computer is nothing more than a "book-keeper". Look at your process from the computer's point of view.
(46)
 
The counters in some PLC's ignore the input control-bit if it is ON when the counter is enabled. These counters look for OFF-ON transitions after they are enabled.


In RSLogix for the AB line the counter only responds if the preceeding logic of the rung is true, not if the rung just came true.

So if you are counting pulses from a prox on a conveyor sprocket, in RSLogix the program will count one every scan of the PLC for as long as the sprocket tooth dwells over the prox, not one for every tooth of the sprocket as it comes up - that would require a one-shot.

As a lot of programmers work on different brands, they learn to program in a way that most PLC's will respond to, which includes adding one-shots when not really needed, because another PLC would require one and they don't have to reconfigure their thinking because the brand name changed.
 
Last edited:
Are you sure about that? The following is from the SLC Instruction Help file on the CTU (count up):
Description

This output instruction counts up for each false-to-true transition of conditions preceding it in the rung and produces an output when the accumulated value reaches the preset value. Rung transitions might be triggered by a limit switch or by parts traveling past a detector.

The ability of the counter to detect false-to-true transitions depends on the speed (frequency) of the incoming signal. The on and off duration of an incoming signal must not be faster than the scan time.

Each count is retained when the rung conditions again become false, permitting counting to continue beyond the preset value. This way you can base an output on the preset but continue counting to keep track of inventory/parts, etc.

IF it only counts on a false to true transition this is saying that it must go from true to false before it can count again. I wouldnt think it would count every scan if the rung stayed true.
 
In RSLogix for the AB line the counter only responds if the preceeding logic of the rung is true, not if the rung just came true.

So if you are counting pulses from a prox on a conveyor sprocket, in RSLogix the program will count one every scan of the PLC for as long as the sprocket tooth dwells over the prox, not one for every tooth of the sprocket as it comes up - that would require a one-shot.
That is ABSOLUTELY WRONG

Terry - did you read this?
I'm talking about AB PLC5 and SLC5 processors.
This sums it up
No. The input does not need to be a "one-shot".
 
Terry, yes I read what you said. This stuff I am fairly familiar with on several brands so got what you were saying.

My above post was to cnrservices comment:
In RSLogix for the AB line the counter only responds if the preceeding logic of the rung is true, not if the rung just came true.

So if you are counting pulses from a prox on a conveyor sprocket, in RSLogix the program will count one every scan of the PLC for as long as the sprocket tooth dwells over the prox, not one for every tooth of the sprocket as it comes up - that would require a one-shot.es comment

Thats why I placed the SLC instruction help on CTU in the question. I knew the statement was incorrect but I have to attempt not to sound argumentative, which many know I can be.
 
Last edited:
Ron...
Ooops... I thought your comment was directed at me.

I agree, Ron.

cnrservices...

I've been down this particular path many times. I find that I prefer ketchup with my crow.


Gerry said...

"Terry - did you read this? (Quote) I'm talking about AB PLC5 and SLC5 processors."

Yes I did. I gave a generalized answer that covered all PLC types. So?

This sums it up (Quote) No. The input does not need to be a "one-shot".

Wasn't that the first sentance in my response...

I had better go lay down... I'm getting so confused....
 
Gerry hit it dead on.

The AB counters will count up (or down) if the input conditions are true, and the relevant control bit (CU or CD) is a "0". The accumulators are retentive in the AB PLC5 and SLC-500 series units.


For the CTU:

When the input conditions go true, if the CU bit is false, then the counter will increment, and the CU bit will be set. When the input conditions go false, the CU bit is reset, and the counter is ready to count again. The CU bit effectively is the inherent "one-shot" of the CTU.

For the CTD:

When the input conditions go true, if the CD bit is false, then the counter will decrement, and the CD bit will be set. When the input conditions go false, the CD bit is reset, and the counter is ready to count again. The CD bit effectively is the inherent "one-shot" of the CTD.


Marc
 
To expand a little on what Marc has said...
If the input conditions to the counter are held true and elsewhere in the program you unlatch (OTU) the CU (or CD) bit, the counter will count.

Terry - no offence intended, just a little dig in response to your reply to Ron. beerchug (MGD)
 

Similar Topics

I have a quirky piece of ladder in RSLogix 5000 that is not acting the way I thought it should. I thought since a counter increments on a rising...
Replies
4
Views
1,939
Hi Guys, I have a 1769-L24-QBFCB1 that has the OK light flashing on the embedded counter module. The manual states it is a resettable fault, but...
Replies
0
Views
112
Hey Everyone, After reading a lot on this forum and elsewhere I see not many are fond of the 1794-VHSC module. I can see to a degree as I was...
Replies
3
Views
178
Hello Folks, Has anyone configured a Momentum high speed counter on Unity 13.1. We need the wiring diagram for Momentum High speed counter and...
Replies
0
Views
83
Hi all, I am working with an incremental encoder (ABZ signals, 360 ppr (so 1440 counts per rev)) to replace the existing "manual" encoder wheel I...
Replies
51
Views
2,655
Back
Top Bottom