RE: Legacy Historian Upgrade

[Lowell, Tim:]

Alex,

We have configured most flows to update at 10 seconds, and most everything
else to update at 30 seconds, with change deltas of 0.1% of engineering
units.  I wish there was a way to configure deltas as percent of actual
observed range, like the Biles AIM product used to have.  That would really
be nice.

I had never even heard of fastest_rsr until the Connoisseur guys added it to
foxapi.cfg, but that of course does not affect AIM*Historian.  That would be
/opt/aim/bin/aimapi.cfg.  Does fastest_rsr also apply there, or is it
something different?

How does one obtain the Solaris Configurator?  Is it part of the "you must
ante-up some more cash" version 3.1, or can I get it for my current version
3.02?

I did refer to I/A Report Writer, which I think is the same thing as the
Foxboro Canada report package with a different name.

Tim Lowell
Control Systems Engineer
Phillips Petroleum Company, Trainer Refinery
Phone:  610-364-8362
Fax:610-364-8211
[EMAIL PROTECTED]


-Original Message-
From:   Johnson, Alex (Foxboro) [SMTP:[EMAIL PROTECTED]]
Sent:   Thursday, September 27, 2001 10:29 AM
To: Foxboro DCS Mail List
Subject:RE: Legacy Historian Upgrade

Re: Loading


The load is proportional to the number of changes and the update
rates. 


What is your setting for fastest_rsr in /opt/fox/ais/bin/foxapi.cfg?
This
controls how often updates are sent from the CP to the historian.


How do you change deltas now compare with the ones then?



Re: You must have at least one Windows NT workstation or server on
the
network to configure it.  It cannot be configured from Solaris
except with
the command line interface, which is great for bulk edits but
cumbersome for
small changes.  This could be a problem for sites not running
Windows NT.


The Solaris Configurator is available and has been for a few months.



Re: no tools are provided for extracting real-time data into tabular
or text
format with AIM*Historian by itself


The I/A Series Report Writer is available.



Regards,


Alex Johnson
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 


-Original Message-
    From:   Lowell, Tim: [SMTP:[EMAIL PROTECTED]]
Sent:   Thursday, September 27, 2001 9:07 AM
To: 'Foxboro DCS Mail List'
Subject:RE: Legacy Historian Upgrade

And now a customer perspective...

Pros of AIM*Historian:

1.  You can modify it while it is running.
2.  You can run it on the NT platform as well as AW51,
and you
can set
up remote collectors on both NT and Unix platforms.
3.  Much better archiving and storage tools.
4.  Reasonably clean Windows NT interface (with some
annoying
little
quirks) as well as the usual bulk command line interface.

Cons of AIM* Historian:

1.  It can be an enormous resource hog.  Our
6000-points-or-so
AIM*Historian runs on an AW51E, 256 MB RAM, a 9.1 GB hard
drive, and
we
notice considerable sluggishness over the AW51E we have that
doesn't
run
AIM*Historian.  The Legacy Historian is no slouch hogging up
resources also
of course, but I can recall a few years back at another site
running
a
similar number of points on an AW51C with a 1.2 GB drive
without
many
problems.
2.  Could be a cost issue for some companies.  And the
AIM*Suite
utilities (AIM*Datalink, et. al.) don't buy you much over
the ODBC
interface
you can already get with the Legacy Historian.  AIM*Datalink
is a
woefully
inadequate product.  The only thing we use it for here is
the DDE
interface
so that we can link AIM*Historian real-time data to our
Excel Visual
Basic
sheets.  Otherwise, no one uses it because it is cumbersome
and
requires
intimate knowledge of how the I/A system is put together,
which our
process
engineers don't have.
3.  You must have at least one Windows NT workstation or
server
on the
network to configure it.  It cannot be configured from
Solaris
except with
the command line interface, which is great for bulk edits
but
cumbersome for
small changes.  This could be a problem for sites not
runn

RE: Legacy Historian Upgrade

[Lowell, Tim:]

And now a customer perspective...

Pros of AIM*Historian:

1.  You can modify it while it is running.
2.  You can run it on the NT platform as well as AW51, and you can set
up remote collectors on both NT and Unix platforms.
3.  Much better archiving and storage tools.
4.  Reasonably clean Windows NT interface (with some annoying little
quirks) as well as the usual bulk command line interface.

Cons of AIM* Historian:

1.  It can be an enormous resource hog.  Our 6000-points-or-so
AIM*Historian runs on an AW51E, 256 MB RAM, a 9.1 GB hard drive, and we
notice considerable sluggishness over the AW51E we have that doesn't run
AIM*Historian.  The Legacy Historian is no slouch hogging up resources also
of course, but I can recall a few years back at another site running a
similar number of points on an AW51C with a 1.2 GB drive without many
problems.
2.  Could be a cost issue for some companies.  And the AIM*Suite
utilities (AIM*Datalink, et. al.) don't buy you much over the ODBC interface
you can already get with the Legacy Historian.  AIM*Datalink is a woefully
inadequate product.  The only thing we use it for here is the DDE interface
so that we can link AIM*Historian real-time data to our Excel Visual Basic
sheets.  Otherwise, no one uses it because it is cumbersome and requires
intimate knowledge of how the I/A system is put together, which our process
engineers don't have.
3.  You must have at least one Windows NT workstation or server on the
network to configure it.  It cannot be configured from Solaris except with
the command line interface, which is great for bulk edits but cumbersome for
small changes.  This could be a problem for sites not running Windows NT.
4.  Unlike Legacy Historian, no tools are provided for extracting
real-time data into tabular or text format with AIM*Historian by itself.
There is an Excel add-in, which is only somewhat helpful, but you must buy
the whole AIM*Suite to get it.  If you want any sort of customization at
all, you must create your own tools using C or Visual Basic.  If you happen
to know or want to learn C or VB, that's great, but if you don't know it or
don't have time to learn, you'll have to spend more money to hire someone
who does.  You could also buy the Foxboro Canada report package, which also
works with the Legacy Historian.

We have AIM*Historian here, and I would never want to go back to the Legacy
Historian, despite the myriad of problems we have had with issues mostly
related to the remote collector we set up.  We bought the whole AIM*Suite as
a small part of a huge project, we have NT here, and I happen to know a
little VB, so the cons are not an issue here, but they may be for some
sites.  The fact that you can modify it while it is running is a big enough
pro for me to recommend it, especially to sites where historian uptime is a
big deal, like a refinery.  

Tim Lowell
Control Systems Engineer
Phillips Petroleum Company, Trainer Refinery
Phone:  610-364-8362
Fax:610-364-8211
[EMAIL PROTECTED]


-Original Message-
From:   Johnson, Alex (Foxboro) [SMTP:[EMAIL PROTECTED]]
Sent:   Thursday, September 27, 2001 9:25 AM
To: Foxboro DCS Mail List
Subject:RE: Legacy Historian Upgrade

You should give consideration to moving to AIM*. It contains
migration
utilities that preserve the customer's data and configuration
information.


Regards,


Alex Johnson
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
[EMAIL PROTECTED]  



---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: sysmonmsg group

[Lowell, Tim:]

We don't have any AW70's, so I'm not sure if I can help much, but I do know
a way to extract message data from AIM*AT to a text file on the AW51.  In
/usr/fox/disp_tools is a program called fh_sacego, which is a tool for
extracting System Monitor and Operator Action Journal messages to a text
file.  The syntax is:

AW5101# fh_sacego   ""
"" "" "" ""


So, for example, to get System Monitor messages for yesterday for all
stations from historian hist01 into a file called messages.txt, the command
would be

AW5101# fh_sacego messages.txt hist01 "" "" "" "2001-09-13 00:00"
"2001-09-14 00:00" -m

The quotes are required.  As you can see, to get all messages without regard
to station, compound or block, the filters would just be double quotes ("").
With no -m, which is the default, you get Operator Action Journal messages
only.

