Let's say I have a tag called Status that is an expression tag, whose value is calculated as TagA OR TagB OR TagC. The Status tag is also configured as an alarm trigger.
When the alarm shows up in an alarm table, I want to allow my users to drill down into the source of the alarm beyond "Status". I want to fetch the expression value from the tag configuration for Status and parse out TagA, TagB and TagC.
It doesn't look like system.tag.browse gets this far. Is there another way?
I think this would be better off being documented in some way. To interpret these expressions the operator or whoever is using the HMI will need to 1) know the Ignition expression language and 2) know what you're internal tag names refer to.
Three separate alarms would solve that and any confusion.
Trying to avoid duplication of work and creating a separate definition that has to be manually synced. In our case, the expressions won't be complex; we can probably even use script to parse the expressions and generate a more user-friendly description. The internal tag names (and paths) are already user-friendly enough for this purpose.
The alarm isn't really the focus here. The "Status" tag (in reality there are several tags like this and I'm just using "Status" as a hypothetical) is used elsewhere and in cases where its value comes into question, we want the end user to be able to see its constituent tags so they can rationalize/validate the value of the Status tag. One of the places where the "Status" tag might appear is in an alarm table. It may also show up in a custom table of historical data retrieved from a SQL database. Wherever it shows up, we want to allow the user to see what tags went into the Status tag so they can get a better idea of where the output data is coming from. There are potentially hundreds or thousands of different pieces of equipment, each of which has its own "status" tags that have custom expressions that sum up the constituent machine tags into a summary value, so adding a bunch of extra alarms and/or manually re-typing these relationships elsewhere would be impractical. Once the expression tags are configured, we just want to expose that part of the configuration to the end user (not every end user, just those with elevated privileges who will understand what they're looking at, like a process engineer) and know that it always points to the source of record - the tag configuration.
system.tag.getConfiguration() will get you what you want.
If it is an expression tag, the function return will have an expression key:
I stumbled across that one about the same time you posted. Thanks 