Micrologix + RSLogix500 Strange Counter Behavior

[mike64b]

So possibly I am misunderstanding the definition of a count up on a false to true rung transition but I've got the following code (attached). You can see that the beginning of the rung checks a bit, if its set it enters the rung and eventually will get to B3:2/15.. this bit is initially set to 0, so the counter is skipped. The next rung then sets B3:2/15 . Additionally, the main rung bit B3:3/5 is cleared so that on the next scan this rung is ignored (code not shown will then set B3:3/5 so that on the third pass the rung is entered again)

Eventually we get back to the rung again, and this time as we go in, the B3:2/15 bit is set, so we hit the counter, and it counts to 1.

Everything works fine up to this point, the counter accumulator never goes past 1... This leads me to believe that the only possibility is that since B3:2/15 remains set, that it does not see a false to true transition.. I figured that the B3:3/5 being cleared would be recognized as the false to true transition... Can anyone help explain or give a resolution?

Thanks!

 

[OkiePC]

Everything works fine up to this point, the counter accumulator never goes past 1

What happens between everything working fine, and the counter never going past one?

If B3:2/15 remains set, the only other logic in this rung that can cause the false to true transition of the rung-in-condition for the CTU instruction would be the 0 to 1 transition of the contents of address B3:3/5,

Said another way (sometimes it helps to translate logic to English multiple ways): Each transition to "1" of the address B3:3/5 while B3:2/15 is also a "1" should increment the counter.

If B3:3/5 is indeed toggling off and on with the other bit 'set' (even though it will be hard to see since you're unlatching it) then there would be something fishy, likely not a bug, more likely some external influence on the whole ladder file in which it's contained (think conditional JSR)*, or the address of the counter, or ???.

To test this, put a dummy counter above that rung:

XIC B3:3/5 CTU [new dummy counter address]

and watch it run...

* The conditional RETurn in your screen shot raises a red flag with me. Are there other rungs before this logic with conditional returns that are preventing this one from executing?

 

[Ken Roach]

I think your understanding of the CTU instruction's operation is correct.

The logic as shown will work; it will skip the first time the rung is scanned, then count up by 1 every time LidCleanTog2 is set.

There has to be something else in your program, either in the logic that sets LidCleanTog2 or executes the Subroutine, that is preventing the counter from continuing.

 

[mike64b]

Unfortunately I don't have the PLC at home so I can't test till tomorrow, I think OkiePC might be onto something and I'm worried what I'm doing won't work. I think its probably not good programming practice but from what I understood it should work... Please see the below ladder logic:

First image shows that if we are set on the lid section, we'll JSR to Lad9 , additionally upon return from that program we will skip to the end of the ladder file.
http://i.imgur.com/me4Mr.gif

Next image shows U:9 (the rungs above these are insignificant I believe), basically, we first check whether the motor done bits are set , if they aren't that we keep RET and coming back in until the move has finished and the bits are set (I did notice an error, that should not be Not(Axis 1 Done) AND Not(Axis 2 Done) it should be Not(Axis 1 done) OR Not(Axis 2 Done), but I don't think this is whats causing the issue, i'll fix it tomorrow and check)..

Rung 7 checks that the toggles are both cleared and then sends an output to a motor, latches both toggles, and RETs out.

Finally, the next image shows Rung 8 which checks if LidCleanTog is set and LidCleanTog2 is cleared, if they are, it MOV's a value, negates it, outputs it to the motor, negates it again to keep it positive, and then unlatches the LidCleanTog and latches LidCleanTog2.

Of course rung 9 is posted in my First post.. Overall these rungs have the effect so that first rung 6 is run, then once that motor move has finished, rung 9 is run, once that is finished, rung 7 is run, once that has finished rung 9 is run, and finally back to rung 6 to repeat the process until the counter in rung 9 exceeds a certain value (the rung to check the ACC bit is unshown but higher up in the JSR).

I was really hoping this setup could work so I'd love to hear if its possible despite it being bad programming practice.. ( I do have an alternative in mind in using the REF command to update the outputs but I'm not sure how well that will work..)

Thanks!

 

[mike64b]

OkiePC looking over your comments I think I have my answer... The conditional RET's above this one mean that this rung does not get run when it is false, therefore, there is no False to true transition... I'm trying to figure it there is a way to fix this hmmmm

 

[OkiePC]

You are right that it is a questionable programming practice. Often, folks who work with high level languages on more "normal" computers have a bit of a hard time wrapping their head around the continuous infinite loop that is the heart of how PLCs work.

They end up grasping for ways to perform branching and program flow control, when the simple answer is just let all of the rungs get scanned, and add very simple bit-examine instructions to "block" the rungs you don't want to execute.

There are tons of examples on this forum and others of this type of programming style ending up becoming a kludge.

If you can clearly define the purpose of your logic and provide enough details, one of us here can probably whip out an example of the "right" way to do it.

Not saying there is a wrong and a right way. I was once told, if it works, it is right, no matter how convoluted it is. I disagree slightly. Clean, efficient code that is easy to understand and modify is "right"-er than complex confusing code that is difficult to understand and modify. Even if they both do the same thing.

Paul