Vision Scripting - What am I missing here?

Retrofit of HMI on older machine. PLC code exists and is working. I have a valve, when clicked opens a popup window. On that window a (2) value multi-state button. Open (control value is 1), Close (control value is two). And also an OK button and a Cancel button. Cancel closes the popup, OK executes a script to write specific integers to PLC addresses. In this case if the button control value is (1) write a 46, if control value is (2) write a 47.

The valve indication is a boolean on another PLC address.
All that works fine.

I was wishing to pre-set the control value of the multi-state button based on the present state of the valve. So I added a custom property to the root container of the popup.

Name: Status
Type: Boolean
Desc: Valve Status

and I linked it to the PLC valve indication.

Then I added an 'internalFrameActivated' script on the pop-up:

# valve is open pre-select close
if system.gui.getParentWindow(event).getComponentForPath('Root Container').Status:
	system.gui.getParentWindow(event).getComponentForPath('Root Container.Button').controlValue = 2
# valve is closed pre-select open
	system.gui.getParentWindow(event).getComponentForPath('Root Container.Button').controlValue = 1	

However it does not work reliably, and I think I have a fundamental mis-understanding of how to set the button property.

Are you using a parameterized pop-up? Typically values parameters are passed into a popup when the pop-up is opened rather than retrieving the values parameters after it has opened.

You could set the values to be 46 and 47 directly, and just write the value instead of having to resort to an if/else logic.

At the time I wrote that - no I was not. But I had a note to look into that, and I just converted my valve popups to parameterized. but I left the status parameter binding in place. And passed the close value, open value, and valve name. Works fine.

And in the time of answering your question, now I added the status.....
And it works great. :beers:

1 Like

Since when? Well designed parameterized popups pass a tagpath, and possibly some behavior constants, and let the popup get all of its data with indirect binding.

So, totally disagree.

1 Like

I try to make my windows "encapsulated", it's not a direct one-to-one definition with programming but the idea is similar - I should have to pass my popup as little information as possible and let the logic of the popup figure out the rest. I shouldn't have to figure out the data for the popup, the popup should do that, I should have to pass in as few parameters as needed.

Therefore for popups that retrieve a record from the database, I should only have to pass in something like {"id":5} as a parameter. To make me have to provide the actual dataset means extra work for every time I need to call and open that popup. Much better to let the bindings in the pop-up do the work and to make your call as to open the window as simple as possible imo. Same thinking for popups that display values from tags as @pturmel points out.

1 Like

A given system can have dozens of control valves, but I will have precisely one popup window for all of them, and they will all pass their parameters into the window. If I ever have to make a change, I will only have to make it one place.

I've done a tutorial on this before:

That tutorial shows the passing of tag paths. I don't see where it disagrees with my statement. The statement of yours that I was objecting to implied the passing of tag values not tag paths. At least, that's how I read it, and would expect others to do the same.