3 of 3 people found this helpful
None of the OSIsoft data references can do this. What you are asking for is 2 levels of substitution. There are just too many things that could go wrong. The first substitution would be to create not just a string, but a string that is a valid path to another attribute somewhere. What if the returned value is not a string but a number? What if it is a string but doesn't refer to a valid attribute path? Then StringBuilder would have to take that value it just looked up and use it recursively to lookup another value. How does it know to do that? How does it know to stop the recursion?
I think that is possible by using AF analytics. I have done something familiar and found this solution on PI Square. I have documented it, but no access at the moment. Will come back on this next Monday.
1 of 1 people found this helpful
I managed to do this for attributes on the same element.
'Result' is the original AF attribute with the PI Point Data Reference. The link goes like this
Value -> ValuePath -> AttributeName -> Result
AttributeName is hardcoded with the string 'Result' which is the name of the original AF attribute.
This is the template that the element is based on
Thanks all. Some good ideas, but ultimately this doesn't help me
My frustration, I guess, is that I can do this with Elements, but not with Attributes. With the elements, where I have the machine split into stages I can dynamically reference the stage name and read the value from this dynamic name:
Attribute: Formula Settings: A=..\..\..\..\|Running;B=..\..\..\..\Calculations\%..\..\Element%|ExitTempUncooled;[A*B]
Here %..\..\Element% is the name of the stage in one section of the model (nested two elements "above"), but is used to reference a separate section (nested 4 elements "above"), since they share the same "stage name". I can write this to look almost anywhere else in the AF database structure dynamically, since the formula here is dynamic, in the sense it uses substitution to find the value.
But it only seems to work with elements, and not attributes. If I try the same logic with Attributes I can "build" the string, in the same way, but it doesn't resolve...! Instead it complains about "unknown" attributes that are clearly there, with good values. Maybe I expect too much.
Rick Davin - it does work with Elements, but not Attributes - hence the questions
Part of my reason is that I have a model constructed of Elements, Child Elements, etc. that are nested. This is sensible as different elements perform different functions. However, I also need to create PI Vision displays, which as far as I can tell require a single Element (so therefore it has to be "flat") in order to create a template that can then be referenced by the one vision display, many times.
I cannot rework the original model as it needs to be nested. So I thought I would try to create a "Pseudo" model that was flat in a single element, and use nested attributes instead. I was hoping the attributes could be cross referenced to the original model dynamically, so I don't have to code each asset type line-by-line, or indeed asset by asset.
Since I would like to use Child Attributes to maintain part of the structure, it would seem I cannot address using the "Analysis" route either? And that is despite it having a seeming error where my "_" in a tag name seems to disappear in the analysis evaluation
Bear in mind I am a novice at this, really, so maybe I am missing something obvious!
Comments remain gratefully received!
1 of 1 people found this helpful
What is the data reference of PPI_Filter|Result ? If it's a PI Point you can simply use an attribute reference.
If it is not a PI Point, can you simply configure the same attribute on this element?
Your screenshot shows "PV_Pump1" yet that's not how your StringBuilder resolved. Have you obfuscated something in your screenshot? Can you provide more detail on your hierarchy?
As an update, I had a colleague with far more expertise (Paul Booth, Emerson) take a look at this, and coincidentally I think this agrees with Sebastien Raposo 's suggestion. It does look at a PI point, so we were able to configure the attribute reference (after some difficulty).
I believe the steps were:
1. Migrate the "model" to an AF template.
2. Ensure the "ValuePath" resolved correctly for the location of the PI Point elsewhere in the database structure (for me this is a string builder construct that looks like: ..\'|AssetName'\%..|..|Attribute%\%..|Attribute%\PPI_Filter|Result )
3. Reference the Value, as a PI Point data reference, using the construct %@ValuePath%. We had some difficulty here as using the "Settings..." dialogue would add %Server% to the PI tag name. This would NOT work. When we removed the \\%Server%\ that the dialogue had added, it all worked fine.
4 Tested the structure by copy/paste in the Element Template and changing the target (e.g. from Amps to ExP) - worked perfectly!!
Thanks to everyone who read, and who commented to try to help. Appreciate the community here, that is so willing to help others