DBL time indicator displays time in strange format

[Fascinated by Electronics]

Hey all,

I have one small, but annoying issue with one of my VIs.... Basically, some indicators for the waveform statistics express vi (the vi that gives you the max, time of max, etc for dynamic signals that you wire into it) display time in a format that I can't make any sense of......... All of the settings for those numeric indicators from a previous, but very similar version of the vi were exactly the same and I confirmed such after I started getting annoyed by it...... The format we desire was already set in the indicator's configuration dialog - numeric, automatic formatting, 6 digits, significant digits, hide trailing zeros, etc.... However, what we get for a display: time of Max is: 3.354339E+9    !!!!!!!!!   3 Billion seconds......... I back calculated and it seems like this is the amount of seconds that have elapsed since 1910 AD .............. I am not sure what is causing our time of max indicator to display time in this manner..... It doesn't change run to run, sample to sample, it is always that number..... Even though I scrutinized the code exactly between the in development and the previous VI version.......

I tried changing the configuration settings to floating point, 6 digits, significant, hide zeros, etc.... but no dice, all it did was make that displayed number in long format: 3343454345 or whatever it was...... I don't understand this.....

Notes: I have LV 2009 with SP1 The previous VI version that worked was originally made on 8.6 and converted over to 9.0 SP 1.

If anyone has any ideas, I am all ears....

Thanks

[DianeS]

It's hard to say exactly, since I can't see your code, but if you look at the "help" for LabVIEW's "Get Date/Time in Seconds" function, you will note that LabVIEW calculates the current date/time as the number of seconds elapsed since 12:00am Friday, January 1, 1904.

You can use the "To DBL" conversion function (found on the "Numeric" palette) to convert the time stamp to a floating-point number.  That will return a very large number -- specifically, the number of seconds elapsed since 12:00am Friday, January 1, 1904.  Sound like what you're seeing?

Changing the decimal point precision of your indicator isn't going to have any effect on the number of seconds displayed, for obvious reasons.  Trying to represent the number with a width of 6 digits isn't going to have any effect either.

So, without seeing your code, I'd have to guess that you are converting the timestamp that you are obtaining to a DBL, and then displaying that number. 

I know this might not solve your problem, but hopefully it gives you somewhere to begin looking.  I never use Express VIs, so I can't tell you what might be going on in yours.

Message Edited by DianeS on 04-07-2010 03:28 PM

[Fascinated by Electronics]

DianeS,

I have attached images of part of the old and new VI that may help someone solve this issue....

• In "Load curve parameters old VI", please see the code section starting where the startup current spike is cut from the signal. From there, the signals (which are raw, 1st LP filtered, 2nd LP filtered) pass into the Statistics VI where the Max, 1st time, Last time, time of max are found.... Those signals then go up to the case structure corresponding with each individual sample load. The signals for Max and Time of Max go to their respective cursor inputs and numeric indicators for them are in the case structure...
• In "Numeric indicator config dialog old VI, the dialog box options that set how to display the time of max, load time, etc are shown. Notice that it is auto formatting, 6 digits, etc... In the VI under development, the options for those exact same indicators are set exactly the same.....
• In "New VI front panel" notice the motor current trace and the indicators on the right.... The ones that are most important are the larger, blue font ones... (the smaller ones are just used to sanity check the values that the blue ones are showing)... Notice how Time of Max Load Torque 1 and Time of Max Return Torque 1 are exactly the same and are that huge large number (which is in floating point format b/c I tried changing some options during troubleshooting, but either way you get the point)...........   3353510000 ...........  The previous VI did its job well and even though it only captured the first peak (not including the inrush spike), it would have indicated the time of max for that peak to be about 0.112 seconds or so..... In other words, the time of max was referenced to the start of the signal trace.... not referenced to some absolute time....

Hopefully these pics help you help me... 😉

[DianeS]

It is much more helpful if you'd post your actual VI, but I'll try to go with what I have.

You say that the original VI "would have" indicated the time of the max was 0.112sec, and that it "would have" given you relative time instead of absolute time.  How do you know that?  Have you confirmed it?  If not, please confirm it before making that statement, because I am pretty sure that you are wrong.  Here's why I say so:

I found the Express VI you are using to obtain your "time of max", and opened its front panel so I could see what was going on inside.  I recommend you do the same.  (One of the reasons I never use Express VIs is they allow you to skip understanding of your own program, which is not a terrific thing in my opinion, and that seems to be the case here.  You don't understand what's going in inside your program and how things are working.)  Anyway, if you did, you would find that inside the Express VI, the "time of max" is obtained from your collected waveform's timestamp for that point, using the "Waveform Min Max" VI, and then converted to a DBL precision number.  The same thing is done for "time of min".

Now.  Here's what happens when you collect data as a waveform using, say, a DAQ board.  (I am going to guess here that you're using an Express VI to collect your data, so this is an accurate description of what you are doing.)  The waveform datatype contains timing data, as you probably know.  Specifically, it contains a time stamp, in absolute time, for each point.  The initial time stamp for that collected data is the current time.  Subsequent time stamps for subsequent points are also in absolute time.  So, let's say I started collecting data right now -- my initial timestamp is today's date and time (4:50:34, April 7, 2010).  Let's say I collected my next point 1sec from now.  The timestamp for that point would be 4:50:35, April 7, 2010.

