Osisoft - Defining the basic interface parameters. v3.4.375

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.