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

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.

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.

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.

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.

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

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.