I have no idea if fh_sacego exists on the AW70, but I think it doesn't.

If you buy the AIM*AT Suite with the ODBC driver license, you can use
Microsoft Access and Excel Visual Basic to view message data from AIM*AT,
but I have had very limited success with this method.  Document B0193YJ,
chapter 10 gives you some examples of using ODBC in this fashion, none of
which address message groups.  AIM*Datalink does a pretty good job of
retrieving message group data, and I would suggest taking the AIM*AT
training class offered at the Lifetime Learning Center to learn how to use
AIM*AT.

Tim


-Original Message-
From:   salvatory dany [SMTP:[EMAIL PROTECTED]]
Sent:   Friday, September 14, 2001 4:12 AM
To: Foxboro DCS Mail List
Subject:RE: sysmonmsg group

Hi Moshe,

My be I didn't clarify the situation very well.
The case is,In the normal Legacy Historian from the
DATA DISPLAY we can save an ASCII file with any data
from Reduction Group and Message Group in
/opt/fox/R_.
My question now is,Can I make the same with the
AIM_HISTORIAN installed on NT platform,And where these
files saved if this is possible?. 



--- Maurice Moshe <[EMAIL PROTECTED]> wrote:
> exactly same place. aim*historian is multiplatform.
> 
> > -Original Message-
> > From:   salvatory dany [SMTP:[EMAIL PROTECTED]]
> > Sent:   Wed, September 12, 2001 12:59 PM
> > To: [EMAIL PROTECTED]
> > Subject:sysmonmsg group
> > 
> > Hi all,
> > 
> > All system messages are stored in the "sysmonmsg"
> > message group in the Historian package for AW51x,
> > What about these messages for AIM-Historian
> package
> > for
> > the AW70's,Can any one till me where these
> messages
> > stored in the AW70's?
> > 
> > thank you for your attention.
> > 
> > __
> > Do You Yahoo!?
> > Get email alerts & NEW webcam video instant
> messaging with Yahoo!
> > Messenger
> > http://im.yahoo.com
> > 
> >
>

---
> > This list is neither sponsored nor endorsed by the
> Foxboro Company. All 
> > postings from this list are the work of list
> subscribers and no warranty 
> > is made or implied as to the accuracy of any
> information disseminated 
> > through this medium. By subscribing to this list
> you agree to hold the 
> > list sponsor(s) blameless for any and all mishaps
> which might occur due to
> > 
> > your application of information received from this
> mailing list.
> > 
> > To be removed from this list, send mail to 
> > [EMAIL PROTECTED] 
> > with "unsubscribe foxboro" in the Subject. Or,
> send any mail to
> > [EMAIL PROTECTED]
> 
>

---
> This list is neither sponsored nor endorsed by the
> Foxboro Company. All 
> postings from this list are the work of list
> subscribers and no warranty 
> is made or implied as to the accuracy of any
> information disseminated 
> through this medium. By subscribing to this list you
> agree to hold the 
> list sponsor(s) blameless for any and all mishaps
> which might occur due to 
> your application of information received from this
> mailing list.
> 
> To be removed from this list, send mail to 
> [EMAIL PROTECTED] 
> with "unsubscribe foxboro" in the Subject. Or, send
> any mail to
> [EMAIL PROTECTED]
> 


__
Terrorist Attacks on U.S. - How can you

RE: Cassandra.org meeting in Las Vegas

[Lowell, Tim:]

Well, I have tickets, hotel reservations, and I registered, but that doesn't
necessarily mean I will be coming.  Since I work for a large organization,
the decision is ultimately not mine to make.  As of now, no air travel is
allowed, and from what I am hearing, air travel will be limited to
"non-discretionary" (meaning only absolutely necessary) for the near future.
So, if I'm there, I'll be at the roundtable, but I wouldn't count on it.

Tim

-Original Message-
From:   Ries, Gerry [SMTP:[EMAIL PROTECTED]]
Sent:   Thursday, September 13, 2001 2:17 PM
To: '[EMAIL PROTECTED]'
Subject:Cassandra.org meeting in Las Vegas

Are you planning to attend the International Foxboro User Group
meeting
October 7 to 11 in Las Vegas?

I'm on the steering committee for the user group meeting and one of
my
responsibilities is a Tuesday night roundtable session from 6:00 to
8:00.  

The session is called "User Utilities and Solutions Roundtable
Discussion".
This is actually the meeting slot for the "Cassandra.org" people.
We had a
similar session last year that was informative and a lot of fun.

The session will be free format and should provide a great
opportunity for
users to share and discuss solutions, ideas, problems etc.

I thought we could use the list server to generate some topics of
interest
and maybe find some people with some "solutions."

Thanks in advance for your participation.
Gerry Ries
City of San Francisco
Water Pollution Control Division



---
This list is neither sponsored nor endorsed by the Foxboro Company.
All 
postings from this list are the work of list subscribers and no
warranty 
is made or implied as to the accuracy of any information
disseminated 
through this medium. By subscribing to this list you agree to hold
the 
list sponsor(s) blameless for any and all mishaps which might occur
due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

Micro I/A

[Lowell, Tim:]

Folks,

I need to do a survey of all Micro I/A with Allen Bradley I/O users that
read this list.  We just finished a day 0 upgrade to version 6.2.1
throughout our system, and we have been having all kinds of problems with
our Micro I/A stations with AB I/O.  Almost all of the I/O is connected to
Type J and K thermocouples.  After the upgrade, some of the thermocouples
values updated, some didn't, and it seemed to be a fairly random.  We could
get the modules to go white on System Monitor, and we could read temperature
values, but they would just freeze at one value.  What I need to know is the
following:

1.  Roughly how much I/O are you using on your Micro I/A stations?  We
have about 1000 thermocouples, spread over 3 separate Micro I/A stations,
which I think is extremely high amount for this product, and might be
contributing to the problem.
2.  What are your scan periods, and are you using phasing in your
database, either for the ECB blocks, Control Blocks, or both?  We run the
ECB and AIN blocks at 5 seconds on 2 stations, and 30 seconds on the other.
We are phasing both the ECB blocks and AIN blocks.  With 2 of the stations.
we managed to get every thermocouple updating, we think, by adjusting the
phases of the ECB's to either 0, 3, 5, or 9.  All other phases did not work,
and sometimes even 0, 3, 5, and 9 did not work for various ECB's, and
required much trial an error.  The other station, with a 30 second period,
had no problems with it as far as we can tell.
3.  What station software version are you at for Micro I/A (the version
found in the upper right corner of the station block detail display)?  We
had problems at the station version of 6.2, so TAC told us to back down the
Micro I/A station software to v4.2.1b and add QF 990320 on top of that.
They said v6.2 Micro I/A software had problems with Allen-Bradley I/O, and
we should not have loaded v6.2.  Of course, this was news to us and the
service techs who did the upgrade.  Have you heard anything about not
upgrading Micro I/A to v6.2?

Thanks in advance for anybody who can answer any of these questions.

Tim

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: FoxView 99.2.1 trends

[Lowell, Tim:]

I did discover a way around the 5 step process of calling up an historical
trend that might be enlightening to someone, I'm not sure.  I configured
buttons with the DM command "trend" on my existing trends.  Trend lets you
draw a trend with many different attributes.  The full command is:

trend [-g trendname] [-trdid n]
[-line # [-name c:b.p] [-descr "dd"] [-range r]
[-hist histname] [-gband g] [-minsp m]
[-name0 0] [-name1 1] [-delta d] [-eng e]
[-lcolor lc] [-marker m] [-dtype d]] [-scan "s u" | -dur "s u"]
[-start time | -stop time | -display "du su"]
[-banded | -merged] [-temp | -perm]
[-gcolor gc] [-bgcolor bc]
[-tstamp t] [-gvis gv] [-offnorm h,l]
[-offnrmcolor oc] [-numgrid nli] [-nummkrs nm]][-resol "t u"]