Note that each point's time stamp is in absolute time, NOT relative time.

Therefore, the Express VI, which takes those time stamps for the relevant points and converts them to DBL representation, is giving you "time of max" as an absolute time.  Not as a relative time.  Thus, the number you are seeing for that parameter makes perfect sense.

If the relative time is about 0.112 sec, and the output of the Express VI is in fact an absolute time in seconds, then of course the time given for the two times would be identical since the resolution is only 1sec.

I've attached a small VI which collects a waveform from a DAQ card, then uses the same function used by your Express VI to obtain the "time of minimum" and the "time of maximum" to obtain the min and max times.  Then I convert the "time of maximum" to a DBL, as your Express VI does.  My little program is a simplified, but accurate, representation of that part of your code.

d

[Fascinated by Electronics]

Diane,

Thanks for your help in explaining and clarifying things concering time and how it is handled in LabView. I am still perplexed because of the following thing - The original VI worked perfectly well for what we intended back in the R&D stage, but lacked the power and some features that are now needed.

Therefore, the original VI (which the code snippets I posted come from) was the basis for the current VI being developed. This newer VI is more streamlined, has more powerful features and is easier to understand for non-labview folks.... However, I am still totally perplexed about this issue because as I showed you, was exactly how it was coded in the original VI... That original VI helped us collect thousands of data files for numerous sample loading runs........ In fact, that code section containing the extract signals, statistics, and the case structures for displaying the waveform graphs and indicators has changed very little going from the old VI to the new one.......

A few things which come to mind are:

• The old VI was made with LV 8.6 and converted (opened with LV 2009 SP1 and then saved) to LV 2009 SP1
• Something might have gone wrong in the upgrade to SP1 for LV 2009
• There might be something wrong with my computer's internal clock - if that is what the DAQ references for "current time"

I will see what I can do in terms of posting our VI up here... I want to make sure it won't violate any company policies....... If I can post it, I will post the old VI and if all goes well, it should work exactly as it has for us in the past.... The other thing is, I will have the original designer of the program, our LV guru take a look at it.... I am just a guru in the making and am still far from that goal!

[DianeS]

When you say the new VI "changed very little" from the old VI, that still implies that there were some changes made.  Can you tell me what the changes were?  Were they in the analysis, or the data collection?  Or both?

You say that the picture you posted (not a snippet, they're different) was of the old VI's block diagram.  Can you post a picture of the old VI's front panel instead of the new VI's front panel? 

Your old VI could not have given the "time of max" as 0.112sec...because, as I mentioned before, the resolution of time when represented by a DBL is 1sec.  So, what value did the old VI give you for "time of max"?

As a side note, you'll attain "guru" status a lot faster if you stop using Express VIs... 

d

[Fascinated by Electronics]

Diane,

Thanks for your help so far. I have posted a pic of the old VI's front panel graphs after a run of 3 samples. As you can see, the Time of Max Torques are correctly displayed and are correct relative to the start of the plot traces...

i think I may have found the reason why my times are displayed in the format that they are. Please try to follow me (even though it may be difficult without having the full vi or even a pic of it):

• In the old VI, we were only interested in capturing the first peak after the inrush current spike.. Therefore a simple use of extract signals at 0.05 X offset and remaining samples setting got us our result. The extracted signal would be fed into the statistics express vi where the values of the peak's Max, the time of Max, the 1st time and the last time were found... THEN, The time of Max and the first time went into a Calculator!!!  The calculation that was performed to find the time of that peak relative to time 0 was easy - TimeOfMax - (1st time + 0.05)        0.05 is the offset from the extract signals vi..... SINCE a subtraction was performed, it doesn't matter what format the time was in (it could be that crazy 3.3E9 format), the value returned was the difference between those two huge values and thus was very small...........
• Our current VI has to capture both peaks after the inrush spike and therefore we couldnt simply use another extract signals at an X offset past the first spike... because those curves may change drastically depending on which motors are used, which sample types are loaded, etc... the newer VI used a more advanced form of peak detection and then windowing of the 100 Hz Lowpass filtered signal to find the data better than the older VI. As a result, there is NO Subtraction that is performed when going from the Time of Max output of the Statistics VI to the time of Max indicator and its respective cursor input in the node......  So therefore Diane, you were right - I didn't notice that subtle difference between the code in the two VIs until this morning........ We don't need an extract signals vi prior to the input of the statistics vi because I used some lower level, but more powerful peak detection coding that can account for those two peaks not matter where they occur - i.e. we don't have to guesstimate an X axis offset location to tell the program where to find each peak

Anyway, I am 99% there for the solution. Thanks so much for your help!

[DianeS]

I'm glad I was able to point you in the right direction, and thanks for posting back and letting me know you'd found the problem (or, in this case, the calculator).  Good job!  Off you go to finish your app now, and to continue in the direction of guruhood! 

d