Re: [foxboro] Batch Application
- From: "Jim Mowrey" <jmowrey@xxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Sat, 26 Jun 2004 10:13:04 -0400
I can offer a solution to what I believe MAY be the root problem. The root
problem in a batch application MAY be that the CP on reboot tries to run
some old batch, often with disastrous results. For instance, you make
changes in the ICC and checkpoint while a batch is adding a particular
chemical to a recipe. But on reboot, the CP attempts to start adding that
same chemical regardless of plant condition, because the phase logic was
active during checkpoint.
Or, on reboot, you start running a completely different batch recipe.
The solution I've used is a CPINIT compound to HOLD, then ABORT all phases
in the CP, thus "cleaning up" the recipe download and phantom phase light
off problem. This has solved this problem in numerous batch applications
that I've done, and if this is the problem you are trying to solve, it works
quite well.
Jim Mowrey
Maxis Automation
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Joseph M. Riccardi
Sent: Friday, June 25, 2004 10:38 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Batch Application
Alex,
Can you elaborate a bit? - I think you have it sorted out.
If they don't do uploads, where does the drift occur? - Let's start with =
a
fresh download and exit the ciocfg (a checkpoint occurs). The working =
file
(with the approved batch default parameters) equals the checkpoint file. =
If
a checkpoint occurs after ... an operator changes any writable parameter
(.SPT), or logic changes a parameter (.MANP), or ... Then the 2 files =
will
no longer agree. If a CP reboot occurs, it uses the checkpoint file, =
which
is now different from the working file (with the approved batch default
parameters).
There are tools to report mismatches between checkpoint and workfiles, =
but
nothing is going to get a checkpoint's .SPT parameter back to the =
workfile's
value automatically. - I couldn't think of anything either, that's why I
sent the e-mail inquiry.
That said, you could reboot to a compound OFF mode and have the Batch
software put the compound and its blocks to the desired state before =
turning
it on. Would that work, i.e., sync to a large recipe rather than the
workfile? - It's a possibility, but a major effort at this point. Since =
I
did not think there was anything that would do it automatically, I was
hoping to solicit some ideas on how to solve the problem. Or better =
yet,
hear from another user with the same requirements; and a tried and true
solution in place. This client just discovered the problem today and is
still trying to sort it all out; and what it all means. I am just =
trying to
supply some potential solutions ...
Thanks ...
Joseph M. Riccardi
Joe@xxxxxxxxxxxxx
"To give real service you must add something that cannot be bought or
measured with money; and that is sincerity and integrity." - Donald A. =
Adams
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] =
On
Behalf Of Johnson, Alex (Foxboro)
Sent: Friday, June 25, 2004 5:54 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Batch Application
Joe,
Can you elaborate a bit?
If they don't do uploads, where does the drift occur?
Is it things like the .SPT parameter that they want to leave fixed?
There are tools to report mismatches between checkpoint and workfiles, =
but
nothing is going to get a checkpoint's .SPT parameter back to the =
workfile's
value automatically.
That said, you could reboot to a compound OFF mode and have the Batch
software put the compound and its blocks to the desired state before =
turning
it on. Would that work, i.e., sync to a large recipe rather than the
workfile?
Regards,
=20
Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (operator)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
For the latest information on ArchestrA, go to
http://www.invensys.com/Archestra.html.
=20
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] =
On
Behalf Of Joseph M. Riccardi
Sent: Friday, June 25, 2004 4:14 PM
To: 'Foxboro Free List'
Subject: [foxboro] Batch Application
Folks,
=20
Our client needs to have the CPs reboot to the working file - default
parameters. How do we keep the CP checkpoint file in synch with the =
working
file (for the default parameters - no uploads allowed). As we make
operational or engineering changes, and checkpoints occur, we get =
farther
and farther away from the working file - default parameters. If we =
reboot,
we don't start with the the working file - default parameters.
=20
Any help ...
=20
Joseph M. Riccardi
<mailto:Joe@xxxxxxxxxxxxx>=20
=20
"To give real service you must add something that cannot be bought or
measured with money; and that is sincerity and integrity." - Donald A. =
Adams
=20
-- No attachments (even text) are allowed --
-- Type: application/ms-tnef
-- File: winmail.dat
=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
_______________________________________________________________________
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:
