It may sound prehistoric, but we're planning on hardwiring our critical vlves and pumps to solve this checkpoint issue, most of our vlves are fail to close, so the unexpected shutdown is not so much of a problem, the unpredictable checkpointfile reboot is much more of a problem. We need to be sure our critical equipment is in the desired default position, by pushing a hardwired button, before the system starts up again. We can then "unlock" the valves after the DCS settings are checked and adjusted. Cost is relitavely small compared to disaster recovery..... We're also still considering any good, clean DCS suggestion..... 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 patric.bonavetti@xxxxxxxxxxxxxx Sent: maandag 6 maart 2006 13:28 To: foxboro@xxxxxxxxxxxxx Subject: [foxboro] Troubles with the Checkpointfile 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=20 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=20 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"=20 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=20 the default values of the cio-config. (Workfile) Any ideas? Regards Patric =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