weird CCW behavior

[MikeBriggs]

I'm trying to figure out some weird behavior I'm seeing in one of my programs. This should be fairly straightforward - except that it's not working. I have an INT named ValveState which is used for controlling 14 pneumatic valves (controlled by booleans named Valve1-Valve14). I'm attaching a snapshot of the rung for controlling one of the valves, Valve6. Note that in the picture ValveState is 5, which *should* be triggering the last path for setting Valve6 to true. And yet Valve6 is false. When ValveState initially becomes 5, it does correctly trigger Valve6 to become true - but then it immediately resets to false. But Valve6 is not being written anywhere else in the program (it is being read in one other rung, in which a digital output is assigned the value of Valve6). I am seeing this behavior with all 14 valves - they will only be briefly set to true when a condition is met, but then immediately revert to false. I feel like there must be something obvious I'm overlooking, but I can't figure out what. Thank you!

 

[doctord]

do not use CCW but what you have looks correct. Is the logic being ran?

 

[MikeBriggs]

doctord - As far as using CCW - what would you recommend instead?

Anyway, I think I figured this out. It still involved some other unexpected behavior (meaning behavior that I think is wrong). I *think* the INT ValveState was getting temporarily set to 1 earlier in the program (but then reset to 5 so it would show up as 5, but not in time to trigger setting valve6 to true). It *shouldn't* have been getting set to 1 though.

I'm attaching a screenshot of a revision I made to the part of the code that I think was causing the problem. The intent of rung 2 is that in State 1, if TankSwapping and ManualGasControl are both false, then ValveState gets set to 1. That was originally being done as part of rung 1 (which resets a bunch of booleans to false if State is 1). Previously I had the MOV command for valveState in rung 1, with the two reverse contacts before it. It should have worked the same (for resetting the coils that are still in rung 1 I don't really care about the status of tankSwapping and ManualGasControl, so I just removed those from there). In the test I've been doing, TankSwapping is getting set to true - so that reverse contact should not be passing.

Initially I just removed the MOV command from rung 1 for resetting ValveState to 1 when those conditions were met, and the problem went away. The valves now get set properly. So it seems like ValveState must have been getting set to 1 from that rung - but it *shouldn't* have been because TankSwapping was true.

Am I misunderstanding reverse contacts? I am viewing them as basically like a direct contact except checking to make sure that the boolean is false. So, in what is now rung 2, if State = 1 and both Tankswapping and ManualGasControl are false, then ValveState gets set to 1.

Since I do want ValveState to get set to 1 when TanKSwapping is not true, I made a separate rung to do that, and it still works fine. But from my point of view it's not logically any different than what it was before, when it wasn't working. I just separated out the MOV command (and took the reverse contacts with it, since I don't care about them for the reset coils that are still in rung 1).

 

[drbitboy]

doctord - As far as using CCW - what would you recommend instead?

When @doctord wrote "do not use CCW ...," I think they were saying that "I [@doctord] do not use CCW," and they were not saying "You [@MikeBriggs] [should] not [be using] CCW."

 

[drbitboy]

So it looked like this before?

​

 

[MikeBriggs]

When @doctord wrote "do not use CCW ...," I think they were saying that "I [@doctord] do not use CCW," and they were not saying "You [@MikeBriggs] [should] not [be using] CCW."

Ohhhhh, that makes more sense now.

 

[MikeBriggs]

So it looked like this before?

View attachment 67315​

Nope, I didn't explain it very well. I should have just included a picture of what it looked like originally rather than trying to use words. I just temporarily remade it to how it was to take a screenshot.



Functionally shouldn't this work basically the same - except that with this original version, all the other things that come after the MOV command wouldn't take effect when the reverse contacts don't pass - but for the moment that's immaterial. The issue is that somehow, with it done like this, it seems like it was triggering the MOV command to set ValveState to 1, even though TankSwapping was true.

 

[drbitboy]

That is certainly odd; if TankSwapping's value is a constant 1, then the value of ValveState should not become 1 from that logic.

Is it possible that the TankSwapping value can become 0 for a brief moment, perhaps as short as a single scan? As a diagnostic, you could run an XIC with TankSwapping into a TOF with a preset of 100ms, and use that TOF's .Q bit value in the logic that writes 1 to the value of ValveState. This would effectively debounce the transition of TankSwapping from 1 to 0, in case TankSwapping is experiencing transient changes. An alternate diagnostic to detect such transients would be to independently count positive and negative edge transitions of TankSwapping.

 

[dburnum]

You say Valve6 goes tre for a brief period and then goes false. Could be from a destructive bit? Is Valve6 anywhere else in your program?

 

[MikeBriggs]

That is certainly odd; if TankSwapping's value is a constant 1, then the value of ValveState should not become 1 from that logic.

Is it possible that the TankSwapping value can become 0 for a brief moment, perhaps as short as a single scan? As a diagnostic, you could run an XIC with TankSwapping into a TOF with a preset of 100ms, and use that TOF's .Q bit value in the logic that writes 1 to the value of ValveState. This would effectively debounce the transition of TankSwapping from 1 to 0, in case TankSwapping is experiencing transient changes. An alternate diagnostic to detect such transients would be to independently count positive and negative edge transitions of TankSwapping.

Hmm... interesting. In the scenario I'm running, TankSwapping should be remaining true (background: the system has four gas tanks, and when the user clicks a button on the UI for changing any of the tanks, TankSwapping becomes true and remains true until they press a "Done Swapping" button. At least that's how it should be working. I should monitor TankSwapping to ensure it's not becoming false somehow. It's controlled by a single rung that has four paths for triggering a Direct Coil that sets TankSwapping true - one path for each of the four tanks that can be swapped). I'll look into that.

Although, if TankSwapping is becoming temporarily false, it seems like my "fix" shouldn't have fixed it, since the same logic is still at play.

 

[MikeBriggs]

You say Valve6 goes tre for a brief period and then goes false. Could be from a destructive bit? Is Valve6 anywhere else in your program?

Nope, I made sure that that is the only rung where Valve6 is being written. So it can't be coming from anywhere else.

I thought it *might* be coming from the UI, because when I do a cross reference check it shows Valve6 being both a read and write in the PanelView 800. But, the only thing it's being used for there is as an indicator, it's not being written to.

 

[Rockfordmfg]

You may be having a firmware issue going on.

What controller and Firmware version are you using? I had a project with the 2080-LC50-48QBB controller and was using Version 12 of CCW at the time. I upgrade my controller firmware to Version 12 and had issues with not being able to control some real variables. No matter what I sent to the variable the controller would overwrite it with what it wanted as a value. I spoke to Rockwell Tech Support and they told me to rename the variables. - Not a good solution! I downgraded the controller to version 11 and never had any more issues.

If you are using the new controllers 2080-L50E-xxxx you can only have Version 20 or 21 There may be a similar issue with these as well. I haven't used any of the new controllers yet, so I can't speak to that.