Now this Point Type that you see right here, this
determines how we are going to store the Values on disc, so
as you can see, we have a variety. The default is Float32.
That's a single precision real. That's typically what
you are going to be storing -- the single precision real. We do a double
precisions at our Float6,
64's, and I will talk about this Float16 in a bit, but
generally, that's what you are going to be using. So, we will talk about that
first. In addition to that, Float32
or Float32, we also have an
Int32. It's an Integer Type. And, of course, this maps
back to, correctly back to these Tags as we saw them.
This is the Float32 here. This is the Int32.
And, then, we had this third one here that did not
take numbers -- it just showed us these values. That's actually
a Digital Point Type.
Now, the Digital Point Type works like this. With,
when you create a Tag that's a Digital, you would specify
what its Digital Set is. And what we are doing is
we are going to map all its incoming Values to
some predefined and, and finite number of
character strings that you define in this Digital
Set. So, the big finish to this would be let's
go out and let's look at this Digital Set called Modes.
Let's see what's in there.
Okay, I just switched over to the Digital State Table, and
here's that Digital Set called Modes. As you can
see, it takes these values
and these are simply strings that are mapped
to whatever input we are getting from the
data source. So, we are actually going to be storing these
as integers, but we map them to these strings here.
It's a more compact storage. It ends up faster for speed
of retrieval. Anyway, it's just, in general, a good way to store
this information. If we take a look back at our Point Builder,
here's my Digital Tag, and if I look
at it's Current Value -- its Current Value is Cascade.
And Cascade was one of those Digital States that you see right here.
Now you will see Digital States later on,
sometimes when you are looking at our Message Log.
Sometimes regular PI Tags are going to take a digital
state that's part of our System Digital State Table.
Now, this is a locked-up table. This has
a variety of different system digital
states that we use, you know, just to indicate when there's
things that have, generally have gone wrong. So, for example, you will see
a digital state called Bad Data in the System Digital
State Set. Anyway, that's a minor point, though. Any
PI Tag can take any of these digital take, ah, states.
Now, here's, this one Digital State Set called
Modes is just one of many Digital State Sets
you can create. These are user-generated. So, here's one called
Phases, where somebody decided to list a series of eight phases.
Presumably, he's going to be assigning
a Digital Tag one of those phases, so that he can
track, you know, production of a batch, for example.
Here are, here's something called Interface
Status. It's indicating whether we are receiving or not
receiving data for an interface. So, this is the type of thing
that we store in a Digital PI Tag.
So, those are the three big we, we
just looked at: the Float, the Integer, and the
Digital. And the rest are, are, I would not say of lesser
importance, they are just less frequently used. So, let's
take a look at those less-frequently used. Now, I.
I mentioned an Int32. We also support a
16-bit integer. I do not, I do not think think you are going to find anybody who really is going to
go for that 16-bit integer, you know, in the
interest of, of having a smaller footprint
in terms of archive usage, or, maybe
faster speed of retrieval. That's not the
primary reason why we support Int16's. The primary reason
is to support compatibility with earlier
versions of the PI System. See, we have got some people who have got PI
System data that goes back to the early
'80's, and, of course, in
some cases their data's been stored as this older
type, this Int16. For quite a while
that was the, the default integer type.
So, anyway, that's the primary reason you see that.
I would probably not recommend that for anybody
who's configuring a modern system.
Same goes for what we call a Float16.
Now, the Float32 and the Float64 are pretty straightforward
to understand. Float32 is a single precision real.
Float64 is a double precision real. This
ends up taking four bytes for storage, this ends
up taking eight bytes. Now, what about this
Float16? The Float16 is actually
a storage that, again, goes back to
an earlier version of PI, and we primarily maintain
this, again, for those users who still have
Float16 data. Now, I could tell you much, much more
about the Float16, and I will, but I will wait 'til the end of the video.
So, you can skip that if you do not plan to ever use these or do not
have any existing Float16's. So, the rest
of these Point Types: String, String is simply a
character string. We can store up to 976
bytes. That could be useful for doing, say, things like
operator comments. You know, just about everybody in production's got some
kind of a some kind of a notepad that
are used by Operations to mark down things like,
you know, Fred dropped his hat in the slurry. We have gotten high impurities.
Things like that. That's the kind of stuff that you would
stick into a String, and by sticking it into PI,
of course it becomes part of the long-term history
of the, the operation. So, it, it's a nice little
feature for storing operator comments and things like that.
We also have something called Blobs. Blobs stands for Binary
Large Object, although to be honest, they are not that large,
976 bytes. Could basically be
anything that you'd like to put into that as a binary
object. And then, finally, we have a Point Type called
Timestamp. This would be a PI
Tag whose, well, it's got two Values
here, just like we were looking at before with
our -- let's take a look at Excel here. Yeah, PI Values,
all PI Values have a Timestamp and a Value.
Well, what would it be like if the second
part of this, the Value, were also a Timestamp? So, it would
look like this: Timestamp, then another Timestamp. We have actually
had requests for this over the years. So, for example,
if an operator enters a
12 o'clock reading at 12:15.
What you can do is you can say, okay, here's the Timestamp.
At 12:15 he entered
this Value that was going with the 12 o'clock reading.
So, the Timestamp is actually something that's going to be stored
as the -- in the Value slot. So that
is supported, and that's something we have had customer interest in,
so we have supported that. Okay. Now, for those of you
who actually do have Float16's, let me go into this into some more
detail. What is was, it was a, a very clever way of
kind of storing Values that were Float Values
but storing them as integers to make them more compact.
And, let me just bring you, this, up this old illustration here.
What we did with a Float16
is we would take a Value
that came in from the data source, like this Value right
here, 250.9. And we would figure
out what percent of the overall range that was --
from zero to the top of the range. So, it's
going to depend on what the Tag is. But, anyway, let's say we,
we get, in this example, 250.9 on a
Tag whose range is zero to 500. We figure out what percentage
that is, and then we take that percentage,
50.18, and we figure out what
falls along the range of Zero to
32,767 -- that's two to the 15th by the way,
what we can store in a, in a
16-bit Float16. Anyway, we figure out
where that 50.18 percent fits
along this scale. As you can see, they are just, they are corresponding
here. So, on that scale, we come up
with 16,442. But we do not store it
as 16,442.4806. We only store
it as an integer, 16,442,
which, in fact, ends up introducing a bit
of error. As you can see, we are no longer
50.18, now we are 50.17853.
Now, when the user goes back
to look at this later on, we pull it off the
archive, and this 50.17853
percent is applied to this scale, and it comes back
as 250.89270. So,
what started as 250.9 ends up
coming back as something very close to 250.9.
Now this introduces error and, of course, the question is
why would you every do this? Well, primarily for the
compactness of the storage and the speed of retrieval. This is a
wonderful mechanism for storing a tremendous amount of
information in a very small space. And, for years and years,
this was the de facto standard
way of implementing PI Tags, so
it was a very robust standard. The only people
it would affect to any extent at all would
be those folks like this down here. Somebody that's got a very
large zero to span, zero to 20 million, for example.
See, if I, if I am trying to map
that to just a range of zero to 32,767
here, basically trying to measure this
20 million units with a ruler that's only got 32,767
tic marks, well, that would be a problem.
So, so, but those are the only people
that it had affected. I mean, for, for the vast majority of
users, you know, all they had were spans like this, zero
to 500, typical production ranges. And for those
fee...people, this was an excellent trade-off of
speed and compactness of storage. Now, the modern PI System
does not really rely on Float16's, but
there's no reason it could not as long as you understand what the
restrictions are. I would stay away from them. They are typically
not what we would use. And, again, I am sorry to spend so much time
on something that's such a peripheral topic, but, you know, this is,
this is why you find these Float16's out there.
If you have Float16's in your system,
you just may help to explain
why sometimes it looks like the data has changed
from what you saw when that data was first
grabbed by the PI System.