fishenguy

while the dust is settling ...

following up on a question from Tripper in post #26:

doesn't the preset need to be 37 if he needs to count 36 (resetting on 37)?

Click to expand...

fishenguy made a start to answering that question in his post #27 ...

Tripper, when I first wrote the program using a regular CTU bit, I did have to set it to 37 because the counter would count up to 36 then reset to one. The high speed counter (HSC) resets to 0 after it reaches the preset.

Click to expand...

but (as frequently happens with PLCs) there’s more to the story than that ... now that fishenguy’s problems have been solved, let’s learn some more from the project he’s just shared with us ...



first things first - and yes this is “picky” ... in the quote from fishenguy (just above) the word “bit” should be omitted ... he just meant to say “using a regular CTU INSTRUCTION or COUNTER” ... the word “bit” (a box that can hold a one or a zero) doesn’t fit the statement - but (in context) we all know what he meant ...



now then ... Tripper has a perfectly valid question ... and the idea that he brought up is exactly what I was thinking about when I asked this question back in my post #20:

is there a possibility that the "miscount" is happening at the precise instant that the counter's accumulator is being reset? ...

Click to expand...

if fishenguy had answered “yes” to that question, then we would have followed up on the differences in operation between setting the preset of the HSC to 36 or to 37 ... the truth is that some people SAY one thing - even when they MEAN something else ... let’s look at what fishenguy said in his original post #1:

... latch a binary bit after counting 36 teeth. At the same time it has to reset ...

Click to expand...

now that’s pretty specific ... to translate that directly into ladder logic, we end up with Rung #1 in my post #2 ... quit thinking about “switches” and “coils” and “resets” for a few seconds - and look at the ladder logic rung as being another (foreign) language ... in simplest terms that rung says this:

IF - the High Speed Counter is DONE - THEN - GO WRITE a ONE into bit B3/0 - and RESET the High Speed Counter ... but ... IF - the High Speed Counter is NOT done - THEN - DO NOTHING to bit B3/0 - and DO NOTHING to the High Speed Counter ...

Click to expand...

this is exactly the way that I would teach a student to “translate” this particular rung in a programming class ...



and that is PRECISELY what fishenguy asked for in his first post ... and so - it might not have been what he WANTED - but I definitely gave him what he ASKED FOR ... (happily it turns out that yes, it WAS what he wanted) ...

now let’s dig deeper ... what EXACTLY happens when the RAC (HSC Reset Accumulator) instruction “does its thing?” ... the easiest way to find out the details is to look in the online Help file for the MicroLogix (not SLC) controllers ... but for our purposes, the main thing that we’re interested in this: the RAC does NOT “reset” the CU bit back to a zero status ... that’s important ... to understand why, I suggest that you program a second counter (C5:1) to run in parallel with the High Speed Counter (C5:0) ... let it look at the same prox switch for its input signal and let it count up to a Preset of 36 ...

preview: as long as we manually trip the prox switch slow enough for the "regular" counter to keep up, then both counters should work identically ... right? ...






now let’s see what happened just before the screen shot was taken ... the input (prox switch) had just made its 36th transition from FALSE to TRUE ... so both counters (C5:0 and C5:1) became DONE ... so both rung #1 and rung #3 were executed with TRUE logic ... on rung #1 the RAC “reset” its HSC counter (C5:0) and did NOT change the status of the counter’s CU bit ... so this counter’s Accumulator stayed (correctly) at a value of 0 ...



so far so good ...



on rung #3 the RES “reset” its “normal” counter (C5:1) and it DID change the status of the counter’s CU bit ... and that’s why this counter now (incorrectly) shows an Accumulator value of 1 ... most programmers call this a “false count” situation ... it results when an RES instruction “resets” a counter and THE COUNTER’S INPUT IS STILL ON ...



you can read much more about this situation - and how to (usually) correct it by programming a “one shot” type instruction where I’ve marked location “A” in the figure above ... click here for a post that should cover the subject adequately ... it would be a good idea for fishenguy to read that one - it will go a long way toward explaining why that “false count” occurred when he used the CTU and RES combination - but not when he used the HSC and RAC combination ...