Which covers just about everything you can do with a trend.  See B0193DF for
full details on this command.  

We use mostly generic, re-useable trends, that get called up by clicking on
an AIN or PIDA value, which in turn passes the COMPOUND:BLOCK as DM shared
variables, such as $P3 and $P4.  The dmcmd trend command can also use these
shared variables in the -name switch to draw a new trend line.  So now when
the console guys call up our standard 1-hr trend, they have 4 buttons on the
bottom which can change the trend to 2, 4, 6, or 12 hour with one click.
Thanks, Foxboro, for getting me to look into this!  Now it's much easier.
Of course, if the console guys want more choices than that, they have to go
through the whole 5 step procedure, or get me to make more buttons.

Some of our guys know about the left-click "Calendar" type interface, but
few use it because it is even more cumbersome than the existing 5 step
system.  First of all, you have to Pause the trend to even get the
"Calendar", and it's kind of a mystery exactly where to click.  This new
"button" system is nice because you can get a longer trend immediately, and
the buttons are very self-explanatory.

If anybody wants to see what I did, I'll post some files on Cassandra.  I'm
not sure if dmcmd trend even works on DM though.

Tim


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

FoxView 99.2.1 trends

[Lowell, Tim:]

We just got done upgrading all of our WP's to FoxView 99.2.1.  For some
reason, the on-line trend configuration tool was changed in this version to
add 2 more steps to the process of calling up a historical trend.  In
version 99.2, you right-clicked the trend, clicked on the "week", "day", or
"hour" button to set the time span of the trend, and hit OK, and you got the
trend.  In this version, you have to click on a "Duration Settings..."
button, click on the "week", "day", or "hour", then click OK, then click on
a completely useless dialog box that offers the choice of the highest and
lowest possible "Scan rate" based on your selection of the time span, then
click OK again, and finally get the trend.

Is there any way to speed this process up with FoxView settings so that our
console guys can bypass all these steps and just get a historical trend
quickly?  Why does it ask you for "scan rate" now?  It used to be, whichever
time span you picked determined the scan rate.  This worked well, and nobody
ever requested a change in any of the International Users Groups I ever went
to.  Often times, there isn't even a valid "lower scan rate", so that choice
is greyed out and you must select the "upper scan rate" anyway.  It seems to
me that if someone wanted a choice of scan rates, you could make a button
just for them, instead of forcing everyone to go through a separate dialog
box, which often only has one choice.  Any ideas out there, other than
re-installing FoxView 99.2?

Tim

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: FoxCAE Enhancements (enclosure loading)

[Lowell, Tim:]

Thanks everyone for the help with Enclosure Loading on FoxCAE.

The next enhancement request for FoxCAE I have is for FoxCAE (and SysDef) to
recognize all possible FBM types.  We have a bunch of FBM37's, which are 8
4-20 mA analog Outputs on 1 card.  Foxboro doesn't have a lot of
documentation on these, since very few people order them, but they are a
standard product with a PSS and everything.  For some reason, SysDef and
FoxCAE both are in denial that FBM37's exist.  When you build a system with
SysDef, you end up having to add the FBM37's on-line because there is no way
to select them from a list.  Of course, this also means when you try to
import your SysDef into FoxCAE, you have to add the FBM37's by hand there
also.  Even then, you can't get the enclosure loading reports to reflect
that the FBM37's you added by hand exist.  You just get blank spots in the
nest loading diagrams where they should be.  Very strange.  Invensys, please
incorporate all FBM types in all your software!  I don't think that is too
much to ask.

Tim

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: FoxCAE Enhancements

[Lowell, Tim:]

As of FoxCAE version 4.0, is the Enclosure Loading function supposed to be
working?  I don't think it is, but someone please let me know how you get it
to work if it does.  What I do is add the FBM data by hand into the
ENCLOSURES.DBF table.  Unfortunately, this cannot even be done with Access,
so I have to download a 4th party shareware tool that will let me input the
FBM types, letterbugs, nest and slots into the table.  Obviously, this is
kind of a silly way to make this function work, and it would nice if we
could get FoxCAE to let us enter the data directly.  It would be even better
if it could import the FBM's from the SysDef file and then we would just
have to type in nest and slot data.

Tim

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Helpfile Viewer

[Lowell, Tim:]

I have installed Netscape Navigator for Solaris 2.5.1 on all of our WP51D's
for Help file viewing.  The only issue is that sometimes on FoxView, the
colors get messed up if you run Netscape.  If you close Netscape and restart
FoxView, the colors look OK again.  This is pretty typical of FoxView in
general.  It doesn't like other applications running that want to use the
color palette.  For the most part, it has been very successful and we've
been happy with Netscape.  

We have an Apache web server on one of our AW51E's, and the WP51D's can call
up HTML help documents via buttons on the FoxView screens from the AW51E
that have nice explanations of our advanced control schemes.  Since the
WP51D's don't have second Ethernet ports, we use the token-ring IP address
on the AW51E to serve the documents to the WP51D's.  That's probably not
incredibly smart, but HTML documents are usually not high-bandwidth, and we
haven't had any traffic problems that I know of.

You can find a compiled version of Netscape Navigator for Unix 2.5.1 at 

http://home.netscape.com/download/0222101/10002-en-solaris2.5.1-4.76-base-12
8_qual.html
 


Tim

-Original Message-
From:   Karppi, Dan [SMTP:[EMAIL PROTECTED]]
Sent:   Friday, March 09, 2001 10:19 AM
To: 'Foxboro DCS Mail List'
Subject:Helpfile Viewer

Hello List Members,
 
I want to provide our plant operators with Help/Operating manual
pages that
are called up by a button on a display.  Standard display manager
text boxes
are too limited.  I am looking for a way to display text and graphic
files
from display manager.  Do any of you do this or know how to do this
using
built in Solaris applications or third party applications.  An HTML
file
viewer would be ideal.
 
Thanks,
Dan
 
Dan Karppi CCST
Falconbridge Limited
Smelter Complex
Falconbridge, Ontario
Canada
P0M 1S0
 
Phone: (705) 693-2761 ext. 3881
Fax: (705) 699-3887
mailto:[EMAIL PROTECTED]
 
 


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Setting the default environment for DM's in Foxview

[Lowell, Tim:]

I forgot!  Alex is correct, as usual.  In addition to changing fv_cmds, you
also need to put the full path in the dmcfg file where the space is for the
Initial Environment.  As in:

TYPERemote  DSM E
/opt/fox/env/Remote.env

Tim



-Original Message-
From:   Bruley, Peter [SMTP:[EMAIL PROTECTED]]
Sent:   Thursday, February 22, 2001 12:41 PM
To: Foxboro DCS Mail List; Johnson, Alex
Subject:RE: Setting the default environment for DM's in
Foxview

Alex

It is my experience that full pathing the env names in the dmcfg
file does
not seem to work

Peter

--
From:  Johnson, Alex
Sent:  Thursday, February 22, 2001 11:38 AM
To:  Foxboro DCS Mail List
Subject:  RE: Setting the default environment for DM's in
Foxview

Two:

Use a full path name for the environment; not just its name.

There's a DM environment variable that you can change to set
the
correct
path for your environments, but darned if I can remember
what it is
and my
expert just went to lunch! How embarrasing.


Regards,


Alex Johnson
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
[EMAIL PROTECTED]  


-Original Message-
From:   Joe Sanguinetti
[SMTP:[EMAIL PROTECTED]]
Sent:   Thursday, February 22, 2001 11:18 AM
To: '[EMAIL PROTECTED]'
Subject:Setting the default environment for
DM's in
Foxview

Here is what I want to do and I am wondering if
anyone has
done
this: 


