Promote Functions on Timing palatte

[JÞB]

The Timing palatte is looking bad with all thes gaps.  A simple fix would be to fill these holes with useful functions. I'm proposing 3 and attaching 2 from my re-use code. (I may re-create the third later)

Time to XL.vi (Attached): and its inverse, XL to Time.vi

12:00:00.0 AM Jan 0, 1900 is a pretty common epoch (Base Date) for external programs and converting from LabVIEW epoch shows up several times a year on the forums. and Time to excel has a few solutions to threads under its belt.   Moreover for analisys against external data from other enviornments you are often using Access, Excel, Lotus... All share the same epoch (and Leap year bug) in their date/time formats.  These vi.s have been pretty useful to me although the names may change to avoid (tm) infringements

Time to Time of Day.vi (Attached) has also been in my arsenal and proves both valuable and get on a few threads per year on the forum.

The gaps in the palatte make it a perfect fit

[wevanarsdale]

This is a neat idea.  I'd like to see your conversion VI extended to handle other epochs like POSIX (1970) and Windows (1601).  Specialized conversion VIs for GPS (1980) would also be useful.  I'd also like to see a standard method for handling leap seconds.

[JÞB]

Certainly Time to ? and ? to Time could very easilly be polymorphic with the epoch in the instance selector! I've never needed other than the XL conversion myself (or I would have them in my reuse lib) but your input is appreciated.  Perhaps a poll on most used epochs could be arranged?  The main advantage of the paired conversion is the ability to recover ZONE from an additional input since Excel's time format ignores zone.  I think the window time stamp contains zone as an element of the time.  so a true poly may not be possible.  Food for thought for the designer though!

[falkpl]

How about an express vi for converting to many different time formats, there are so many different reps of time, I have written several over my career.

I like this.

[JÞB]

falkpl wrote:

...I like this.

---

You missed the kudos button.

[vasgeo]

You are a genius, Jeff Brohrer!

I am a new user of Labview and I`ve been trying to do the opposite thing (XL to time), but obviously I have to read much more.

Would you please attach "Time to XL".vi to see where my mistakes are.

Thank you in advance.

Have a great day!

[JÞB]

Due to popular demand and a desire to fix some cosmetic issues, I upgraded the timing vi's to 2011 Silver and recreated XL to Time.vi.  All three are open for download in the code sharing repository here

[eximo]

Adding a error terminal to the time functions would be great too, that way we can tell exactly when certain pieces of code are executed without installing probes or flat sequences.

Also adding an additional input and output on the tick count counter would most useful.  The input would be received from another tick counter, the out additional output would be the difference.  Giving you the number of seconds or milliseconds in between tick counters.

 I created my own vi to handle this called tic toc, which is useful with loops using shift registers.  Also useful for monitoring the length of time it takes to execute a vi or piece of code.

[Brandyn]

This is a neat idea.  Is there an OpenG timing pallete?

[NI-hilator]

Thanks Jeff

[muks]

Late on this but a good idea...