Parallel Acquisition and control

[Water]

Hi,

I would need to control a galvomirror(via inputting voltage) and acquire the photodetector voltage reading.

The process is as such

1)      The photodetector voltage level is to be read

2)      It is to be then fourier transform to obtain the spectrum

3)      Reading at certain frequency is to be stored

4)      Galvomirror is to be moved to new position by setting the voltage

5)      Above process repeated for n readings

I have the following question

A) Programming via Labview

 The NI cards I have are PCI-6133(only analog input reading) and USB 6008 (for analog output). I am using Labview 7.1 and DAQ mx8.3. I have written a program using parallel acquisition and output but I have some doubts.

i) Is it advisable to program both task in a parallel loop format? One loop for reading in the photodetector voltage and processing spectrum continuously while the other loop will be responsible for recording and moving the galvomirror

ii) I have used the local variables for passing the values between the two loops. Is there other ways to handle it as I read about the high memory consumption by using local variables

iii) Is there any examples that is similar?

I have trimmed down my program and attached it. Most of the sub-vi handles the more minor task such as to set the DAQ and to extract frequency value

 B) Programming style

i) I have found that programming large vi usually have large amount of criss-crossed  wires especially if u have multiple nested loops. Would some folks here advice me on how to keep a vi program looking neat? Do most of you hide the wires behind nested loops and sequences? How do you improve readability of the program?

ii) Is there any method for us to switch the connection points of vi around, somewhat like Mathlab simulink where you can switch the node point of a simulink block(ie allowing for program flow from right to left)? Or switch the location of the sequence local, without causing the wires to run crisscrossed in the previous frame

Thanks for your help!

[devchander]

First thing, I would suggest you go with producer consumer design pattern for your application

This will also avoid your usage of local variables

Do most of you hide the wires behind nested loops and sequences?

Never hide anything behind anything! that affects your code's readability/Tracability

Read Style Guide and to Rules to Wire enhance the clarity of your program

You cannot reverse the direction of Dataflow in LabVIEW

Regards,

Dev

Message Edited by devchander on 05-25-2007 04:16 AM

[Water]

Hi,

Have studied the suggestion but I have some query over here

1) If we are using producer/consumer architecture, how do we handle the information that we might not want in the queue. For my case, not all the information that the detector has produced would need to be processed. Also how do we mark/identify which data sets in the queue is those that belongs to certain environmental change? in my case, I would need to shift the stage and take readings of the photodetector. How would we identify which reading in the queue belong to the shifted result and which belongs to the previous shift? Do we also need to encase the data with the stage reading value before we enqueued it? What's the more common practice?

2) Would a master and slave design sounds more practical?

Thanks for your help!

[devchander]

You could probably incorporate a check while enqueqeing data ( For example: use a Data range check and enqueue data inside a case structure, only if your constraints are met)

[Anthony_de_Vries]

About the wiring style.  I've checked your test.vi...    With all respect...    Oh my God!  What a mess!

Keep the code cleaning, immediately while your working!  

Here's some tips:

• Don't hide wires behind anything.
• Keep the wires as straight as possible.
• Have the code flow from left to right.  (For vi's as well as wires and code in general.) 

Also try to avoid (non-flat) sequence structures, because they create input wires from the right.   IF you need to use a sequence structure, then first pull the wires all the way to the left, and work from there.

Certainly, also read the suggested style guides.

In this case, probably pictures say more than a thousand words.  Check out the differences.... NB: I've only moved wires and vi's around to make it more clear.  I haven't changed any code at all! 

Cleanup up:

Message Edited by Anthony de Vries on 06-04-2007 03:22 PM

[Anthony_de_Vries]

Cleaned up:

(Sorry... as I'm using Labview 8.2.1,  I can't save into Labview 7 anymore.   So it's either pictures or nothing...)

Message Edited by Anthony de Vries on 06-04-2007 03:26 PM

[Luke_G]

Hi Water,

As for the master/slave vs producer/consumer question, you could probably succeed with either one.  I agree with Devchander, however, that the producer/consumer would be beneficial because it would remove the local variables.  This would increase readability and determinism. 

In regards to tracking the stage position, there are several ways to do this.  You could (in the producer loop) enqueue the measured data with the stage position, or (in the consumer loop) compare the time at which the measurement was made to the time at which the stage was moved.

Good luck!