I would firstly recommend using a StringBuilder data reference to bring the Parent attribute value down to the Child element level. The configuration of this StringBuilder would be pretty simple:
Now in your Formula data reference, your variable can reference an Attribute in the same Element level - it will effectively be a sibling Attribute.
The next thing I would ask though, is what are you planning on doing with this string value in your Formula? There are some limitations on what you can do with strings in the Formula DR, one of which is performing string comparisons.
1 of 1 people found this helpful
The Formula Data Reference does not support string attributes as inputs. The only string support with Formula DR is the ability to output an error string when you output a bad value.
As John Messinger explained, you will need to use the String Builder Data Reference to bring the parent element's string attribute into an attribute on child element.
Furthermore, John asks what else you plan to do with this string value, especially since Formula DR does not support it? String Builder DR has other functions available to further manipulate the string, though this might be cleaner if you did that in a 2nd attribute on the child attribute. You may also consider using Asset Analytics because it works quite nicely with strings, and it could easily read the parent element's MyPrefix attribute as the first expression in the analysis. I'm guessing the parent element's attribute is a static string value, so the analysis would have to be adhoc or on-demand. If the parent attribute was a historical tag, then the analysis could be event triggered.
Thank you John & Rick
Better to use the right tool for the job :-)
the reason for the string is that I have a number of output tags for different parts in my hierarchies that require specific naming. this allows my to define the prefix in the top level element and then I can trickle it down the tree and and use the attribute in dynamically defining the output tag I will be writing to.
Yes, for tag name building the StringBuilder is the way to go. As Rick Davin mentioned, use a second Attribute to assemble your tag name from the other input attributes required. The principle that I always use for this is based on a concept you will find in most if not all of the example kits that have been published, and that is to use a StringBuilder to generate the tag name. This StringBuilder attribute is a child of the PI Point data reference attribute, and does all the heavy lifting of reading, manipulating and concatenating the required input strings to generate a dynamic tag name. The PI Point DR simply reads the value of it's child attribute to get a tag name that it can resolve.