From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Read from text file takes very long after the first time

Solved!
Go to solution

Dear LabVIEW experts,

 

I'm having a problem with read from text file. I'm trying to read only every nth line of a file for a preview with this sub vi:

read nth line.png

I seems to work well the first time I do it. The loop takes almost no time to execute an iteration.

Then when I load the same file again with exactly the same settings one iteration takes around 50ms.

Subsequent attempts seem to always take the longer execution time.

Only when I restart the calling vi it will be quick for one file.

 

When executing the sub vi alone it is always quick, but I don't see how the main vi (too complex to post here) could obstruct the execution of the sub vi.

I don't have a the file opened elsewhere in the main vi, I don't use too much memory...

Right now I don't now where to look. Does anyone have an idea?

 

Regards

Florian

0 Kudos
Message 1 of 20
(3,621 Views)

I don't know the LabVIEW internals here, but I would think that it is quite possible that closing a file opened for read/write access writes a new copy of the file to disk, or at least checks the file in order to make sure a new file does not have to be written.

 

Therefore, if your main VI calls this subVI sequentially (you don't give any information about the place of this subVI in the main VI), you are actually looking at a close (check/write) -> open operation for any time you call it, as opposed to a simple open operation the first time. If you were to open the file for simple read access (since that's all you do), it should work fast every time because there is no need to check to see if it has changed.

 

Cameron

 

To err is human, but to really foul it up requires a computer.
The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
Profanity is the one language all programmers know best.
An expert is someone who has made all the possible mistakes.

To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):

LabVIEW Unit 1 - Getting Started</ a>
Learn to Use LabVIEW with MyDAQ</ a>
0 Kudos
Message 2 of 20
(3,595 Views)

Thanks for the answer camerond.

 

The sub vi is only called upon the press of a button by the user, so it is called only once at a time. It does not seem to matter how much time has passed between the calls.

 

Following your suggestion I set the operation of open file to read only. Now the sub vi is always slow when called from the main vi (even for the first time) but still quick when executed on its own.

Weird.

Anything else I could try?

 

Regards

Florian

 

0 Kudos
Message 3 of 20
(3,588 Views)

Well, seems like something in the interaction of your main VI with the subVI, please post the main VI so we can see.

 

Can you really manually detect 50 ms after a button press (1/20 sec)? Or are you using a datascope of some kind? For me, that would be pretty much instantaneous, but I guess my old nerves have slowed down (and I don't drink Red Bull or other supercaffeinated beverages).

 

Screen rewrites sometimes slow a computer's response down, could this be your problem?

 

Cameron

 

To err is human, but to really foul it up requires a computer.
The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
Profanity is the one language all programmers know best.
An expert is someone who has made all the possible mistakes.

To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):

LabVIEW Unit 1 - Getting Started</ a>
Learn to Use LabVIEW with MyDAQ</ a>
0 Kudos
Message 4 of 20
(3,584 Views)

It's not a single delay of 50ms but each iteration of the while loop in the snippet suddenly takes 50ms instead of say 1. I took the time with timer (ms) vi. The loop may run for thousands of iterations.

Loading a 7MB file takes about 1 second on the first try. Subsequent attempts take more like half a minute!

 

It can't be screen writes. The FP of the sub vi is not shown.

 

Posting the main vi really isn't feasible - I guess I'll have to create a striped down version that still replicates this behavior.

This may take some time.

 

Thanks again

If anyone has suggestions that could save me trouble of decomposing my main vi completely I'd be overjoyed Smiley Wink

 

Regards

Florian

0 Kudos
Message 5 of 20
(3,578 Views)

I'd change the function slightly, instead of looping through, reading Y rows at a time, read all (-1) and decimate the array afterwards.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 20
(3,573 Views)

I'm most likely just displaying my ignorance here, but why do you have your file refnum wire going into a shift register on your while loop instead of a plain tunnel?

 

Cameron

 

To err is human, but to really foul it up requires a computer.
The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
Profanity is the one language all programmers know best.
An expert is someone who has made all the possible mistakes.

To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):

LabVIEW Unit 1 - Getting Started</ a>
Learn to Use LabVIEW with MyDAQ</ a>
0 Kudos
Message 7 of 20
(3,566 Views)

@camerond wrote:

I'm most likely just displaying my ignorance here, but why do you have your file refnum wire going into a shift register on your while loop instead of a plain tunnel?


That's a common way of doing it for FOR loops, because if you don't, and the loop iterates zero times, the reference would get invalid when using plain tunnels. For WHILE loops it does not matter, because they always iterate at least once, but why not use the same everywhere and make it a habit instead needing to think about it in every sceanrio. 😉

0 Kudos
Message 8 of 20
(3,562 Views)

@Florian.Ludwig wrote:

When executing the sub vi alone it is always quick, but I don't see how the main vi (too complex to post here) could obstruct the execution of the sub vi.


How do you measure the reading speed?

0 Kudos
Message 9 of 20
(3,559 Views)

The only thing I can think of at the top of my head is that if your main VI is doing some sort of disk access, that would slow down this VI.

 

I also agree it would be better to just read the entire file and just throw away the lines you don't want.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 10 of 20
(3,550 Views)