RSlogix 5000 : Can someone explain this?

I’m using rslogix5000 v20 with ControlLogix L72. I added some rungs to monitor time meter of our propulsors. But with same ladder instruction I get different result. As you see in the first rung ADD and MOV instructions were executed but in the second are not.
Can anyone explain what could be the reason for getting this? Is there any difference between doing ADD and MOV in parallel or in series?

You don't need the one shot in either png second rung.

Test also for possible multiple use of the same one shot bit.

bernie_carlton said:

You don't need the one shot in either png second rung.

Click to expand...

OK! I agree with that.

bernie_carlton said:

Test also for possible multiple use of the same one shot bit.

Click to expand...

I already checked that and there is no multiple use.
After only toggling ONS bit the ADD and MOV are executed and there is no more problem with the second rung. I don't understand this behavior.

Removing the ONS on Rung 2 will correct the issue as Bernie said. But if you use ONS on both you should move rung 2 above rung 1. Reset then ADD.
The Add Instruction is still True during the scan cycle you try to reset. The next scan the reset ONS will not MOVE 0 because of previous scan.

1) Is the ladder file of Second_Rung.png being called?

2) I'm with @Bernie: something else was keeping a 1 in OneShot[9]; perhaps via indirect access, that is not so easy to locate?


P.S. Assuming CLOCK_1S is not a one-shot itself, the one-shots on the upper rungs should be on CLOCK_1S only, then AND that one-shot result with sampled bit Deco1:O.Slot[5].Data.x . It probably does not matter, but if the measured bit changes more than once while CLOCK_1S is 1, you will accumulate phantom "seconds" in the runtime.

cwal61 said:

Removing the ONS on Rung 2 will correct the issue as Bernie said. But if you use ONS on both you should move rung 2 above rung 1. Reset then ADD.
The Add Instruction is still True during the scan cycle you try to reset. The next scan the reset ONS will not MOVE 0 because of previous scan.

Click to expand...

I don't understand.


Why does "ADD instruction* [being] True" on a scan or a rung affect a later parallel MOV instruction? Does ControlLogix L72 not follow left-to-right, top-to-bottom?

* do you mean output rung of ADD instruction?

ONS on lower rungs does not hurt, but removing it should not help either.

Order of rungs does not matter in this case, it only affects the order in which the values change on each scan.

Also, why did essentially identical code work in First PNG but not in Second PNG?

One other solution would be to use a CTU for seconds instead of ADD and use the CLR to reset the CTU.ACC back to 0. That would eliminate the need for the ONS in rung 1.
Using the CLR to reset the counter's ACC would require a false transition of the CLOCK_1S bit before counting again. Which means your leaving the CTU.CU bit true while clearing the Accumulation to 0 which would not happen if you the (RES) instruction on the counter.

your right Drbitboy. Please disregard I don't know what I what I was thinking about.

drbitboy said:

1) Is the ladder file of Second_Rung.png being called?

Click to expand...

Yes, all those ladder rungs are located in the same routine

drbitboy said:

2) I'm with @Bernie: something else was keeping a 1 in OneShot[9]; perhaps via indirect access, that is not so easy to locate?

Click to expand...

There is no indirect addressing, I added this OneShot tag as new bool[32]

Why this not happen with first rung? Why this not happen again after toggling ONS[9] as you see in attachment?

Thanks All!

MedSelmi said:

Yes, all those ladder rungs are located in the same routine


There is no indirect addressing, I added this OneShot tag as new bool[32]

Why this not happen with first rung? Why this not happen again after toggling ONS[9] as you see in attachment?

Thanks All!

Click to expand...

The output instructions will not be run in the circumstance that Oneshot[9] is already true when the GRT is true. Under normal conditions this should never occur -- the GRT is true for a single scan cycle during which it sets Oneshot[9] to true, but then the output logic is run and clears the seconds value so the next scan the GRT is false (which then resets Oneshot[9])

As others have brought up, the most common cause for this is if Oneshot[9] were to be used elsewhere.

Alternatively, perhaps for whatever reason OneShot[9] was already true when the logic as shown was first run. For example if you had previously been using that bit elsewhere and it happened to be true when you deleted it, or if you added the MOV instruction when the seconds were above 59.

Are you downloading the program with OneShot[9] true, or making changes online.?
If there is no indirect addressing, what about an alias?

Have you considered posting the code in its entirety for review.?

lostcontrol said:

Are you downloading the program with OneShot[9] true

Click to expand...

This sounds like the problem to me. Downloading the program with a value over 60 already in temps_transport_p2_sec and the ONS already being true. It makes sense if OP managed to solve the issue by manually toggling the bit.