CTU in PLC-5

[Bill Linne 0]

I'm trying to put a counter in a file (file 4) that is scanned every one second as controlled by an STI. Whether I make the rung unconditional or not, or use a ONS or not, nor anything else I can think of makes the counter increment. I've tried setting a bit true within file 4, then setting it false again in file 2, and several variations of that theme, with and without an ONS instruction in front of the counter. What am I missing? The idea is to verify that file 4 is actually being scanned every second by examining the accumulator of the counter several hours after resetting it. (Just to verify what I suspect is perfectly accurate.)

[Bill Linne 0]

Found it! Added an unconditional OTU in file 2 to reset the .CU bit of the counter. Works like a champ!

[Mickey 71]

I would have used an ADD instruction on an unconditional rung in your STI file.

[Bill Linne 0]

That is exactly what I did to start with, Mickey. The .CU bit goes true on the first scan and STAYS that way! I still don't understand that, and I tried several variations on that rung. Ultimately had to reset the .CU bit from a non-STI scanned file to make it work. I'd be very interested in hearing the explanation, believe me.

[Mickey 71]

Why didn't you stay with the ADD instruction?

[Guest]

Greetings Bill ... suppose that we program a simple CTU rung like the one below ... suppose that we turn SWITCH_A ON and then leave it ON for several scans ... question: how does the CTU instruction “know” to count the switch’s ON action only ONCE - and not count it again and again on every scan? answer: the processor uses the status of the counter’s CU (Count Up) bit/box to keep track of what’s happening from scan to scan ... here's the play-by-play ... suppose that SWITCH_A is OFF ... each time the processor scans the CTU instruction with FALSE logic, the processor does NOT change the ACCUMULATOR - but it DOES write a ZERO status into the counter’s CU bit/box ... this happens scan after scan - as long as SWITCH_A remains FALSE ... now suppose that SWITCH_A is suddenly turned ON ... each time the processor scans the CTU instruction with TRUE logic, the processor first checks the status of the CU bit/box ... on this FIRST scan with the rung TRUE, it finds that the status of the bit/box is ZERO ... this ZERO status tells the processor that this particular instance of a TRUE switch action has NOT been counted yet ... so the processor increments the ACCUMULATOR by one - and then it writes a ONE status into the counter’s CU bit/box ... now let’s look at the next scan - and suppose that SWITCH_A is still ON ... this time when the processor scans the CTU instruction with TRUE logic, he rechecks the status of the CU bit/box ... on this SUBSEQUENT scan with the rung TRUE, it finds that the status of the bit/box is already a ONE ... this ONE status of the CU bit/box tells the processor that this particular instance of a TRUE switch action HAS already been counted ... so the processor does NOT change the ACCUMULATOR - and the ONE status stays in the counter’s CU bit/box ... on the next scan - and the next - and the next - as long as the ONE status stays in the counter’s CU bit/box, the processor knows that the switch’s ON action has already been counted ... now suppose that SWITCH_A is turned OFF ... the next time the processor scans the CTU instruction it will be using FALSE logic ... the processor will NOT change the ACCUMULATOR - but it DOES write a ZERO status into the counter’s CU bit/box ... and now the counter is “reloaded” so to speak - and ready for another FALSE to TRUE transition ... now let’s talk about why your attempt to count the scans of your STI wouldn't work with your original setup ... the reason was that each and every time that the processor scanned your CTU rung, it was always using TRUE logic ... specifically, there was never any reason for the CU bit/box to go to a ZERO status ... and therefore the counter never got “reloaded” before the next TRUE scan ... you solved your own problem: and hopefully that’s the explanation that you wanted ... in simplest terms, the OTU just writes a ZERO into the counter’s CU bit/box ... this has the effect of “fooling” the processor into thinking “I haven’t counted this particular ON condition yet” ... going further ... apparently you misunderstood my distinguished colleague Mickey’s suggestion ... he was talking about using an ADD (Add) instruction - rather than a CTU (Count Up) instruction ... that’s the way most programmers would tackle your “scan counter” project ... I suggest that you make use of a “floating point” data location such as F8:0 (as Mickey demonstrated) if you follow that path ... with an integer location, the processor will fault (oops!) if the value tries to go above 32,767 ... Edited 9 Oct 2007 by Ron Beaufort

[Bill Linne 0]

Thanks a million, Ron! I actually preset the first counter to 32,400 (nine hours) then cascaded another counter. And you're right, I misread the ADD advice, sorry Mickey. Bottom line is that the timing of the STI is dead on, so that is not the problem. The situation is that I'm using the same multiplier to derive engineering units (MGD) in one section of the PLC that controls the speed of the influent pump (I.E. Plant Operator wants 15 MGD, VFD runs pump to produce 15 MGD). In the STI logic, using the same math, I totalize the flow once per second. The TOTALIZED daily flow is significantly less (yesteday should have been 12 MG, totalizer came up with 10.6 MG). Got me scratchin! Thanks again, guys. Bill

[TConnolly 13]

Thats the easiest way to do it and then you don't have to worry about roll over. However, with a floating point number the highest you can count by "ones" is 16.77 milllion. After that you loose ones resolution and cannot increase the number farther by adding just one. But if that is high enough for you then that is the easiest solution.

[OkiePC 14]

?Sure the STI is "trustworthy" plus or minus a few ms, but there may be rounding errors, calibration imperfections, and possibly other sources of inaccuracy. Being off by a large percent indicates one of the above causes, though... It should be closer than that in my humble redneck opinion...BTW, what is MGD? (I don't have Logix at home to look it up...not that I am lazy, but my slow ISP thwarts my search too )