PV+ Inhibiting of interlocked push buttons

DairyBoy

Member
Join Date
Jun 2007
Location
UK
Posts
393
I'm trying to find a way to prevent a PV displaying a change of state that isn't being acted upon in the (L32E) plc.

I have 5 interlocked buttons that write 1,2,4,8 or 16 to a tag in the plc. The first five bits in the tag are then used to enable outputs in 5 rungs which each have their own respective interlock bits.

If all conditions per rung are met, the output will be enabled. Fine.

If the conditions are not met for a given rung, the output bit will not be enabled but the array of buttons will change it's indicating state from one to another all the same because the new value has been written to the plc. This is what I'm trying to prevent.

First thought was to place a MOV in parallel with the output bit per rung to hold the value in the tag and freeze the displayed button value, but that wouldn't work: Even if the new "target" rung's conditions are all met, the pv would get a message back from the plc that the previous value is held and would be re-written with that value, so nothing would change. (Or would that only be the case when trying to change from the last of the five rungs in scan-order?) Either way, that's a non-starter.

To one-shot the MOV would be the same as the pv is doing anyway. The animation on these buttons is limited to visibility so nothing doing there as they form part of a graphic representation and need to remain visible.

Stumped!
 
Do the interlocking and inhibiting in the PLC - just have monentary pushbuttons on the PV+.

I generally favour HMIs being as simple as possible, basically just I/O points.
 
Yes, I agree. It's one of those that started growing in complexity once I arrived on site. Interlocks that I'd written into it were taken out on day one and others that I had not included arrived soon after. Online juggling time :unsure:hehe.
 
I've side-stepped it: As no outputs or other logic are affected by an inhibited rung, I've added an overlaid warning on each button. Much quicker for now.

Re keeping the hmi dumb, my first and unfortunately most complex plc/hmi job was a tube cutter/bender/dimpler for jet engines. It was my first use of the Paradigm (now red lion) range. PLC was GE9030 with dos editor. I did ALL the calcs in the hmi using the built in C++ facility; there were loads of them (6 servos) and the dimpling patterns -using arrays of pneumatic pins- kept me up late for weeks. But looking back after fifteen years, I still dread to think what it would have taken to do it all in that particular plc.
 
I'm trying to find a way to prevent a PV displaying a change of state that isn't being acted upon in the (L32E) plc.

I have 5 interlocked buttons that write 1,2,4,8 or 16 to a tag in the plc. The first five bits in the tag are then used to enable outputs in 5 rungs which each have their own respective interlock bits.

If all conditions per rung are met, the output will be enabled. Fine.

If the conditions are not met for a given rung, the output bit will not be enabled but the array of buttons will change it's indicating state from one to another all the same because the new value has been written to the plc. This is what I'm trying to prevent.

First thought was to place a MOV in parallel with the output bit per rung to hold the value in the tag and freeze the displayed button value, but that wouldn't work: Even if the new "target" rung's conditions are all met, the pv would get a message back from the plc that the previous value is held and would be re-written with that value, so nothing would change. (Or would that only be the case when trying to change from the last of the five rungs in scan-order?) Either way, that's a non-starter.

To one-shot the MOV would be the same as the pv is doing anyway. The animation on these buttons is limited to visibility so nothing doing there as they form part of a graphic representation and need to remain visible.

Stumped!

Here's how I would do it. When one of the outputs is set, MOV the value from "OUTPUT_ENABLE_TAG" to "OUTPUT_ENABLE_HOLD_REGISTER". When one of the buttons is pushed, a new value would be written to "OUTPUT_ENABLE_TAG" by the PV+, so a NEQ of the tag and the hold register could set a bit, call it "NEW_VALUE". For each output, OTL another bit, call it, "NEW_VALUE_ACCEPTED".
At the end of the routine you could have something like this:

Code:
 XIC "NEW_VALUE" BST XIO "NEW_VALUE_ACCEPTED" MOV "HOLD_REGISTER" "OUTPUT_ENABLE_TAG" 
NXB XIC "NEW_VALUE_ACCEPTED" MOV "OUTPUT_ENABLE_TAG" "HOLD_REGISTER" 
NXB OTU "NEW_VALUE" 
NXB OTU "NEW_VALUE_ACCEPTED"

That way, if no action is taken by the push buttons, because of the state of the output interlocks, the value of the tag will revert to its original value.

Hope this helps.
 
Last edited:

Similar Topics

Hello guys, We a compact logix processor and one of the safety input modules 1734-IBS seems to be faulty as sometimes the module led turns red...
Replies
4
Views
1,453
Hello, I am working with ControlLogix on one of our cells. We were replacing one of our Robots, so we had IO not responding obviously for the...
Replies
0
Views
1,184
Hello again everybody, I am making a new simple application with Micro 850 plc with 48 i/o. The i/o are not sufficient for me, so I will buy a...
Replies
0
Views
2,552
Our building is running mostly PLC5 setups with 1400e Panelviews. In those stands, we block out panelview downloads if the test is running, and...
Replies
8
Views
2,783
Is a door interlocked disconnect always mandatory? My customer is requesting a control panel that aligns with UL508 guidelines but they do not...
Replies
32
Views
12,546
Back
Top Bottom