I want the same functionality that was in
Display
Manager.
I want to be able to set the initial environment for each
configured
DM in
dmcfg.  I spoke with TAC and they say this is not supported
with
Foxview.
This was done with the TYPE parameter in dmcfg.  

Any ideas 

Joe 




---
This list is neither sponsored nor endorsed by the Foxboro
Company.
All 
postings from this list are the work of list subscribers and
no
warranty 
is made or implied as to the accuracy of any information
disseminated 
through this medium. By subscribing to this list you agree
to hold
the 
list sponsor(s) blameless for any and all mishaps which
might occur
due to 
your application of information received from this mailing
list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail
to
[EMAIL PROTECTED]


---
This list is neither sponsored nor endorsed by the Foxboro Company.
All 
postings from this list are the work of list subscribers and no
warranty 
is made or implied as to the accuracy of any information
disseminated 
through this medium. By subscribing to this list you agree to hold
the 
list sponsor(s) blameless for any and all mishaps which might occur
due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Setting the default environment for DM's in Foxview

[Lowell, Tim:]

Foxboro says you can't do this, but you can.  You need to change the file
called /usr/fox/wp/data/fv_cmds. You need to comment out the line that
reads:

$OPTFOX/env/Initial.env# call in initial environment

and uncomment the line that reads

#$ENV1   # call in configured first environment

It should look like this when you are done:

#$OPTFOX/env/Initial.env# call in initial environment
$ENV1   # call in configured first environment

Then you should configure dmcfg the way you normally would.  Make sure that
the Initial Environment that you configured in dmcfg actually exists in
/opt/fox/env.  Then reboot, and your FoxViews should pop up with the correct
Initial Environment.  

We have FoxView 99.1 and a few new FoxView 99.2.1 WP's, all with dual heads,
and all the FoxViews on both heads pop up with the proper Initial
Environment on reboot.  Foxboro says it shouldn't work, but it always has.

Tim

-Original Message-
From:   Joe Sanguinetti [SMTP:[EMAIL PROTECTED]]
Sent:   Thursday, February 22, 2001 12:18 PM
To: '[EMAIL PROTECTED]'
Subject:Setting the default environment for DM's in Foxview

Here is what I want to do and I am wondering if anyone has done
this: 


I want the same functionality that was in Display Manager.
I want to be able to set the initial environment for each configured DM in
dmcfg.  I spoke with TAC and they say this is not supported with Foxview.
This was done with the TYPE parameter in dmcfg.  

Any ideas 

Joe 


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

First Meeting of Mid-Atlantic Foxboro Users Group

[Lowell, Tim:]

The first meeting of the Mid-Atlantic Foxboro Users Group will be held at
Sun Chemicals in Philadelphia, on Friday, February 16th.

The address is the intersection of Margaret and Bermuda Streets,
Philadelphia, PA 19137. 
19137.

DIRECTIONS TO SUN CHEMICAL
>  From 95 N. exit at Bridge St. As you exit 95, bear to the right at the 
> 1st light. Continue to Bridge St. and make a right at the light.  You 
> will pass the contractor entrance to the plant, continue to the  next 
> light and make a right. (7-11 on corner). Go up to the 2nd light, Lefevre 
> St. and make a right. Before you get to the next light, the plant 
entrance is on the right, directly below 95.

Map:
http://www.mapquest.com/cgi-bin/share?s9ner8l7mehdpnri
 
 > 

We plan to begin at 11am.  Sun Chemical will offer a tour of their offline
I/A system to present some of their design philosophies on graphics, etc.

Topics will include:

Sun Chemicals discussion.
Creating a gripe list.
Prioritizing what we'd like Foxboro to be doing for us.
Open to suggestions / to be developed

Certainly, we'd like to discuss what we can do as a group to steer Foxboro's
efforts in a direction coincident with our needs.  Lunch will be catered by
Cape Software.

More information can be obtained by subscribing to the Mid-Atlantic Foxboro
Users Group mailing list, [EMAIL PROTECTED]  .
You can subscribe by going to http://www.coollist.com
 , and clicking on Join a New List.  Type in
"mafug" (no quotes) in the list name space.  You will be sent an e-mail to
confirm your subscription.


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Alarm Formats

[Lowell, Tim:]

Stan, 

I certainly respect your decision to go on your own here, but please let me
add my two cents on each of your points.  I'm trying hard not to sound like
a LogMate salesman, but we have it here, and it's a no-brainer as far as
setup and support.  Anyway:

1.  LogMate supports ANY serial RS-232 communication from ANY system.
If your systems print out to a serial printer, LogMate can read it.
2.  You only need one license of LogMate for each DCS system you are
hooking up to, as long as each individual DCS system is networked to itself,
such as Foxboro, Honeywell, A/B, etc.  Locations don't really matter.  Of
course, if you have islands of each DCS all over that aren't networked to
each other, this becomes more expensive.  Worst case is you have 25 separate
DCS systems that aren't networked at all.  Then you need (1 x $4000) + (12
x $2000), which is $28,000 worth of licenses. Chances are, it is less than
that, because at least one of your DCS's are networked together somehow.
For example, our I/A system has 2 nodes connected by a LAN, so I only needed
1 license for the whole system.  LogMate requires a Pentium 90 to run and
can run on Windows 95/98/NT.  If you don't have at least Win95, you can
upgrade the PC for about $50.  I would think implementing any system at all
would require at least these specs.  If you are attempting to collect data
on a Pentium-60 DOS machine and feed it to a relational database that is
web-enabled, you are a better man than I, Gunga Din.
3.  LogMate is not web-enabled, but since it stores the messages in a
Paradox database, you should be able to use readily available tools to
extract the data and create a web-based viewer.  TiPS even supplies a
Paradox database engine for Windows for free on their web site if you don't
have one.
4.  As far as lifetime support goes, I'd still rather bet on a software
company that knows what it is doing and has a fairly large installed base
than attempt to create my own custom solution.  TiPS dates back to 1988, and
has been a first-class company to deal with whenever I have dealt with them.
I see what you are saying about source code, but who is to say that an
engineer working 25 years from now will be able to debug a program in C++ or
Perl, or even Visual Basic?  These languages might be as dead as Latin then.
You might be the only one around who can figure it out, if they can find
you.

To me, LogMate is a "killer app" for doing what it does.  I have yet to see
anything close to it for ease of use, price, and options.  But like Dennis
Miller says, that's just my opinion, I could be wrong.

Tim

-Original Message-
From:   Stan Brown [SMTP:[EMAIL PROTECTED]]
Sent:   Friday, December 29, 2000 9:34 AM
To: [EMAIL PROTECTED]
Subject:    Re: Alarm Formats

On Fri Dec 29 08:55:15 2000 Lowell, Tim: wrote...
>
>Stan,
>
>Here's my best guess as to the breakdown of the Alarm messages:
>

Thanks so much! That's exactly what I needed.

If I can help you with anything UNIX related, PLEASSE let me
know.

As to why not use Logmate, here are at least some of the
reasons.

1. This project is to handle input from many more systems
that just IA (AB
Flame safety systems, Fox iA, Sectrum etc.)

2. We will be deploying this system eventualy in perhaps as
manyas 20 to 25
locations. We will be reuseing PC's that the IS group has
taken out of service
as to old, and slow to run any flavor of Windows (ealrt
Pentium machnines)

3. We will be able to provide web based access to these
alrams via a CGI script
for the operations suspervisors, and ODBC access to our
process control
engineers.

4. Systms in our mill tend to live rather long lives, often
extending beyond
the life of comercial software providers. This makes it very
dificult to
maintain these systems, since we dont have access to the
source code, and the
vendor is no longer in businees, or no longer supports the
product we have.


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Alarm Formats

[Lowell, Tim:]

Stan,

Here's my best guess as to the breakdown of the Alarm messages:

For a HIABS, LOABS, HHABS, LLABS, HIOUT, LOOUT, HIDEV, and LODEV alarm:

  
   <(ALARM LIMIT)>

The ".ANM" field (which means Alarm Name) only appears if the ANM parameter
has been configured for that block.

The "RTN" means "return from alarm".

For a State alarm (like with a CIN or COUT block) you get:

  <"STATE" OR "RTN">
  

ALARM TEXT is the value of the ALMTXT parameter for that CIN or COUT block.

If an alarm has been inhibited or uninhibited, you get:

  
  

There are other messages for GDEV and MTR blocks, as well as IND and other
sequence blocks that I rarely see, so I'm not sure about them.

System alarms come in all kinds of varieties.  The most common ones are the
equipment failure ones you cited.  In those cases you get:

 "0"   "Station" or "Equip ="

"SYSMON"  

Why they put the "0" and the word "Station" or "Equip =" on every message,
only Foxboro knows.  The SYSMON ID refers to the System Monitor name that is
configured in SysDef for the piece of equipment that is having problems.
The STATION ID is the letterbug of the piece of equipment having a problem,
such as a CP, WP, FBM, etc.   is some sort of Foxboro internal
code that numbers each type of message.  Good luck finding documentation on
that.

This is only one type of System message.  There have to be at least 5
others, with different formats.

I agree with Alex and Dennis, go buy LogMate or something similar.  You will
save yourself man-weeks of aggravation, for only about $5,000 for a 2-PC
capture/view license, and $500 for each additional view license.  You can
even network it.  And you won't have to support it for the rest of your
tenure there.  And if you want, you can still flex your programming muscles
building a Web interface, since LogMate doesn't have one.  It stores
messages in a Paradox database (with well-documented fields), so I would
think it is theoretically possible anyway.  Try
www.tipsweb.com/products/logmate/logmate.htm
 

Tim




-Original Message-
From:   Stan Brown [SMTP:[EMAIL PROTECTED]]
Sent:   Friday, December 29, 2000 8:21 AM
To: [EMAIL PROTECTED]
Subject:Re: Alarm Formats

On Fri Dec 29 00:12:46 2000 "Johnson, Alex P (Foxboro)" wrote...
>
>It's fixed. There is no description that I'm aware of in the
documentation
>other than a discontinued system messages B0 book.
>
>Sorry about that.
>

Thanks.

Well, surely someone on this list must understand what these
message contain,
right?

It appears that the come in at least 2 formats. Let's call
them process, and
system.

Common features, they both seem to cnsist of 2 80 character
lines folowed by a
blank line, right?

Jeree is a typical process alarm (at least for us):


503TEMP:IG1447D HYDROGRATE SOUTH  SECTION
ENABLE
12-11-00 09:28:13:4ALARM MESSAGES
ENABLED  

I believe that 503TEMP is the comound, and IG1447D  is the block.

Sometimes there is an extra field next following a dot as in;




508COE:IPC005B.MILL DAY TAN DAY TANK LEVEL
LOABS 
12-11-00 09:35:00:2 9.05FEET   (  8.8) LOW LEVEL
RTN  



Can someone tell me what this is?

Next we seem to have, what I am calliing "alarm description" as in:

"HYDROGRATE SOUTH  SECTION", and "DAY TANK LEVEL" in my 2 examples
above.

Next we seem to have what I am calling the alarm "type" as in
:ENABLE" and HIABS"
in these 2 examles.

At the start of the 2nd line we have what appears to be a date/time
stamp. But
whats the filed after seconds?

Next we have an optional filed which contains, I assume, the PV if
the signal that
trigered the alarm. When is this sample, when the alarm is first
detected in the
scan?

In the second exmaple above we have a value in ()'s which I am
thinjing is the
alarm stepoint? correct? This filed also appears to be optional,
right?

Then ew have some text. "ALARM MESSAGES ENABLED", and "LOW LEVEL"
what is this, and
where is it configured? then in one example we have "RTN" I am
thinking this is the
"Return To Normal" or out of alarm message. right?

OK now system alarms:

Here's 2 example of them:


12-11-00 09:35:51  0  SYSMON = SYSMN1  WP0501  Station

  SYSMON -00045 Equipment failure acknowledged


12-11-00 10:15:02  0  SYSMON = SYSMN1  CP0505  Equip = CP0505

  SYSMON -00056 Currently using PIO bus A

These seem, to start with a date/timestamp, but this time without
the filed
  

What Honeywell hath wrought

[Lowell, Tim:]

I just got back from my first ever Honeywell course (we also use Honeywell,
and my boss finally asked me to learn it), and I really like some of their
system status displays, so I attempted to duplicate one of them on the I/A.
After a few days development, I have come up with this:

A graphical display of all the FBM's in a given CP, area, unit, whatever.
Each FBM on the display is represented by its letterbug.  Clicking on the
letterbug runs a script file which creates a substitution list and then
calls up a re-useable display that gets filled in by the script with all the
configured I/O blocks on that FBM.  On the re-useable display you get the
block name, description and current value of each block on that FBM, with
the current value in background text so you can see if it is BADIO or not.
You can click on each block name to call up a standard detail display for
each block.

It's not completely real-time like Honeywell, because I couldn't figure a
way to extract blocks in real-time given the FBM letterbug.  What I did was
write another script that creates the "master list" of all I/O blocks in the
system with their IOM_ID's and PNT_NO's which takes about 30 minutes to run
using "getpars" and "omgetimp" calls.  You could use FoxAPI unbuffered reads
too, I suppose.  The substitution list script then greps out the FBM
letterbug from the "master I/O list".  The idea is that you run the "master
I/O list" script once a day or once a week using crontab, since you don't
normally add I/O points very often anyway.  You could run it on demand also.


The whole scheme is kind of kludgy, but it works and I think will be very
useful around here.  You could use it to see if a given FBM has any spare
points or to see what's on an FBM if it goes bad.  It's also nice just to
monitor an FBM to see how the points on it are doing.

If anyone wants to see the scripts and displays, I would be happy to provide
them.  The current version supports AIN, AINR, AOUT, AOUTR, CIN, COUT, GDEV,
and DPIDA, because that is all we have here.  You could add other I/O blocks
easily enough.  I also would love to hear any better ways to accomplish what
I tried to do, especially ways to make it more real-time, and any other
system status displays that people have come up with.

Tim

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Daylight Savings time (again)

[Lowell, Tim:]

No thanks.  Console guys get pretty jumpy when every screen locks up and you
have to reboot them all.

Tim

-Original Message-
From:   Joe Sanguinetti [SMTP:[EMAIL PROTECTED]]
Sent:   Friday, October 20, 2000 1:45 PM
To: 'Foxboro DCS Mail List'
Subject:RE: Daylight Savings time (again)

You might give it a try on 99.1, it might work. 

Joe 


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Daylight Savings time (again)

[Lowell, Tim:]

Sounds good.  We skipped 99.2 on Foxboro's orders, still at 99.1.  I ordered
99.2.1, waiting for it to arrive.

Tim

-Original Message-
From:   Joe Sanguinetti [SMTP:[EMAIL PROTECTED]]
Sent:   Friday, October 20, 2000 1:25 PM
To: 'Foxboro DCS Mail List'
Subject:RE: Daylight Savings time (again)

I believe that even in Foxview 99.2 you can just kill the Foxview on
the console and it should respawn itself.  If it does not come back you can
restart it and things are ok.  It would be nice if you could set the time
from the command line so you can have a machine automatically adjust the
time when you need it done.


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Daylight Savings time (again)

[Lowell, Tim:]

Brain damage, I like that one...

No, Foxboro I/A does not use the TZ variable.  If you are especially unlucky
to be using FoxView, you cannot even set the time backwards for the end of
Daylight Saving Time, or you will freeze any AW51 or WP51 running FoxView.
Even the developers of FoxDraw/FoxView blame the developers of I/A for not
using the TZ variable right in the Release Notes, so what are you gonna do?

Well, what we are going to do is run all winter an hour ahead, just like we
did last winter.  We have no alternative.  I hear from the TAC web site that
FoxView 99.2.1 only requires a restart of FoxView if you set the time
backwards, as opposed to a full AW/WP51 reboot.  Anybody know if that is
true?  That we could do, with some advanced planning and script files.
Rebooting all 17 of our AW/WP51's is not an option.

Tim



-Original Message-
From:   Stan Brown [SMTP:[EMAIL PROTECTED]]
Sent:   Friday, October 20, 2000 10:38 AM
To: [EMAIL PROTECTED]
Subject:Daylight Savings time (again)

I think we had this discussion about this time last year,
but I have
forgotten the conclusions (if any).

Is there any reason that the Foxboro machines (AP, WP, AW)
can't have
there hardware clock set to UTC, and use the TZ ebvironment
variable to
present date/time information to the operators in local
time? We have
several other UNIX based systems which are set up this way,
and it
avoids all the flailing around that happens twice a year.

All data on these other machines is loges in UTC, and any
viewing of it
is morphed to the local time via the OS via the TZ
environment
variable. This is so clean, i can't believe that it's not
the way to do
it on Foxboro systeams. Or am I missing some Foxboro brain
damage?


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: AIM*Historian

[Lowell, Tim:]

If you would like to extract System Monitor or Operator Action Journal
messages from AIM*, there are existing tools to do this.  You need to
download Quick Fix #991513, which consists of two programs, oajgen and
fh_sacego.  These programs are Foxboro-supplied C programs that can be used
with AIM* to replace the functionality that the ACE report writer has with
the legacy historian.  If you follow the Quick Fix instructions, it works
pretty well.  I use it to generate a System Monitor report every day.

If you need to extract process data and alarms from AIM* with a C program,
so far, you are on your own.  Foxboro does not supply such applications at
the moment.  In fact, they supply nothing whatsoever to extract Alarm data
out of AIM*.  I would recommend a company called TiPS, Inc., which sells a
nice product called "LogMate" that captures alarm messages from the I/A
Series COMM10 port, among other DCS systems, and stores the messages in a
Paradox database on an NT PC, Vax/VMS Alpha machine, or NT network.  They
can be found at www.tipsweb.com  .

For AIM* C Programs, the make string should look like this, based on my
experience with AIM*:

-llargem -laimapi -laimhistory -lfox -lfoxfdr -lsocket -lnsl -lposix4 -lm
-lmfc40 -lcommdlg32 -lodbc32 -lolest32 -lcommctrl32 
-lgdi32 -luser32 -lkernel32 -lprnt32 -lwinsock32 -lC -lthread -lw -lgen -lXm
-lXext -lXt -lXmu -lX11 -ldl -lfoxlc -lhi -ldsp

I think you will get a bulleted list in Microsoft Outlook when I send this.
Ignore that.  All the libraries should have "-l" (the letter "ell") in front
of them with no space and then the library name.
According to the documentation (B0193YN), there is a -laim, but that doesn't
exist.  The correct library is -laimhistory. I also had to rename libC.so.5
to libC.so in /usr/lib, and I had to add -ldsp to the list.  Alex Johnson of
Foxboro and Jeremy Milum of Hunstman helped me figure this stuff out.
I hope that gets you started.
Tim

-Original Message-
From:   [EMAIL PROTECTED]
[SMTP:[EMAIL PROTECTED]]
Sent:   Friday, October 20, 2000 8:26 AM
To: - *[EMAIL PROTECTED]
Subject:AIM*Historian

Hi,

We are using the AIM*Historian on an off-line SUN-platform.
We are looking for an extraction tool (preferable in 'C') to extract
data from
the AIM*Historian data files or the exact 'make'-string or a list of
all the
libraries wich should be linked !
A search in the Cassandra database showed us some tools like
makeaatab.tar.Z,
ez_archive.zip and ez_archive.tar.Z but I don't think this is an
answer to our
problem.

Best regards,

Vaningelgem Alfons
Bayer Antwerpen N.V.
Afdeling IN-EP/PAS
Haven 507 - Scheldelaan 420
B-2040 Antwerpen
Tel. (0)3 540.35.40
Fax. (0)3 540.36.90



---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Alternative Displays

[Lowell, Tim:]

You guys are really pushing your luck discussing such heathen ideas like not
giving all your money to Invensys on this board!

Just kidding...maybe.

Tim

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: find command ussage?

[Lowell, Tim:]

When I said I remove it every Monday, that just means that Monday is when I
happen to look for it.  I use one of Angel Corbera's scripts on a crontab
schedule to find the core files (Thanks, Angel!), and I delete them each
Monday morning.  We use GoGlobal instead of eXceed here, and I think that
has a lot to do with FoxSelect creating these core files.

By the way, here is Angel's command for finding core files, which works
well:

find / -fstype urfs -prune -o -name core -ls

I don't know what urfs is either, but I know this works on an AW51E at v6.1
every week.

Tim

-Original Message-
From:   Murray, Steve [SMTP:[EMAIL PROTECTED]]
Sent:   Tuesday, September 26, 2000 2:54 PM
To: 'Foxboro DCS Mail List'
Subject:RE: find command ussage?

Hi Tim, 

  My particular core file was generated last Thursday when a PC
running Exceed had a Fox Select window freeze up.  I had to shutdown Foxview
(on the PC) to get the Fox Select window to go away, and I found the core
file on Friday morning.

  "file core"  indicated the culprit was Fox Select, and the
timestamp was from Thursday, so I am "assuming" the PC exceed problem caused
the core dump.

  
 Is Fox Select causing your core dumps? 

  If you get one every Monday and it has the same timestamp, you
might look for something in cron that runs about the same time.

   A few years ago on my first Foxboro system I had a core file
generated every five minutes by the historian reduction group program.  It
wasn't very big, but it was dumped every five minutes for at least five
months.  My predecessor had deleted some collection points but had not
removed them from the reduction groups.

  Didn't seem to cause any harm, but it was odd when I found the
core files .  .  . 



---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: find command ussage?

[Lowell, Tim:]

I remove that same core file every Monday.  What is up with that, anyway?
Does anybody know what causes FoxSelect to core dump routinely?

Tim

-Original Message-
From:   Murray, Steve [SMTP:[EMAIL PROTECTED]]
Sent:   Tuesday, September 26, 2000 10:08 AM
To: 'Foxboro DCS Mail List'
Subject:RE: find command ussage?

Hi John,

  I just removed a 13 MB core file from one of our root directories,
core
file left courtesy of Fox Select .  .  .

  The root directory seems to be a popular place for all the Foxview
stuff
to puke core files.

Stephen Murray



---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Rolling average

[Lowell, Tim:]

Steve,

CALC blocks are can do something like this, only over less time, or updated
less frequently.  You could do a block like this:

PERIOD = 6 (60 sec)

RE: WP51D's with dual monitors

[Lowell, Tim:]

I guess I should clarify that this must be only with very recent orders.  We
also have some WP51D's from a previous order, but they did not have this
problem.  They used a different 2nd video card than the ones in our recent
order.

Tim
-Original Message-
From:   Alan J Schaff [SMTP:[EMAIL PROTECTED]]
Sent:   Tuesday, August 29, 2000 3:51 PM
To: Foxboro DCS Mail List
Subject:Re: WP51D's with dual monitors

Tim,
We have dual headed WP51D's and are using the 4 connector cable with
no
problems.  We are using cable P/N P09071HF with no adapters.  I
guess we have
never had any of the problems that you describe.  I'm not sure if
that makes me
nervous or not.

Alan Schaff


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

