Continuing with our
post VMS install steps, we'd like to setup and
configure a typical interface. While we are at that,
we are also going to enable IORates
for that interface and configure shutdown events and
check for crashed command files. Our PINet
node is equipped with a test program called
fractal. This is not necessarily found on all PINet
nodes, but ours happens to have it. Fractal is a simulation
program or test program that generates data for
PI. And it is
designed to comply with OSI's standard for
instrument computer inferfaces.
So this test program, fractal,
has a PointSource, a start up command file that we need to
configure and all of the other features that we would expect an interface
to have. To begin, we might
consult the documentation for the interface.
Most of our documentation for interfaces
has a section that describes installation and start up of the interface program.
It may also have a installation check list.
So what you find in most
of the interface documents is a brief
description of one line
items necessary to start the interface. And then another
section of the book that describes things in detail. This particular
interface is fairly simple, so they skipped the check list
and just provided the detailed instructions.
To start the interface program, it looks like we need to have a command
something like this one here. And you can see we are running the fractal program with a
couple of parameters passed to it. The
first parameter, the ? is the
point source character. And the second parameter is the
IORate counter. Interfaces may have
more items on their command line than this, such as
scan frequencies, ports if we are talking to a serial
port, or other instrument system specific information.
So it looks like I need to add something like this to
the site specific start up file for PI.
The site specific start up file for PI is
called PINetSiteStart and there is a similar site stop
command file. Let's see how we setup the
interface for start up.
We might begin by editing
my SiteStart.com
file. And
this is typical generic
empty file, so I will paste in some
lines here.
So what I have done here is I have
used the lexical function f$ search to
check and see if the file exists. And if the
file does exist, then I will get a fully qualified
file specification back including the
expansion of this logical name.
If I get a null back,
then the things will not exist.
And if the file does exist, then I
want to start up the interface, passing it the appropriate
command line parameters, being the point source
character and the IORate counter.
So that is all that I need to do here.
Again this if then else
construct here was a little bit sophisticated.
You do not have to do this, merely typing in
the command here would have been adequate. But
my thought here was that is something happens to the
fractal interface in the future and it disappears,
then I will not have a broken situation here.
So I will just save this and we will want to make a corresponding
change to the site specific shut down file for PI.
You want to check the interface
documentation. Most of our interfaces allow you to
stop the interface merely by killing the program, and that's
what this command file stop
does for us. It asks the program to leave
using an exit handler that the program may or may not be compiled
with. If the program does not respond, then it is just killed.
Most of our interfaces can be stopped safely
in this particular fashion. Some of the interfaces
such as the mod 300
interface, Honeywell CM50 interface,
they have a special shut down
procedure you must execute in order to cleanly and safely
shutdown the program. Fractal is one of those that
fits in the majority case where you can just kill the program and that is a safe thing to do.
So I will stop the
fractal interface by doing this.
Putting the program name
in quotes is optional.
You may see examples where
we have done this. Strictly speaking
it is not required, but if you want to be safe, it never hurts.
So that will take care of getting the fractal
interface started and stopped automatically next
time, we reboot PI. If I wanted to at this
point, I could execute
the SiteStart.com file to
test that I can start the fractal
program. And I see fractal
running. If I wanted to, I
could execute the SiteStop command file to test to make sure that
I can shut the fractal program down correctly.
As I said, there may be more details to starting
up an interface and configuring its start up file.
You should always check the interface documentation to make sure.
I would like to take a moment to talk about some more
features that are involves in starting up one of the interfaces for
PI. I would also like to introduce the idea of [inaudible].
I have logged into a different PINet node that has a
[inaudible] chip system.
The chip system, we have
an interface we call
Chip2PI that runs on OpenVMS.
This particular interface happens to run on
some other platforms as well but we are going to limit our discussion here to
the OpenVMS discussion.
If I were to look at the
PINet directory, I would find a number of files
whose name is
Chip2PI something. There is a Chip2PI.com
file which we are going to edit in a few moments, and we are going to see that it
contains some command line parameters that we need to configure
in order to setup the behaviour of the interface.
There is also a
Chip2PIdetach.com file. There is a
Chip2PI.exe which is the executable that
runs and then you can see we have run this interface a few
times and there are logs that have been produced.
The Chip2PIdetach command file,
I sometimes refer to a high level command file.
It's normally the command file you execute
to start the interface. However, it's normally
a file that you do not need to edit-- you just run it.
So the parameters and other items found in this
file, normally are appropriate as they ship from
OSI-- no change is required.
I would like to refer to the Chip2PI command file as a low level
command file. And this is the command file
that contains parameters and that you are responsible for configuring and
maintaining. This is considered a site specific
file, so it will not change on upgrade.
If there are new features, you will need to determine that
from checking the PINet build
directory after an upgrade and by reading the software
release notes and the product documentation.
Chip2PI is a command that you edit and maintain,
but it's not a file that you would normally execute directly. Normally to start and
stop the interface, you would execute
Chip2PIdetach.com.
Chip2PIdetach.com is not a very long
command file. One of the things I might ask you to do
is take a look at what is on the screen
here and tell me the name of the program that actually executes when
we try to start the interface. I will give you a hint-- this is a
trick question.
While looking at this, we see there is a run
detach command. So this looks like something that is going to run
something. The rest is mostly house-keeping and messaging.
And what we see actually gets run by this
is not the Chip2PI program, but rather
logging out.
This is the same program that runs when you walk up to a terminal
and you bash on the return key to get the system's
attention. And this sytem response by putting up the username prompt.
What we are in essence doing is we are creating a separate
instances in the VMS command shell by
running the logging out program. And instead of
prompting for username and password, we are running this in
the background, the detach switch. And instead
of executing a login.com file to startup
this new session, we are executing an input
file called Chip2PI. So this is where the configured
parameters that you set go. And rather than
direct the output to a screen and interact with a keyboard,
we are redirecting the output to a log
file and this is how the log gets generated.
But the key thing to note here is we are not running the interface, we are
running [inaudible] to create a new command shell or
command interpreter to execute the interface within.
The reason we do this is partly
so that VMS keeps better track of the interface
program and it
keeps accounting and other troubleshooting and debug
information. The other reason for doing this is so that
the interface program is not dependent on a parent process
for resources. So rather than become a
child of the program that launches this,
when we run the interface in this manner,
it is independent and stands on its own.
So those are the reasons why we do it this way.
If we take a look at Chip2PI
we will see that this is even a briefer command file.
And the catch here is that it has got a command line with a
bunch of command line switches. The syntax here is quite a bit
different than what we saw with fractal. And
this is partly due to the fact that this is a
[inaudible] program. So the next lesson we will
talk about the [inaudible] features specifically.
In the earlier lesson, I
mentioned that some of our interfaces are based on something
called [inaudible]. OSI has a
set of reusable code that we use
as the starting point for many of our interface
developments-- we call this [inaudible]. [inaudible] provides
many common functions that an
interface needs to support, such as
the implementation of a point source.
Reporting of status and performance through
event counters and performance points,
scan frequencies and so on.
If we take a look at the interface documentation
for the Chip2PI interface, we find a section
that details command line parameters that are entered
into the Chip2PI.com file.
Each of the [inaudible]-based interfaces
will have a slightly different list of command line parameters
but many of the command line parameters are
similar due to the nature of [inaudible]
So there is a debug option. If I scroll
down here, there
is a snap shotting option.
PointSource option.
An ID option. There is an event counter option that we will find here.
Scan frequencies. You can learn more
about the generic options of the
[inaudible] interface
and the specific options of the interface by looking
at a document on your
PI Documentation CD called
[inaudible] end user manual.
Taking a look at our
Chip2PI example here, you will see that
one of the differences we see here versus the
fractal program we were looking at is there is a
slash used to separate the items on the command line.
So in the fractal program
we were using spaces. In some of the other PI
interfaces, you use commas to separate the items on the command line.
Also the items on the command line with the [inaudible] interface
are prompted. So there
is a one or two or more character long
prompt that identifies the parameter to
follow. So I add
PS for PointSource and EC for event counter.
And I have [inaudible] scan frequency and I can add more than one scan
frequency here. ID number
for the interface number and so on.
So this is characteristic [inaudible] based interface.
Most of the [inaudible] interfaces
support PointSource, event counter,
scan frequencies, id number,
and also such things as snap shotting
[inaudible]
So we want to set those up for each of your interfaces. And your
guideline for doing so will be the documentation
for the interface program
and there will be a section that talks about the command line
parameters or the start up file. And that's how you will find
those settings.