RsLogix 500 CTU First pass

Hello all,
I have an issue with part of the attached program and in need of help understanding why this is, little bit of a description of what I’m trying to do.
I have a flow transmitter 4-20 mA output 0-2700 gpm, I trying to totalize the flow over an hour and store the value along with a date/time stamp. LAD3 is set-up to trigger evey second with a STI.
I have set the SCP instruction LAD3 Rung 1 to read the full span 2700 GPM and totalize over an hour just to see how the logic works out prior to implementing.
The issue comes along when the processor ( ML1100 SER.B 1763-L16AWA) is first put into run mode.
LAD 3- flow sample is taken 60 times added and then divided by 60 to get the GPM.
During the first 60 times the logic is executed the value in F208:2 would suspect to be 2700GPM but the value is 2745. This tells me there is something going on with the CTU C:200:0 counter during the first scan, since 2700/60=45, so at some point the counter counts 61 times, I’m just unsure of how this happens.
Definitely on the first scan the CTU counter does not increment to a 1 and I’m not sure as to why.
Please help me in understanding the logic scan of the CTU counter.

Logic Program

Try replacing the CTU with an ADD instruction to add 1 to an ordinary Integer register every time the STI executes.

Leaving a CTU unconditional and unlatching the /CU bit is unusual, so that is the first thing that jumps out at me as a suspect.

In LAD 3, rung 1: Try swapping the positions of the OTU and CTU. This will absolutely insure the counter sees a transition on each scan.

Please help me in understanding the logic scan of the CTU counter.

Click to expand...

in spite of the unorthodox way that you're treating it, I really don't think the Counter is causing your problem with a mysterious "extra" count when you first go into the Run mode ...

instead what's causing the extra count appears to be tied up with the logic in your rung 3 ...

I've got a hunch that you THINK that the S:1/15 bit/box has a ONE status only the first time that your rung 3 gets "scanned" ... that is incorrect ...

in reality, whenever the processor first goes into Run mode, S:1/15 will have a status of ONE in its bit/box ONLY until the processor completes one full pass through its scan sequence ...

specifically, once the processor goes through a full "scan sequence" (a matter of milliseconds) then the value of the S:1/15 bit/box gets written to a ZERO ...

more specifically, you can NOT have one specific rung just "wait around" until the first time that specific RUNG gets "scanned" by using the S:1/15 bit's status ... (there ARE ways to accomplish that effect – but not by using S:1/15) ...

remember that your STI file (3) has to wait for one full second before it gets scanned ... by the time the logic on your rung 3 finally does get scanned, S:1/15 (bless its little heart) has had a status of ZERO in its bit/box for quite awhile ...

so ...

when the STI file finally DOES get scanned, this ZERO status causes the XIO instruction on rung 3 to execute as TRUE – which makes the ADD instruction throw an "extra" value into the total that you weren't expecting ...

nailing it down ...

as near as I can tell by what you've posted, the CTU is NOT counting when the STI first gets triggered (which is exactly what you intended) ... but ... on the other hand, the ADD instruction is indeed adding a value to the total on the first STI scan (definitely NOT what you intended) ... and that's why you're getting 61 ADD "operations" – for the price of 60 ...

incidentally, yours was a VERY well written post ... thank you for that ...

.

and just for clarity ...

some of the suggestions which others had posted earlier would go a long way toward "fixing" your problem ... you should explore those ...

at this point, it would probably be easiest to make the CTU "count" even on the first STI scan – so that the "additions" and the "counts" would accurately stay in step with each other ...

my previous post was written in response to your specific request to help you understand the operation of the CTU ... and (as I said earlier) I don't think that the CTU was the root cause of your confusion ...

I wrote the previous posts in between customer calls – and inadvertently left something out ... it doesn't change the originals, but just in case you're wondering ...

here's why the CTU never counts the first time that the STI gets scanned – even though you have it located on an unconditional rung ...

PRESCAN always writes a status of ONE into the CU (Count Up) bit/box as soon as the Allen-Bradley processor has a "Go-To-Run" experience ... this PRESCAN step happens BEFORE the "First Pass" - and it happens regardless of the status of S:1/15 ...

so ...

when the first trip through the STI finally does get around to executing your unconditionally TRUE rung for the CTU, the counter thinks that it has "already counted" – based on the ONE status of the CU bit/box ... specifically, the Accumulator does not get incremented ... then your Unlatch for the CU bit writes a ZERO status to the CU bit/box so that the counter WILL increment on the subsequent passes ...

putting that part together with what I wrote earlier explains why the Counter does NOT count on the STI's first execution – but the ADD controlled by the XIO for S:1/15 DOES add a value into the total ...

therefore you are getting 60 operations for one component – but 61 operations for the other ...

Thank you all for your help.
I just got to start tinkering with the PLC code again.

@KEN
I went with Kens suggestion and uses an ADD instruction
Upon the initial processor entering RUN MODE and scanning the logic 60 times the value of F208:2 was 2700gpm, that worked out good.


Hello MR. Beaufort, good to hear from you again.

Yes I did think that the FIRST PASS BIT will help in preventing the execution of adding since I figured there is something going on with the execution of the counter during the first STI trigger execution of LAD 3, Thank you for clarifying the status of FIRST PASS BIT in STI.

To clear one thing, the S:1/15 was placed in the logic while I was trying to see if the CTU instruction was not advancing but the Add instruction was adding, it did not work because FIRST PASS Bit already held a 0 in bit/box by the time the STI triggered to scan LAD 3

when the first trip through the STI finally does get around to executing your unconditionally TRUE rung for the CTU, the counter thinks that it has "already counted" – based on the ONE status of the CU bit/box ... specifically, the Accumulator does not get incremented ... then your Unlatch for the CU bit writes a ZERO status to the CU bit/box so that the counter WILL increment on the subsequent passes ...

putting that part together with what I wrote earlier explains why the Counter does NOT count on the STI's first execution – but the ADD controlled by the XIO for S:1/15 DOES add a value into the total ...

therefore you are getting 60 operations for one component – but 61 operations for the other ...

Click to expand...

Well put MR.Beaufort, Thank you for explaining the CTU execution in my unorthodox way of placing it in the logic. Lessons learned, the CTU will never see the light of Logic in this manner again.

Again Thank You