Re: [foxboro] Clock to be advanced
- From: Corey R Clingo <corey.clingo@xxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Fri, 30 May 2008 09:45:34 -0500
We also move our clock twice a year to keep up with daylight savings time.
Going forward is the least painless move, as we don't have to stop the
I/A legacy historians we run, but in both cases we have to stop our Aspen
IP.21 data collector, change an environment variable in a script -- an
ugly Aspen hack to work around the ugly Foxboro
we-didn't-want-to-change-our-Venix-code-so-all-time-zones-are-UTC hack
that underpins timekeeping on an I/A system -- and restart the collector.
Sometimes it doesn't pick itself back up, so someone with Aspen PIMS admin
knowledge and access has to thump the collection on the server as well.
Otherwise, we do this with no ill effects, and since my mom wouldn't use
the clock on old Sun boxes as an egg timer it is so bad, we get the fringe
benefit of adjusting clock offset as well. Or maybe I'm just
rationalizing, since my DCS is the only remaining system I have that I
have to change the clock on twice a year :)
As for your APC, I agree with Mr. Ricker; that is application-dependent.
It may not like hitting 88 miles an hour in a flux-capacitor-equipped
DeLorean.
Corey Clingo
BASF Corporation
"Jones, Charles R. \(Chuck\)" <Chuck.Jones@xxxxxxxxxxxxxxx>
Sent by: foxboro-bounce@xxxxxxxxxxxxx
05/30/2008 08:31 AM
Please respond to
foxboro@xxxxxxxxxxxxx
To
<foxboro@xxxxxxxxxxxxx>
cc
Subject
Re: [foxboro] Clock to be advanced
"Please confirm that if we advance the master time keeper on our AW51D
(Boilers) and AW51E (CDU) time on APC PC, what impact will this have on
the performance of DCS and/or APC and what else should be done to avoid
any undesired effect on the systems"
Waseem,
We are a refinery and do not use any motion-controllers (robots) that
would be affected by a sudden time change. Your plant may be different.
We change our time twice a year--forward in the springtime and backward
in the autumn.
In our experience:
Moving the time forward an hour in the springtime does not affect our
process at all--other than the time change.
Moving the clock backward an hour in the autumn is difficult for our
historian, but again the process runs just fine. It always seems to
cause the historian (OSI/PI) to crash. So, we have adopted this
practice:=20
* shut down the historian
* change the time back an hour in the I/A system
* wait for an hour until the time is the same again
* restart the historian
Perhaps there is a better method, but for us, it is relatively painless.
OSI/PI runs on Windows, so it takes itself down (crashes) at random
times anyway.
Chuck Jones
Automation Technologist
Tate & Lyle
***************************************=
******************************
_______________________________________________________________________
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:
