Vision Scripting - What am I missing here?

Ignition
1

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
else:
	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.

2

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.

3

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.

4

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
5

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
6

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
7

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:

8

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.

2 Likes