Re: [foxboro] Batch Application

Joe,

The main problem I see with the "reboot from checkpoint file" design is the
probable bumping of field devices.  If field devices are configured to go to
failsafe positions when communication between CP and FBM is lost, this is
undone when the CP starts communicating with the FBMs.  The checkpointed
output drives are most likely NOT the required failsafe positions.  We've
gotten around this issue by using PLBs with latched zone control.  A loss of
communications or a power failure (COMMFAIL, POWERFAIL) latches the zone off
and asserts the FAILSAFE coil.  All application rung logic is inserted
within the zone.  The CPs are configured with a RESTART sequence in the last
compound which initiates all required I/O drive cleanup before re-enabling
the zone control (via pulse!) and clearing the FAILSAFE coil.

This works well for discrete devices and is one way to address the issue.
The RESTART sequence can also be used to initialize critical parameter
values and take care of other loose ends before allowing the normal logic to
proceed after a reboot.

Regards,

Doug Lloyd
DGL Controls

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Joseph M. Riccardi
Sent: Saturday, June 26, 2004 12: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:             http://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:             http://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:             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

Other related posts: