[Bug or Feature?] Having Designer open triggers onChange script multiple times

Ignition
,
1

Hey guys,

Me and my coworker were trying to set up a change script for onChange events for Perspective input fields and we have run into some odd behaviour that we're not sure is a bug or a feature. When we tie the change field to a tag and change said tag, we find that if we have anyone with a designer open on the view where the event script is, the script actually runs multiple times! Once for the initial change, and then once per person that has the view open. Is this expected functionality? I would expect the onChange script to run once on the change (which is crucial to us that it does) instead of running for each open Designer as well. If this intended behaviour, is there a way to disable this behaviour? I know it's not the script doing it because we use an almost carbon copy of it in other views and don't experience this behaviour. Any insight on this matter would be appreciated.

Thanks,
Tyler

2

Can you share what the change script is doing? Is there any chance the open Designers have a resource open which has its own script that writes back to the tag based on some condition? Remember if you used to have something in one Designer and removed it, that change won't be present in other Designers until they update with the new content.

3

I can't really share the exact code, company resources and all. But the gist of the script is it accepts a product scan and if it matches our product regex pattern, performs multiple data transforms on our internal systems via API calls from Jython. We do write to the tag at the end of the process or on error but that has already been accounted for in our analysis of the issue. We were all working collaboratively since we are just trying to reapply this to another station and any time there was a change made, we all would update from the Gateway to ensure we were all on the same page before the test. Naturally, we were quite stunned when we were seeing it duplicating. I just happened to notice it was happening [1 + # of people connected] so we had one person drop (again, updated to the same version as everyone) and when that decreased our value by one we knew we were on the right track and disconnected everyone before the next test.

4

A rudimentary version of the script might look like:

prev_val = "" if previousValue == None else previousValue.value
new_val = currentValue.value

if prev_val == new_val:
    log_error("Error message")
    clear_input("tag_path")
    return

if new_val == "":
    return

if matches_pattern(new_val) == False:
    log_error("Error message")
    clear_input("tag_path)
    return

if check_product_status_good(new_val) == False:
    log_error("Error message")
    clear_input("tag_path")
    return

if perform_transforms(new_val) == False:
    log_error("Error message")

clear_input("tag_path")

#non-system function definitions below

which would indeed trigger twice, but that's known and accounted for nature. The script would run 6 times if there were 2 connected to the designer as an example. 3 times with the new value, and 3 times with the empty string after clearing the tag

5

Do the input fields have any binding against the tag value?

My main concern is that if the fields are bound, you have a sort of looping cycle in place where the field is bound to the tag, the field writes to the tag for this session. The tag receives the write and updates its value, which then updates any fields which are bound to the tag. These secondary fields now register that their value has changed, resulting in the whole cycle starting again.

You can get around this by only executing your change script when the origin is from the browser.

Wrap your existing script inside a conditional:

def valueChanged(self, previousValue, currentValue, origin, missedEvents):
    if origin == "Browser":
        # your existing code here. Beware of mixing spaces and indents.

That code should limit your change script to only executing when the front-end ("Browser") makes a change to the field, instead of executing the code when the value is updated via the backend (binding).

1 Like
6

That would make a lot of sense and could most likely explain what is happening to us. The snip-it you've provided looks very promising. Not enough time to get the group together to test this out today but I am definitely going to try this tomorrow. Fingers crossed! Thanks for the help so far, I will report back tomorrow with the results. Hoping it's just something this simple!

2 Likes
7

Thanks for the help cmallonee. That was indeed my issue. I have marked your snippit as the solution so that hopefully someone else with my issue may find this simple fix to an otherwise annoying issue!

1 Like