Well this is weird

[MikeBriggs]

I'm trying to figure out a weird behavior I'm seeing in my CCW program. It's for controlling a gas polarizer (for medical imaging). I'm using an INT called "PolarizeStep" for counting through various steps in the process. Have a look at the attached screenshot please.

If you look at rung 80, you'll see that it starts with two checks that pass - NowPolarizing is true, and PolarizeStep equals 6. During this process some liquid containers are being moved down. Once they're both at the bottom, "BothAtBottom" becomes true, and PolarizeStep should advance to 7. Note that BothAtBottom IS true, but PolarizeStep remains at 6.

To make things weirder - the next rung, which is for when PolarizeStep does equal 7, is being triggered. It seems to think that PolarizeStep currently equals BOTH 6 and 7, because both of those rungs are being triggered.

The problem that this is creating is that the timer in rung 6 can expire (even though it should no longer be running since BothAtBottom is true), and trigger an error (the stuff below the part in rung 80 where PolarizeStep should be moving to 7).

Has anyone seen anything like this before? Where CCW thinks a variable has two values at once? My best guess is that rung 80 IS advancing PolarizeStep to 7, which triggers rung 81, but something somewhere else in the program is making PolarizeStep go back to 6. But, there is only one place where PolarizeStep can be set to 6, and it's in a rung that should only be getting triggered if PolarizeStep is 5.

Help!

 

[MikeBriggs]

In case it helps - I'm using a Micro 850 2080-LC50-48QBB.

And another oddity to add to this. This weirdness ONLY happens if I tell it to stop the polarization process (by pressing the on-screen Stop button three times), and all that does is advance PolarizeStep to 4 (since we still need to do the processes from 4 onward). If Stop is not pressed, and it gets to PolarizeStep 6 by working its way through the preceeding steps, this part runs fine - when BothAtBottom becomes true, PolarizeStep properly advances to 7, and it continues on. But if the Stop button was pressed 3 times (which only has it advance from whatever step it's currently in to PolarizeStep 4), it will get stuck at 6.

 

[drbitboy]

It seems to think that PolarizeStep currently equals BOTH 6 and 7, because both of those rungs are being triggered.

Here's the thing. In PLCs, when is more import than what. PLC programming is about time, and the scan cycle is the clock, along with the order of operations (top rung/branch to bottom rung/branch, left to right along an unbroken rung/branch).



So when you say that

• It seems to think that PolarizeStep currently equals BOTH 6 and 7"

I instead say that, during each scan cycle,

• when the PLC evaluates the first EQU instruction on rung 80, it read the value of PolarizeStep as 6, which made the EQU instruction evaluate to True, and the PLC then acted according to the rest of the logic on that rung, which including writing a value of 7 into the tag PolarisStep,
• AND
• when the PLC next evaluates the first EQU instruction on rung 81, it read the value of PolarizeStep as 7, to which is had been set microseconds before during the same scan cycle, which made the EQU instruction evaluate to True, and the PLC then acted according to the rest of the logic on that rung

So yes, the PLC found values of both 6 and 7 for PolarizeStep during one scan cycle, it did not do so at the same time.

CCW in online mode shows just one value for PolarizeStep. When it sampled that tag for its value is unknown, but apparently it sampled it when PolarizeStep was 6, because that is what is displayed.

How the value of PolarizeStep went from 7 in Rung 81 back to 6 is more than I'd care to guess at, since we only see a few rungs of the program.

But as sure as God made little green apples, its value was 6 when the PLC started evaluating rung 80, and its value was 7 when the PLC started evaluating rung 81.

 

[MikeBriggs]

True, I shouldn't have said it thinks PolarizeStep is both 6 and 7. My line of thinking has been that it is executing rung 81 because PolarizeStep is getting advanced to 7 in rung 80, and *somehow* getting reset to 6. The problem is I can't figure out how. The ONLY rung that can assign 6 to PolarizeStep is a rung that requires PolarizeStep to equal 5. I need to monitor the program to see if that rung is also getting triggered in the same cycle.

Unrelated - what is up with this website today? I've had to login probably 20 times. Every time I try to do anything (click on anything), it requires me to login again. It's like the auto-logout time is set to something incredibly short. I've even logged in and after it says "thank you for logging in" it immediately takes me to the login screen again. Repeat that 2 or 3 times and eventually it decides to let me go on to whatever page I was trying to access.

I'm not sure if this is even going to post, since it will surely require me to login repeatedly.

 

[MikeBriggs]

Woohoo! I figured it out! (the PLC thing, not the issue with having to login repeatedly - I had to login 7 or 8 times to be able to reply to this thread).

Pressing the stop button three times was making a boolean "StopPolarizing" become true. I had a rung that said that if StopPolarizing is true, set PolarizeStep to 4. Steps 4 and 5 have timers, after which it increments PolarizeStep. Once it had made it to PolarizeStep 6, those timers had already completed - so every cycle the program was resetting PolarizeStep to 4, but it would skip right ahead to 6. I should have used a Pulse rising edge contactor on the "StopPolarizing" boolean for the command to set PolarizeStep to 4, since I only want it to do that once.

Now to login 10 times so I can post this....

 

[Steve Bailey]

Maybe it's me, but the color choices that indicate the true and false states seem bass ackwards.

 

[drbitboy]

Maybe it's me, but the color choices that indicate the true and false states seem bass ackwards.

Gee, something done poorly in Fisher-Price CCW?

Imagine that