continued in next post ...

and more from Tripper in post #26:

I have a bit of time, might put it into an slc and try it.

Click to expand...

that’s an EXCELLENT! idea ... it’s ALWAYS more instructive to play (oops! I meant WORK) with a real system than simply trying to learn by reading ... just remember that there are some differences between the SLC platform and the MicroLogix system that our friend fishenguy is working with ...



now let’s close out the “big picture” idea that Tripper brought up ... let’s keep in mind fishenguy’s original specification to “count 36 teeth and then latch and reset” - and let’s count the teeth in slow motion ...

we’ll start with a count of 0 ...

Click to expand...

the prox does NOT see a tooth ...

the prox DOES see a tooth ...
the count goes to 1 ...
is it time to reset yet? ...
no - we’ve only counted 1 tooth so far ...
the gear turns ...
the prox does NOT see a tooth ...
the count stays at 1 ...

the prox DOES see a tooth ...
the count goes to 2 ...
is it time to reset yet? ...
no - we’ve only counted 2 teeth so far ...
the gear turns ...
the prox does NOT see a tooth ...
the count stays at 2 ...

the prox DOES see a tooth ...
the count goes to 3 ...
is it time to reset yet? ...
no - we’ve only counted 3 teeth so far ...
the gear turns ...
the prox does NOT see a tooth ...
the count stays at 3 ...

Click to expand...

and so on and so on ... let’s jump ahead toward the end of the sequence ...

the prox DOES see a tooth ...

Click to expand...

the count goes to 35 ...
is it time to reset yet? ...
no - we’ve only counted 35 teeth so far ...
the gear turns ...
the prox does NOT see a tooth ...
the count stays at 35 ...

the prox DOES see a tooth ...
the count goes to 36 ...
is it time to reset yet? ...
YES! - we’ve finally counted the 36 teeth that were specified ...
so we “latch” the internal bit ...
and we “reset” the HSC ...
the count goes to 0 ...

Click to expand...

and so no, Tripper, it would NOT be correct to wait for the next tooth (#37) before taking action - as long as fishenguy got the specifications right in the first place ... (and he did) ...



BUT ...



you’re EXACTLY correct in being suspicious of those “count” specifications ... in many cases, a “specified” count will be off by one ... being able to successfully debug a program often hinges on being able to spot those “near miss” issues ... so you get extra credit ...



one more thing while we’re in the “learning mode” ... back in post #22 Gil47 mentioned trying to use the Histogram feature to nail down the cause of the “miscount” issue ... I’m afraid that wouldn’t work for this project ... you might want to read this post before the next time you try the Histogram feature in RSLogix500 ...



basic idea: with RSLogix500 the Histogram gets all of its signals through the Serial Communication cable ... this is usually around 9600 baud - and the Histogram cannot update often enough to catch fast changing signals ... so it’s WAY too slow for something like this project ... which is probably what Gil47 had in mind when he mentioned the “speed” issue ...

Ron,

Excellent follow up posts!!! That clears up some issues, some that I didn't even know existed.

Thank you!!!!

Now I understand why the counter reset to 1. It makes sense now, knowing that it was done and reset while it still had an input.

Thanks I'll remember the osr trick.

I'm still pretty new at this stuff, I'm not quite ready to program a MOV instruction. To tell the truth, I don't fully understand how to even use an Integer in a line of logic. I guess these will be my next tricks, after I study some programs using them.

Believe it or not, I did ponder my mistake of calling the timer a bit while going to work today. I know better than that, I guess my fingers type faster than my brain functions.

Thanks for the explanations. It does help me to understand.

Now please tell me, at what frequency will a regular counter not work in a program, and I'll have to use a HSC.

fishenguy said:

Now please tell me, at what frequency will a regular counter not work in a program, and I'll have to use a HSC.

Click to expand...

Anything that cycles faster then the plc scan would need an HSC. Ex: If your scan time is 10ms but something is cycling every 8ms.

Ok, That makes sense. I guess if I'm going to do this kind of work, I'd better develope a better train of thought. That's why I'm really enjoying this forum. It keeps me thinking. Thanks

It keeps us all thinking. I had written out this story about a generator, carnival ride, and plc before I realized the simple answer to your question.

A carnival ride? Now you piqued my interest.

Another question about counters

When I wrote this program, I had to use another CNT instruction later on to latch another output. In order to reset the ACC value of said CNT (5:1), note this was a CTU instruction, I tried to incorperate a CTD instruction with the same adress (5:1). Apperently you can't do this because the program would not allow me to verify the project. I got an error message on the CTD rung. I eventually figured out how to get the same results by using only the CTU instruction and a RET instruction. It worked really well for me, but should I have been able to use the same adress for the CTU and CTD?

I am not sure what you are asking but you can use the same address for an up/dn counter, they do have to be conditioned though.



Many here know I worked in the amusement (traveling carnival) industry. One of my first experiences involving a PLC was on a carnival ride called the Sea Dragon


As you can see it swings, it is driven by tires that are hydraulically powered. The problem was the swing was not timing right, the boat was hitting the tires at the wrong time.

This happened in 1985 in Madisonville, KY. This was my first time dealing with a PLC and the factory sent another one so we changed it out, same problem.

Anyway after many phone conversations I figured out that it used the 60HZ from the supplied power as a base for the timing ckts. The genset we had was running slightly above 60HZ, the frequency meter was off, when I readjusted the throttle (speed) of the genset it started working properly. This was when I got my first Fluke 87 meter because of the built in frequency meter, the show owner bought several and gave them to the top people.

thanks Ron, you have a gift in teaching, keep it up!

My notes from the original program try are at work. I'll try to remember to bring them home so someone can show me why they're wrong. Then next time i'll understand what doesn't work and why.

Note to Ron, Tripper's post speaks for me too.

Just as a small input regarding the CTU and CTD instructions, I usually never use those (a result of some problems I had while using Siemens S5 and S7 PLC in my first years of programming)

If I have to make a counter I simply take and ADD instruction and add "1" to an Integer and then use the same Integer as the destination. If I want to count backwards I use the SUB instruction, and I can do what I want with the value of my "counter".

Michal

Michal, Using an integer is something I don't know how to do, yet. I need to see that in a simple example in ladder logic. I would love to get a book detailing some of this stuff, to refer to.

Anyone have any sugestions?

from Michal ...

If I have to make a counter I simply take and ADD instruction and add "1" to an Integer and then use the same Integer as the destination. If I want to count backwards I use the SUB instruction, and I can do what I want with the value of my "counter".

Click to expand...

well, Michal, if that works for your applications, please don’t let me confuse you ... and actually I often recommend something very similar for applications which need to count higher than the CTU’s customary limit of 32,767 – except that in that case I use a floating point location (example F8:0) rather than an integer ... for one thing, the floating point will accurately display a number as high as 9,999,999 without rolling over into exponential notation ... in addition, by using the floating point, you won’t have as many issues with a “math overflow” condition faulting the processor when the counted value tries to exceed 32,767 ... (click here for a BIG COUNTER example) ...



but beyond all of that, what Michal has posted does lead into a very interesting (at least to me) discussion of some of the little known characteristics of the OSR (One Shot Rising) instruction in RSLogix500 ...



let’s use the “home brew” counter arrangement mentioned by 88888888 and see what happens when we count parts coming down a conveyor line ... notice that I’m using the integer location (to keep things as simple as possible) and that I’ve used two separate “counting” rungs to track the same PROX_SWITCH input signal ... of course the OSR instruction is included in the top rung in order to keep from ADDing repeatedly while the PROX_SWITCH “sees” the same part on numerous processor scans ...







and everything works fine ... in other words, both “counting” mechanisms keep perfect track of the parts on the conveyor ...



now let’s have an “issue” ... and incidentally, this is all taken from a “true story” debugging episode that I helped a programmer with several years ago ...



suppose that it’s time to do a maintenance operation on the conveyor equipment ... the maintenance technician lets the conveyor “run dry” to clear out all of the parts - and then he shuts down the system by putting the SLC-5/04 processor into the Program mode ... so far so good ...



while the technician is doing the maintenance routine, an operator (probably named “Bubba”) finds one more part that didn’t quite make it off of the conveyor before the system was shut down ... so he manually slides the part down the line and leaves it in the “finished” position right in front of the PROX_SWITCH ... so far so good ...



now the technician has finished the maintenance operation – and so he puts the system back in operation by switching the processor into the Run mode ...



oops! ... now we might have an “issue” ...



the “real” counter C5:0 will NOT count that “extra” part that Bubba manually slid in front of the PROX_SWITCH ... but ... the “home brew” counter will ...



now that might be an “issue” to talk about – but is it really a “problem”? ... in some (most?) situations no – but in the system that I got called in to help debug it certainly WAS a problem ... because the “home brew” counter that the original programmer had used would SOMETIMES – SOMEHOW get off by a count of one ... and so the identification numbers on the barcode labels which were being applied to the finished parts were SOMETIMES – SOMEHOW off by one also ... and SOMETIMES – SOMEHOW the wrong parts were being shipped to the wrong customers ...



now notice that the “issue” only developed at very random and very intermittent times ... sometimes months would go by with no problems ... and then all of a sudden, things would SOMETIMES - SOMEHOW start going squirrelly again ...



if you want to duplicate this experiment yourself, make sure that the “counters” do NOT see the input signal while the processor is still in the Run mode ... then switch to the Program mode ... then turn on the input signal ... and then go back to the Run mode ... and that’s when the “home brew” counter (with its OSR condition) will make a count that the “regular” counter won’t register ...

SLOW DOWN a second ... in SOME cases we actually DO want to count that “extra” part that Bubba manually slid down the belt ... I mean it’s really and truly physically THERE isn’t it? ... so maybe we need to program the SLC to “deal” with it ... in cases like that, a simple “regular” counter might not do the trick ... now there ARE ways to program this situation for reliable operation – but many programmers don’t take the “Bubba” factor into consideration while they’re getting the system ready to make money ... now let’s get back to our original discussion ...

Click to expand...

and just for completeness, if you try this same little trick with a PLC-5 or a ControlLogix system you won’t get the same results ... that’s because those systems use the ONS (One Shot) instruction as their “right-in-the-rung-only-happen-once” type gadget ...



ONE KEY POINT OF THE WHOLE DISCUSSION: the OSR instruction (in RSLogix500) does not ALWAYS work exactly the same way as the ONS instruction (in RSLogix5 and RSLogix5000) ... the biggest difference occurs when the SLC processor first goes into the Run mode ...



so now ... just to continue the discussion, here’s a “fix” which can be VERY educational for those who might want to dig deeper ...







putting this new rung in the program BEFORE (but not AFTER) the “home brew” counter will usually take care of that little “issue” that we just discussed ... whether or not you ever really NEED anything like this in an actual program is almost inconsequential ... but ... the REASON that this technique works the way it does can lead into some very interesting (and very educational) “nuts and bolts” discussions ...



most of the students in my week-long Boot Camp classes don’t get this far, but for those who do, the discussions that come up during exercises like this one are well worth the educational “juice” that we can squeeze out of them ... sometimes I’ll stay after class with one or two students who can’t seem to get enough of this stuff in a regular eight-hour day ... often this is the type of material that we get into ...



so ... if anyone is interested, I’d suggest that you plug these simple rungs into a spare SLC processor the next time you have a few extra minutes to experiment with some of these “under the hood” topics ... I’m out of typing time right now – but I’ll be glad to discuss the reasons WHY these things work the way they do if anyone wants to pose any specific questions ...