LabVIEW
Does the Runtime engine store crash logs anywhere?
@mcduff wrote:
Somewhere on VIPM, maybe from @hooovahh, there is a function that can look for bad sectors on a TDMS file.
I do not know of anything like this. But it should be possible to make one when looking at the TDMS file structure. It will have things like offsets and lengths of the data to read. If those line up maybe the TDMS file is fine? Then again you might have data, but not be able to convert it to the data type you expect. Most of the times I know a TDMS file is corrupted because either the TDMS Open will tell me (with an error) the Defrag will generate and error, or I will read some channel and the Read will return an error. Of course for this one you'd need to read all values from all channels to know something isn't wrong or missing.
I have seen plenty of examples of the index file causing problems, and deleting it, then making a new one fixed the issue. If the data files are small I try to not have an index get created. And when transferring data from RT to the host I don't bring along the index file. This will mean a longer Open on the first time without it.
It doesn't sound like what you're describing. I use the TDMS files to store Actor data. When an Actor runs its test, it keeps its data in memory until the user exports a TDMS file containing all of the tests. Importing the TDMS file launches new Actors that get populated with this old data. All of that works fine.
The issue is that, if I load up some certain old test data, I can read it and look at it just fine- until I open a NEW Actor, which doesn't interact with the TDMS file in any way. There could be some dangling reference to the TDMS file that, when left hanging, will crash somehow, but that seems unlikely. Or perhaps there's a memory leak when the TDMS Read happens, but it doesn't get "noticed" until the new Actor launches.
@Hooovahh wrote:
@mcduff wrote:
Somewhere on VIPM, maybe from @hooovahh, there is a function that can look for bad sectors on a TDMS file.
I do not know of anything like this. But it should be possible to make one when looking at the TDMS file structure. It will have things like offsets and lengths of the data to read. If those line up maybe the TDMS file is fine?
Your Tremendous TDMS package has a VI called "Split Corrupted TDMS" that calls (as best as I can tell) the same algorithm from that thread. I think that's what mcduff was talking about.
At any rate, running either the linked "LocateCorruptedSgmt" vi and the "Split Corrupted TDMS" from Hooovahh's Tremendous TDMS package doesn't indicate there's any corruption, as far as I can tell. (The "Corrupted Segment" is always the same as the number of segments in the file, and "Segment Offsets Correct?" is True on any of the files I run.
It looks like that code will open up the TDMS in larger, and larger segments, then if an error occurs, you will know that the file after that segment is corrupt. This won't find all forms of corruption but probably most. I have seen a TDMS file that would open just fine, and would read all data from most channels. But some channels couldn't read all the data. This type of corruption is probably harder to detect since it would require you read all data from all channels one at a time.
Yes part of that code is in my toolkit, and probably deserves some more attention.
Unfortunately, the tool doesn't detect any issues.
At any rate, I would think the crash would happen on TDMS Read, which is definitely not the case. I do call a TDMS Read just after launching a new Actor, but it gets an empty path so it just throws error 118 (which gets filtered out) and moves on. Each Actor has a TDMS path in its private data that gets populated during a Load, but it's empty when I launch a new one. That's how my launcher knows if it's launching a new fresh test or if it's showing the results of a locked older test.
I use a class block diagram constant to initialize the new Actor (my factory pattern uses a Map of names and constants) so even if the Actor is reusing memory space, the private data should be reset since it's reading from a BD constant with an empty default value. And even if I'm mistaken there, it would get an old (yet still valid) file path when it tried to read, and I know for a fact that the Read process gives me valid data. Again it could be doing something else that only gets picked up later on, but that seems less likely.
