Question about OSR

[robertmee]

as I said the reset and count up are independent functions one can happen without the other
As long as the count rung stays true the counter will only count 1 time
in the next scan after the reset the counter acc value will be 0
it needs a false to true transom to count, holding it on will do nothing.
the best way to count the boxes is to have the sensor connected to an off delay timer,
box present timer DN bit is on the when the box is past the timer times down and resets the DN bit
preventing the sensor from fluttering on and off with the box present
the DN bit of the timer is used as the input to the count up
this will keep you from counting multiple times for each box.

Read the counter info closely....you're missing a key bit of info. The counter uses the en bit internally for the false to true transition to know when to count. When a false to true occurs the counter increments and sets the .en bit. As long as the .en bit remains true it doesn't count....that's the internal oneshot. However the RES not only clears the ACC bit it clears the DN and EN bits. So now the counter has lost the internal one shot. So next scan it will count again due to the RES if the prox is still true. This has come up often on this forum and I thought like you before, but I was set straight. Test it in code and you'll see.

 

[Rocguy]

Here is what the book is saying about that part.

The retentive OSR instruction is true for only one scan and then false again, even if the triggering proximity switch signal stays true. This may be required for the count pulse to operate properly.

After a count of 50, the done bit of the counter changes state to stop the conveyor motor automatically and reset the counters accumulated value to zero

 

[jrsnydley]

I think the discussion has strayed from the original poster's question. Regardless of why it is used in this scenario, a OSR is used to make the rung true for one scan only and resets on a true to false transition. The processor scans an entire program in a fraction of a second. Without the OSR, if the processor scans again before the input has a true to false transition, it would execute the instruction again causing an error in the count.

 

[Operaghost]

what would happen if the counter was at 49 and then the counter input went true? Think it through. It is easy to miss this. Many programmers do.

OG

 

[Operaghost]

I think the discussion has strayed from the original poster's question. Regardless of why it is used in this scenario, a OSR is used to make the rung true for one scan only and resets on a true to false transition. The processor scans an entire program in a fraction of a second. Without the OSR, if the processor scans again before the input has a true to false transition, it would execute the instruction again causing an error in the count.

No jrsnydley, the OSR is here for the RES. We are spot on topic. And your comment about it (CTU) executing again causing an error is not correct. Read the posts from Daba and Robertmee. The CTU itself doesn't need the OSR. We NEED it so it will properly reset.

OG

 

[Operaghost]

..........After a count of 50, the done bit of the counter changes state to stop the conveyor motor automatically and reset the counters accumulated value to zero

What happens on the next scan? Look at Robertmee's post for the answer, but think it through. What happens to the .EN and the >DN bits?

OG

 

[Operaghost]

Sorry for the multiple posts. I was away and I've seen a lot of comments that need clarification/explanation.

.....it will be reset with the DN bit or the input is true but the count will not be added until the rung goes false and true again.

This is where people go wrong. That part, "until the rung goes false and true again" is incorrect. This an incorrect understanding of how the counter (and reset) works. But, it is a common mistake. Daba and Robertmee are giving clear explanations.

OG

 

[jrsnydley]

Yeah, I guess I read the question as how does a OSR work but I see now it asks about the counter instruction. I've never used a CTU without a OSR or ONS instruction. I never realized it was built in.

 

[Geospark]

This is 101 stuff, but it can be tricky.

This is from Rockwell themselves...

48922 - On a counter is reset, the accumulated value set to 1 instead of 0
Access Level: Everyone

...but I don't feel it is all that clear or very well explained. I don't think the Author's native tongue is English by the sound of it?

For starters, the title of the technote should read...

"Sometimes, when a counter is reset, the accumulated value is set to 1 instead of 0. Why does this happen?"

However, it does try to explain what the guys have better explained here. I've only posted it up as proof of an official stance from Rockwell on the matter.

GaryS,

You, and perhaps others, seem to have some misconceptions here as to how Counter instructions execute and are reset?

The following is assuming no One Shot instruction is used...

...the reset and count up are independent functions...

They are not independent...

