[foxboro] FW: PI I/A Interface and non-updating values (on behalf of Dirk Pauwels)
- From: tom.vandewater@xxxxxxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Fri, 15 Apr 2005 14:34:28 -0400
My apologies to Dirk for not forwarding this PI related message yesterday.
His exchange server is not letting him send to freelist.org and thus I am
forwarding it for him.
Tom VandeWater
-----Original Message-----
From: Pauwels, Dirk - RSM
Sent: woensdag 13 april 2005 11:02
To: 'foxboro@xxxxxxxxxxxxx'
Subject: RE: [foxboro] PI I/A Interface and non-updating values
We have had PI points "freeze" also,regularly. Points belonged to the
same list, not all of the points in the list froze. We had to stop PI,
do a restart of the FoxApi, and then restart PI to get the tags working
again. My PI lists (collection groups) were setup like this: 1 list per
CP and per scanning rate, so ie: tag in CP6001, with scan rate 2 would
result in 12. Because we've experienced problems with big lists, I've
created a lot of smaller lists ie 21 becomes 211,212,213 etc. In the
past the problems with frozen tags always started after tags in the same
list were created or edited, with the smaller size lists this problem
does not occur anymore and if it should occur again, the amount of tags
affected is smaller.
So a few tips:
- Only put PI tags in the same list if they're in the same CP and all
have the same scan rate.
- Use smaller lists, if you need to create a lot of tags do not use an
existing list, but create multiple new ones
- use separate lists for read and write tags.
- After creating a tag, and assigning a datatype (boolean, int...) to
it, check the pi message log file, FoxApi sends the datatype to PI, this
might be a different type then the one you assigned in the pitag config.
If it is , it is reported in the log file. Adjust it accordingly in PI.
- Make sure you create a communication check, we called it PIHEARTBEAT,
which will create an alarm whenever PI communication is slow or broken.
It will save you angry calls from production, when they're missing vital
data for the last 8 hours or so...
- Use Pi healthcheck to verify the lists for bad input tags.
- in the excel pi add in, be care full deleting tags you've sorted with
the autofilter option, you might be deleting tags which are not shown on
the screen, but also have an "x" in the selection column.
We haven't had CP's fail due to PI, we did have a CP60 fail in the past,
and the FT DID NOT take over... In a batch process this means:
PANIC....Even more panic when the CP booted with an "old" checkpoint
file. Valves opening, pumps starting etc...
We're trying to figure out a way to have the CP reboot with a "clean"
checkpoint file, A file we can create and edit ourselves to allow a safe
startup after an unexpected CP reboot. Invensys is checking out the
possibilities...
Rgds,
Dirk Pauwels - DCS coordinator
Engineering dept.
Lawter International BVBA
An RSM Company
Ketenislaan 1c - Haven 1520
B-9130 Kallo, Belgium
T. +32.(0)3.570.95.97/ Mob. +32.(0)497.428.300
F. +32.(0)3.570.16.09
E mail: dirk.pauwels@xxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of brad.s.wilson@xxxxxxxxxxxxxx
Sent: dinsdag 12 april 2005 22:44
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] PI I/A Interface and non-updating values
Seeing all these messages about PI prompted me to write with my own PI
problem.
We have v4.3 with 17 CP40s (non-FT). Occasionally I will have some
points
"freeze" in PI ... there will be no error messages such as I/O timeout
or
bad input ... but the value will stop updating, so I get a flat line.
The
last good value is timestamped with the time the freeze occured, but I
can
find no apparent cause for it ... no I/A error messages (at least none
that
make sense to me), the DCS is unaffected. The values are always (I
believe) analog. Often (but not always) they are all in the same
collection group, but not ALL the points in the group freeze. I know of
no
way to "kick-start" the group without stopping and restarting the PI
interface, which clears anything that might have been in the buffer and
causes breaks in all my data. I don't know if these "frozen" points are
even being scanned or if the values are in the buffer but not being
uploaded to PI. Without much knowledge of how collection groups
actually
work, I have created 2 groups per CP ... one for analog values and one
for
discrete. The points are not evenly distributed between groups, because
some CPs are more heavily loaded than others. We have 2 nodes, but only
only one PI portal, so the PI interface must go cross-node to reach 13
of
the CPs. Any ideas?
Brad Wilson
ExxonMobil Chemical Co
Edison Synthetics Plant
732-321-6115
732-321-6177 fax
Brad.S.Wilson@xxxxxxxxxxxxxx
_______________________________________________________________________
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: //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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
- » [foxboro] FW: PI I/A Interface and non-updating values (on behalf of Dirk Pauwels)
