Counter, AB Micrologix 1500

I had a fellow programmer call me the other day with a problem he was having on an AB Micrologix 1500. He had just written the code and had a counter that when the input (a limit switch) was closed the counter would start to count up instead of counting one it kept counting. I never counld get him to send me the code. I was wondering what could cause this? He said that he was going to write the code over again and I never heard back from him so that makes me think that it was in his code instead of a physical problem like loose wire at a terminal etc.

Is there any way to increment a counter in code besides the input going high?

Any one run across this before?

Thanks

It would be nice to see the program...

If you reset the CU bit, the CNT instruction won't "know" that it was updated last scan, and will update this scan.

If you use the same counter address in a different CTU block, with different rung conditions, the second CTU block would reset the CTU (and EN) bit if ITS rung conditions are false.

So when the first CNT with the duplicate addres gets scanned, the counter increments again.

How's that for debugging without seeing the code?

Maybe he needs a one shot?

Re: It would be nice to see the program...

Allen Nelson said:

If you reset the CU bit, the CNT instruction won't "know" that it was updated last scan, and will update this scan.

If you use the same counter address in a different CTU block, with different rung conditions, the second CTU block would reset the CTU (and EN) bit if ITS rung conditions are false.

So when the first CNT with the duplicate addres gets scanned, the counter increments again.

How's that for debugging without seeing the code?

Click to expand...

I think that is fantastic. I have seen his code before, (no comments wack-n-hack code) and know that he must have had two counters with the same address.

I did duplicate that on my ML1500 and if you set either counters cu bit it increments once each scan. If you set both counters cu bit on it stops counting each scan.

CTU

In my experience with the PLC-5 family if you MOV the .ACC of a timer into the .ACC of a counter it will do that.



Note: For a PV display that counts up and down, assign the same address to a CTU and a CTD then you will be able to incriment the display up and down.

Re: CTU

rogerhollingsworth said:

In my experience with the PLC-5 family if you MOV the .ACC of a timer into the .ACC of a counter it will do that.

Click to expand...

Yup, that would make the counter mirror the timer's accumulated value. Which brings up a good question (for jthornton to ask).

At what rate is the counter incrementing?

Note: For a PV display that counts up and down, assign the same address to a CTU and a CTD then you will be able to incriment the display up and down.

Click to expand...

Please elaborate on this "same address" comment Roger... You totally lost me on that one...

Note to George... Good idea, but in the MicroLogix, a counter's accumulated value increments (or decrements) at each false-to-true transition of that rung. Sort of like a "built-in" one-shot. Adding a one-shot immediately before the timer would be redundant.

Hmmm... Redundant... Where have I heard that recently?...

beerchug

-Eric

Counter

As I have stated in the past I am only familiar with Allen-Bradley products. I will give you an example; I wrote a program to control a couple of steam turbines and the operator needed to change steam pressure setpoints and he did this via two hard wired pushbuttons on his panel, this was prior to changing to PanelViews.
The up button was programmed to CTU C5:0
The Down button was programmed to CTD C5:0

The buttons manuliped the ACC value of C5:0, up & down.

CTU and CTD

Eric:

Just to elaborate on what Roger said (and to fix some of my typos)

A CTU instruction uses the .CU bit to know that its already incremented. The CTU instruction, when its TRUE, checks the .CU, and if it is false, increments the .ACC and sets the .CU bit.

If the rung conditions are FALSE, then the .CU bit is reset.

So if you use the same C5 address in two CTU instructions, and one is enabled and the other disabled, the .ACC will increment every scan. This is my best guess as to what J Thornton's "friend" did.

Similarly, CTD instructions use the .CD bit to know its already fired. Two CTD instructions sharing the same C5 address will have one run wild.

But (and this is Roger's point), you CAN have one CTU and one CTD share the same C5: address, since the instructions use different bits (.CU is bit 15, .CD is bit 14) for checking their "already fired" state. This makes for a nice count up/count down device, useful in many applications (like roll-your-own FIFO, or just keeping track of how many widgets you are supposed to have between two photoeyes, or _{[your imagination here]} ). Or use two HMI buttons to "increment" and "decrement" a register instead of using one-shots and the ADD and SUB instructions.

OK, now I get it...

Thanks Allen, that makes sense...

I got tripped up by the "same address" comment... I was thinking PanelView address and and saying "How the heck can you do that with one address?"

I don't do that much A-B programming, so I re-read the Instruction Set Reference Manual on counters to refresh my memory. I was shocked to find no Up/Down counter instruction... More than 1/2 dozen comparison instructions (do we really need a > AND > instruction?), yet no up/down counter instruction?

When I need to count up and down in an A-B, I usually just do the increment/decrement thing you mentioned...

beerchug

-Eric