Any ideas on how to make program simpler?

[ctolson]

This program is designed to send multiple TTL pulses to different instruments, while at the same time receiving and analyzing analog input data.  We will likely be sampling at fairly low rates (rarely over 100 Hz).  We will be getting a new USB board soon, but this program is written for the USB-6008.  The program is over 9 MB, and I would like to know if there is anything I can do to make it more manageable.  I have already gotten a lot of help from this forum and really appreciate it (haven't done much computer programming before this summer) and those of you in cyberspace have saved me a lot of headaches.  Thanks in advance for the help!

[johnsold]

I can see several things which may help.

First, it is considered good practice to keep the diagram to one screen in size. Unless you have a huge screen yours is too large both vertically and horizontally. This has minimal effect on the size of your program files and none on performance, but the programmer wastes a lot of time scrolling around looking for things. Eliminating white space alone will almost get you down to one screen.

Which leads to point two.
When you have duplicated code, make it into a subVI. The six case structures with sequence structures inside at the left are identical except for the data values.

3. Event structures are almost always used in while loops. Typically they would have several cases, one for each type of user action which requires a response from the program. For example if your booleans Wavemaker ON/OFF... each had an event case which fed the associated delay and I/O reference to the subVI suggested in 2, the program could run each channel as the user selected it.

4. For loops do not need both the N terminal wired and autoindexing on arrays enabled.

5. Sequence structures are almost never needed. If your TTL Pulse.vi had error in terminal, then dataflow would allow elimination of the sequence structure and would keep the DAQmx tasks from running if some prior error had occurred.

6. Since you are always using the same few elements of the arrays read from files, do the indexing outside the for loop. No need to do the same thing over and over.

Lynn

[Ray.R]

To learn more about LabVIEW, I suggest you try looking at some of these tutorials.

R

[ctolson]

Lynn

Thank you for that great reply, I took your advice and made the changes you sugguested.  The delay needs to be a time interval from when the VI is started, so I put a wait until done VI from DAQmx instead of the time delay.  I am hoping that this will work, but am not sure.  I have attached a copy of the new program, if you or anyone else out there has any more advice.  It seems that a 9 MB VI bogs down my computer when it runs.

Thanks again

Chris

(The SubVI's should be in the folder as well)

[johnsold]

Chris,

That is much easier to look at.

I second JoeLabView's recommendation on the tutorials. It is clear that you do not yet fully grasp the meaning and power of dataflow.

The TTL Pulse subVIs at the left may run before or after (or even simultaneously) with the rest of the main VI because there is no data dependency.

Lynn

[johnsold]

Chris,

I did not address your other issue. What do you mean when you say it "bogs down?"

You create, write twice, and clear a digital task and do a 1 ms wait up to six times (TTL Pulse). You read analog data taking about 100 ms using the default values on the front panel. You open, read, and close 4 spreadsheet files then open, write, and close 4 spreadsheet files. All those DAQ and file operations can be time consuming. This program cannot run in less than 100 ms and several hundred might not be out of line if the files are large or the OS is not responsive.

Have you used the VI Profiler to check time an memory usage?

Lynn

Message Edited by johnsold on 07-23-2008 04:43 PM

[ctolson]

Lynn

I know that I am not an expert in this area, I am actually Civil Engineering student with a part of my work consisting of writing labview programs for our lab.  the computer bogging down could be partly my own OS, which has been acting up lately.  I figured that the program was a lot more complicated that it actually needs to be.  I am assuming that it is not too much to ask a DAQ board to acquire analog inputs and send digital outputs at the same time, but the software is slowing it down.  I will look at the tuitorials tomorrow and see if I can find what I am looking for.  I ran the profiler, but don't really know what it means.  I am assuming by your last post that I am asking labview to do too much at once, am I correct in this assumption, and if so, how could I correct it?

Thank you

Chris O.

[johnsold]

Chris,

The DAQ board should be able to do digital output and analog input simultaneously. Your program actually permits that. What I was trying to point out was that you have no way of knowing which part will happen first if there is no data dependency between the parts. I was guessing that you wanted the 1 ms digital pulse(s) to occur before the analog acquisition started. The digital pulse(s) will almost certainly finish before the analog acquisition, but there is no way of knowing which will start first.

Can more than one of the booleans be true when the program runs? If so, the pulses will follow one another, in no specified order. The order could be different on different runs with the same settings.

If you give a description of how the program is supposed to work, someone will be able to make suggestions on specific improvements.

Lynn

[ctolson]

Hello again

Thanks lynn for the advice, I am sorry for the delay since my last post.

I am pretty comftorable with the programming of labview, but not the applications of DAQmx and data flow overall for that matter.  I have been searching the forums all morning trying to find some examples of what I wish to do, but have been unsuccessful.  What I am working on is creating a program that controls all of the instruments in the lab, in other words, send triggers to different instruments at different times to turn them on and off. 

I now see that the wait VI that I put in the TTL subVI was a poor choice and am still trying to find a way around it. 

I want to set up some kind of a clock that starts when the VI is run.  From this, I want to allow the user to set up a delay for each TTL, so the wavemaker might be triggered immediatly, but the individual instruments could be triggered after some time interval.  The On/Off booleans are present because we do not use all the instruments at all times, so if say the laser is off, LabView would not send the TTL to laser's computer.  I would also like to incorporate the data acquisition to the clock, say to let the wavemaker run for 5 minutes before data is acquired, however that part won't be too hard once I figure the timing out. 

An example of what might need to be done could be

1.  VI is started

2.  Wavemaker is triggered immediatly

3.  Data acquisition is started after 5 minutes, and acquires 10,000 samples at 100 Hz

4.  Laser and ADV are triggered simultaneously after 6 minutes

5.  After voltages are acquired, they data are analyzed (plugged into a calibration curve to get pressure or wave height...)

6.  The final values are written to a spreadsheet.

I am thinking that using a tick counter and event structures might work, but I havent been able to figure it out yet.

Thanks

Chris

[johnsold]

Chris,

Look at the State Machine Design Patterns under the File menu. File >> New.. >> VI >> From Template >> Frameworks >> Design Patterns...

I think that a state machine, probably a variation on the Producer/Consumer (Events) pattern, will be a good choice for you.

I would set up a three loop system. One loop would handle the user interface. It would have an event structure, a method of updating the displays, and very little else. The second loop would take care of behind the scenes processing, command timing, data manipulations, saving to files, and communication with the other two loops. The third loop would handle all the DAQ stuff: Writing the TTL pulses, acquiring analog data, and handling the safe shutdown if the equipment at the end. Exchange commands and data among the loops with queues or Action Engines. It might be feasible to combine the first two loops, but keeping the UI and event structure separate often simplifies things.

Use a shift register with the tick counter for the timing. When you start a process, read the current tick count. Add the delay. Put this "end time" value in the shift register. Each time through the loop compare the current tick count to "end time" and take the appropriate action. Use a separate shift register for each device needing independent timing or use an array or cluster of tick counts so that one wire handles all.

I have done these things and they wrk well.

Lynn