LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Open/Create/Replace File.vi poor performance on RT controller

 

I am using a PXI-8106 controller with LV 2010 SP1.  I am attempting to write small data files (CSV format, <10KB each file) to a folder on the PXI controller that may contain up to 5000 files.  I have found that the Open/Create/Replace File.vi takes 5-10min to complete executing when the input path points to the directory with many files.  I am guessing this has something to do with having to generate a list of files within the directory before it can obtain the file reference.  Here are some things I have determined from troubleshooting:

 

1. All of the files in the directory have the same prefix (i.e. TestData<date_time>_<Run1, 2, 3…>).  The long execution time occurs if I attempt to write a file to the large directory with a filename containing the same prefix as the other files in the directory.  But if I attempt to write a file to the large directory using a filename that begins with a different character (i.e. XestData_date_time>_<etc>), then it executes within an insignificant amount of time.  These leads me to believe the search algorithm within the Open/Create/Replace.vi is at fault here.

2.      

Th 2. The red “Drive” LED is illuminated on the PXI controller during execution of the Open/Create/Replace.vi, before the code has even begun writing the data file.

     

3.  3. A similar directory structure on a Windows platform does not replicate this issue, but instead completes within an insignificant amount of time.

 

Any help would be appreciated.

 

Thank you

Dan

0 Kudos
Message 1 of 4
(2,444 Views)

Dan,

 Sounds like a bug- Can't replicate here but your approach is clear and reasoning sounds on target.  Hope your SSP is up-to-date.  I'd have this in a support request pretty quick since few forum members will have the HW/ SW packs to duplicate the issue.

 

Just for a work-around (since its obvious) try a file name format of JJJ_YYYY<TestData>Run_N.  (a 5 digit julian won't help too much.  I think you got a OS File reference issue- that, will take some time to fix.  you are going to need to work around and through it


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 4
(2,441 Views)

Hello Dan,

 

I am going to try an duplicate the issue on my end but I have a few questions to clarify the behavior you are seeing:

 

-Is the 5-10 minute timeframe it takes to complete execution a cumulative problem in that the time it takes to execute increase as more files are added?

OR

-Does the long execution happen abruptly when we get to around 5000 files?

 

Regards,

National Instruments
Applications Engineer
0 Kudos
Message 3 of 4
(2,407 Views)

The issue seems to be cumulative...delay gest longer as number of files increases.  I appreciate the help.  FYI - I also submitted an SR (#7329427) on this and some otehr NI engineers are also looking into it.


Dan

Message 4 of 4
(2,403 Views)