Momentary Pushbuttons in Perspective

Ignition
41

i would test the unplug mouse on on this

1 Like
42

I checked the open source code, and i see the module was created quite good. With some checks in it.
However like you said this still doesnt cover everything and never can replace a physical button for instant security/critical safety

2 Likes
43

It helps that it was created by Travis from IA, so most customers don't have an issue with it. It'd be nice if IA could add it as standard as most people that want a momentary button will still attempt to use what's there now and only find out how unreliable it is months later. :upside_down_face:

44

It should not be a standard component because it is unreliable and never can be. making it more accesable only increases the danger of people using it without research, thinking its good.

Hopefully, now atleast some find this post before finding the module and see its not good to use, for critcal things

8 Likes
45

My bad for getting back to this after so long, but I just re-read this and have a question about how your workflow would be for this. Am I completely off track below?

Say we have three tags:

  • AutoCmd [bool] - Written from SCADA only
  • AutoCmdAck [bool] - Written from PLC only
  • HOA [sint] - 0 Manual, 1 Auto, 2 Off

Would the auto command from scada be handled like so?:

  1. SCADA operator sets AutoCmd to TRUE
  2. PLC monitors AutoCmd, sees TRUE, sets HOA to 1 and sets AutoCmdAck to TRUE
  3. SCADA sees AutoCmdAck set to TRUE, ValueChange event on this tag fires and writes AutoCmd back to FALSE with system.tag.writeAsync (to avoid waiting for the return and blocking tag event queue) - What if this write actually fails?
  4. PLC sees AutoCmd go FALSE and sets AutoCmdAck to FALSE

Would you use a GW timer event instead to monitor the AutoCmdAck tag(s) and write them to FALSE instead? This would handle failed writes by retrying them indefinitely, but it requires a lot more process diligence to ensure all command ack tags are included

46

Terrible example. For this sort of thing, have your buttons write directly to the HOA tag. Single write from Ignition. No write to the HOA tag at all from the PLC.

The race with booleans to be concerned about is when you are using them relatively quickly (like data transfer trigger+ack), or your UI depends on visual feedback from the button boolean.

Gateway events should be used to write ack booleans when the PLC is setting and clearing a trigger. Similarly, you can use a gateway event, preferably a timer, to clear a trigger boolean when the PLC ack for it true. (Using a timer like a PLC task avoids the failed write issue.)

1 Like
47

Yes, HOA was a bad example! (quick reply before lunch) Replace hoa with a motor start command.

For these types of commands like start cmd where the plc resets it, I've been using opc.write to issue the command to avoid race conditions which would see the ignition tag have a different value than the plc

1 Like
48

Wouldnā€™t it still have a different value, just the other way? Tag would have a 0 while PLC tag had a 1. Albeit, youā€™re probably immediately resetting the tag upon use in the PLC, so likely the gateway never sees the transition from 0-1-0, but still. Iā€™ve been using standard tag bindings in buttons that set the value and the PLC resets, and I've yet to encounter any race conditions.

49

This is a point that canā€™t be stressed enough. Any critical safety or jog should be on a physical button.

This is especially true if you are talking about a perspective app because those apps can be run in locations that are not safe to operate the function. I make this point every time someone asks me to implement a jog button in a perspective app because I think itā€™s engineering malpractice to implement one.

Putting jogs on a physical button ultimately controls where those functions can be used and eliminates the issues with momentary buttons from perspective. Yes, you can geofence things but I feel like thatā€™s bad architecture when a physical button accomplishes the same thing without all the unnecessary complexity. Why force the square peg into a round hole?

Simple systems are cheaper and easier to support. In this case itā€™s also safer.

5 Likes
50

I've seen it latch on in ignition before more than once and then block any future control of the button until you restart the tag.

51

Iā€™d wager your tag groups are configured w/ 1) Read After Write = False; 2) Data Mode = Polled; or 3) (less likely) Mode = Leased (and clients tend to refresh views before reporting issues).

My opinion - thereā€™s really no need to obscure PLC logic to handle the race condition, provided youā€™re willing to make the marginal sacrifice within Ignition.

From the Tag Group docs:

Caution: Do not use Read After Write with OPC tags in subscription mode due to a race condition that can leave you with Ignition tag values that don't match PLC tag values.

52

How much you want to wager :wink:

Not polled or leased, Subscribed Direct. Read after Write is false.

100K tags, 8 months since roll out, 0% load on devices, buttons are updated at 150ms, everything else 1000 to 3000 ms rates. Not a single instance of a button hang on or tag Not updating across dozens of clients.

53

Never once have I seen that behaviour, but have always used Control Logix driver. All my PLC code has always reset HMI PB tags since the dawn of time and wonderware. Current rollout of around 100K tags, 8 months old now.

54

:man_shrugging: One can only warn of previous experiences

55

= Configuration #1, eh? :+1:

2 Likes
56

No. Mobile OSes allow the user to put in false GPS coordinates. Typically requires developer mode, but the website involved is not notified of this. Geofencing is just a convenience, not a security barrier. In spite of its use in Ignition "Security" Zones.

5 Likes
57

I didnā€™t know that.

Even more reason not to put momentaries in perspective.

1 Like