LabVIEW
HDF5 Call Library fails sometimes
The symptoms you describe would hint in the direction of uninitilized output buffers to those function calls. I haven't looked at the HDF5 API in a long time, so don't know the details anymore how this API works nor what data types it accepts. But it pretty surely will comply with standard C programming notions, which means when you call a function that writes information into some buffer, you have to make sure those buffers are properly preallocated before calling the function. One or more bytes to little can often work for quite some time, and suddenly crash, cause exceptions or cause computation errors.
Why it suddenly misbehaves at some point can be very random. Your mentionening that opened front panels seem to make it always work are an additional hint in this direction. They increase the memory foot print of your LabVIEW program and make it more likely that a buffer overrun won't immediately fail, though given an application that runs long enough it will at some point fail in some way too. There is nothing LabVIEW can do to prevent these buffer overruns other than trying to detect them and throwing an exception (indicated by an error in the Call Library Node error cluster). Depending on your CLN debugging level, this is done rather stringent, casually or not at all.
If your API only returns it's information in simple arrays then you can make it work with direct Call Library Node calls but need to be very wary about any output buffers those functions require. If however your API requires complex datatypes (structures with arrays and more liek this) then trying to get this done without a wrapper DLL is mostly an exercise in vain. The knowledge about how a C compiler lays out memory for such datatypes, which is required to be able to do that, is a lot more complicated than just writing a C DLL. So you make the problem in fact more complicated and sometimes basically impossible by trying to avoid the wrapper DLL.
