I have mentioned several times earlier
that there are a number of switches or parameters or
arguments that are passed to the
interface when it starts up. Those switches are stored in
the batch file. Before we go any further, I know when
I am in a class like this, I like to know where there is more
documentation. So I am very happy to
report that we are now storing
with the interface installation, we are now storing the
best reference guide that you will find
to this particular set of information.
If you go into Program Files,
PIPC Interfaces, there is now a
UnInt which stands for Universal Interface. And that is where
you will find the UniInt end user documentation.
It is in the end user documentation that
you will find the definitive word on
each of these switches. See in the interface
manuals and in these slides, you are going to see a
little bit of explanation for some of these switches. But
when you go to that UniInt end user doc
you will find a tremendous amount of information about the
/HOST switch for example or the /PS
switch. So let's look at some of theses switches.
First of all there is a /HOST switch, that is
simply the name of the PI Server
that is receiving the data. It's basically your home node
or the PI Server node.
Now the /PS and /ID
work together. Because
an interface needs to know two bits of
information about a PI Tag
before it can decide whether to start
scanning that tag or not. So it needs
to know what the PointSource of the tag is
and what the ID of the tag is-- the interface ID.
When you configure a PI Point,
in the point configuration, the interface ID
is identified within the point
configuration with the field called location code 1.
So it's in the PI Interface
Configuration that you define this /ID switch.
This /ID
has to match what we find in location
1 on the point that is configured for that interface.
The /PS corresponds
to the PointSource field on the PI Tag.
Now here is one way
of visualizing that using the
point configuration and the interface configuration utility.
If you look at the PointSource, the PointSource for this
particular tag is R and that is going to have to
correspond to whatever the PointSource has been
set in the interface configuration utility
using that switch as we are describing right now. So the
/PS switch corresponds to the PointSource
and ICU and that has to match the PointSource
when configure a tag.
The interface ID is another
switch, this /ID switch and it
also corresponds to the interface ID section
of the ICU. And that corresponds
to location code 1 when you
configure a point.
Now the reason for discussing any of this is
because when an interface starts up, it needs to know
which tags out of the 1000s of tags that you can find
on the PI Server are the
tags that it is supposed to keep track
of, or supposed to scan. So for example, let's pretend
you have 10,000 tags listed here on the
PI Server, when this interface starts up, it needs to
know which of those 10,000 tags it is supposed to use.
So when you configure this tag
for this interface, you setup a /PS switch.
So for example if I say
/PS equals H for Honeywell
then that means the interface will dutifully
go out to this server here. It will pick
only those tags whose PointSource attribute. That
might be the 5th attribute in this list
here of all of the attributes. So it's only going
to find everyone with a PointSource
equal to H. Now one of the problems
with the older way we have supported
PointSource is that PointSource has traditionally only been
a single character. So what happens if you have two
interfaces? An interface there and an interface here, and both of them
use this same /PS equals H?
Now you have got a problem here because
now these two different interfaces are both
competing for the same list of tags.
The way we solve that is by adding another switch
/ID equals and then
you put some arbitrary number. It's not unusual
to put a 1 here and then just do a /ID equals
2 over here. And then in the location
1 attribute of each of
these tags you would put either a 1
or a 2 to indicate which interface
that particular tag goes with or is scanned by.
So again, pretending that you are the
interface, when the interface starts up, it needs to
ask for all of the tags from the PI Server that
it is supposed to scan. And it does that by looking at PointSource.
But then it further filters by looking
just at those with the ID equal
to whatever ID is set
in the actual start up file for that interface.
You can think of it
this way. The interface needs...
Well you need to know two things about an interface to identify
it uniquely among all the interfaces.
You need to know its PointSource and its ID. So for example
in the log files, if you have got two
different interfaces running that have the same PointSource.
Let's say you have 2 OPC interfaces and the PointSources
for both of these is equal to an O.
Now what will help you distinguish the messages from one interface
versus another is the /ID switch.
And that is identified in the log files.
And what is more important is when the interface
starts up, it knows how to find the tags that are associated
with that interface. And we do that through PointSource
and ID where PointSource /PS
maps to the PointSource attribute in the tag, and the
/ID switch maps to the location 1
of the tag. Now there are some
restrictions as to the PointSources that you can actually use.
Here are some of the default PointSource
attributes used in PI.
These that you see listed here, all of
these can be changed using the
/PS switch. So for example, even
Performance Equations, you can actually modify the batch file
that starts that up and change that to a different PointSource.
Now these, the Alarm,
SQC and Alarm Groups,
there is actually involved modifying a registry key if you would like to change that PointSource.
And we do have one that is
hard coded. So the /T or the
T for totalizer, that's a PointSource that cannot be changed.