Quick RSLogix 500 question

[jedft]

I don't have any way to simulate this at the moment.... does anyone know offhand if when a CTU instruction is overflowed (i.e. PRE is 6 and ACC is set to 7) will the counter toggle the done bit? (DN = true)

What happens if it is not reset? Does it keep counting? I assume it will set the Overflow Trap (S:5/0)

RSLogix 500 ver.6.2
MicroLogix 1500 LRP processor

Thanks!

Jed

[Dr. Watson]

Originally Posted by jedft

I don't have any way to simulate this at the moment.... does anyone know offhand if when a CTU instruction is overflowed (i.e. PRE is 6 and ACC is set to 7) will the counter toggle the done bit? (DN = true)

What happens if it is not reset? Does it keep counting? I assume it will set the Overflow Trap (S:5/0)

RSLogix 500 ver.6.2
MicroLogix 1500 LRP processor

Thanks!

Jed

I'm about 99% positive that the counter will continue to accumulate and the done bit will remain on until the counter is reset.

[jedft]

If the done bit was not previously set, will it be set?

Specifically, I have a program that is changing the PRE from 6 to 2. When this changes, the ACC is higher than 2. This will cause an overflow because the ACC is now higher than the PRE. As long as the done bit becomes true when this happens I am ok. If it does not become true then I have found the problem.

[Dr. Watson]

Originally Posted by jedft

If the done bit was not previously set, will it be set?

Specifically, I have a program that is changing the PRE from 6 to 2. When this changes, the ACC is higher than 2. This will cause an overflow because the ACC is now higher than the PRE. As long as the done bit becomes true when this happens I am ok. If it does not become true then I have found the problem.

Hmmm...that, I'm not sure about. Is it possible for you to issue a reset command to the counter when the preset value is changed?

[geniusintraining]

As soon as I went into run mode the DN went high and stayed high when the bit switched state, ACC=10 PRE=6 DN=1

[Rube]

The DN bit will remain set until a RES command is used (the book says the bit will reset when the .ACC is less than the .PRE, but I don't know for sure about that). You could MOV a value into the .ACC. after the RES.

[Ron Beaufort]

I have a program that is changing the PRE from 6 to 2. When this changes, the ACC is higher than 2.

suppose that you have a CTU with a Preset of 6 ... and the Accumulator is currently equal to 5 ... the Done bit is OFF ...



now suppose that the Preset is changed to 2 ... the Accumulator remains at 5 ... when you do that, the Done bit WILL come ON ...



now suppose that the Preset is changed back to 6 ... the Accumulator remains at 5 ... when you do that, the Done bit WILL go OFF ...



going further ...



suppose that the Accumulator has already reached its maximum value of 32,767 ... the Preset is at 6 ... the Done bit is ON ...



now the input causes one more count ... the Accumulator will “roll-over” to -32,768 ... note the negative sign ... the Done bit will stay ON ... the counter’s OV (overflow) bit (example: C5:0/OV) will come ON ...



now suppose that more and more counts keep coming in ... the Accumulator will eventually get back into positive numbers ... all of this time the Done bit will stay ON ... for all practical purposes, the counter has now been “broken” by the overflow (roll-over) condition ... the Done bit will basically stay on until something external (example: an RES) resets it ...



note that the counter’s OV bit is NOT the same as the processor’s “overflow Trap” bit (S:5/0) ... specifically, the “roll-over” of the counter (and the subsequent setting of its OV bit) will NOT fault the processor ... I think that here you are confusing the operation of a math operation (example: and ADD) which tries to store a “too-large” number in an integer location ... the counter doesn’t do the same thing ...



and yes, I just tried and confirmed all of this on a spare SLC-5/04 in the lab ...

[geniusintraining]

Originally Posted by Rube

The DN bit will remain set until a RES command is used (the book says the bit will reset when the .ACC is less than the .PRE, but I don't know for sure about that). You could MOV a value into the .ACC. after the RES.

The book and you are correct, a MOV of 1 to C5:1.ACC, reset the counter and the DN bit went low

[Mickey]

Originally Posted by Ron Beaufort

suppose that you have a CTU with a Preset of 6 ... and the Accumulator is currently equal to 5 ... the Done bit is OFF ...



now suppose that the Preset is changed to 2 ... the Accumulator remains at 5 ... when you do that, the Done bit WILL come ON ...



now suppose that the Preset is changed back to 6 ... the Accumulator remains at 5 ... when you do that, the Done bit WILL go OFF ...



going further ...



suppose that the Accumulator has already reached its maximum value of 32,767 ... the Preset is at 6 ... the Done bit is ON ...



now the input causes one more count ... the Accumulator will “roll-over” to -32,768 ... note the negative sign ... the Done bit will stay ON ... the counter’s OV (overflow) bit (example: C5:0/OV) will come ON ...



now suppose that more and more counts keep coming in ... the Accumulator will eventually get back into positive numbers ... all of this time the Done bit will stay ON ... for all practical purposes, the counter has now been “broken” by the overflow (roll-over) condition ... the Done bit will basically stay on until something external (example: an RES) resets it ...



note that the counter’s OV bit is NOT the same as the processor’s “overflow Trap” bit (S:5/0) ... specifically, the “roll-over” of the counter (and the subsequent setting of its OV bit) will NOT fault the processor ... I think that here you are confusing the operation of a math operation (example: and ADD) which tries to store a “too-large” number in an integer location ... the counter doesn’t do the same thing ...



and yes, I just tried and confirmed all of this on a spare SLC-5/04 in the lab ...

I just did the same on a ML1500 LRP Series C and all worked as stated above.
P.S Ron, You type faster then I do

[jedft]

Thanks all! That certainly answers my question and then some! Sure makes it diffucult to troubleshoot someone elses program when you have no way to see the program in action, but it makes it interesting anway

[Rube]

I knew for certain a timer's DN bit would remain set when a lower value was entered in the .ACC but was unsure about a counter. I've never tried it to find out.

[Ron Beaufort]

Greetings geniusintraining,

... a MOV of 1 to C5:1.ACC, reset the counter ...

now I HATE to be “picky” ... but ... we need to talk about the way you’ve used that word “reset” ...



an RES (Reset) instruction will really-and-truly “reset” a counter ... an MOV (Move) instruction MAY - or may NOT - reset the counter ...



doubletalk? ...



suppose that the counter’s OV bit has been set to a 1 somehow ... possibly by the “roll-over” beyond 32,767 that we just discussed ...



we could see something “weird” like this:








basic idea: when the counter’s OV bit is ON, then “all bets are off” ... specifically, the counter's Done bit is “stalled” and can’t be counted on (no pun intended) to give reliable results anymore ...



now to the “picky” point ... if we MOV a value of 0 into the Accumulator will this “reset” the counter? ... no ... not if your definition of “reset” is the same as mine ... specifically will an MOV of 0 into the Accumulator “FIX” the counter and make it work correctly again? ... no ... it won’t ... the counter's Done bit will still be “stalled” ...



but ...



on the other hand, an RES operation WILL “fix” the counter ... because not only does it “reset” the value of the Accumulator back to zero (we all expect that) ... it ALSO “resets” all of the status bits back to zeros too ... (and that’s the trick) ... in normal operation, there’s no problem ... but ... once the OV (or the UN) bit is set to a 1, then things can get pretty tricky ...



this “reset-with-an-MOV” approach has trapped quite a few programmers with tricky “what-the-heck-happened-here?” situations ... its close cousin the “reset-with-a-CLR” will do the same thing of course ...

and incidentally, geniusintraining, what part of SC are you located in? ... if it's anywhere near Charleston, how about this winter weather? ...

[geniusintraining]

I have just tried it all, several different ways and no matter how I did it, you are correct

I have never used a MOV to change the ACC on a counter, just never needed to I guess, I have always used a RES to "reset", I guess I used bad terminology in that.

But thanks for the correction that's good info, I would of scratched my head for hours on that one before posting on here, if I ever came across it in the real world

By the way I’m from the Columbia area, yes one hell of a winter, I’m still in shorts

Do you ever work in the Columbia area?, I farm out the majority of my upper level programming, lack of time and knowledge, there’s a lot of Siemens S5 STL its in German that’s the bad part.

[HLeap]

I hate CTU instructions.... I always end up using a CPT and write logic around that. As in X = X + 1 .

[Ron Beaufort]

Greetings to all ...



well, I don’t know about you guys, but I just LOVE a thread that starts off as a “Quick Question” and then runs on for umpteen posts ...



for anyone who’s interested, here’s just a little bit more on the “resetting-a-counter-by-MOVing-a-zero-to-the-Accumulator” issue ... now some people might ask:

Why on earth would you even consider doing it that way? Why not just always use an RES (Reset) instruction and get on with your life?”

well, there is a valid reason ...






so why does the “false count” occur? ...



because not only does the RES drive the Accumulator to zero ... it ALSO writes zeros to all of the status bits (CU, CD, DN, OV, and UN) ...

this "resetting" of the status bits to zeros explains why we can get a "false" count when using the RES ... specifically, the next time the processor scans the counter rung and finds the “count me” input still TRUE, it first checks the CU bit to see "have I already counted this?" ... since the CU bit is now OFF (because of the RES action) then the processor assumes that the TRUE condition of the rung has not yet been counted ... and it adds a “false count” of one to the Accumulator ...

so how about this solution? ...







notice that the "MOV-a-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 the slightly-more-elegant CLR (Clear) instruction rather than MOVing a zero ... you'll get exactly the same results with either method ...



so there IS indeed a perfectly valid reason to use the “MOV-a-zero” approach to resetting a counter ... and many programmers do it ... but ...



now suppose that we run into something like this:







we talked about this “stuck-Done-bit" issue in a previous post of this thread ... the problem is caused by the fact that this Counter has previously “overflowed” past its maximum value of 32,767 and set the OV (Overflow) status bit ... note that the same “stuck-Done-bit” effect will result if the UN (Underflow) status bit is set – but that usually happens with a CTD (Count Down) counter ...



and so ... where does this leave our machinery? ... and the bo$$man's bottom line? ... if all that the programmer has provided is the “MOV-a-zero-to-the-Accumulator” approach to “resetting” the Counter, then I’m afraid that the machine operator won't be able to fix this one on his own ... specifically, someone is going to have to show up with the laptop to get this thing working right again ... yep, the OV bit is going to have to be manually reset to zero ... how about just using the keyswitch to toggle the processor to the Program mode and back to the Run mode? ... nope, that won’t reset the OV bit ... how about power-cycling the processor? ... nope, that won’t do it either ... the OV bit is still set ... so the Done bit is still “stuck” ... and the machine won’t work right ... sorry folks, but I sure hope that this thing isn’t way out in the boonies somewhere ...



so how about another programming approach? ... one that will use the powerful “reset-the-whole-darned-counter-including-the-status-bits” RES instruction – but won’t give us that annoying “false count” problem at the same time? ... how about this? ...






yes, 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 ...



and so ... Counters ... after all, just how complicated can these little things be? ... well, sometimes they can even confuse the people who write the official books ... take this statement (copied verbatim) right from page 3-8 [Adobe Reader page 51 of 169] of the official 1785 PLC-5 Programmable Controllers Quick Reference manual (publication 1785-7.1, dated May 1999) on the official Allen-Bradley website ...







can you spot the error? ... yes, we’re all human ... even the people who write the official PLC books ...



and now to geniusintraining ...

Do you ever work in the Columbia area? I farm out the majority of my upper level programming, lack of time and knowledge, there’s a lot of Siemens S5 STL its in German that’s the bad part.

actually I do very little programming these days ... my boss has decided that I’m too old to hunt for the tribe anymore, so now I mostly just teach the young braves how to follow a trail of buffalo dung ...



as for Siemens, I have zero experience there – and even less with German ... if we had enough “technician training” customers asking for Seimens training, then I’m sure that my boss would be intere$ted in following up on it ... right now, I’m keeping pretty busy with just Allen-Bradley ...



anyway, let me know if you’re ever down in Charleston ...