I might be missing something easy here, but the way the PLC programmer built three tags for an alarm bypass was the following:
Alarm Bypass Status (1-Bypassed, 0-Unbypassed)
Alarm Bypass (One-shot - Sends a 1 goes back to 0, Status is in Bypass - also has a read after write tag group)
Alarm Unbypass (One-shot - Sends a 1 goes back to 0, Status is in Unbypass - also has a read after write tag group)
With the above, I would like the (Bypass or Unbypass) perform the action, the have the Status tag be polled/read right after.
By working with a combination of a one-shot button component, driven tag group with read after write, tag change events, I'm unable to get this working. Also, I don't think there is a script function to do a demand poll. Changing the tag group of the Status tag always results in a long delay before it reads the tag again. (This is not comm speed performance as a read after write set to true is very quick on it's own tag, but Status is not being written to at the PLC).
Since I have a UDT setup, a driven tag group doesn't seem to allow parameters for dynamic location, nor does it work selecting the data type option (needs to be a specific tag).
Not sure about the one shots (not a plc guy), but this sounds normal to me to have cmd buttons to change state, as then the plc has control of when and if the alarms can be bypassed or not. We usually have enable tags provided by the plc for the cmds as well so can disable them in scada if they will be rejected
Thank you for confirming. This was my original thought, but the PLC programmer said it was for the purpose of the status confirming after a write. Maybe this was an older method used?
I mentioned that Ignition had a one shot button that can write directly to the tag while waiting for the return read and request a read after write (tag group setting) for quicker feedback to the operator.
There are a handful of threads on the forum regarding race conditions that occur with specific tag group configurations... especially OPC subscriptions w/ read after write whose tags auto-reset (or are overwritten) by the logic controller. While you mentioned that you were able to get yours working, I'm curious if this isn't contributing to strange behaviors...otherwise, I'm not sure I understand the need for tag change events here.
If it's programmed how I envision, I don't hate this style of programming, and - personally - do not recommend a change. The ladder logic I picture is designed to resemble a logic circuit w/ separate start & stop buttons, and is about as straightforward as logic can be. Call me old fashioned.
I would change all your commands to a dedicated tag group, either polled w/ read after write, or subscribed w/o the additional read. Further, ai would make all commands leased tags, w/ a fast scan of a few seconds, and slow scan of -never-. For the status tag, can you place that tag in a leased group with a slow scannof 2mins, fast scan of a few seconds?
Not sure this is the reason that I would give for this style of logic...as the more-direct 'single tag' method recommended by @pturmel :
would quickly show any error when reading the status back from that same tag.
@rpavlicek, I would wager a friendly bet that your programmer did not prevent a write to the status tag. There's also a good chance that you CAN start (and stop) the bypass by just writing to this tag.
If you arent able to speed up your tags by using leased tags, then I would entertain this recommendation. No need to change the logic, just attempt a write to test it out.
That is the fundamental problem. In a system with physical buttons, those buttons are momentary inputs. That type of logic has huge problems when the "buttons" are driven by non-deterministic protocols. Deterministic remote I/O technologies simply do not use TCP/IP, but fast-repeating UDP (Class1 EtherNet/IP, GE EGD) or raw ethernet (ProfiNet) packets.
If you don't have the protocols to support "old fashioned" logic, that logic is simply wrong.
I would love to agree, but have a problem with your insinuation that Ignition is incapable of reading & displaying the actual value in the PLC just because Ignition tried to write a different value in the past. If this were true, I would not use Ignition's drivers, and recommend that others avoid doing the same.
I'm aware that my previous comment oversimplifies a complicated subject. I believe that the native Ignition driver is capable, and that everyone should be advised on the importance of selecting correct tag groups. The Ignition manual (Tag Groups : OPC Settings) provides a clear recommendation:
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.
So, avoid that scenario. Turn off Read After Write, or change data mode to polled.
You are missing my point. If you have to alter the PLC code to turn off button bits for you to make a non-deterministic protocol work, you don't have "old fashioned" logic at all any more. You have a cobbled-together pile of junk.
OPC data delivery has very specific standards, and if abused (read after write), otherwise compliant OPC servers in corner cases can not report values that, by their rules, are not changes. The abusive features were added to mitigate UI confusion when the read following a write didn't match the write (because the PLC changed it already).
The corner cases and pathological behaviors are always associated with variables that are written from two directions on a regular basis, usually quickly. (Like immediately resetting a button bit.) If the writes in question are "fire and forget", that is, there's no handshake or verification requirement, that also avoids the pathological behavior.
When you combine writes from two directions with any kind of handshake or verification, you are screwed. "Old fashioned" logic cannot fix this.
That's why I recommended simply writing the mode. For the button, it is fire-and-forget. There is no extra PLC code needed as a handshake. And it is verified by a human seeing that status on the next normal subscription update.
@rpavlicek, well, there you have it... at least two opinions from a couple of individuals that will have to agree to disagree on this topic...one that has already veered far enough from your original question. I added my concerns on the side-topic due to the 'tag change events' comment. Sounds like you've already remedied that detail. Hopefully there is enough information in here for you to move forward. Let us know if any recommendations in here need additional clarity or if you hit any additional hurdles.
I confirmed I can write directly to the Status tag, so I'll use that. From within Ignition, I'm going to write directly to the Bypass Status tag with the appropriate tag group settings. This would have been my original thought, but I went off track based on the programmer's train of thought of using the two one-shot bit tags, which he can keep on the PLC for classical purposes.
