LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is it my computer or the labview program that is slowed down by this program

When I run this Vi with a large excel file the playback is extremely slow. I don't see why it would be the program, but the file are not that large so it shouldn't be the computer. I have attached the code and a small (book1) and a large ( book8) excel files.
 
Thanks
- there is always an easy way, but it is always the hardest to find
Download All
0 Kudos
Message 1 of 6
(3,276 Views)
Neither. It's your code.

Specifically:
  • You're reading the file each time through the loop. Why? Is the data changing? Are you changing filename on the fly? If you are, you should use an event structure.
  • You don't have a delay inside the loop, so the loop churns away at maximum speed, leaving almost no time to respond to events. Place a wait function inside the loop with a small (say, 50 msec) delay. Better yet, use an event structure.
If you do the following two steps you will see the speed increase tremendeously:
  1. Place the file reading outside the loop.
  2. Add a wait function inside the loop.
0 Kudos
Message 2 of 6
(3,255 Views)

I cannot run your VI because we need the subVI called filename.VI

Here are a couple of suggestions.

1. Get rid of all the property nodes and use wires with a shift register and put a small wait in the loop.

2. Dataflow- right now you have race conditions because of all of the property nodes- you have no idea as to which one will operate first if you want to continue to use all the property nodes then use the error in and error out to ensure dataflow.

3. Look into using some type of coding architecture. A good one for this would be a qued statemachine with event handling. This will make your code much more robust and more easily upgradeable, there are many examples for this and even a template to get you started.

4. Use execution highlighting to see where your VI is spending its' time




Joe.
"NOTHING IS EVER EASY"
0 Kudos
Message 3 of 6
(3,249 Views)

Thank you

That was a brain fart on my part.

- there is always an easy way, but it is always the hardest to find
0 Kudos
Message 4 of 6
(3,244 Views)
Can't take a look at your VI (using 7.1 Smiley Indifferent ) but I would like to comment on your Book8 by saying, "wow".... that is an impressive amount of data there.

Message Edited by Steve.Briggs on 01-03-2007 10:33 AM

0 Kudos
Message 5 of 6
(3,228 Views)
A few comments:
 
  • "Read from spreadsheet file" cannot read native excel files (e.g. book1). Book 8 is NOT an excel file but a simple ASCII table. (the xls extension forces the OS to try to open it with excel, and excel will try its best to parse the data. This can go wrong.)
  • None of the data actually changes during the run and you are only manipulating the scales. the code for reading the file and all graph terminals belong outside the play loop or in a read event if you want to switch files during run..
  • For local use, local variable are better that value properties and carry much less overhead. Still you don't need very many.
  • Don't be afraid of wires! You read "playback" many times per iteration with property nodes, while you could simply tap into the same wire.
  • It is inconvenient to have a play and pause button. Use one button and label one state play and the other pause. This also simplifies the code.
  • SImply show the digital display of the playback slide, eliminating the extra numeric indicator.
  • Use a shift register for the position indicator, then simply increment or decrement according to the button events.
  • Dont use the same label for two different controls (stop), this will get confusing once you try to assign events.
  • ...

the picture show a quick sketch how you could do things more efficiently (not all events are shown). It'll probably still needs a few tweaks. 🙂

 

Message Edited by altenbach on 01-03-2007 08:43 AM

Message 6 of 6
(3,207 Views)