Evaluation order of RC components, tag / SQL bindings


I have a fairly simple template i’ve tried to build, but its proving quite complicated to get it to work reliably.
I have a combination of Root Container custom properties, bindings to standard components, bindings on RC properties.
Some bindings are expressions, some are using ‘runScript’, some are SQL queries, some are indirect bindings to PLC tags.

What i would like to understand is whether or not there is a strict evaulation order in Ignition for different bindings depending on the type of binding, or where it is located.
Do root container properties get evaluated first strictly before other components on the template/window?
If a root container property is a runScript or SQL binding, does that have to be evaluated before the other components on template/window can be evaluated?

I have a dropdown list which gets its ‘data’ from an SQL query. This query has references in it to RC properties.
I have tried to bind the dropdown ‘selectedValue’ to a different root container property (PLC tag binding), in the hope that the dropdown would get its data, then display the value that matches the selectedValue.

However i am finding that sometimes it works, and sometimes it doesn’t.

Any advise would be much appreciated.

Nope. Or rather, there may be at startup when bindings are established, but it immediately devolves into pseudo-random chaos as data arrival from the gateway varies in time. Since bindings are all event-driven, the varying arrival time of data varies the dependent calculations in other bindings, plus the effects of invokeLater() scattered through propertyChange events, yada yada yada.

The only thing you can really count on is the synchronous execution of propertyChange events, even where that produces unexpected recursion. (Yes, the python script that assigns to a property will be paused at that point while the nested propertyChange executes.)

Hi Phill,

Thanks for the response. A bit dismaying but i am definitely experiencing some of that pseudo-random chaos at the moment. Can you elaborate a bit more on the synchronous execution of propertyChange events?
I’ve tried printing to a logger in a propertyChange script to identify what might be evaluating in what order, so is it likely that if i have 8 custom properties on the root container, only one propertyChange event is fired at a time?

For example the debug code is:

logger = system.util.getLogger("BatchTemplateRC")

if event.propertyName == 'FCode':
	logger.info("FCode changed from '%s' to '%s'" % (event.oldValue, event.newValue))
if event.propertyName == 'FCodeData':
	logger.info("FCodeData changed")	
if event.propertyName == 'FCodeIDX':
	logger.info("FCodeIDX changed from '%s' to '%s'" % (event.oldValue, event.newValue))
if event.propertyName == 'RoleString':
	logger.info("RoleString changed from '%s' to '%s'" % (event.oldValue, event.newValue))

if event.propertyName == 'UserProdArea':
	logger.info("UserProdArea changed from '%s' to '%s'" % (event.oldValue, event.newValue))

And the response on the diagnostics console is:

15:17:24.162 [AWT-EventQueue-0] INFO BatchTemplateRC - FCodeData changed
15:17:24.164 [AWT-EventQueue-0] INFO BatchTemplate - Dropdown Data changed
15:17:24.208 [AWT-EventQueue-0] INFO BatchTemplateRC - FCode changed from '' to 'F2078'
15:17:24.209 [AWT-EventQueue-0] INFO BatchTemplateRC - FCodeIDX changed from '-1' to '24'
15:17:24.210 [AWT-EventQueue-0] INFO BatchTemplateRC - RoleString changed from '-1' to 'Role_Supervisor'
15:17:24.219 [AWT-EventQueue-0] INFO BatchTemplate - Dropdown Selected Label changed from: '<Select One>' to 'F2078'

Sometimes on opening of the template i don’t get that last component evaluating, the “Dropdown Selected Label” property, which is causing me grief.
I can probably make it polled so it will eventually update, but it seems like a bad workaround.


Well, started at a time. A property assignment within a script “pauses” that script to start any propertyChange event on that target. And so on to recursive infinity if you’ve unintentionally created a circular call pattern. These events run on the GUI thread, so no parallelism. Property bindings are also synchronous–you can think of them as a propertyChange event pre-programed to assign new data from one property to another.

1 Like

If you want to force things to load in a specific order doing it through bindings may not be the way to go. Aside from that you need to be cautious with sql and runScript bindings. I believe the client poll rate is 250ms so it refreshes the bindings at a fast rate. I learned that the hard way a while back when I had a screen that worked fine locally but would lock up when connected over VPN. It was a SQL binding that locked it up for me. I was using a template repeater though so if it was just a single instance it may of been fine but with multiple instances trying to load at once it had issues over VPN.

Back to what you were talking about with order though. You could consider doing a script to that does your initial queries for data and fills everything in when the page loads. If you do a print on the template when it loads, there should be a property called componentRunning or something similar. If you trigger on this you can load your initial values with the script in the order you want. If it is stopping because its missing the initial values then this may get you past that. Personally I would consider moving your queries and runScripts out of bindings though if you can. You can run them either through tags on a fixed scan rate then pass them into your template or call them using a propertyChange script.

1 Like

Thanks for the responses. I’ve ended up making some changes to the popup itself to simplify the interface which allowed for better functionality and less reliance on chicken and egg evaluation issues.