LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Feedback Request: Living Known Issues Document


Roy F wrote:

Just realized we hadn't answered your questions.  

AE - an acronym for Applications Engineer. When you call or email support, you will be connected to an AE. 

 

Support - Go to ni.com and click on Support or just enter ni.com/support. When you request support, a Service Request (SR) is created to track handling of the support.

 

CAR - Corrective Action Request, the name we use for our bug tracking software and for bugs filed in that application. We'll say things like "I'll CAR it" - means to file a bug. "I CARed it" - a bug was filed. CAR ID - the number we use to identify a bug.

Roy


Thanks for the info. I will post my wish to solve the bug "Digital Display Legend Doesn't Adjust for Number of Plots in Executable" (37476  44H8J3ZP) in the next version and why this is important for me.

 

Thanks

Marc

CLD
0 Kudos
Message 51 of 64
(1,924 Views)

My team was using LV 2009 SP1 and we encoutered the crash described in the following thread :

http://forums.ni.com/t5/LabVIEW/LabVIEW-Run-Time-Crash-2009-lvrt-dll/td-p/1466440

 

The thread mentions that the crash was fixed in the lvrt 2009 SP1f1 release, but this is not clearly stated in the list of the bug fixed in this version, nor, as far as I know, reported as a LabVIEW 2009 and 2009 SP1 Known Issues.

 

Can you tell me if you are aware of it, and if so, if I got it wrong and that there is actually a Known Issue that corresponds to this crash anomaly ?

And if this is the case, also tell me if it was actualy fixed in the SP1f1 release ?

 

On our side we have decided to use the latest release, lvrt 2009 SP1f3, and so far the crash has not shown up anymore.

 

Regards,

Philippe LOVERA

0 Kudos
Message 52 of 64
(1,594 Views)

Hi Philippe,

 

I suspect the CAR at issue is:

#220887 - Calling LabVIEW 2009 built DLLs in previous versions of LabVIEW can cause a crash

 

As it's the only CAR that appears to result in a LabVIEW RTE crash. It is documented in the LabVIEW 2009 Known Issues List and the LabVIEW 2010 Bug Fix List. Only the CAR's documented here were fixed in the f1 patch, so if your issue doesn't match these, it may have been a different fix.

 

I hope this helps,

Fred Visser -- SystemLink R&D -- National Instruments
0 Kudos
Message 53 of 64
(1,582 Views)

Hi Fred,

 

What I would like to ensure is that indeed that CAR is linked to the crash mentioned in the thread I put in reference in my first post.

Apparently it has more to do with Listboxes than DLL calls, but there might be a link between the two issues that I do not see.

 

Regards,

 

Philippe Lovera

0 Kudos
Message 54 of 64
(1,562 Views)

Hi Philippe,

 

The listbox issue is documented with CAR #214421, and is fixed in LabVIEW 2009 SP1 f3 patch. It wasn't addressed in any of the earlier fixes, including the LabVIEW 2009 SP1 f1 patch.

You should be good to go!

Thanks,

Fred Visser -- SystemLink R&D -- National Instruments
Message 55 of 64
(1,531 Views)

Many thanks Fred,

 

That should answer my question.

 

Best regards,

 

Philippe

0 Kudos
Message 56 of 64
(1,508 Views)

Under "Functions, VIs, and Express VIs" is issue 381656, "Adding or subtracting timestamps causes a conversion to double and precision loss."  

 

The reply said,
"Workaround: Cast the timestamps to clusters of U64 'seconds since epoch' and I64 'fractions of a second' before the operation and then cast back to timestamp after the operation"


This is wrong. The U64 and I64 are backwards.  Based on various NI support documents, this is my understanding of Time Stamps:

 

The Time Stamp is a 128-bit fixed-point number with a 64-bit radix. LabVIEW stores a Time Stamp as a cluster of
four [32-bit] integers where the first two integers (64 bits) represent the signed number of whole seconds after
(or before) the Epoch, which is 12:00 a.m., Friday, January 1, 1904, Universal Time [01-01-1904 00:00:00]. 
The next two integers (64 bits) represent the unsigned fractions of seconds.  (So it's basically I64 + U64/2^64)

 

5.2 seconds before the Epoch is
12/31/1903 23:59:54.800 UTC = 0xFFFFFFFFFFFFFFFA.CCCCCCCCCCCCCCCD  =  -6 + 0.8

This is why it works to add or subtract time stamps as clusters; you work with the whole and fractional parts separately, then combine them with Add or Subtract like this VI does:

 

 

You can compare the perfectly-precise clusters with the not-so-perfect DBL conversions.  As long as you don't have the two time stamps on opposite sides of the Epoch, DBL should be quite adequate.

 

I find this interesting but moot, because conversion to double still gives you a time resolution of better than a microsecond.  Furthermore, I believe this is more than 3 orders of magnitude better than LabVIEW delivers with Windows 7, where the actual time resolution in a running VI is apparently only 1 ms.  At least working with Time Stamps converted to DBL doesn't have the potential problem of wrapping around like the millisecond timer can.

 

Jon Frost

0 Kudos
Message 57 of 64
(1,287 Views)

Guess I have to attach the VI...

 

Jon

 

Download All
0 Kudos
Message 58 of 64
(1,281 Views)

Hey Jon,

 

Thanks for the feedback! I've fixed the error in our internal known issues database, and will update the external page in the next few days. 

 

You're absolutely correct; the discrepency is minor, and people are used to dealing with the inherent imprecision of floating point numbers. However, the timestamp format was designed so people could be very, very precise with timing, so we wanted to document this issue.

 

Thanks again!

 

Fred Visser -- SystemLink R&D -- National Instruments
0 Kudos
Message 59 of 64
(1,252 Views)

I have attached an updated version of PrecisionDateArithmetic.vi;

 

Now the time stamp displays are all set to 24-hr UTC, demonstrating that after conversion to DBL, the math gives the same results. In my earlier post, I thought that there was a DBL conversion problem for dates before the Epoch, but I was mistaken. My misconfigured time stamp displays led to that conclusion.

 

Sorry for any confusion,
Jon

0 Kudos
Message 60 of 64
(1,217 Views)