I have 4 LED's that I wish to turn on one after another, while measuring the light detected on a photodiode when each LED is turned on. I would like to use the analog output and input of my NI-USB-6259 DAQmx board to do this, and I'm struggling to get the sequence to work, I would appreciate some suggestions/guidence on how best to do this from you guys.
The whole thing happens in a 150Hz cycle. First a 5 volt signal is turned on channel one, this turns on LED one and it will stay on until the 5v signals is removed. While this 5v signal is on, the DAQmx is recording the voltage detected on one of the analog input channels. Then there is a very short delay, and the same thing is repeated for the other 3 lasers, with the same short delay in between each lasers. Finally there is a longer delay at the end to measure an ambient voltage (background measurement when no LED its turned on.)
Right now I have a while loop with a sequence structure with something like this in each sequence. However this turns on the 5v and it doesn't seem to want to turn it off before moving on the the next sequence. I haven't tried to run the simultanous aquisition in each sequence yet, but I'm worried that when i do I will not be able to get the timeing right....
Another way that I thougt of doing it was not to use a sequence but to set up a trigger train of pulses with differerent aplitudes and use it to continously trigger all the channels continously.
My experience with labview is limited, and I'm wondering if I am missing a silver bullet solution on this.
Solved! Go to Solution.
It would be easier to comment if you posted your actual VI rather than what you used as a reference.
"However this turns on the 5v and it doesn't seem to want to turn it off before moving on the the next sequence."
Aren't you turning it off by either writing a False if it is a digital output, or writing a zero if it is an analog output?
Doing something where you need to execute a series of steps sounds like you want a State Machine architecture. Search ni.com and the forums for examples of that.
Doing a series of pulses and recording all channels at once sounds like a valid idea. But it might be a bit more work because you'll need to decode the recorded analog stream to determine when the light was effectively on for each of the channels.
You're wise to have concerns about getting the timing right using an approach similar to what you linked to. If you need to cycle through all 4 On/Off/delay sequences at 150 Hz, you will *not* get there using software to control your timing. You will definitely need to use your hardware.
The good news is that your hardware is capable. The "silver bullet" solution *is* to run AO and AI tasks in "Continuous Sampling" mode so that all the timing is controlled by clocks on the DAQ board. Here are some details you'll need to look into, try out, understand:
1. Continuous Sampling
2. Synchronize AO and AI tasks
Thanks for your response on this. From your excellent advice I went on to make something that works pretty well, but I'm stuck on the very last step.
The pulses that I require to trigger the LED are all working great (I think), and I have a lot of flexibility in the timings etc.
The aquistion part is also working but it's lacking the last piece of polish to go from functional to something nicer. Right now all I can do is aquire a continous stream of voltage values ffrom the photodiode, and I would have to post process this array later. As it is set now I get about 20-30 samples for each pulse of an LED. I really only need to record the average of these 20 values and call that the values for that pulse, and of course separate out the different channels.
I'm stuck with how to trigger the aquistion into difference channels using the square waveforms that I built for the actual triggers.
What do you think is the best way to do this?
Thanks in advance,
I don't understand what you mean by:
"I'm stuck with how to trigger the aquistion into difference channels using the square waveforms that I built for the actual triggers."
Referring back to my prior post, you haven't yet addressed item #2, syncing the AO and AI tasks via a shared sample clock. I'm not sure it's strictly necessary but my hunch is that it'll help you out with correlating your outputs and inputs.
Part of item #3 was the suggestion to have the AI task capture the AO output signals along with the sensor response signals. This is another way to help correlate your outputs with your inputs during data processing. You can either physically wire the AO signals to AI inputs or you can use "Advanced" terminals with names like "ao1_vs_ao_gnd".