08-18-2009 02:47 PM
Well the time cluster is simply that, a cluster! There is nothing special about it that would tell LabVIEW that it does contain in fact a time and honestly I do not think there should be. One specially blessed cluster type (error cluster) is IMO already enough.
If you want to do time arithmetic you should use timestamps. LabVIEW knows that they are times and will work accordingly. Besides the logical result of a date/time subtraction is only a time difference, not another date/time.
Rolf Kalbermatter
08-19-2009 08:16 AM
08-19-2009 08:30 PM
At first, thanks a lot.
so much people give me help 🙂
bu I've try use National Instruments\LabVIEW 8.6\vi.lib\Waveform\TSOps.llb\Timestamp Subtract.vi
it not perfect.
08-20-2009 01:18 AM - edited 08-20-2009 01:23 AM
DFGray wrote:
If you want to subtract two timestamps and maintain the timestamp format, use <vi.lib>\Waveform\TSOps.llb\Timestamp Subtract.vi. This has been around since about LabVIEW 6.1 or 7.0.
You should not have mentioned that!
The reaction you see was sure to come like the night following every day.
And Boone, what do you expect when subtracting two absolute dates from each other? The date since the beginning of the worlds? your birthday? from the start of the christian calender? or rather some other arbitrary calender? The Maya calender comes to my mind as especially interesting.
The start date of LabVIEW time, which not uncoincidentially is also the old Macintosh start time, seems just as much a good point to me than any other, although I prefer to think of the difference of times in relative terms.
It seems to me you try to calculate a difference between two dates in terms of months, days, hours and seconds but that is a very tricky thing. For one, different months have different number of days so a simple subtraction will not work at all. So your original approach would be the closest you can hope for but you have to go through all members of the cluster and do proper carry forward for any negative numbers starting of course with the seconds. And then hope that you do not want to display years too, because then you get into a real mess to do proper carry forward from the months to the years if months happens to be negative.
Rolf Kalbermatter
08-20-2009 02:23 AM - edited 08-20-2009 02:24 AM
Hi Boone
For calculating differences in dates and time a good approach is Julian Day. It is kind of the same as LabVIEWs timekeeping, just a different starting point. Difference is that there are a lot of algorithms around for just what you are trying to do that works with Julian Day. I used this just need to implement them approach myself in C back in the day. Might be something to look into.
Best Regards
David
NISW
08-20-2009 02:51 AM
08-20-2009 09:01 AM
Let's go back to basics. Time is a measureable quantity which, like length, has a start point and an end point. The start point is often called the epoch. For LabVIEW timestamps, the epoch (start point) is midnight, January 1, 1904 GMT. For the Julian calendar, the epoch is about 2009 years ago at nominally the birth of Christ (0 A.D.). The LabVIEW timestamp is the time, in seconds, from its epoch (Jan 1, 1904) until the time it represents. Time is always measured in relation to another point in time.
What happens when you subtract timeA from timeB (assuming both have the same epoch)? You effectively move the epoch of timeB from its previous value to timeA. This does not change the instant in time that timeB represents, but it does change the value.
In your example above, one timestamp is subtracted from another. This changes the epoch. However, the LabVIEW timestamp control assumes the epoch is Jan 1, 1904, which causes it to display the date incorrectly. The value in the timestamp is correct, but the display is showing the wrong thing.
The timestamp display is based on technology created when the LabVIEW timestamp was represented by a U32, not the current signed 128-bit fixed point number. As such, it has indeterminate behavior when the timestamp is outside the values available to a U32. This is usually not a problem, since few people show dates before 1904 or after about 2036 (I forget the exact number). However, the timestamp itself is capable of representing time back to about the theoretical start of the universe. So if you are an archeologist plotting dates for T. rex during the Cretaceous, we have you covered. If you are a theoretical cosmologist, maybe not (change your epoch! 🙂 ).
So, the timestamp datatype will accurately give you differences. However, the control will not correctly display them (and it can't without knowing the epoch). The subtract primitive converts the output to a double for precisely this reason - to avoid confusion. An IEEE double usually has enough resolution (54 bits) to accurately represent the difference of two timestamps.
Let us know if you have any further questions.
08-20-2009 09:27 PM
Dear all,
Sorry for my direct, I don't want to read so much reason!
who can solve my question, as follow(I want to get how much time have passed):
TimeA-TimeB=TimeC
Remark:
TimeA:Now
TimeB: a time before now.
TimeC:How much have passed, this is I want to get.
Based Timestamp Subtract.vi, I improve it, but not perfect still as attachment.
Boone
08-20-2009 09:57 PM
Do you want to know the passage of time in Days, Hours, Minutes, Seconds, or the combination of all of them?
Do the subtraction and get seconds.
Then using quotient/Remainder, you can break it down to days, hours, minutes, and seconds.
08-21-2009 01:29 AM
Hi
Here's another example. You need to initialize the VI with a "Set" command and then you get the difference with "Get", see Main.vi for an example on how to use it. It gives you the difference in format HH:MM:SS or in seconds.
Best Regards
David