Why is Time treated as an ugly child in labview

[bdougr]

Why do we always have to do things to get time formatted correctly. I will pay extra to have some good time functions built into labview. I should be able to do math on a time string and DISPLAY time on the xaxis of a chart without jumping thru obscure hoops.

btw I am reading data from a database of temperature values and displaying them on a chart. Temperatures come into the database at irregular intervals.

AND put the timestamp variables somewhere where they can be found.....

TIME for Labview to make use of TIME (not seconds past midnight 1903)

[uscmagz]

*bahahaha...*

You know your entire life revolves around Friday, January 1, 1904 at 12am!

[shawn]

Hello,
Your comment made me take another look at LabVIEW time. I think there is definitely room for improvement. However, I don't think it is all that bad right now. I've attached a VI (LabVIEW 7.0) that shows some of the issues I think exist. If you (or anyone else) has more specific critiques of LabVIEW 7.0 time, I would welcome them.
Perhaps the biggest problem is learning how to use LabVIEW time (your example of not finding the Timestamp Controls/Timestamp constants is a good example of this). You can also send suggestions to National Instruments. Go to www.ni.com, click on Contact NI, then Product Feedback.
Shawn

[bdougr]

What I mean to say is the use of time is inconsistant. Trying to put time on the x-axis of a chart is terrifying. XY chart is pretty easy and intuitive. Measurement Studio and VB is intuitive.

The realtime.vi is a help but what happens when your data is coming in at irregular intervals. (40sec to 1hour++)

If you put a time format on a DSC realtime trend you will crash labview.

Doing math on a date should be as easy as VB. I shouldn't have to parse the string or figure out leap days.

btw I love Labview and use it for large data collection tasks. (over 1000 analog tags) Just getting frustrated doing simple things.

[rolfk]

bdougr wrote:
> What I mean to say is the use of time is inconsistant. Trying to put
> time on the x-axis of a chart is terrifying. XY chart is pretty easy
> and intuitive. Measurement Studio and VB is intuitive.

Charts and Waveforms assume constant delta T. Their time axis is defined
by a To start time and a delta T for each sample only.

> The realtime.vi is a help but what happens when your data is coming in
> at irregular intervals. (40sec to 1hour++)

If you have not a constant delta T for a data set then you do need to
use the XY graph. Your problem is probably the lack of a XY chart. This
is a long time request of many people, but it hasn't made it into
LabVIEW yet. There is an example though, showing you how to simulate an
XY chart wit
h an XY graph and a local buffer VI.

> Doing math on a date should be as easy as VB. I shouldn't have to
> parse the string or figure out leap days.

Well, basically you should never even try to deal with time in string
format. This is bound to fail sooner or later with different language
settings, localization, timezone, etc. The way LabVIEW does it with
internally using a fixed numeric value in UTC time format seems the most
intuitive and simple way to deal with such a complicated thing as time.

There is no problem in doing math on a LabVIEW time. As they are all
inherently absolute seconds to the reference date of 1. Jan 1904 or
relative times in seconds only. No idea how VB does it, but the way you
describe it it seems you feel "1. Jan 2004 - 3 day 56 min 34 sec" seems
intuitive. I wonder how this is gonna work when moved to other
plattforms with different localization settings.

Rolf Kalbermatter

[Greg_McKaskle2]

> What I mean to say is the use of time is inconsistant. Trying to put
> time on the x-axis of a chart is terrifying. XY chart is pretty easy
> and intuitive. Measurement Studio and VB is intuitive.
>
> The realtime.vi is a help but what happens when your data is coming in
> at irregular intervals. (40sec to 1hour++)
>

If you send waveforms to a chart, each waveform has a t0, and the
waveform can have one point or 1,000,000. So to get a variable time
chart that isn't completely XY -- won't do circles -- just send a
waveform with one point to the chart. This means every point is
timestamped and you probably will get what you want.

I believe this is what happens by default when using single point DAQ.

Greg McKaskle

[chutla]

Greetings:

You will find that in Labview, the squeaky wheel gets the grease! Until recently, EVENTS in Labview were treated as ugly children, now, the entire architecture of Labview is event driven. This change was brought about only because of vocal popular demand. I believe more input from users like you (and ME!) will eventually do for TIME what we've done for EVENTS.

Eric

[Greg_McKaskle2]

> You will find that in Labview, the squeaky wheel gets the grease!
> Until recently, EVENTS in Labview were treated as ugly children, now,
> the entire architecture of Labview is event driven. This change was
> brought about only because of vocal popular demand. I believe more
> input from users like you (and ME!) will eventually do for TIME what
> we've done for EVENTS.

While feedback is always welcome, just to be clear, I think stating that
the entire architecture is now based upon events is a bit much. In
fact, the marrying of events with dataflow was a bit tricky, and I'm
pretty happy with how it turned out, but LV is still very much a
dataflow environment. Events are there to help out with UI, and the
other sy
nchronization primitives that were already there are now
supplemented by user events. User events are pretty much notifiers that
feed into the event structure.

As for time, in LV7.1 I believe the timestamp is now a 128 bit integer
that measures on a much finer time resolution and for a much larger
scale. This should work well for HW timed measurements. Of course the
other time systems, including the ones the system and Excel use will
still be with us. If you or anyone else has more concrete suggestions,
please let us know about them, here or better yet in a suggestion form.

Greg McKaskle