08-20-2013 08:38 AM
Hello,
i use this MDF data storage plugin to write MDF files: mdf plugin
I created a project with some VI's like MDFOpen.vi, MDFClose.vi, MDFWriteDouble.vi, etc ...
I also created a Test VI which generates data at a specific rate (want to see performance) and write it to a MDF file. It works ....
Now I want to use this in C#. I compiled a LabView .Net DLL out of my MDF VI's and referenced it in Visual Studio. I can open a MDF File from C# and close it. But as soon as I write a double (actual content) into the MDF File I get an exception when I call MDFClose.vi from DLL. Obviously "Close Data Storage <APPEND>" from inside my MDFClose.vi returns error -2570: LabVIEW could not write the file back to disk. I have no idea why.
regards
Thomas
08-30-2013 11:37 AM
Hmmm.... a plugin within a VI within a DLL within a C# program ... Can't say I'm surprised that it doesn't work.
Why are you going for such a complex architecture?
My suggestion is to switch to C++ and use this library: http://vector.com/vi_mdf4lib_en.html
08-30-2013 11:44 AM
Well since we already use LabView and have the LabView MDF Plugin "for free" and our customer knows this it will be hard to convince him to buy a licence for a MDF library from Vector or ETAS. And it works somehow, I can create an empty MDF file. I just cannot write any values into that MDF.
I have created a support ticket for that issue but it seems that NI is also "uncomfortable" with this scenario since I have not heard from them until now and the ticket was created a week ago.
So I will have 2 options:
1. stick with the MDF LabView plugin and create a LabView Exe with a tcp/ip interface to interact with my .NET app
2. switch to Vector or ETAS
10-28-2013 07:27 AM
So I guess it's time to update this post for anyone who also have problems with MDF or Storage/DataPlugin VIs in general.
My task was to create a MDF Logger, so I needed to write MDF files. MDF4Lib from Vector mentioned in an above post can only read MDF files. ETAS is also selling an MDF Lib but there are reasons I don't want that. So why not use MDF Storage/DataPlugin from NI? I can tell you.
My MDF Logger is now finished and can create MDF files with groups and channels, just like TDMS, but ... when I write data in a loop and then finish by closing the MDF File/Reference it may happen that:
If it does not crash or throw an error it succeeds finishing my MDF file correctly but next time I repeat this (without restarting application) I notice writing data takes longer than in first run and my memory is increasing. The more I repeat the longer it takes to write data to MDF and the more memory is increasing until it finally crashes. It also depends on how much data in how many groups/channels are written.
NI Support already got this and confirmed that with desktop execution tracekit you will see that with each call to a Storage/DataPlugin VI references are leaking. Those leaks are assumed to be the root cause of all that trouble. There is not bugfix but apparently one or more CAR's about this. So I guess this is not MDF specific but generally with Storage/DataPlugin.
My current only workaround is to close the app each time after I am done writing one MDF file. My future fix will be to implement MDF on my own.