Dropdown menu script firing when comms go down

Ignition
1

Good morning,
I have a script on a dropdown menu that allows me to enable or disable a valve. Similar script on dropdowns that will start and stop a pump. We were having comms issues where the connection failed. This caused the script to fire because it thought the value had changed. What can I add to this to first check the quality of the tag before firing the script? This is what I have that works fine, except with sporadic comms issues:

   if event.propertyName == "selectedValue" and event.source.valueConfirmed != event.newValue:
          title = "Change Mode?"
          message = "Are you sure you want to Enable/Disable the valve?"

          if system.gui.confirm(message, title):
                 event.source.valueConfirmed = event.newValue
          else:
                 event.source.selectedValue = event.oldValue

I was messing around with various scripts, but the problem only appears to happen during specific types of connection issues, which, I cannot elaborate on simply because I don't have any granular diagnostics to know exactly what happened to cause the comms issue in the first place. I was going to try something like this today. Am I on the right path?

if system.tag.read("MYTAGPATH").quality.isGood():
    if event.propertyName == "selectedValue" and event.source.valueConfirmed != event.newValue:
           title = "Change Mode?"
           message = "Are you sure you want to Enable/Disable the valve?"

           if system.gui.confirm(message, title):
                  event.source.valueConfirmed = event.newValue
           else:
                  event.source.selectedValue = event.oldValue

Thanks for any help!

2

Hello,

Have you considered using a button to toggle the enable/disable for these items? This would not have to use property change events which are subject to multiple unwanted executions for comms issues as you have described.

Frank

3

Yes, I have buttons in other situations. Sometimes there are more than two choices on the dropdown, and I like that the dropdown takes up minimal space on screens that have a lot of components. If I cannot find a decent scripting fix, I may have to redo some of them as buttons as you have suggested. This is my first ignition project and do not have a programming background, so I'm hoping to find a simple solution where if a script is called, it will evaluate something else, like the quality, before issuing the popup confirmation dialog.

4

Perhaps a combination of a drop-down and a single button?

5

Yes, for the behavior you are describing, this approach should reduce or eliminate the symptoms of the underlying problem, but I'm curious why a tag changing quality would affect a user input? Is this dropdown bound in some way to the tag? Also, what do you suspect is causing your com issue?

6

Cool, thanks. We have various comm issues throughout our system. We are a water plant and have 4 remote sites, miles away. Storms, electrical issues, construction, weird firewall rules with our routers etc. Unfortunately, it's not just one issue. Locally within the main plant things are much more stable.

The dropdown is bound to the tag, yes. The tag is non-bidirectionally bound to the selectedValue, and bidirectionally bound to a custom property. When those two values do not match, such as when the user selects a new item, it initiates the script. When comms go out, the custom property value disappears, and the selectedValue property goes to -1. This triggers the script.

The weird part is that I tested it with a different script that seemed to work when I disabled the tag, as well as comms going out organically. But then a few hours later, it happened again. So I'm not sure if comms were going out in a different manner that Ignition reacted differently to?

I will implement this script on the components on a remote site and see if it works as intended. Thanks everyone.

7

Hmmm. It seems like a simpler check would be this:

If event.source.valueConfirmed and event.newValue  >  -1:
8

Didn't even think of that. I suppose that would be easier to paste into the existing script without having to locate the tag path for each component.