Is there a set of best practices for how users should using PI Tags to store string values?
If need to use PI Tags to store string values, the first thing is to create the PI Tags with string type. Please use the following code as the reference:
private static PIPoint CreatePIPoint ( Server server)
NamedValues nvAttributes nvAttributes = new NamedValues();
return server.PIPoints.Add("test1", "classic", PointTypeConstants.pttypeString, nvAttributes);
After this, you could use UpdateValues method to insert the string values into the tag.
Thanks for the reply. I'm looking for more of a functional best practice. For example:
"String values should only contain single values" - meaning don't store things like "value1;value2;value3"
Should I use string values to store frequently changing persistent values (last time some process ran)?
Should string values be used as a mechanism to infer relationships between other attributes / tags?
String is just a point type and string processing can be expensive, not only with PI. Hence my recommendation is to use String data types only if necessary; when no other data type fits better.
Steve Buster"String values should only contain single values" - meaning don't store things like "value1;value2;value3"
In case values are of type String it may make sense concatenating information into a point of type string i.e. when building a message string based on information from other sources. On the other hand I cannot think of any reasonable use case for concatenating numerical values into a string.
Steve BusterShould I use string values to store frequently changing persistent values (last time some process ran)?
For this purpose I would prefer a tag of type TimeStamp.
Steve BusterShould string values be used as a mechanism to infer relationships between other attributes / tags?
No. When dealing with relationships; setting information into a context, please consider using PI Asset Framework (PI AF).
Is there a way to read a string value and convert it into a digital state, without doing any custom coding?
@Randy: PI Point configured to be of digital state that received string value or numerical value representing the state number would be converted appropriately. This is handled for you.
The PI SDK and AF SDK are doing this for you when calling either the UpdateValue or UpdateValues methods if you use it throughout code.
Was it what you were looking for?
I was thinking more along the lines of if I have a tag that represents 4 states, but in a string form. Lets says the states are "FIRST","SECOND","THIRD","FORTH"
Is there a way to read in those strings and then say ok if you read "FIRST" then you are digital state 1.
From what you said I assume the strings would have to be "0","1","2","3" in order to convert into a digital state automatically.
@Randy: You could defined your digital state with these states:
You cannot skip any states within a Digital State definition but you can set some state to empty because you don't use them.
@Randy: yeah, as Mathieu said, you could use digital state to store your strings which needs to be displayed in the PI digital state configuration, and create some digital tags which will store the int type values to match the int number for the digital state. However, I believe it should be more easy to use the Enumeration in the AF server, it is better than using digital state in PI server. That is because the start number of the digital state is 0, and the int number should be constant as 1,2,3 in order....; however, in the Enumeration of AF server, the int number could be without any order. This should be more flexible. If doing this, you need to store the values in the PI tag as int type, and using AF SDK to take out the string display from the attributes.
Given the direction of postings regarding digital states, one could say the first best practice about string tags is to deeply question whether you truly need a string tag or not. If you have a fixed set of strings, then a digital state would be a better choice. Don't think of fixed set as meaning only a handful of choices. Even if you have 200 fixed strings, it would work better as a digital state than as free-form strings.
I reserve string tags to things like brief operator comments coming from a DCS. I expect a variety of misspellings, abbreviations, punctuation or lack thereof. And by brief, I mean something under 1000 characters, as there is a quirk that you cannot write a large string to a PI tag. I don't know the exact length off the top of my head. For some reason the length 960 or 1020 rings a bell.
Gregor mentioned a Timestamp tag. We had used those in the past but about 3 years ago we discovered that PI-to-PI did not transfer data for Timestamp tags. Since then we rewrote our application, for reasons totally unrelated to this quirk, so I don't know if that limitation persists with PI 2012.
As Mathieu says, the known limitation with digital states is there numbering must begin at 0 and they must be sequential. This has never been a limitation that bothers me. I would present to my users the fixed set of choices and they - nor I for that matter - ever need be concerned about the number used underneath.
Since your data apparently resides in PI, I think digital states are the way to go. With that in mind, I would downgrade Xi's suggestion that you could use an AF enumerated set instead of a digital state. If you have the data in PI and are using AF as wel, you may investigate something in AF to compliment, not replace, the digital states in PI. Even if you thought you could use an AF enumerated set there is no guarantee the the AF set values will exactly match the digital state codes. With multiple developers working in our databases, all it would take is someone to erroneously click the "Renumber Enumeration Values..." menu option to goof up our application with out-of-sync codes.
If I need to duplicate some digital state into AF, I use a lookup table. I can configure an attribute to do a code lookup by text, or a text lookup by code without resorting to AFSDK to do the same with an AF enumerated set.
Another advantage of digital states in AF, whether or not you have a complimentary lookup table in AF, is that you can use the state code in a formula, which you can't do with the state text. A standard practice of mine is anytime I define an attribute to hold a digital state, I will define it twice: once for the text and a child named 'StateCode' for the integer. Below shows a string attribute and it's integer child attribute, both of which are mapped to the same digital point in PI:
I leave it to others personal choices whether to map both tags exactly the same, or whether to configure 1 in relation to the other. I've done it both ways. If I were to configure 1 in relation to the other, I would map the StateCode child to the PI Point, and set the 'Flow Status' config string to ".|StateCode". In most cases, the end-user sees the friendly flow status message they are used to, but if I ever need to create a formula using that state, I can grab it's StateCode child.
Many thanks Rick, this was enlightening to share your thoughts on the question.
Rick I don't know the exact length off the top of my head. For some reason the length 960 or 1020 rings a bell.
As a quick answer for the maximum number of characters for a string tag, it is 976 characters.
Retrieving data ...