Create a Script Function to Evaluate an expression.
closed
c
cbohon
I am trying to evaluate some "Expression Language" expressions in a script. But I dont see a good way to do this. Could you add a scripting function to do this? Something like:
system.util.evaluateExpression(expressionString, [tagPathString])
returns value
Log In
P
Paul Griffith
closed
We don't have any plans to add this capability first-party, but the (free) Ignition Extensions module adds a
system.util.evalExpression
function that can be used for this purpose:J
Jeremy Dodson
I've gotten a lot better as I've gotten used to writing expression functions for tags, but it would still be useful to be able to test them in the scripting console rather than having to commit changes on a tag every time and then try to read through the alarm messages that come up.
I can't think of anything that expression functions can do that I couldn't just do with scripting if I wanted to, but having a way to iterate through and troubleshoot issues in the console would really speed things up for me.
Something like the reverse of runScript()?
system.util.runExpression( "expression" , failover )
A command like this or what cbohon came up with that would evaluate the expression and toss out a result or error message in the console would be enough to help me out a lot when I'm trying to learn how to work with an unfamiliar expression function or even when just I'm trying to troubleshoot why someone else's expression tag that has five or six nested functions isn't working properly.
With a script I can toss it in the Script Console and simulate some variables to see what's comes out the other end, which makes it easier to iterate and troubleshoot when things break. Even though expression is simpler to use and understand, it's tougher to troubleshoot and iterate through without a tool like that.
I'm still fairly new and inexperienced with Ignition, so if this is already a thing and I'm missing out, please let me know lol.
Kathy A.
Can you give us a use case? Most expression functions are also available as script functions.
c
cbohon
Kathy A.: If I want to find out current settings of all the alarms in a script, I can use a couple of different functions to get a list of all alarms and their current settings, but the expressions are not evaluated. I'd like to evaluate the expressions so that I have a list of current settings.
Another idea would be to put an optional boolean input for functions that might return an expression, like system.tag.getAlarmStates, to give the option of returning a tuple with the expression, and the current value of the expression.
O
Oleg M
Kathy A.: I am voting in support for this feature, since it would provide a good work-around for the single component property binding limitation. Suppose, we have a lot of similar components of the same type, whose property value depends on the same expression, e.g. a complex pipeline, consisiting of lots of segments, whose state depends on the set of adjacent valves. Introducing a new valve would require a lot of manual work changing the property bindings for every single segment. If we had smth like the "evaluateExpression" method, we could simply introduce a new custom property, holding the expression string for every pipe segment, and a script that runs every time, when the custom property gets updated. Now we could select multiple components that has the same (custom) property to change that property at once!
J
Joe Friedrich
Kathy A.: I just want to create a qualified value. That functionality is not (currently) available in scripting. (The reason I want to create a qualified value is in order to automate testing.)
P
Paul Griffith
Joe Friedrich: You absolutely can create a QualifiedValue in scripting; something like this:
from com.inductiveautomation.ignition.common.model.values import BasicQualifiedValue, QualityCode
qv = BasicQualifiedValue("someValue")
qv2 = BasicQualifiedValue("someValue", QualityCode.Bad_Failure)
qv3 = BasicQualifiedValue("someValue", QualityCode.Bad_Stale, system.date.now())
c
cbohon
tagPathString would be an optional argument to give the script correct context when needed. It would point to the tag that has the expression binding on it.