That is the intent....if you think your CP may bootup in undesirable conditions, then you want to not have the CP boot until proper personnel are available and in place. -----Original Message----- From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of Doucet, Terrence Sent: Monday, March 06, 2006 8:52 AM To: foxboro@xxxxxxxxxxxxx Subject: Re: [foxboro] Troubles with the Checkpointfile Russ, "Disable Download" would seem to prevent a reload of the CP database = after a reboot. Terry -----Message d'origine----- De=A0: foxboro-bounce@xxxxxxxxxxxxx = [mailto:foxboro-bounce@xxxxxxxxxxxxx] De la part de Boulay, Russ Envoy=E9=A0: March 6, 2006 8:48 AM =C0=A0: 'foxboro@xxxxxxxxxxxxx' Objet=A0: Re: [foxboro] Troubles with the Checkpointfile 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.=20 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=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 =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 =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