I would do following things:
* Put the HSCO1 parameter in your historian along with the VALUE
parameter. This will let you see when the value changes.
* Enable the OAJ on all of your WPs and use AIM* or FoxAMI to build a
history of Operator Actions.
* Build a trend display for VALUE and HSCO1.
* Monitor the trend for changes to HSCO1, check the OAJ log for
actions at that time, check my other applications (scripts, sequence blocks,
batch S/W) and determine if an operator made the change or some application.
Does this happen on particular blocks or all blocks at random?
If it is a small set of blocks, you could consider opening a write list with
OMA or another tool. Putting this points on a write list would secure them.
Securing them would cause the application that tries to change them to get
an error when it tries. The application might then leave a trace of its
failure somewhere that you can find. (This is a brute force way to handle
finding the culprit, but it might be worth the effort.)
You might also use d_edit to dump your displays and grep them for HSCO1 to
determine if any of them are connected to the HSCO1 parameter by mistake.
Hope this helps.
Regards,
Alex Johnson
10707 Haddington
Houston, TX 77063
713.722.2859(v)
713.722.2700(sb)
713.932.0222(f)
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
-----Original Message-----
From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, November 21, 2000 8:28 AM
To: [EMAIL PROTECTED]
Subject: blocktype "REAL" HSCO1=0
Dear fellow engineers,
Does anybody have any experience with the following:
Data blocks of type "REAL" have ocasionally parameter "HSCO1" at
zero,
despite its configured parameter that is non-zero. This results in
VALUE=0
whenever the VALUE is modified to a non-zero value, e.g from
"select" or from
other applications. It occurs every now and then, 5-10 times a day
on a
population of 325 REAL-blocks in one CP40. We have not been able to
relate
this problem to configurator actions, checkpointing, upstream
connections,
gets, sets and so on.
When noticed, we recover by keying "enter" on the block's parameter
in the
control configurator (in the configurator the parameters are still
in tact),
followed by "DONE".
Up to now the problem seems to be limited to CP40, CP30 seems to
operate
properly.
We apply those parameters for all kind of process settings,
therefore this
phenomenon can be very harmful.
Of course you can think of work-arounds, but none of them have the
advantage
of the functional name and block-descriptor that you can assign to
each
block. The number of REAL-blocks we apply is too high to be able to
replace
them by other type of blocks, not to mention the amount of
application work
this will result in. And above all, this is an elementary function
that
should operate properly.
Additional data:
CP40 type a Hosted by AP50 rev 4.3
Eeprom revision level 1.2
Thanks in advance,
Groeten,
Cees Esser
BELLT-GCA, the Netherlands.
-----------------------------------------------------------------------
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]
