Tom Fantasia

NI's support team determined that this issue is a "potential bug." Follow CAR 488186 for updates.

Sharing a single reference would solve this particular problem. It would also add more messaging overhead. The process that closes the reference would have to notify the other processes and wait for acknowledges before it could safely close the reference. Otherwise another process could attempt to access the TDMS file with a bad reference. One of the reasons I chose to use the TDMS file format was its out-of-the box support for concurrent access. Perhaps properties writes don't work the same way as data writes do (as you hypothesize hooovahh)...

I am accessing a TDMS file from two VIs running in parallel. One VI is responsible for opening the TDMS file and writing a property. The second VI is responsible for reading said property. Here's where things get interesting...The second VI cannot find the property while the first VI has the TDMS file open unless the first VI also writes data to the TDMS file. I've created a few VIs (attached) to help illustrate the problem. Any ideas as to what is going on? I would have expected properties to be available as soon as they are written. Read TDMS Property Names.vi Write TDMS Property (with data).vi Write TDMS Property.vi

What an exciting time to be alive. Everything that can be decentralized will be decentralized. What do you think of ethereum Shaun?

Why do .lvlibs load nested .lvlibs into memory?

Excellent idea.

Thanks for your help Jack. We ended up going back to a known working version of the code base. That seemed like the fastest way to get the code working again.

Just to (kind of) close the loop on this problem. I'll summarize what we found. A couple of weeks ago I removed about 20 (mostly abstract) classes from a library. I did this by: Adding all of our source code to a new project (in order to load everything into memory). Right clicking on the classes in question and selecting "remove from library" Our main VI continued to work afterwards, but the EXE started throwing a 1502 error. Changing the "Additional Exclusions" settings as described in this thread didn't help any: http://forums.ni.com/t5/LabVIEW/Error-while-creatiing-executable-Error-1502/td-p/669757 Anyone have any idea why removing classes from a library would cause the EXE, but not the VI to break?

We recently moved about 20 classes out of a library. These were mostly abstract classes, but one might have contained a typedef, but I don't think that any contain a typdef'd cluster. After resetting the mutation history for all classes as described in my previous post, a single typedef claimed to have unapplied changes. It did contain an event reference. That may be just another red herring, but I figured it worth mentioning.

Hey guys, I'm Mike's state-side coworker, Tom. I have tried resetting the mutation history of every class in our depot via two methods: [*]The Set Mutation History.vi in vi.libutilityeditlvlibslvclass. [*]A custom script that deletes everything between the tags and (including the tags). After resetting the mutation history (both ways) I am able to build an executable, but the error "VI has an error of type 102208. The full development version of LabVIEW is required to fix the errors." in thrown as soon as I run the executable.

+ 1 Stream your test data to disk. That way you never have to worry about running out of memory. There are many file types to choose from, each with their own benefits and drawbacks: TDMS, datalog, CSV, databases, etc. TDMS is great for concurrent read/write access. Datalogs make great object based config files.

Congratulations! I got the good news today too! Thanks for your help and motivation preparing for the CLA Mike.

Thanks Mark!

Yes, be super nice to your coworkers back in the office. Perhaps send them Swiss chocolates every once in a while! Enjoy your trip Mike. Talk to you soon. Tom