WP51D's with dual monitors

[Lowell, Tim:]

I know this is a pretty obscure one, but I just thought I'd mention it, in
case anyone is buying WP51D's with dual monitors:

The Sony monitors supplied with a dual monitor installation on WP51D's come
with RGB type connectors.  These RBG connectors have 5 plugs: Red, Green,
Blue, Horizontal Sync, and Vertical Sync.  The standard monitor cable
supplied by Foxboro (P0971FB) has 4 connectors: Red, Green Blue, and Sync.
In order to make this work, you need to have a Composite Sync Video Adapter
(P0971DZ).  You put this between the video card and the adapter cable
(P0971WG) which connects to P0971FB.   Apparently, the Composite Sync Video
Adapter does not ordinarily get shipped with the dual monitor installation,
so you'll need to special order it.

Here is a crude description of the assembly, starting at the card going
toward the monitor:

2nd Video Card  (15 pin VGA connector) --- Composite Sync Video Adapter (15
pin VGA connector on both ends)  ---  P0971WG cable (15 pin on one end, 24
pin on other end)  ---  P0971FB cable (24 pin on one end, RGB-sync on other
end) --- Monitor Cable (RGBHV on one end, 15 pin VGA on other end) ---
Monitor (15 pin VGA)

The documentation on the web site for this installation, B0400PT, is only at
Rev A.  Rev D is shipped as a hard copy with the hardware.  Rev. D explains
this cabling arrangement in great detail, but since this revision is not on
the web site, you might overlook the piece of paper lying at the bottom of
the box, as I did for 2 days.  I hope you can avoid the same fate.

Tim





---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

FoxCAE and Foreign Device Integrator 30

[Lowell, Tim:]

Has anyone out there been successful in back-documenting a Foreign Device
Integrator 30 on FoxCAE 3.02?  We just installed an FD30, and I tried to
back-document it, and FoxCAE gave me an "Invalid Letterbug" error.  I looked
through the CAR database, and didn't see anything that said you couldn't
back-document an FD30.  Any idea what I might be doing wrong?  The FD30 is
called DI1001, and it is running and talking to its foreign device OK.
DI1001 shows up in /etc/cplns and the checkpoint and DB files are where they
are supposed to be.  I'm stumped.  Any help would be appreciated.

Tim

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Foxboro DCS Mail List Photos at the I/A User Meeting

[Lowell, Tim:]

Thanks for your swift reply.

Tim

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Foxboro DCS Mail List Photos at the I/A User Meeting

[Lowell, Tim:]

Does anybody have a copy of the e-mail from Foxboro regarding the latest
CP40BFT/CP30BFT reboot problem?  Our service guy said we should have
received it already (we didn't), and Foxboro said they can get it to us next
week, but if one of you had it, that would speed things up a bit.  Since I
won't be in the refinery next week, it would be nice to know what is going
on so that I can inform the people who will be here what the problem is.

Thanks,

Tim

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: An interesting note on quality.

[Lowell, Tim:]

I love it.  Why is it that the result of almost any program by any
management team anywhere is the elimination of manufacturing plants and the
shift of production and engineering to China?   I think it is a lesson for
us all.  Lose weight and move to China!

Tim

-Original Message-
From:   David Johnson [SMTP:[EMAIL PROTECTED]]
Sent:   Thursday, July 27, 2000 9:32 AM
To: [EMAIL PROTECTED]
Subject:An interesting note on quality.

Here's a little something I found in the Invensys annual report that
I 
thought might be of interest to those of you on the list.

"We are aggressively applying Lean Enterprise and Six Sigma quality 
improvement practices in manufacturing, project engineering,
administration 
and the supply chain.  During the year we cut the number of
manufacturing 
plants by 22% and continued to shift production and engineering to
lower 
cost countries: 20% of I/A Series(c) hardware is now produced in
China."

Bruce Henderson
Invensys Intelligent Automation Division Chief Executive

from the Invensys 2000 annual reportpage 29




I have a hard time reconciling sentence number one with sentences
two and 
three in the above paragraph.  Of course that could just mean SUN is

manufacturing in China these days. :-o

BTW if you want an Invensys annual report just go to the Invensys
web site 
and e mail for one to be sent to you.  It's more interesting reading
than 
you might think.


Regards,
David





---
This list is neither sponsored nor endorsed by the Foxboro Company.
All 
postings from this list are the work of list subscribers and no
warranty 
is made or implied as to the accuracy of any information
disseminated 
through this medium. By subscribing to this list you agree to hold
the 
list sponsor(s) blameless for any and all mishaps which might occur
due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Historizing objects other than C:B.P's

[Lowell, Tim:]

You can historize station loading.  We have done it.  FoxDoc B0193AX,
chapter 97 (Station Block) gives an excellent description of all the various
Station parameters that you can trend.  The address is
CPLBUG_STA:STATION..  Is that what you mean?  I'm not sure about
any of the other stuff, such as all the counters you can access via the PERF
button on Sys_Mgmt.  I don't believe those are historizable, but I could be
wrong.

I hope to see you all at the Conference.  I'm with Bo, I think we need
online upgrades more than anything else by a long shot.  We're in a
situation where even during a complete refinery outage, we have to keep
boilers running, so we don't really ever have a COMPLETE outage.  At least
now we can run one node at 6.1, and the other at 6.2, so that is an
improvement, but I'd certainly rather have all stations at the same release
level if I could.  This is going to require an enormous effort on Foxboro's
part, since it will force them to undo engineering decisions made at the
very earliest stages of I/A development, so it is imperative we show
solidarity on this issue.

I'm glad to hear that Foxboro is revamping their development process.  My
recent experience has been less than encouraging, especially with FoxHistory
1.2 and FoxView/FoxDraw 99.2.  Both of these products were more or less dead
on arrival.  Our local service people have told us to not bother loading
FoxView/FoxDraw 99.2 at all.  We are staying at 99.1, which is working
pretty well.  I think it is a travesty that the development group pours who
knows how many person-hours into a release, and the service group loads it a
few times, and it's so bad, they tell all their other customers not to load
it.  It sounds like Foxboro feels the same way, and they are trying to fix
it.  I hope that is true.

I didn't have any choice with FoxHistory 1.2, since we had already bought it
when I took the job.  It was quickly replaced with 1.2B, then 2.0, then
AIM*Historian 2.5, all of which have had either major problems or severe
limitations.  AIM*2.5 has been pretty good for the most part, with some
minor irritations, and the usual lack of some important features that I have
grown used to over the years in all Foxboro historian packages.  Now
AIM*Historian 3.0 is out.  I don't know if it's any better, since I have not
managed to obtain a copy of it.  I would echo the person who wished Foxboro
would release upgrades to customers without us having to beg and plead.

See you next week.

Tim




---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Trouble with phasing blocks in an AB Integrator30

[Lowell, Tim:]

Well, like I said, my experience with Integrator 30's is limited.  I just
double-checked, and all of our compounds on the MG30's are 1/0, and the
MDSCAN' s are something else.  You have me stumped.  Are you getting the BAD
message on the ABSCAN detail display?  I know I've had to do some strange
things with MG30's to get that BAD to clear, such as DELETE/UNDELETE or
simply going into the ECB block of the PLC in question on the ICC and
editing a random parameter and hitting "DONE".  Gateways like to be started
up in a very particular fashion, and if you make changes after the initial
loading, you have to kind of "jump-start" them.

Tim

-Original Message-
From:   David Johnson [SMTP:[EMAIL PROTECTED]]
Sent:   Monday, June 19, 2000 9:57 AM
To: Foxboro DCS Mail List
Subject:RE: Trouble with phasing blocks in an AB
Integrator30

[Summary:
  I can't get an Integrator 30 to read from a PLC with Period 3,
Phase 1.

  Tim Lowell suggested that I leave the COMPOUNDS PERIOD 1 PHASE 0
and then 
phase the ABSCAN and following blocks to reduce station loading. ]

Tim,

I did attempt to use a PERIOD 1 PHASE 0 on the compound, and then
PERIOD 3 
PHASE 1 on the ABSCAN and subsequent BLOCKS. The problem persisted
until I 
phased them to PERIOD 3 PHASE 0.

Any other ideas?

Thanks,
David


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Trouble with phasing blocks in an AB Integrator30

[Lowell, Tim:]

David,

Based on my limited experience with Integrator 30's, I would recommend not
phasing the compounds.  Leave them all at PERIOD 1, PHASE 0.  I would phase
the ABSCAN's, and then phase each block under each ABSCAN with the same
PERIOD and PHASE as its corresponding ABSCAN.  This should be allowed by the
ICC, and will spread out the loading.  We do that here with MG30's, which
are similar devices.  

Tim

-Original Message-
From:   David Johnson [SMTP:[EMAIL PROTECTED]]
Sent:   Monday, June 19, 2000 9:43 AM
To: [EMAIL PROTECTED]
Subject:Trouble with phasing blocks in an AB Integrator30

I have had some strange results recently when trying to phase some 
compounds in an AB Integrator 30.

Here are the particulars.

The Integrator is running with a Base Processing Cycle (BPC) of 1
second.

Most of the existing COMPOUNDS are running with a PERIOD 1 PHASE 0.
(That should be every second, on phase 0)

Most of the BLOCKS in the existing compounds are running with a
PERIOD 3 
PHASE 0.
(That should be every two seconds, on phase 0)

All of this is working correctly.

We added a COMPOUND with a PERIOD 3 PHASE 1.
(That should be every two seconds, on phase 1)

The BLOCKS in the new compound are PERIOD 3 PHASE 1.
(That should be every two seconds, on phase 1)

This PERIOD, PHASE combination is acceptable to the control
configurator.

However, the ABSCAN block will not successfully connect and read
data from 
the PLC at this PERIOD (3) and PHASE (1).  If I change the PHASE to
a 0 on 
these COMPOUNDs and BLOCKs every thing works.  But having everything
PHASED 
at 0 causes issues with the station loading.

I hope some of you can shed some light on this mystery for me.

Thanks,
David Johnson

[EMAIL PROTECTED]



---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: C programming with AIM*API

[Lowell, Tim:]

Alex,

Well, I've been down that road, and what happens is, apitst only gives you
one message at a time.  There's something about a "more" parameter, which
tells you if there are more messages.  I can't figure out how it works.  If
you could get me in touch with a developer, maybe I could understand it
better.

Thanks for the reply,

Tim

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

C programming with AIM*API

[Lowell, Tim:]

I've got TAC on this case, but they might not be the best place to go for
this, so I thought I'd throw it on the list server to see if any of you
Foxboro wizards can help me out:

We have AIM*Historian, and it does not provide any tools to extract alarm
messages into a text format.  Unlike the legacy historian, AIM*Historian
doesn't generate a flat circular file like "almhist", it actually stores its
data in tables that are located in files that you can store for years.  I
know what tables they are stored in, and I even know the syntax of the C
call to access the tables.  Unfortunately, I cannot figure out all the
little important things you need to do to write a C application for this
purpose, such as what header files to include, how to declare the variables,
what kind of output the C call actually generates, and how to compile and
link the finished source code.  

The AIM*API documentation provides the syntax for the C call, which is
called fh_FdbMsgQuery, but it doesn't have a sample program using this call,
which is really what I need.  Someone at Foxboro developed a C program
called fh_sacego that queries the same tables and extracts System Monitor
messages and Operator Action Journal messages, presumably using the same
calls.  If someone at Foxboro could send me the source code for this
application, or a stripped down version that at least illustrates what is
required to properly declare the variables, handle the output, and compile
and link the C code, it would be much appreciated.  Anybody up to the task?
Has anybody else written any code with AIM*API?  

Thanks,
Tim



---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: Question about /etc/aplns and /etc/wplns

[Lowell, Tim:]

Stan,

All AW's and AP's are configured with 2 names, the "AW name", and the "WP
name".  This is done in System Definition.  The "WP name" of an AW/AP is
what the Alarm Alert system uses to send alarm messages to.  You will see
the "WP name" for your AW51B's under "SHOW...Available WP's" in the ICC,
because the ICC reads /etc/wplns to build this list.  There are other
reasons for the two names, but I can't recall what they are off hand.

Tim

-Original Message-
From:   Stan Brown [SMTP:[EMAIL PROTECTED]]
Sent:   Tuesday, May 02, 2000 8:22 AM
To: [EMAIL PROTECTED]
Subject:Question about /etc/aplns and /etc/wplns

I have ben working on some scripts lately that do various
things on our
Foxboor nodes. All of the nodes, exceept for 1 consits of
one or more
AP51B's, and WP51B's. On these machines ehre are the files
/etc/wplns
and /etc/aplns. Thes files descibe what WP's and AP's exist
ont ehis
node.

I have just deplyed these cripts on a node thta consosits of
a AW51B,
and a WP51B. Mich to my suprise, I found thta /etc/wplns
contaied the
folowing entry:

AWP400

This is the WP, I think it's real name is AW0400. Can anyone
tell me
why this entry is there?

Thanks.


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: AIM*AT 2.5 Installation Alert!!! Please read if you havepurc has ed this!!!

[Lowell, Tim:]

Wouldn't you know it, but the CSC web site went kaput at 10 AM yesterday, so
I did not have access to this database.  Figures.

Tim

-Original Message-
From:   James Kahlden [SMTP:[EMAIL PROTECTED]]
Sent:   Tuesday, April 04, 2000 8:05 AM
To: [EMAIL PROTECTED]
Subject:Re: AIM*AT 2.5 Installation Alert!!!  Please read if
you havepurchas ed this!!!

Tim,

Thanks for the info, just want to let everyone know that there is an
AIM*Historian Troubleshooting Guide on the Foxboro CSC website which covers
this problem plus many others.
Jim Kahlden

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

AIM*AT 2.5 Installation Alert!!! Please read if you have purchas ed this!!!

[Lowell, Tim:]

Well, it's been a fun day "upgrading" our historian to AIM*AT on our AW51E.
It's finally working, but I need to mention a very large omission in the
AIM*AT installation instructions:

If your historian has more than 1200 points, which it probably does, you
MUST do the following:

1.  cd /opt/aim/bin, or wherever you installed AIM*AT on your AW51.
2.  Edit the file called "aimapi.cfg".  As shipped, the file has one
line.  You must add a line to this file with your favorite text editor that
looks like this:

maxobj = (# of points that your historian is licensed for)

e.g.  maxobj = 2

If you fail to add this line, your AIM*Historian will only collect the first
1200 points.  Isn't that special?  This little tidbit does not appear in the
documentation, the Release Notes, or anywhere in the 1-week AIM*AT class I
just took in FoxMass.

Also, you may already know this, but it's a good idea to reiterate:  if you
have recently deleted a large number points from your CSA database, make
sure to also delete these points from your Historian.  All Historian
packages use either AIS, AIM*API or FoxAPI to establish connection lists to
the C:B.P points, and if the C:B.P's aren't there, it will take a long time
for either AIS, AIM*API or FoxAPI to start up.  I should have seen that one
coming, but FoxHistory is weird about deleting points.  They don't really
get deleted, they just don't get collected or count toward your license
amount.  Deleted points stay in your configuration forever, taking up index
points.  They show up in red on the GUI, and you can undelete them later if
you want.  I was concerned that if I "deleted" points that I had removed
from the CSA, that I could no longer retrieve them from tape archives.
Turns out, you can retrieve them, since they never really get deleted.

Ah, just another wonderful day in Foxboro-land!

Tim





---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]