Re: [foxboro] Troubles with the Checkpointfile
- From: "Pauwels, Dirk - RSM" <Dirk.Pauwels@xxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 6 Mar 2006 16:02:31 +0100
Makes sense Steve and thanks for the suggestions BTW, but what I really
meant was that the CIN/SwTCH option does not see the difference between
a controlled CP reboot and a "panic" CP reboot. When you do a controlled
CP reboot for image update etc...all critical equipment will go to
interlock position? Or is this no problem with Fault Tolerant CP's? We
checkpoint our CP's, do the reboot and resume from the checkpoint file,
which is a nice feature we would like to keep. It's only the
uncontrolled cp reboot's we're troubled with.
Changing the initma to 1 before performing a regular controlled CP
reboot would work, but switching it back to initma =3D 0 to cover the
uncontrolled reboot option will require a "done" and therefore will
require a temporary lock of the switch block to 1 to cover this initma =
=3D
0, Ma =3D 0 status of the cin. I could live with that, don't know if the
foxboro service engineers like this solution.=20
Also I think some people won't like the idea that a large part of the
facility (1 cin controlls 1 CP) can be shut down with one cin.... Anyone
with access to the select can toggle the cin to false by accident.
I did the regular checkpoint procedure as well for some time but this
being a batch plant, with a lot of units and addition headers, and a lot
of actions being performed in a 16-35hr period, even checkpointing every
hour won't be enough to cover most of the scenario's. It will limit the
number of "accidents" but won't prevent all of them. This procedure will
work fine in a continuous plant though. Unless checkpointing requires
several attempts, we sometimes need to perform the checkpoint 3 times to
get a good one.
Disabling the checkpoint utility is no option for us.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of steve.shimp@xxxxxxxxxxxxxx
Sent: maandag 6 maart 2006 14:48
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Troubles with the Checkpointfile
Dirk,
The CIN block will not initialize unless you turn the compound off and
on
or do something to the CIN block in the ICC. We have the logic for this
interlock mechanism in its own compound, for what it's worth. We have
not
had any problems with the block accidently initializing, even when
making
configuration changes to other blocks in different compounds.
Blocks do not initialize simply because a checkpoint was done.
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
foxboro-bounce@xxxxxxxxxxxxx wrote on 03/06/2006 08:29:21 AM:
> We have the same problem. The item has been mentioned before on the
> list, the solution with Cin on initma 0 and switch block tied to the
> interlock parameter only works if you're NOT checkpointing the CP.
What
> happens when you make a change in the ICC and a checkpoint is done,
the
> cin will initialize in manual causing all vlves to lock! This is not
as
> dangerous than the vlves opening randomly but very enoying.
>
> Rgds,
>
> Dirk Pauwels - DCS/MOC coordinator=3D20
> 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: maandag 6 maart 2006 13:40
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Troubles with the Checkpointfile
>
>
> Patric,
>
> Assuming that you have implemented some sort of interlock scheme, one
of
> the elegant solutions was to use 2 blocks, a CIN and a SWCH, that
> control
> the interlock. The CIN block will be configured to initialize in
manual
> (INITMA =3D3D 0). The SWCH block then "monitors" the MA status of the
CIN
> block and controls the interlock status. When the CIN block is in
> manual,
> the SWCH block will set its output to 1, which engages the interlock
> condition. When the CIN block is in auto, the SWCH block will set its
> output to 0, which will clear the interlock. This interlock mechanism
> should be established in each CP. When a CP reboots, the interlock
will
> be
> triggered and any unwanted states loaded from the checkpoint file will
> be
> overridden.
>
> 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
>
> foxboro-bounce@xxxxxxxxxxxxx wrote on 03/06/2006 07:28:01 AM:
>
> > Hi,
> > We use different releases of IA Fox-Systems (6.2 - 8.1, Solaris, NT,
> XP).
> >
> > In my opinion, the checkpoint-file will be generated, updated after
> > CIO-Config changes, with the current CP-Image.
> > And after a reboot the checkpointfile will get loaded in the CP.
> >
> > The problem is, we never know the state of the Checkpointfile. So,
its
> > state can be like the state we had, months ago, when we
> > did some changes on the cio.
> >
> > So if we get a power failure on the system, and all CP's reboot, an
> "old"
>
> > checkpointfile get loaded and we get a state of the system we don't
> want.
> > Motors, pumps, etc. starts, they weren't running before the failure,
> but
> > they were running during last checkpoint (Months ago).
> >
> > I would like to get the system after reboot in a safe state. Best
> would
> be
> > the default values of the cio-config. (Workfile)
> >
> > Any ideas?
> >
> > Regards Patric
> >
> >
> >
> >
> >
> >
>
_______________________________________________________________________
> > 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=3D3Djoin
> > to unsubscribe:
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
> >
>
> =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:
//www.freelists.org/list/foxboro
> to subscribe: =3D
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
> to unsubscribe: =3D
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
> =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
>
> 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
_______________________________________________________________________
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
Other related posts:
