Re: Now, I'm wondering if this was a waste of time? It appears that the
fastest_rsr parameter will override anything we do. Is this correct?
The fastest_rsr will place all lists at this scan rate for every list that
FoxAPI opens for any application.
So, you are wasting your time as far as CP loading and Nodebus traffic are
concerned.
Re: Is any effort to control nodebus traffic impact of PI in any way other
than controlling the number of tags/datasets futile?
The degrees of freedom are:
* fastest_rsr (one value per AW/AP)
* change delta (per tag)
* shared lists
We have discussed fastest_rsr.
Change deltas should be set to eliminate noise in the signal and must always
be non-zero.
* For .PNT parameters attached to traditional transmitters this is
usually 0.5% of scale expressed in engineering units.
* For .OUT parameters 1% of scale expressed in engineering units
usually good.
* Operator setpoints seldom change so the change delta can be whatever
non-zero value you like.
* Cascaded setpoints should be 1% of scale expressed in engineering
units.
Of course these are simply recommendations, you can choose whatever you want
as long as you understand the impact on the system and your application.
(However, if you choose 0 you will regret it since that results in a change
every 0.5s)
Shared lists are very valuable. If you have an AIM*Historian Data Collector
and PI on the same AW/AP, they can share lists by setting a parameter in
AIM*API's configuration file.
If the lists are shared, the smallest delta will be used and the CP will see
only one user of the tag.
This behavior is true for other AIM* and FoxAPI applications as well, e.g.,
DMCplus Bridge, Connoisseur, etc.
So, you should load the PI data collector on an AW/AP that is already using
FoxAPI/AIM*API.
FoxAPI applications automatically share lists. AIM*API applications share
lists automatically. To get AIM*API and FoxAPI to share lists, do the
following:
From the AIM*AT 3.1 Release Notes:
2.4.3.2 *** Configuring AIM*API to share Object Manager
connections with FoxAPI (use_aimapi=0)AIM*AT installs AIM*API. AIM*API and
FoxAPI are two separate subsystems. I/A Series programs that use FoxAPI
(FoxDraw, FoxCAE) will need FoxAPI to be running to operate. AIM*AT
applications only use AIM*API, and require it to be running to operate.
AIM*API and FoxAPI can share I/A Series Object Manager (OM)
connection resources. This feature needs to be activated by the following
procedure:
1. Edit the aimapi.cfg file to include the "use_aimapi = 0" flag. For
aimapi.cfg file location, see "Edits to aimapi.cfg file for AIM*AT server
machines" above.
2. Start FoxAPI.
3. Start AIM*API.
Failure to configure use_aimapi=0 will result in FoxAPI and
AIM*API each opening their own OM connections, wasting resources and
increasing the amount of time to open OM connections when the I/A Series
station is rebooted.
Also, make sure the MAXOBJ in both the foxapi.cfg and
aimapi.cfg files are set to the same value.
Regards,
Alex Johnson
Invensys
10707 Haddington
Houston, TX 77063
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx <mailto:ajohnson@xxxxxxxxxxx>
For the latest information on ArchestrA, go to
www.invensys.com/Archestra.html
<http://www.invensys.com/divisions/Archestra.html> .
-----Original Message-----
From: stan [SMTP:stanb@xxxxxxxx]
Sent: Wednesday, December 11, 2002 9:17 AM
To: foxboro@xxxxxxxxxxxxx
Cc: ddc5@xxxxxxxxxxxxxxxx
Subject: Re: [foxboro] FOXAPI Configuration for Foxhistory
Ver 2.0
On Wed, Dec 11, 2002 at 09:47:45AM -0500, Johnson, Alex (Foxboro)
wrote:
>
> The fastest_rsr value controls the period that is used by the OM
in the
> remote station. The period controls how often the OM checks a list
for
> changes. So, a 10s fastest_rsr will cause the CP to report changes
on the
> list once every 10 seconds.
>
How fortuitous that this should come up for discussion at this time.
One of
my co-workers ran into this value, in a discussion with TAC this
morning,
and I would like some clarification here.
Here is the situation. We have a management edict to get large
volumes of
data into the mill-wide PI system. Now we of course are trying to
minimize
the impact of this on the control systems. Areas of concern include
of
course CPU loading on the PI host A[PW}'s, and nodebus loading.
What we had done relative to nodebus loading was to break the data
into
groups, and attempt to "phase" the collection of this data. For
example we
have some datasets that we have told PI to check every 2 seconds,
and some
datasets we have told it to check every 5 seconds.
Now, I'm wondering if this was a waste of time? It appears that the
fastest_rsr parameter will override anything we do. Is this correct?
Is any effort to control nodebus traffic impact of PI in any way
other than
controlling the number of tags/datasets futile?
--
"They that would give up essential liberty for temporary safety
deserve
neither liberty nor safety."
-- Benjamin Franklin
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys
Process
Systems (formerly The Foxboro Company). Use the info you obtain here
at
your own risks. Read
http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list:
http://www.freelists.org/list/foxboro
to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: http://www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave