Re: [foxboro] Troubles with the Checkpointfile
- From: steve.shimp@xxxxxxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Mon, 6 Mar 2006 07:39:56 -0500
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 = 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=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:
