How Do I Convert LV7.1 Datalog Files to LV8 Format?

[Larry_Stanos]

Travis,

Well I could have sworn that I had disconnected Record ID from its typedef as well, but it was in fact still linked.  The new version of the files contains the correction and should avoid the crashes you experienced with the previous version.  Rest assured that all of my sub-control typedefs have remained stable over time, otherwise I would have experienced problems with reading the databases in LabVIEW version 7.1 as well.  I disconnected the typdef links in the test file simply to reduce file clutter.

Yes, the reason I have to typecast the refnum returned by Open Datalog with Timeout to a cluster record file refnum is precisely because, as you stated, datalog files are written with cluster records and not variants.  The cluster records in this case, however, are not fixed in size (Table Measurements.Values array sizes vary) so I doubt that LabVIEW uses the file size to determine the number of records.  I think it must keep the number of records in the file header info or count the number of record delimiters in the file.  Regardless, I've never seen Get Number of Records.vi (inside Open Datalog with Timeout) return the wrong number of records.

Disconnecting the variant control terminal on Open Datalog with Timeout did not appear to change the error 116 error rate (~88%) so I suppose it is true that it is not needed if I'm going to typecast the file refnum anyway.

Larry

[Travis_M.]

Hello Larry,

I think your right about the file size (sorry about any confusion).  I noticed the behavior too -- though I had to remove a couple of error handling VIs from the "open with timeout" VI.  However, I have a real big question with how these datalog files were written.  It was my intention to check whether the datalog file was written with exactly the same format as the read record indicator, so I removed the typecast, I removed the “open with timout” and replaced it with a direct Open Datalog file VI.  Then set out to find the correct datatype to wire to the “record type” parameter of the open VI.  I believe that the record type of the datalog file type should match the output of the read datalog record _exactly_, so I merely created a constant from this indicator and wired that to the type terminal in the open VI.  No dice – error saying that the datalog file type doesn’t match the input.  I tried the input to the VI named “Measurement File Record” as well as the cluster constant inside of what used to be the datalog file refnum constant – also with no success.  If I converted any of these to variant before opening the file, I had to first remove the indicator from the “read” VI (no typecast anymore).  When running like this I got a dialogue asking if I wish to convert the datalog file to the current version.  I say yes – error 116.  I think you have described this behavior before as well.  So, long story short – I gather that you were writing each datalog entry as a variant - of cluster - of custom controls – containing variable sized arrays.  If you were writing it as a variant, I don’t see why you were able to cast it back to a cluster with any reliability.  If you weren’t writing at as a variant I don’t see any reason (other than a type mismatch) as to why the file wouldn’t open with the record from the read VI.  I haven’t reproduced this on a small-scale yet, but I’ll give it my best (see below)!

So from here, I am going to try to replicate this behavior using a simple datalog record consisting of a numeric and a variable-sized array.  I’ll add these to a cluster and then convert to variant before writing to the file.  I'll write that datalog file with LabVIEW 7.1 and read it back in 8.  If it fails, I'll file a report to our LabVIEW R&D team on it and they can look into fixing it for future LabVIEW releases.  If it does not fail, we'll have to investigate further....  In either case, we should consider alternatives for your program until this gets resolved.  One option is to write the datalog file in a less adaptable manner.  It would be easy enough to convert it if we can run the VI we have in a good state.  Another alternative is to keep it working by automating the “close and reopen” procedure until we get a file open properly.  This is less than ideal, but it might be suitable for now.

I’ll take a look at this and get back with you as soon as I have any new news.  If anyone else reading this has any input we’ll of course be happy to take it as well!

[Larry_Stanos]

Travis,

You've captured the essence of the problem scenario very well.

With respect to how the LV7.1 datalog files were created and opened in the first place, files were created and opened with a cluster, converted to a variant, wired to the datalog type terminals of New File.vi and Open File.vi respectively.  Then the file refnums returned were typecast using a refnum constant containing a cluster constant based on a cluster typedef.  Records based on the same typdef were then written to the file referenced by the typecast refnum via direct wiring (no coercion to a variant) to the data terminal of Write File.vi.

Just in case it matters, please note that my custom record cluster actually includes an array of clusters containing a variable-length array, not simply a variable-length array.

If there are no breakthroughs offering superior solutions, I'll plan on implementing one of the alternatives you suggested in your previous post.

Thanks!

Larry

[Travis_M.]

Good morning,

Well, I do have a small update for you.  First of all, after thinking about the typecast a little more, I believe that (unless I’m missing something) you should remove it.  Your Open File With Timout VI just takes a variant, datalog files can be of type variant, so there’s really no need to trick LabVIEW with a typecast.  The attached example will show how you can achieve the same result with a cleaner diagram. 

Second, and most significantly I have reproduced the behavior you describe with a much smaller control (a modified version of the example we have been exchanging).  However, the errors only seem to occur when opening the file with the “Open File With Timeout” VI! 

To use this demo: open the write datalog VI and create a datalog file of variants from LabVIEW 7.1.  Then open the read datalog VI from LabVIEW 8.  Run the VI first with the switch set to regular, then again with the read with timeout VI.  The read with timeout gives errors sometimes and no errors other times.  I’m pretty sure that debugging should start with this VI now. 

-Let me know what you think-

[Larry_Stanos]

Travis,

Good detective work.  I was able to isolate the problem to the new Deny Access.vi.  Removing this vi from Open Datalog File with Timeout cleared the Error 91 errors.  Inserting Deny Access.vi after your regular Open/Create/Replace Datalog.vi brought error 91 back.  The conflict only arises when the datalog file contains a variant data type.

Larry

[Larry_Stanos]

The LabVIEW 8 help topic for Deny Access.vi states that you cannot deny access to a datalog file using this vi.  Presumably the Get and Set Permissions vi's should be used for this purpose instead.  (I need to deny write permissions to other clients while one client is writing to a datalog file.)

So the LabVIEW 7.1 -> 8 code converter is making the mistake of inserting Deny Access vi's wherever datalog files were opened with a constant wired to the deny mode terminal of the old Open File vi.  Even the built-in Read Waveform from File.vi suffers from this conversion error.  (See http://forums.ni.com/ni/board/message?board.id=170&message.id=151455&requireLogin=False)

Larry

[Travis_M.]

Larry,

Great find -- thanks for linking in that information!  The bug referenced in the forum has been reported, and will be fixed.  I'm glad that we've been able to get this resolved -- and hopefully the suggestion about removing the typecast will also be helpful!