Interrupting for loop, measuring AO voltage

[Klas Lindfors]

I have two questions related to a program I am developing using LabView 7 on WinXP. I am using a PCI-6229 multifunction DAQ to control my experiment with the analog out (AO) channels of the card and simultaneously I collect data using the analog in channels. The first one of my questions sounds very simple but I haven't figured out how to do this: Can I interrupt a for loop? I would like to have a "panic" button to stop a measurement loop in case something goes wrong with the hardware that is controlled by the DAQ.

The second one of my questions is equally simple: How do I measure the AO voltage (with software)? In some parts of my application I slowly ramp one of the AO voltages and then collect some data. After this nothing happens until the user inputs some data. At the moment I clear the AO task after the target voltage has been reached. Since I have quite a few features in my program and more are probably going to be added in the future, I would like to be able to "check" what is the current voltage at, e.g., the AO2 channel. This just to be sure that what happens is what the user wants to happen! Is this possible and how can it be done?

Thanks in advance!

Klas

[Dr._Imad]

You cannot interrupt a for loop. However, you can include your funtionality inside a case struture (True/False) inside the loop. And depending on the condition, you can set the case structure to execute the code (True case) or not (False case).
Why not use a while loop instead ? You can interuupt the loop by wiring an error status or Boolean "panic" button to stop or continue running the while loop.

Reading the value of AO
If you want to read it for confirmation, connect the AO signal directy to an analog input channel. You should be able to write anlog-out and read the value of the output at the same time

[Klas Lindfors]

Thanks for the answer. Later I also realized that I could just as well use a while loop to accomplish the same thing as with the for loop and also be able to interrupt it. Regarding reading the AO voltage, do you suggest that I connect the hardware AO to an AI channel?

A new question: I am simultaneously reading several AI channels as I ramp the AO voltage. Things work nicely but I have noticed that there is a clear time delay between the different AI channels when I plot the results. The delays are a few milliseconds and all happen at the beginning of the ramp. I would therefore conclude that the problem is with the start of the task and not really a limit of the hardware. I used the NIDAQmx synchronisation example (simultaneous AO-AI) to build my VI. How can I minimize the time difference between the different AI channels and synchronize the AI to the AO? The sampling rate of the AI is relatively low, maximum 1 kHz/channel.

Thanks again in advance!

Klas

[Dr._Imad]

do you suggest that I connect the hardware AO to an AI channel?
Yes, wire directly to an AI channel, and read it with the rest of the channels.

How can I minimize the time difference between the different AI channels ?
I am not sure if what you are seeing is due to the card/software. It could be your test system characteristic, where the rise/drop is so fast , and a frequency of 1kHz is not adequate enough to capture the sudden changes.
You know, you can keep reading data continuously regardless of whether AO is set to 0 or some other value. Then you would see if the start of the task is the problem or not since you would intialize once and keep the task running (collecting data)

[reddog]

I suspect what might be happening is that some AI channels are reading the AO data before it has updated, and others are reading the data after the AO channel has updated. The attached picture illustrates how this might happen on a multiplexed AI board. In the top picture, the first AI channel reads the previous AO data since it takes a finite amount of time for the output to update and settle. The second AI channel then reads the new data creating a phase offset of 1 sample between the channels. The bottom picture shows the same scenario except the first conversion has been pushed out in time to allow the output to settle before reading it. If you think this might be the problem, you can use the following properties under the timing property node:

More -> AI Convert -> Rate
More -> Delay From Sample Clock -> Delay Units
More -> Delay From Sample Clock -> Delay

The convert rate property determines how closely the convert pulses are spaced in time between sample clocks, and the delay and delay units determine how long the first conversion is made after each sample clock. I hope this helps.