Re: [foxboro] How to keep accurate time

  • From: "Boulay, Russ" <Russ.Boulay@xxxxxxxxxxxx>
  • To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
  • Date: Tue, 26 Feb 2013 09:23:04 -0500

How that works.....with FoxView and AIM..

If Auto Adjust is unchecked.....FoxView will display the first set of data 
collected.
If Auto Adjust Box is checked....FoxView will display the second set of data 
collected.


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On 
Behalf Of Terry Doucet
Sent: Tuesday, February 26, 2013 6:17 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] How to keep accurate time

When local time"Falls back" and you have 2 sets of data time stamped between 
02h00 and 03h00, the first set for xST and the second set for xDT, how do you 
display that on a trend?  
I'm not sure I'd want to pay some team to write that code for a once a year 
event.  The Spring flat line is easy, nothing happened between 02h00 and 03h00.
Terry

> From: stan.brown@xxxxxxxxxxxxxxxxx
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] How to keep accurate time
> Date: Tue, 26 Feb 2013 12:48:49 +0000
> 
> Actually I think the correct way to do this is a lot like *NIX deals with 
> this from the user interface point of view. The system clock is set to UTC. 
> When I log on, I set (automatically) an environment variable that tells the 
> system what time zone I am in, and it presents the data in a format corrected 
> for my view of the world. Thus if I am logged onto a computer physically 
> located on the West coast of the US, and I am physically on the East coast, I 
> see the time as the format I expect (locally).
> 
> The only issue with this has to do with historical data, and the 
> continuing meddling with DST start/end dates by the politicians. The 
> system does have a file /etc/tztab that tells it what the current 
> value of these change dates is, but (currently) the format of that 
> file does not allow for a start and end date of the effective time of 
> the start end dates of the DST change. Guess we will have to enhance 
> the software to compensate for the politicians :-)
> 
> 
> > -----Original Message-----
> > From: Stan Brown [mailto:stanb@xxxxxxxxx] On Behalf Of Ken Heywood
> > Sent: Tuesday, February 26, 2013 7:37 AM
> > To: foxboro@xxxxxxxxxxxxx
> > Subject: Re: [foxboro] How to keep accurate time
> >
> > This is just an observation for what it's worth:
> >  <rant>
> > For 50 some years the process industry has used computers to 
> > control/gather process data. In that 50 years, nobody has figured 
> > out that you just don't grab just the time/date to index a piece of 
> > data for archiving. You also need to record the time zone. The issue 
> > has always been how to store the process value for 2am EST or EDT 
> > around the time change. The answer has always been you can't. Each 
> > time slot is unique in that time change interval. If you record only 
> > time/date, the computer (and human) gets confused. Sure, your 
> > historian must store an extra byte for each value to account for 2 
> > hours of data slots each year. But the logic will work every time 
> > instead of crashing the software once or twice a year in the wee 
> > hours. And you'll have a side- effect, because you store TZ, you'd 
> > be able to synchronize events worldwide across databases.
> > </rant>
> >
> >
> > Thank You,
> > Ken Heywood
> > Calibration Laboratory Manager
> >
> > PROCESS CONTROL SERVICES, INC.
> > Established in 1983
> >
> > http://www.processcontrolservices.com
> >
> > mailto:KHeywood@xxxxxxxxxxxxxxxxxxxxxxxxxx
> > Telephone: 734-453-0620
> > Wireless: 508-241-2040
> >
> > ===============================================
> >
> > -----Original Message-----
> > From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro- 
> > bounce@xxxxxxxxxxxxx] On Behalf Of Dirk Pauwels
> > Sent: Tuesday, February 26, 2013 3:28 AM
> > To: foxboro@xxxxxxxxxxxxx
> > Subject: Re: [foxboro] How to keep accurate time
> >
> > Philip,
> >
> > We've had this kind of problems also on 6.3, 8.4 etc....
> > When the clock is turned back an hour, PI lists stop collecting data.
> > Strange thing is that the PI server is time synched by NTP because 
> > it's an ADMIN server, not a DCS server. It hasn't got a problem with 
> > it being at 7pm and the DCS timekeeper being at 8pm, |(errors but no 
> > crash), but as soon as the master timekeeper DCS is changed to 7pm, 
> > PI crashes. I usually stop PI and INbatch to change the time 
> > manually if we have to turn the clock back. Forward is no problem, 
> > this can be done online.
> > We had the same problem with our former I/Abatch, (replaced by 
> > InBatch ),  it needed to be stopped when we wanted to turn the clock 
> > back 1 hour. We had plenty of problems when DST on the DCS 
> > timekeeper was in AUTO. (the way this setting is presented in the 
> > system manager is very confusing). Batches blocked, PI crashed etc....
> >
> >
> > Rgds,
> >
> > Dirk
> >
> >
> >
> >
> > ____________________________________________________________________
> > ___ 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
> >
> 
> 
> ________________________________
> 
> The information contained in this message and any attached files may be 
> privileged and/or confidential and protected from disclosure. If you are not 
> the intended recipient, any disclosure, copying, distribution or use of any 
> of the information contained in or attached to this transmission is strictly 
> prohibited. If you have received this transmission in error, please so notify 
> the sender immediately without reading it. Also, please promptly destroy the 
> original transmission and its attachments. Any views or opinions presented in 
> this message or attachments are those of the author and do not necessarily 
> represent those of KapStone Paper and Packaging Corporation or its 
> subsidiaries.
>  
>  
> ______________________________________________________________________
> _ 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
 


*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its 
contents to any other person. This email comes from a division of the Invensys 
Group, owned by Invensys plc, which is a company registered in England and 
Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 
7AW (Registered number 166023). For a list of European legal entities within 
the Invensys Group, please select the Legal Entities link at invensys.com.


You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail 
reception@xxxxxxxxxxxx. This e-mail and any attachments thereto may be subject 
to the terms of any agreements between Invensys (and/or its subsidiaries and 
affiliates) and the recipient (and/or its subsidiaries and affiliates).


 
 
_______________________________________________________________________
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:

  1. Home
  2. foxboro
  3. Archive
  4. 02-2013