I don’t see why you couldn’t use a script in property change event for control value. That value will change regardless if you bind it to anything or not.
Whatever you do be very careful and test rigorously. Three position hoa switches are very reliable and retain state through power outages. Much more challenging to achieve the same reliability in software, especially in scripting. The last thing you want is a machine turning on when you restore or restart a gateway ( or one of the other many edge cases). It happens…trust me.
Personally, I would avoid putting logic in the script and modify the PLC code so the PLCretains the HOA state in an integer PLC value. The PLC code would monitor signals from the HMI and change state on rising edge. My ‘go to’ design is to set an integer command value on the HMI (1= hand, for example) then the PLC code sees the change of the command value from 0 to 1 and then sets a different PLC tag state to 1 if interlock conditions are ok. The PLC then sets the command value back to zero. The same HMI command tag with a value of 2 sets auto mode and a value of 3 sets off mode. In this way multiple clients can set the value and the PLC ultimately has total control of when the state changes(or doesn’t). I am not a big fan of HMI and scada systems maintaining state for a important parts of a control system.
One other benefit to this design is new commands do not require a new HMI tag and keep the tag structure much easier to modify down the road. (Cycle stop could be a command value of 4, for example. )
Strongly disagree. Tags that can be written from multiple directions/sources are inherently racy and don’t play well with OPC’s fundamental assumptions for subscribed values. Separate your signals and your acknowledgements.
I agree with you on the racing. It is better to have the signals separated for robust operation. Bi-directional values between PLC and OPC server can be very buggy as you said. Separating the command request (HMI → PLC) tag from the HOA state tag (PLC → HMI) is what I suggested. I think that you mean the command request (HMI->PLC) should not be reset by the PLC ? I have had no problem resetting the command request in the PLC in many applications but you could argue it is better done in the HMI script after a delay or confirmation from the HOA state tag(PLC->HMI). Nothing writes to the HOA state tag except internal PLC code.
But my main point is that an HOA switch is essentially a “memory” device that maintains state physically with switches and detents. Unless you cut the wires or lose the remote IO connection to the PLC they are very reliable. Most simple PLC code is not written to be fault tolerant for HOA switches because they assume the switch will always be there and working properly. Usually a good enough assumption. But not in critical systems. If you replace the HOA switch with a tag in an OPC server in the HMI you will introduce many more ways for the state to be lost/set to old values and possibly cause unwanted dangerous behavior. For example, what does the PLC logic do if there is no OPC server connection available ? (It depends on how the PLC code is written )
I have seen some potentially dangerous situations when someone has maintained state values in HMI tags then restored a tag database or gateway that was made while a system was running. Because of bad design the machine started to do something is should not have been doing. Preserving state in tags is something everyone should think very carefully about. (As well as restoring things assuming the worst could happen)