12-07-2010 06:10 PM
This VI crashes LV 2010 (with the saved default inputs).
The crash occurs at the To Timestamp primative.
LV 2010, Windows 7 32bit
12-07-2010 06:22 PM
12-07-2010 06:28 PM
I had written a pretty exhaustive routine to save a cluster of data within a TDMS file in LV2009. At some point I added the Timestamp, and for brevity's sake, changed all the data to EXT. Wasn't saving a lot of data, so the extra space wasn't a big deal.
At some point I discovered that when you write EXT data to the TDMS, there is a good chance the file will be corrupted as soon as it is closed (this took a while to figure out).
So I decided to split the TS into two DBLs and store it with the rest of the data in the TDMS. This works fine.
But at some point I made an error and passed incorrect data to the TS function, and I have spent the last 2 hours dealing with it!
12-07-2010 07:12 PM - edited 12-07-2010 07:13 PM
On a side note, you could simplify your code quite a bit, e.g. as follows, less pink!
(Of course it still crashes! :()
12-07-2010 11:46 PM
Nice! I forget about the imaginary functions; only had to code with them once!
12-08-2010 08:18 AM - edited 12-08-2010 08:19 AM
I believe the problem here lies in the typecast operator. An EXT is 80 bits in memory. A CDB or two DBLs is 128 bits. A timestamp is also 128 bits. So when you typecast 128 bits into 80 bits, you overwrite some memory you shouldn't and it crashes when you then try to use that section of memory. A simple To Time Stamp of an EXT does not crash. (of course, it should not ever crash, it simply should not work!).
I am somewhat confused why you did not use timestamps directly in your TDMS file. They are supported. It is also unclear from your writeup if you are using the DBLs as a convenient 64-bit container or they are actual DBLs. Conversion to a timestamp is relatively simple in either case.
If using as a 64-bit container, cluster them with the high word first, then typecast this cluster to a timestamp. If they are truly DBLs, the conversion will depend on what is in each one. If one contains seconds and the other fractional seconds, it is easy. Convert the one containing seconds to an I64. Multiple the fractional seconds one by 264, coerce to nearest integer, and convert to a U64. Cluster the two integers, I64, then U64, then typecast the cluster to a timestamp.
If you need more info, let us know.
12-08-2010 10:36 AM
I agree that the operations are questionable in general, but there are a few points:
12-08-2010 10:59 AM - edited 12-08-2010 11:01 AM
Correction: The 264 in my previous post should be 264.
I have submitted CAR #277392 on the problem.
Based on what I know at the moment, I believe the problem is in the typecast. I think its output is corrupted. However, I have not actually looked, so this is conjecture.
12-09-2010 04:59 PM
@DFGray wrote:
...
I am somewhat confused why you did not use timestamps directly in your TDMS file. They are supported. It is also unclear from your writeup if you are using the DBLs as a convenient 64-bit container or they are actual DBLs. Conversion to a timestamp is relatively simple in either case.
Thanks for the thoughtful comments.
This actually stems from another problem. I have an application that is in the early stages of design and doesn't generate that much data (.5-.25 Hz, 10 scalars per sample). So I am storing the data in a TDMS for convenience sake.
However, I need to make sure that all the values are saved atomically. So I converted them all to EXTs, arrayed them, and then saved them with one call.
The problem is that when I did this, the use of EXTs (to capture the Timestamp along with all the other DBL values) would corrupt the TDMS file when it was closed. Every time.
To fix this, I did the above cast to get 2 DBLs to append to the array of DBLs I wanted to store.
In the final version, I will probably use a datalog file (this is more appropriate for what I am doing).
12-10-2010 08:18 AM
Could you post a snippet of code you can post which shows this problem? This sounds like a bug and I would be happy to post another CAR on it for you.