Re: [foxboro] DST
- From: "Goldie, Shaun S" <Shaun.Goldie@xxxxxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 7 Sep 2007 14:01:24 +1200
Thanks for the response Russ
We are running FV10.1 and Aim AIM_AT_3.2.5.24 (QF1008915)
The Mesh is UTC=20
The Node is IATIME=20
AIM instance is on the node and the AIM* collectors have GMT parameter
set to +12 for the Aim* Collectors as per B0400EL page 57-58
When we move from winter time to summer time, we turn the DST flag on in
the aim* remote collectors and then restart the trend? Servers with
start_server STOP start_server FH.
What we have done to identify the problem is historize STATION.DAY HOUR
and MINUTE for a CP60 and a FCP270. My theory is pausing a trend of
STATION.HOUR the trend value and the time stamp should always agree, we
have found that after moving into summer time the mesh trends for the
winter time portion disagree with the time stamp being 1 hour less than
the trend, on the node side everything is fine. There is no problem with
the CP time change. It happens within the first minute of DST change
over.
We have also seen strange results depending on the duration of the
trend.
If the duration is say four hours the timeline on the trend looks
correct, but the timestamp at the top of the trend is an hour behind.
If the duration of the trend is short (10 minutes) then the timeline is
wrong for the winter time data, and so is the time at the top of the
trend.
I have 3 weeks to solve the problem but the northern hemisphere must be
approaching wintertime which is much more problematic especially for
FoxView users.
I am considering putting the mesh TZ to zero without DST but haven't
found a P91 version of set_mtk, using a DOS batch file to adjust the
windows time can take up to 10 minutes to propagate the CPs
Shaun
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Boulay, Russ
Sent: Friday, 7 September 2007 09:04
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] DST
Shaun,
What time constant are you using on the Mesh side. UTC or IATime ?
If you are using UTC then the paragraph below applies?
At V8.2 and above the combination of FoxView 10.1 on Mesh and AIM 3.2.4
on the node is required. On FoxView 10.1 when a trend is called it looks
at the system_time.cfg file and sees UTC or IATime in that file.
FV10.1 is then smart enough to make a UTC or IATime request to the AIM
3.2.4 historian. AIM 3.2.4 is the only current version of AIM that is
smart enough to answer that request. It will return the proper time
according to the request made.
What really surprises me is your node running GMT+12 ?
Legacy nodes are usually limited to GMT 0 unless something special has
been applied. =3D
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Goldie, Shaun S
Sent: Tuesday, September 04, 2007 9:47 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] DST
Hi List
We in New Zealand are moving to summer time at the end of the month
To make my job interesting we now have a mixed system 8.3 and Unix 6.5.4
Thrown in is a DST date change
My problem is I cannot seem to make the mesh side to time shift
correctly
8.3 P91 has the correct DST times and the windows applet is set to auto
adjust
Sys management is DST auto
Node is GMT
Aim historian is on the Node and set to time zone GMT+12
When the witching hour occurs (0200) the P91 sets the node time and CP
times forward to 0300 within a minute
A cron task stops the Aim servers turns on the DST Flags and restarts
the Aim servers
When looking at trend history a marker set at 0130 displays correctly on
the Node side but on the mesh its displayed at 0030
I don't know the relevance but our platform type has always been set to
NT even though the historian in on a Solaris machine
Shaun
=3D3D0A=3D3D0ANOTICE - This message and any attached files may contain
informatio=3D3D
n that is confidential and intended only for use by the intended
recipien=3D3D
t. If you are not the intended recipient or the person responsible for
de=3D3D
livering the message to the intended recipient, be advised that you have
=3D3D
received this message in error and that any dissemination, copying or
use=3D3D
of this message or attachment is strictly forbidden, as is the
disclosur=3D3D
e of the information therein. If you have received this message in error
=3D3D
please notify the sender immediately and delete the message.
=3D
=3D
_______________________________________________________________________
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
=3D
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
=3D
Confidentiality Notice:
This e-mail and any associated files are intended solely for the
individual=3D
or entity to whom they are addressed. Please do not copy it or use it
for =3D
any purposes, or disclose its contents to any other person. Further,
this e=3D
-mail and any associated files may be confidential and further may be
legal=3D
ly privileged. This email is from the Invensys Process Systems business
uni=3D
t of Invensys plc which is a company registered in England and Wales
with i=3D
ts registered office at Portland House, Bressenden Place, London, SW1E
5BF =3D
(Registered number 166023). For a list of European legal entities
within t=3D
he Invensys Process Systems business group, please click here
http://www.in=3D
vensys.com/legal/default.asp?top_nav_id=3D3D77&nav_id=3D3D80&prev_id=3D3D=
77.
If you have received this e-mail in error, you are on notice of its
status.=3D
Please notify us immediately by reply e-mail and then delete this
message =3D
from your system. Thank you for your co-operation. You may contact our
Help=3D
desk on +44 (0)20 7821 3859 / 2105 or email
inet.hqhelpdesk@xxxxxxxxxxxxx T=3D
his e-mail and any attachments thereto may be subject to the terms of
any a=3D
greements between Invensys (and/or its subsidiaries and affiliates) and
the=3D
recipient (and/or its subsidiaries and affiliates).
=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
=0A=0ANOTICE - This message and any attached files may contain informatio=
n that is confidential and intended only for use by the intended recipien=
t. If you are not the intended recipient or the person responsible for de=
livering the message to the intended recipient, be advised that you have =
received this message in error and that any dissemination, copying or use=
of this message or attachment is strictly forbidden, as is the disclosur=
e of the information therein. If you have received this message in error =
please notify the sender immediately and delete the message.
_______________________________________________________________________
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:
