daqmx READ 2d nchannel nsample

[deskpilot]

I am running two parrallel while loops, one that is outputting continuous low speed data to the front panel, and a second that is waiting for a high speed finite trigger. The program sits and waits for the trigger and does not display the continuous data, so I set the timeout on the finite sample READ, and then disconnected the error output inside of the READ block diagram. This appears to work, although I am only using simulated devices at this time, but is there a better way to do this?

[Nathan_R]

Hi deskpilot,

If I understand you correctly you have two while loops. In one you are doing a continuous low speed acquisition and displaying it on the front panel. In the other loop you have a high speed finite acquisition that is waiting on a start trigger.  As long as you are not trying to do two different analog input tasks on the same card at the same time your loops should work. You need to make sure that no data from one loop is needed by the other; such as if you wired an error line out of one loop and into the other. This would make the second loop dependent on the first and they would not execute in parallel. If I made an incorrect assumption here can you please post a screen shot of your block diagram or the VI itself so I can better understand what you are trying to do. Let me know if you have any questions and take care.

Thanks,

[deskpilot]

It sounds like you get it. If the high speed triggered as soon as the program started, it works fine. But that is not the case, so it sits in the lower while loop (block diagram screen shot) and waits for a trigger, and does not continue with the top while loop, so no continuous data is ouput to the screen. The structures above the data output is just dividing it up into sepearte graphs, that was originally just data output to graphs and it worked the same then.

My remedy was to set the DaqMx Read to timeout each iteration of the while loop that it does not trigger. The timeout is set to the total time of acquisition inside of the DaqMx dual trigger subVI. Since this pops up an error every time the finite while looop does not trigger, I went into the Read block diagram and disconnected error passing as shown in the other screen shot (realize now I could just use clear error Vi in that block diagram). Crude but it worked on my simulated devices. When I moved to real devices though, something is not working right, and I am assuming it is an error in the Read that I am not getting. If there is an easier way to view continuous while waiting for finite, I'm all ears, I'm pretty new to this and may be going about it all wrong.

On a side note, I am not sure that I will be able to use the dual trigger set up with the 6133 card I will be using for the finite acquisition, but I have a similar set up with single triggering that yields the same results (or lack thereof). The dual trigger is just two trigger functions wired in series that use different trigger channels. It works great on a simulated device, but not sure if I can use anything but ai0 to trigger on the 6133?

Message Edited by deskpilot on 03-27-2008 08:14 AM

[Nathan_R]

Hi deskpilot,

I don’t recommend changing the DAQmx read so that it cannot return an error. You will have no way of knowing if something has gone wrong. You should not need to do this to have both loops running in parallel. If you do have to clear an error I would recommend checking the error code to make sure that it is the timeout error and then using the clear errors vi.

I’m not sure what you mean by double triggering. If you put two DAQmx trigger VIs in series you do not have two triggers. The first VI will setup a trigger configuration and then the second VI will overwrite that configuration for the task. You will end up with one trigger using the settings in the second trigger VI.  As far as I know there is no way to have two hardware start triggers for a task using multifunction DAQ.

I could not really tell how your program is structured from the screenshot you posted. Most of the code was not displayed. Can you try to simplify your code down to just the two loops with DAQmx tasks and then post the VI? I’d be happy to take a look at it and see if I can help. Let me know if you have any questions.

Thanks

[deskpilot]

I wasn't sure about the double trigger. We are transitioning from another acquisition hardware that allows this, which prevents the loss of data if the first trigger does not activate. Really would be nice if there is a way to do this in Labview, short of independently acquiring on a second card or chassis.

As for the main problem, I did similar to your suggestion and used the general error handler at the daq Read level to exempt that particular error. The program remains very dependent on the timeout setting of the daq read in the finite loop, but seems to work well once I found the sweetspot. If I set it to 0 (read once) or even less than .5, it misses the trigger. It is a little bulky with the longer timeout, but I think it will be ok.  

Thank you for your help.