Judging by you code and the results you reported I guess you are the other side of the world from me.
I just happened to have worked with a driver that was provided by Cincinati Sub-Zero as part of the LabVIEW driver that supports one of their temperature chambers.
As part of the driver they include a VI that does exactly what you want. CSZ does not support this driver, so do not call them for help. The sub-VI is included below.
The issues that are hitting you here are patially addressed in a memo posted to Info-LabVIEW by Rolf.
I include the same below.
Ben
"
"LewisDrake"
wrote:
>Another annoyance related to time changes is that the LabVIEW XY graphs,
>formatted to show Time & Date on the X axis, generate major tic marks that
>aren't synched to midnight local time. Instead, they place major tics at
>7:00pm (in the US Eastern time zone). Before the time shift, they showed
>major tics at 8:00 pm. Of course, they have always been off by the offset
>between GMT and the computer's location.
LabVIEWs internal time (seconds since January 1, 1904, midnight UTC) are UTC
based. All times displayed on a frontpanel however are in local time which is
dependant on the time zone set in the OS.
>I believe that the major tic locations are determined from midnight GMT
>rather than from midnight local time. To display properly, one must
>configure Windows to use GMT instead of local time and turn off automatic
>time adjustments.
If you want to have a graph set to Time & Data and display only the time to get
a nice 24 hours display for instance (relative time format has unfortunately
not the same formating features as the absolute time) you can easily get that
by setting the X axis offset to the appropriate offset of (24 * 3600 -
(timezone offset)). This is a one time thing when opening the graph window
and then the graph displays fine with 00:00 ......
There are utilities on the Info-LabVIEW site, I believe developed by Stepan
Riha, to get the actual UTC offset correctly calculated. It isn't really
difficult just a little bit diff calculation and proper 24 hours overflow
handling.
>I WISH NI WOULD FIX THIS.
Not so simple without causing many more problems for existing applications.
Also using UTC as internal time format is a good choice, it really is! And
displaying local time for absolute times is also what 99% of the users expect
to see, so a good choice too.
The only workable approach I see is either improve the formating capabilities
of the relative time display to allow similar display formats as in the
absolute time format and/or add an option to the absolute time format to
display UTC instead of local time. But above fix can solve the problem nicely.
Rolf Kalbermatter
CIT Engineering Nederland BV tel: +31 (070) 415 9190
Treubstraat 7H fax: +31 (070) 415 9191
2288 EG Rijswijk http://www.citengineering.com
Netherlands mailto:rolf.kalbermatter@citeng.com
"
