incorrect time stamps in Empower

Katarzyna
Katarzyna
in Software Products
<p class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-size: 12pt; color: #000000; font-family: Calibri;">Hi All, </span></p><p class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-size: 12pt; color: #000000; font-family: Calibri;">I have a question: How are time stamps assigned in Empower?</span></p><p class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-size: 12pt; color: #000000; font-family: Calibri;">We are running empower 1 enterprise system. It happened recently on few occasions that Empower clearly assigned incorrect time stamp to acquired injections. It happened on the acquisition on the new LACE (came in month ago, the type with lots of Ethernet connections, but no bus/Lace card). We fitted the bus LACE card in and connected LC to it. So it happens it is one of the oldest alliances we have (probably around 9 years old, but on firmware version 2.04). </span></p><p class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-size: 12pt; color: #000000; font-family: Calibri;">Two sample sets were queued in. One went perfectly fine and finished at around 23.30. The other was running straight after and started at 19.09 according to the software! It is impossible because the system was acquiring the first run at 19.09 hours. It was running five injections counting form 19.09 and realised on the sixth one that it really should be at 03.30, counted form 23.30 (the end of first sample set). </span></p><p class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-size: 12pt; color: #000000; font-family: Calibri;">Has anybody seen anything like that and has an idea what caused it? </span></p><p class="MsoNormal" style="margin: 0cm 0cm 10pt;"></p><p class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-size: 12pt; color: #000000; font-family: Calibri;">Many thanks</span></p><p class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="font-size: 12pt; color: #000000; font-family: Calibri;">Kate</span></p>

Comments

  • FlaskJockey
    FlaskJockey

    Hi Kate

    Is your server and LACE on a different time zone?

    Thanks

    Si

  • Katarzyna
    Katarzyna

    Hi Si

    apparently it was. We later checked the times on LACE nad it was 5 hous behind. So when it lost connection to the server it got the tame stamp form the LACE. Whn it was reconnectedc it again got the timwe form the server. The LACE is still under observation, because IT are convinced they changed it to GMT, which is the time zone for us. So it shouldn't be really reading american time.

    Kate

  • FlaskJockey
    FlaskJockey

    Hi Kate

    Perhaps someone from Waters can comment on this but I seem to recall when moving to Empower 2 years ago, we set our LACEs to GMT and the server to EST (as it is based in the US).  This caused us problems with Agilent 1100s.  It can cause an instrument failure if the time difference between client and server is greater than (I think) 1 hour.  Not sure if this has been sorted in recent ICOP/Feature Release updates but we still do this today as it is embedded within our SOPs.

    Thanks

    Si

  • Katarzyna
    Katarzyna

    That's interesting

    Thank you

  • Dot
    Dot

    Hello Kate,

    The responses have all been excellent and good suggestions but maybe we can offer some things to check.

    There is a technical note that describes how timestamps are assigned.  It is TECN1852729 “Origin of date and timestamps in a client/server environment”.  I have provided a link to the document for you so you do not need to search.

    http://www.waters.com/waters/support.htm?lid=1852729&type=TECN

    This might be helpful in understanding the timestamps and their creation.

    After reading the description you have provided here a few suggestions that might be helpful.

    1. Connect to the Lac/e32 and remotely login, go to the Control Panel/Regional and Language Options applet.  Select the Regional Options tab and insure the settings are correct as well as the time.
    2. Check the recover.log file on the Lac/e32 at or before the date/time of the occurrence. It is possible that the Lac/e32 went into buffering mode if the database was not available and then reconnected to the database.  This would be normal.   Technical note TECH10007994  “Factors that may contribute to frequent buffering”  writes about buffering in an environment.  http://www.waters.com/waters/support.htm?lid=10007994&type=TECN
    3. Technical notes refer to a Time Zone update.  You might have already performed this update in your environment.  However, if not perhaps, they would be good to review to see if they are applicable.   TECN10008076 “Empower Build 1154 and Empower 2 Build 2154 support for Daylight Savings Time”http://www.waters.com/waters/support.htm?lid=10008076&type=TECN  TECN1851664 “Daylight Saving Time changes and Empower Build 1154”  http://www.waters.com/waters/support.htm?lid=1851664&type=TECN  TECN1852458  “Testing complete for Daylight Saving Time Hotfix from Microsoft” http://www.waters.com/waters/support.htm?lid=1852458&type=TECN .

    Before making any changes or applying updates check your company SOP and insure you have a good backup.

    I hope this is helpful.

    Dot

  • Katarzyna
    Katarzyna

    Thanks Dot,

    very helpful

    Cheers

    Kate

Categories