Setting a loop to run for a set time

[altenbach]

---

@Vikster wrote:
When the data gets saved to an Excel file using the write to spreadsheet file.vi it gets all the correct numbers and times. Is it possible to make the graph from the file?

---

Using "write to spreadsheet file" does NOT generate an excel file, but a plain ASCII table file. This can be easily read back to data using "read from spreadheet file". Just read and send it to a graph.

Some people give the "spreadsheet file" file an xls extension, forcing the OS to open it in excel, which will then make some efforts to parse it in a reasonable way. If you would open it in excel and then save it in native excel format, reading it later using LabVIEW will be a bit more complicated.

[Vikster]

Okay i realized there was a much simpler way for me to do this. The multiplier is the current problem. And to get the correct value the formula is:

1 / (Number of points/User defined time)

So I thought if I make the program get a new multiplier every time I run it I will always get a perfect graph. The problem is though, that the value for the number of points measured is made at the end of the loop. So is it possible to create the chart even after this?


The next question is: The write to spreadsheet file.vi automatically asks at the end of the loop for a destination to save the file. Is it possible to not force the user to save it immediately. I want them to be able to click a button called "save" whenever they want.

Message Edited by Vikster on 08-28-2007 02:22 PM

[altenbach]

---

@Vikster wrote:
So I thought if I make the program get a new multiplier every time I run it I will always get a perfect graph.

---

The time between points should be easy to obtain from the beginning. How else can you acquire data?

---

@Vikster wrote:
The next question is: The write to spreadsheet file.vi automatically asks at the end of the loop for a destination to save the file. Is it possible to not force the user to save it immediately. I want them to be able to click a button called "save" whenever they want.

---

Yes. Use a state machine architecture and keep the data in a shift register. When "save" is pressed, go to the "save" state and save the data.

[Vikster]

Unfortunately the harware reading time is not consistent. There are different values if I read for 1 second/5seconds/ etc.

[Vikster]

I just put a delay in the loop and now the time between reading are stable. Thank You.

Now Im going to work on your suggestion for saving the file.

[Vikster]

---

@altenbach wrote:
Yes. Use a state machine architecture and keep the data in a shift register. When "save" is pressed, go to the "save" state and save the data.

---

Im not really understanding how to use a State Machine Architecture. Do i need to change my While Loop to a Select Case loop, and then put a while loop around that? Or can i keep it the way it is and put a Case Loop around the while loop?

[Vikster]

Forgot to attach my VI

[Daniel_E]

Generally, a state machine is a case structure inside of a while loop.  You then use a enum to define each state.  LabVIEW actually has some templates for this built in.  From the LabVIEW Getting Started splash screen, go File >> New... Then VI >> From Template >> Frameworks >> Design Patterns >> Standard State Machine.  That should give you an idea of the structure.

Here is a good tutorial on state machines: http://zone.ni.com/devzone/cda/tut/p/id/3024

Also, if you search NI.com for state machines, you will find a lot of example code that you can look at.

Hope this helps!

[altenbach]

---

@Vikster wrote:
Forgot to attach my VI

---

OK, there are many things in your VI that don't make sense and I thought we already talked about some of these points in the past.

• First of all, your program is linear and there is no turning back once it runs.
• The operator needs to set the input parameters in edit mode, then press the run button.
• There is no way (except for the abort button) to interrrupt the code if something goes wrong.
• There is no error handling
• Even if there are errors (e.g. if it cannot comminucate with the instrument), it will bang its head x times trying to read from an instrument it could not even initialize.
• Once the loop is finished, you get exactly one chance to save the file, if you mess that up, all data is irreversibly lost.
• I have no idea why you make the array into 2D feeding to the array max/min node. All you get is a "1 by x" array of the last set of data. Don't you want to accumulate all data?
• Same with the mean. Since there is no autoindexing, you'll only get the mean of the last dataset. Is that really all you want?
  

If you design the program as a state machine (as desribed in the post above), the program will aways run, but will initially be in an idle state that just reads and verifies the setup parameters. If you then press e.g. an "acquire" button, it will go into a state that corresponds to your while loop contents. It does not need it's own while loop, but simply spin the main loop while aqcuiring the data. The data should be built in shift registers so it will be available to other states. Once the acquisition ends, it will go to a state where it closes the device (if needed) and then go back to an idle state. Now you are allowed to press the save button to execute a state where it writes to the file, then go back to the idle state. Now you can start another acquisition, save the file once more in a different location, or do whatever else the program can do.

See how far you get. 🙂

[vikster1]

---

@altenbach wrote:

---

@Vikster wrote:
Forgot to attach my VI

---

OK, there are many things in your VI that don't make sense and I thought we already talked about some of these points in the past.

• First of all, your program is linear and there is no turning back once it runs.
• The operator needs to set the input parameters in edit mode, then press the run button.
• There is no way (except for the abort button) to interrrupt the code if something goes wrong.
• There is no error handling
• Even if there are errors (e.g. if it cannot comminucate with the instrument), it will bang its head x times trying to read from an instrument it could not even initialize.
• Once the loop is finished, you get exactly one chance to save the file, if you mess that up, all data is irreversibly lost.
• I have no idea why you make the array into 2D feeding to the array max/min node. All you get is a "1 by x" array of the last set of data. Don't you want to accumulate all data?
• Same with the mean. Since there is no autoindexing, you'll only get the mean of the last dataset. Is that really all you want?
  

If you design the program as a state machine (as desribed in the post above), the program will aways run, but will initially be in an idle state that just reads and verifies the setup parameters. If you then press e.g. an "acquire" button, it will go into a state that corresponds to your while loop contents. It does not need it's own while loop, but simply spin the main loop while aqcuiring the data. The data should be built in shift registers so it will be available to other states. Once the acquisition ends, it will go to a state where it closes the device (if needed) and then go back to an idle state. Now you are allowed to press the save button to execute a state where it writes to the file, then go back to the idle state. Now you can start another acquisition, save the file once more in a different location, or do whatever else the program can do.

See how far you get. 🙂

---

Thanks 🙂 . Im creating the State machine now. I just have a couple questions: For my application, what goes in the shift registers? and where should I wire the "aquire" button to?
Ty. Im glad to see this program finally getting close-ish to completion.