Re: [foxboro] FW: parameter state at CP boot

Dirk,

One suggestion not yet mentioned is to use the COMMF flag in the PLB logic
in conjunction with the FAILSF coil in a latching arrangement.  Any
communications failure with the CP, including a CP reboot, triggers the
COMMF flag which locks the outputs in their defined failsafe state.  Reboot
logic in each CP than has all the time it needs to clean up discrete output
drives before resetting the failsafe latch.  This gives you a good shot at
making the reboot process "bumpless" without having to make extensive edits
to all existing logic.

Good luck with it.

Regards,

Doug Lloyd
DGL Controls

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Pauwels, Dirk - RSM
Sent: Monday, January 30, 2006 10:55 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FW: parameter state at CP boot

Terry,

Thanks for your suggestions. Unfortunately we have a large number of
aout's and gdev's connected to PLB which are not in PID loops, but are
controlled by sequences, logic/calc and/or operator action. The PID
loops we have are not so much of a problem. I'll have a look at the
CIN/Switch method, but I've always wondered why such an important issue
was never covered by a default parameter function in the blocks. It
would have been so easy to include a parameter: "Startup default
position" or something similar.We have this setup for about 10 years,
(regular upgrades, CP60's) and haven't had much "unexpected" shutdown's
since, but the few times we did have them, were certainly very
"exciting"....=20
Thanks for the response guy's.

Rgds,
Dirk

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Doucet, Terrence
Sent: maandag 30 januari 2006 16:11
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FW: parameter state at CP boot


Dirk,

Are you using PID type blocks to AOUT to ECB and then to a valve?

If you configure the FBM's ECB for fail safe, and you set the AOUT =3D
PRIBLK true (1) then on recovery of a failure, either the field bus =3D
fails or the CP reboots, your PID (I assume you set it to initialize in
=3D
Manual) will hold its output at whatever you selected for the ECB =3D
failsafe value, regardless
of the value for PID.OUT in your checkpoint file.

If you have blocks between the PID and the AOUT, you need to back =3D
propagate status bits so that you can still set AOUT.PRIBLK true.

If you are talking about ON-OFF valves controlled by PLB, you need to do
=3D
a lot of coding to make this happen, but it can be done.

Regards,

Terry



-----Message d'origine-----
De=3DA0: foxboro-bounce@xxxxxxxxxxxxx =3D
[mailto:foxboro-bounce@xxxxxxxxxxxxx] De la part de Pauwels, Dirk - RSM
Envoy=3DE9=3DA0: January 30, 2006 9:45 AM
=3DC0=3DA0: foxboro@xxxxxxxxxxxxx
Objet=3DA0: [foxboro] FW: parameter state at CP boot




We have the same problem. Not for controlled shutdowns, in which we take
a checkpoint with all vlves/pumps in safe position, but for crash,
uncontrolled, shutdown... Most of our valves are fail to close, so
shutdown is not so much of a problem, it's the startup we're worried
about....Because there is such a thing as a checkpoint file I asked
Foxboro if it was possible to create a default checkpoint reboot file,
which would contain safe valve/pump autdsr. This file only has to be
executed during reboot ,not during regular checkpoint. I was told it was
not possible to handle it this way. I'm sure other sites have the same
problem, so I'm also interested in knowing how they handle it. Creating
calc blocks to switch all of these vlvs to "safe" position would mean we
would have to create a large number of blocks.

Rgds,

Dirk Pauwels - DCS/MOC coordinator=3D3D20
Engineering dept.
Hexion Specialty Chemicals
E mail: dirk.pauwels@xxxxxxxxxxxxxx
T.  +32.(0)3.570.95.97
F.  +32.(0)3.570.16.09
Mob. +32.(0)497.428.300


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of steve.shimp@xxxxxxxxxxxxxx
Sent: vrijdag 27 januari 2006 16:43
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] parameter state at CP boot


I am looking for tips/feedback regarding setting parameters to a known,
safe state when a CP reboots.  For instance, we have a valve configured
via
ICC such that AUTDSR =3D3D3D 0 and INITMA =3D3D3D 1.  However, the =3D
checkpoint =3D3D
file
has
the AUTDSR =3D3D3D 1, which happened to be the desired valve state when =
=3D
the
checkpoint occurred.  When the CP reboots, the valve will be in auto and
open, which is undesirable.  I need a way to override this when the CP
reboots.

Is there any way that I can definitively tell when a CP is first
initializing/booting and explicitly override any undesirable parameters
that may be in the checkpoint file?


Steve Shimp
Maintenance & Systems Engineer
ExxonMobil Paulsboro Lube Plant
phone: 856.224.5059      cell: 609.820.8501      fax: 856.224.5030
email:  steve.shimp@xxxxxxxxxxxxxx

=3D3D20
=3D3D20
_______________________________________________________________________
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
=3D3D20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =3D3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Djoin
to unsubscribe:      =3D3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Dleave
=3D3D20
=3D20
=3D20
_______________________________________________________________________
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
=3D20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe:      =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
=3D20
=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: