Referencing Named Queries in Expression Tags - or a potential workaround?

Ignition
,
#1

Hi - this is somewhat of a two part question.

  1. Is it not possible to reference the result of a named query inside an expression tag?

  2. If not, I’ve attempted to generate a UDT that will allow me to provide the Named Query name in a Memory tag (string) and I have an expression tag using a series of runScript() with system.db.runNamedQuery().

The issue I am running into is that when I try to reference the sibling ‘NamedQueryName’ tag within my UDT definition, tag({PathToParentFolder} + "/NamedQueryName") is returning -1. However, if I use this same expression in a sibling expression tag, it returns the value of the corresponding sibling memory tag NamedQueryName.

For those curious, my final expression is for my OutputValue tag (which is a float) is: runScript("system.dataset.toPyDataSet(system.db.runNamedQuery('" + tag({PathToParentFolder}+"/NamedQueryName") + "',{}))[0][0]")

(the bolded part is returning -1, but if I use that same expression in its own expression tag, it returns the appropriate value).

It is safe to say I already feel uncomfortable building out this custom python expression using runScript() inside a tag, but I feel it is my only option.

Thank you

EDIT: I believe to have resolved my issue with the expression. It appears that the scope of the expression tag needs to have the project defined, which is understandable. However, I am still somewhat uncomfortable doing this via runScript(). I am looking to keep these queries only defined in one place as they are using in the reporting plugin too.

#2

I wouldn’t run this in an expression. I haven’t messed with tag in 8.0 but in previous version it was a best practice to avoid it if possible. Does the run script need to run at a fixed rate or does it need to run if a specific value changes in the UDT? Personally if you need the results at a set interval, I would do a gateway timer script or I would skip the named query and do the query directly in the tag. Since its in a UDT, it can still by dynamic to follow the UDT instances. If you have a value in your UDT that changes to use as a trigger then you can do a tag event script to run your script.

If at all possible though, I wouldn’t use the runScript and tag functions unless you have no other options.

#3

Thanks for the reply. The issue is that the values resulting from these Named Queries also need to be present in a report. Unless I am missing something, I would have to create parameters to be passed into the report for every one of these values. I am trying to avoid this as well.

The issue here seems to be finding a common place where the Ignition Gateway and Reporting system can obtain this data from.

#4

What is wrong or difficult about having to create the parameters for each value for your situation? If its just because its a lot of tag names or what have you, seems like a good time to make a constant list variable in one of your modules and just iterate through that.

#5

Nothing is difficult, we are just looking to simplify the configuration as much as possible, but based on my lack of confidence in runQuery() I am considering creating parameters as it is the lesser of two evils.

Btw, tell Eric and Scott I said hello.

1 Like
#6

Ah ok. I think personally would have a list of tuples - [(tagName, parameterName), …], iterating through, system.tag.read() each and creating a parameter dictionary like that. Then any additional parameter you add to the report you would just need to add to the list - would make it easily extensible.

And ha I thought that might have been you! Will do. PSM4 still has your fingerprints all over.