Using variable with custom property in expression

[ian.sebryk]

learning more about expressions; can someone explain why this doesn't work? i have used the same variable construction elsewhere in a script and it chooched just fine. it just isn't as an expression.

if ("{Assets/"+{session.custom.assetName}+"/ONLINE}", \
    "Assets/"+{session.custom.assetName}+"/Voltage".value/100, \
    0)

i just get an Error_Configuration error. which does not surprise me, i am a n00b.

EDIT: just tweaked to more accurately reflect what i'm trying to do so i get a better response.

[pascal.fragnoud]

You can't reference tags or properties like this. If you need to build their path dynamically, you'll need to use the tag and property functions. Or work around it using temporary properties and such.

[ian.sebryk]

well that sucks. expressions evaluate faster, so i was trying to use those instead. but i can go back to just binding to a transformed a tag i guess.

[pascal.fragnoud]

tag and property are expression functions.

[lrose]

Nested tag references are not allowed in expressions.

You could use the tag() expression in this case, but I would avoid that.

Instead create two custom properties bound with an indirect tag binding. Then use those properties in your expression.

if({asset_online_prop},{voltage_prop}/100, 0)

Also, the expression language for the most part ignores white space so the \ isn't needed if you have that in you actual expression.

[lrose]

@ian.sebryk

expressions evaluate faster

expressions evaluate faster than scripts, not necessarily bindings. Tag bindings are also pre-compiled, so are just as fast if not faster than expressions.

[ian.sebryk]

um.... so if i want to work directly with tags in scripts, i have to first bind the tag property to a custom prop and then reference that??

[lrose]

Expressions are different from scripts.

If you want to work directly with tags in expressions, you can use the tag() expression. This allows you to provide a string as the path, and returns the value.

For best performance you should prefer indirect bindings over a tag() expression.

[ian.sebryk]

@lrose

This allows you to provide a string as the path, and returns the value.

i'm not married to the expression idea, i was under the impression they were just faster. but since a tag-tranform-script is precompiled and just as fast: pfft. whatever i can get to work in a streamlined way gets the win. i just don't know how to access a tag's property directly from within a script. which i why i went with indirect expression. so... yeah. this is where i'm at right now.

#  indirect binding to Assets/{assetName}/ONLINE, a boolean flag
if value:
  newValue = Assets/{assetName}/superImportantValue + 20
  return newValue
else:
  return 0

you can see where i'm stuck.

[pturmel]

@ian.sebryk

so if i want to work directly efficiently with tags in scripts expressions, i have to should first bind the tag property to a custom prop and then reference that

As annotated, yes.

[pturmel]

@ian.sebryk

since a tag-tranform-script is precompiled and just as fast

Simply not true.

[lrose]

@ian.sebryk

but since a tag-tranform-script is precompiled and just as fast: pfft

A transform on a binding is not pre-compiled.

@ian.sebryk

#  indirect binding to Assets/{assetName}/ONLINE, a boolean flag
if value:
  newValue = Assets/{assetName}/superImportantValue + 20
  return newValue
else:
  return 0

you can see where i'm stuck.

No, I can't really. This script would not work, unless you're intending it as pseudo code.

To get the value of a tag in a script you must use a call to system.tag.read*()

In this case, I would create three custom properties:

• assetName
• onlineState
• voltage

I would create indirect tag bindings on the onlineState and voltage properties using the assetName property. That would look something like this:

Now you can reference those custom properties in an expression binding.

if({this.custom.onlineState},{this.custom.voltage}/100,0)

Note, that if this is going to be a popup, embedded view, or docked view where you want to send the asset name, you should make that a view parameter. The rest would still be applicable you would just need to change the paths to assetName.

[ian.sebryk]

*click|* ooookay... lightbulbs are turning on! you guys are so helpful. thank you very much.

[ian.sebryk]

@pturmel this is where i got the notion that tag-trasform-script and expressions are they are equally speedy.

@lrose

Tag bindings are also pre-compiled, so are just as fast if not faster than expressions.

can you explain the difference for me? is @lrose just referring to the property binding on a view/component and not the subsequent transformations?

[pturmel]

Bindings, throughout Ignition user interfaces, deliver values to session/view/window/page properties, custom or otherwise. All bindings are "set up" when a Perspective view or subview or Vision window or template is opened. The setup yields a java collection of objects tightly integrated with each other and with the target component. With the exception of any jython involved, everything is effectively pre-compiled during setup. Information flows from element to element in handsfuls of microseconds or less.

While some bindings are "once and done", like expression bindings that yield constants, or non-polling queries, most bindings are intended to monitor some source of data and deliver updates through the binding. When a source reports a change, the binding completely re-executes.

Transforms are a Perspective-only enhancement to bindings that create a chain of consecutive operations, with one result feeding the next, with the final operation's result providing the value for the target property. {Perspective desperately needed transforms because its complex components' architectures have a severe "impedance mismatch" with Ignition's internal object types, particularly dataset objects.} Transforms, for some unclear reason, introduce substantial overhead, on the order of high tens to low hundreds of microseconds.

Jython, meanwhile, whether invoked in a binding by runScript() or by a script transform, adds considerable additional overhead. Again, tens to hundreds of microseconds per invocation, plus the performance penalty of an interpreted language.

For some timing comparisons between script transforms and pure expressions for some common Perspective UI tasks, look at my Integration Toolkit module's topic for some of the testing shown there:

Automation Professionals' Integration Toolkit Module

I have spent my holiday poking at this. Wanted to provide an efficient replacement for a common use of python transforms: Make a (Perspective) table that dynamically populates both .data and .columns from source dataset that isn't constrained to any particular structure or data types. In Vision, one can achieve this (mostly) by pre-populating the column attributes dataset with all of the possible column names your application might deliver. No such thing in Perspective. But a transform can …

For some benchmarks on transform overhead versus runScript versus no script at all, check out this topic:

Tag binding or expression to read dynamic list of tags

Collected some overhead stats. Added a sixth binding for comparison, and made them all trigger from a common reference. The new expression transform looks like this: nanoTime() - {value} It is notably faster than the other transforms. To make the recorder() run smoothly, I made a trigger timestamp with now({this.custom.pace}) and set pace to 200. Then I modified the transforms' first stages to look like this: asList( {this.custom.trigger}, nanoTime() )[1] The non-transform tests of run…

[pturmel]

Further elaboration:

When you split a binding into separate custom properties, you are essentially constructing a sub-expression that only has to re-evaluate when one of its dependencies changes. If used in an outer expression, and its dependencies haven't changed, then its usage is nearly free--just the lookup of its latest value.

Tag indirect bindings have some asynchronous delivery advantages over the use of tag() functions, on top of eliminating the unnecessary re-evaluation of the tag path expression.

[ian.sebryk]

@pturmel not gonna lie, i kinda have some localized increase in blood flow right now... thank you so very much.

excellent Christmas reading, btw... ;)