For a Count Up (CTU) instruction, the Reset (RES) instruction, when executed, will reset the Count Up Enable (CU) bit to zero (0) and reset the Accumulated (ACC) value to zero (0). The rung-condition-in for the CTU instruction, at the time the RES instruction is executed, will have no control over this. The CU bit will be reset to zero (0), regardless.

...As long as the count rung stays true the counter will only count 1 time...

No. Not the rung condition. As long as the CU bit stays set (1) the counter will only count 1 time...

If the RES instruction has been executed after the CTU instruction, then the CU bit is now reset to zero (0), and the Counter's detection of the last false-to-true transition is now reset ready for another detection.

...in the next scan after the reset the counter acc value will be 0...it needs a false to true transom to count, holding it on will do nothing...

No. Again, not the rung condition. To do nothing it needs the CU bit to remain set (1)...

At the next scan of the CTU instruction rung, after the RES instruction, with the rung-condition-in still true, and the CU bit still zero (0), the CTU instruction will execute and the CU bit will be set to one (1) and increment the ACC value to one (1). The Counter has now counted the same false-to-true transition twice.

As the RES instruction is often executed when the Counter's ACC value is equal to its PRE value i.e. the Done (DN) bit is set to one (1), it is usually expected, or desirable, that the Counter will reset and not count again if the rung-condition-in to the Counter instruction is still true. The above explanations (not just mine) would hopefully demonstrate that this is not the case and that false counts may be observed upon a Counter reset.

Using a One Shot Instruction...

Using a One Shot instruction (OSR in this case), between the preconditional logic (the input) and the Counter instruction, prevents the Counter from detecting that the rung-condition-in before the One Shot is still true, after the Counter's CU bit has been reset. The One Shot instead becomes the Counter's rung-condition-in. This occurs because the One Shot instruction is only set (1) for one scan after the preconditional logic goes true. At the end of this scan the One Shot is reset (0) and so on the next scan of the rung it prevents the Counter instruction from seeing that the preconditional logic is still true.

With the CU bit reset (0) and awaiting the next detection of a true rung-condition-in, it cannot detect such a state until the One Shot instruction is set (1) again. The One Shot instruction will not be set (1) again until the preconditional logic transitions from true-to-false and then from false-to-true. The One Shot is then set (1) and the Counter's rung-condition-in is now true. The CU bit is set (1) and the ACC value is incremented by one (1).

So, by using the One Shot instruction in this manner, the Counter instruction's CU bit may be reset (0), but it will not count up again until the preconditional logic transitions as described. Without some intervening logic, the Counter instruction will falsely detect the existing true rung-condition-in as a new instance and "make it count".

Basic stuff, but important to know.

Regards,
George

 

[daba]

I've had class discussions along the same lines many times..

I usually remind delegates that each instruction knows only one thing when the processor executes it.. (or rather it is told only one thing by the processor during execution).

No instruction has any knowledge of what precedes it, or succeeds it. The only thing that "links" instructions on a rung is the current state of the rung, true or false, in the Allen-Bradley world this is called "Rung Logic Continuity", (RLC) (or "lack of"....).

A : When a CTU instruction is executed with the RLC True, the instruction tests the .CU bit, and if this is also true, the counter will not count up. The .CU bit acts as the counter's internal memory that the instruction has already been acted upon.

B : When a CTU instruction is executed with the RLC True, the instruction tests the .CU bit, and if this is False, the counter will set the .CU bit and count up.

C : When a CTU instruction is executed with the RLC False, the instruction resets the .CU bit, thus preconditioning the CTU for the next time the RLC is true. The accumulated value is retained.

When a counter is Reset (RES) the accumulated value is reset to zero, and both internal memory bits (.CU and .CD) are reset.

So resetting a counter will put us into scenario B. The next scan of the counter with RLC True will cause the counter to count up, whether the rung has transitioned false to true, or whether it has remained true throughout.

Remember, the counter only knows the RLC when it is executed. This is why people use ONS or OSR preceding a counter, so that the correct RLC is examined by the counter. In the OP's case in particular, that is when a new carton is detected by the photocell, not that a carton is there.

The .DN bit is the last part of the instruction execution. It is simply set if the ACCumulator value is greater than or equal to the PREset value, and this will happen even if the RLC is false when the counter instruction is "scanned" (executed).