Bug within Write to Measurement Express vi

[mic3030]

I think I have found a Bug within the Write to Measurement express VI.   I have attached an example VI to help reproduce the error.

Here is a bit of history.. I have a data monitoring system which runs continuously.  I have the write to measurement setup to create a new file every 12 hours.  What I noticed is that even though a new file has been created,  I still cannot access the old files until I stop the VI that has the Write to Measurement VI in it.  I am trying to access the files via Diadem.  

For this application, it is not practical to stop the Data Monitoring Main VI every time I need to look at the data.  The alternative that I found was to not use the Write to measurement express VI and use open/write/close TDMS vi's.   This is not an acceptable solution as the features programmed into the Write to measurement Express VI are need for my application.  

Can someone please fix this or help me fix it?

Thank you

Mike

[JeffBoettcher]

Sorry for the inconvenience, you might find some workaround information in the discussion thread here: http://forums.lavag.org/index.php?showtopic=6252

This was reported to R&D (46KIDFWJ) for further investigation.

[mic3030]

Thanks for the quick response.   I looked at the forum you mentioned but didn't see any work arounds for this.   

Doesn't National Instruments have an Expert Labview Programmer that can go in to the code and figure out why the files aren't being closed or released by labview? The Express vi's were one of the KEY selling points for all the hardware and software that we bought from NI.  They simplify programming, for non programmers.  It's really not acceptable just to say yes we know there is a bug yet not give a work around for it. 

I cannot reproduce all the features that are in the Write to Measurement Express VI.  I need some help on this one.

How do I go about escilating this? 

Mic

[JeffBoettcher]

Hello Mic,

Please understand that I can suggest a workaround, and I've tested it in your scenario and it seems to work OK, but I cannot guarantee this workaround for all possible use cases of this Express VI.  It is for this reason that we generally don't like to recommend one-off modifications to VIs that ship with LabVIEW - they do not get tested with as wide a set of use cases as we do on VIs when we ship them.  As such, I'm not going to just hand you a VI to replace in vi.lib, but I will show you a few edits you can make to work around this issue.

Open this VI:  "[LabVIEW Install Dir]\vi.lib\express\express shared\ex_TDMS\ex_createorOpenTDMS.vi"

Open its diagram.  Near the left there's a section that looks like this:

The current known bug is with the "Not A Number/Path/Refnum?" function on TDMS files, so you'll see the following changes in the below diagram, which hopefully you can make and try out in your use case.  I would highly recommend making a backup copy of this VI before saving any changes!

1. Delete the "Not A Number/Path/Refnum?" function.
2. Connect the "new file?" input to a "Not" function, and wire the output of the "Not" to the case structure selector where "Not A Number/Path/Refnum?" was previously being used.
3. Delete the wire connecting the error out of the first inner case structure to the second inner case structure, and re-route the error wire around the first case structure.

Hopefully with these three instructions and comparing the shipping and workaround images you can successfully get up and running.

Message Edited by Jeff B on 03-01-2007 08:12 AM

[mic3030]

Thanks for the suggestions.  I Modified everything as you specified, unfortionately it still didn't work.  Possibly it's a different problem.

Let me explain in a bit more details what is happening in my case.

I have a VI that pulls data from a fieldpoint unit, using the Field Point Express VI and saves the data to a TDMS file using the "Write to Measurement" express VI.  This VI runs continuously reading and writing data every 10 seconds.  The "Write To Measurement" is setup to create a new filename every 12 hours.  In the example aboove, I have it setup to create a new file every 1 minute so the error could be reproduced faster. 

I have included a screen capture of the error I am getting in Diadem. 

If I try and open one of the files for viewing in Diadem, I get this error.  The only way to view the files are to complete Stop the VI that the Write to measurement file is in.  My first thought was that the file was in use or currently being wrote to, so I could not open it but that isn't the case for this error.  I still get the same error when I try and open a file that was previously wrote to. As you can see from the example screen capture, I was trying to open the ATC****_001.tdms file but still got the error.  FYI the system was writing to the ATC***_002.tdms.

Does that sound like the same error you were referring to? Any ideas on how to fix this?

Thanks

Mic

[mic3030]

Here is the log file that Diadem creates. 

The Error Reads

ERROR: TDS Exception in Initialize: Tds Error: TdsErrAccessDenied(8):

[mic3030]

Does anyone have a fix for this?  Surely there is someone at NI that can help me.

How do I go about escilating this. 

Mic

[DuffmanSays]

Hello Mike,

I apologize, but as Jeff mentioned previously, this is a known issue in LabVIEW 8.2 with the express VI. Essentially when writing to multiple TDMS file, the application does not release the files from memory when the subsequent files are written. Because they are still in the LabVIEW memory, they cannot be opened in DIAdem. This behavior has been addressed and will be corrected in a future LabVIEW release.

If the steps previously mentioned did not work for you, I would suggest using the low-level TDMS file VIs to write your application. In this way, you will be able to configure when the files are opened and closed such that you can determine when they would be accessible to another software program (such as DIAdem). I hope this information is useful for you. Have a great day, and good luck with your application.

Mike D.
National Instruments
Applications Engineer

[mic3030]

Mike,

The problem with the Write to measurement express Vi is bigger than just not closing out the files so they can be read in Diadem.  Anyone that has a continuous logging application that uses this express vi will start to have memory issues as more and more new files are created while the old files aren't completely closing out.  My application was writing a new file every 12 hours in 24 different VI's.. After two weeks I found out that there was over 8064 open files, that were locking up the Windows box.  Not to mention all the data we lost. 

Using the low level VI's is a great solution for those that have tons of labview experience however it's not a very good solution for us non programmers that were sold on labview because of the express VI's.  Remember, the Write to Measurement Express VI has a lot more functions than simple reading and writing the data. The solution is not as simple as just using the low level VIs.

So here I sit with $$k in hardware and software from NI with my management asking is it ready yet, it was suppose to be easy... and I am trying to explain that Labview has a few bugs in it that they aren't fixing until the next version. 

This isn't acceptable to me.  How do I escilate this?

Mic

[Travis_M.]

Hello Mic,

To escalate this beyond the discussion forums:
-If you are an SSP customer, please create a service request by visiting www.ni.com/support
-if you are not an SSP customer, please  email support@ni.com with your question and a link to this forum.  In general, emailing this address without a service request is discouraged, but we are interested in troubleshooting with you in a more direct way, so feel free to email us.
-if the above techniques are unsuccessful, please let us know.

thanks-