Re: [foxboro] Troubles with the Checkpointfile
- From: "Boulay, Russ" <russ.boulay@xxxxxxxxxxxxxxxx>
- To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 6 Mar 2006 08:47:51 -0500
Blocks don't initialize when a checkpoint is performed. Blocks only
initialize when DONE is selected for that particular block or during CP
reboot. During reboot is when the state of the checkpoint file comes into
question. There are several approaches.
Some users schedule automatic checkpoints daily. So if CP fails they are
relatively current.
Some users "Disable Upload" in SMDH so the CP won't just boot back up under
an unknown status without any maintenance personnel available.
Relying on the workfile is not always a good option as all it takes is one
UPLOAD from the CP and the workfile is no longer in it's original configured
state when system was engineered.
So, daily or timely checkpoints are usually the best solution.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Pauwels, Dirk - RSM
Sent: Monday, March 06, 2006 8:29 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Troubles with the Checkpointfile
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=20
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 =3D 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=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
_______________________________________________________________________
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:
