I'm attempting to do something in LabVIEW that is probably possible but in many different ways and was wondering what the LabVIEW community thought about it. The problem is simply to set up the hardware to continuously acquire n points from a PCI-6052E DAQ card in response to a digital trigger. The hardware should pause and wait until the next trigger, after which it should read another n points, and so on...
Details: This is a sonar application which will drive a transducer, so i'm using one of the counters to generate a pulse train (frequency 3 - 12 Hz, depending on range setting) which effectively sends a 'ping'. This counter is looped back into the PFI0/TRIG port to trigger the start of the A/D.
I do not want to contin uously acquire data. I only want to acquire n points, and then pause the acquisition until the next ping arrives. Ideally, i would like to start off a process which makes the card do this, entirely from hardware, but i have yet to find an elegant way. As it stands i can:
- start a continuous acquisition (no good, i only want to get n points after a trigger) or - put the AI Control vi, programmed to respond to a digital trigger, inside of a while loop (no good, since the AI Read Buffer command will be dependent on the AI Control command, and the AI Read takes quite long, and i miss some triggers before i can re-arm it - essentially, i'm dropping pings). Besides, i'm using software to read, which i want to avoid.
or - use scan clock gating (i'd like to get n samples, i'm afraid of missing samples by letting the gate pulse go too long or short).
If thought about putting the AI Read vi in a while loop, which is concurrent with the AI Control in another while loop, but i can't guar antee order of execution, and it seems hokey, frankly.
This seems like a standard operation, how should this be handled?
WOW!!! this sounds very interesting. I think that scan clock gating is not the option for you because of the pulse going too long or short thereby effecting the points you want to read.
This can be done using advanced AI programming (the way i call it). Basically you use AI Config,Trigger Config before you enter the while loop. Within the while loop you call AI Control (controlcode=start), AI Read (readposition=relative to trigger point) and then AI Control again (controlcode=pause immediately). This while loop would essentially be waiting for trigger. Once the trigger comes, you start the clock on the board, acquire the data relative to the trigger point and then pause the clock on the board and wait for the next trigger. The number of points would be equal to the buf fer size.
Pausing the clock is a must, otherwise driver thinks that the board is still busy acquiring the data from the previous trigger ,when you start the clock during the next iteration of the while loop.Once you are done then call AI Clear.
The only downside to this technique is that you might miss some trigger points depending on the speed of your trigger pulses. This makes sense because you are continously starting and stoping the clock on the baord and this takes time for the call to reach the board thru software layer plus time takes by the board to actually stop/start the clock. However if your ping (trigger) signal are slower than what it takes the board to start/read/stop, then this is the efficient and the best way to do.
I think I have found a LabVIEW shipping example that does exactly what you are trying to do. It uses to counters on the board to do a retriggerable finite analog acquisition. To find this example, open up your NI Example Finder by going to Help>>Find Examples... in the menu bar of the front panel window. When the NI Example Finder opens, browse through the following folders, Hardware Input and Output >> DAQmx >> Synchronization >> Multi-Function, to find the example called "Multi-Function-Ctr Retrigg Pulse Train Generation for AI Sample Clock.vi".
This example demonstrates how to generate a finite retriggerable digital pulse train from a Counter to be used as the clock for Analog Input. This example utilizes two counters.
That's not a a problem at all. The following is a link to a program that does the same thing except that it is written using the Traditional DAQ driver. http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B45EACE3F09F56A4E034080020E74861