I need to build an automated test set using a PXIe-5442 AWG and niFgen to generate signals for a device-under-test and a PXI-5105 and niScope to record the device's response to the signals. This is my first time with LabView and I'm looking for some guidance. I'm not sure I understand the concepts well enough to find the right examples and forum posts. I'm using LabVIEW 2020.
Below is a representative example of my automated test. All signals are 1.00 Volt amplitude. Rather than switching the output on and off to create the desired space between signals, I've used a DC 0 volt waveform for easy scripting:
1. Sine Chirp, 30 kHz - 60 kHz, 1 second duration
2. DC 0 Volts, 0.5 second duration
3. Sine Chirp, 120 kHz - 125 kHz, 10 seconds duration
4. DC 0 Volts, 0.5 seconds duration
5. Sine, 10 Hz, 10 seconds duration
6. DC 0 Volts, 5 seconds duration
7. Sine, 150 kHz, 10 seconds duration
I thought Frequency List generation mode could work with my test structure, but it doesn't seem to me to support an arbitrary waveform like the chirps. The next easiest mode seems to be script mode? Using a (very) slightly modified LabVIEW example, Fgen Arb Script.vi (attached), I've been able to write a script that can step through a series of sine waves using the attached waveform definitions and script.
I was hoping to get some opinions on next steps.
It seems convenient to make csv files with my various waveforms instead of using the Waveform Information Array input in the attached vi. I've found examples using the Read Delimited Spreadsheet vi. One inflexible part of the attached vi is that I'm using # of points with a fixed sample rate to control frequency, leading to some needlessly large waveform definitions for lower frequencies. Seems clumsy but easy.
For the acquisition side of this program using the PXI-5105, it would be acceptable to initiate one long recording for the entire automated test and save it to a file. Because the real test is 10 to 15 minutes long, a desirable complication would be to trigger off the generation side of the program to create a separate file for each step in the above automated test. DC 0V signals would not need to be recorded, but could be recorded and discarded. I've looked at the niScope example VI's for fetching data and saving to a file, but haven't tried to integrate with my signal generation yet. With a script running like I attached and exporting the clock and a trigger from the PXIe-5442 using the Export Signal vi, it seems I'd get a trigger for each repetition of each signal definition which wouldn't provide a useful way to notify the PXI-5105 when the script has moved on to the next step of the automated test? Any thoughts on how to approach this?
Any higher-level direction or links to examples of pieces of the described functionality would be appreciated.
Solved! Go to Solution.
Your high-level idea seems right, I would also approach this in a similar fashion - of course, a bunch of optimizations due to the duration of the test.
Does the duration between chirps need to be so precise? if not software level timing will easily get you in the order of ms.
At a high level, I will configure Scope to start acquisition for a predefined duration when it gets trigger from the FGEN. This way, both generation and acquisition are synchronized.
Overall, I will have three parameters as arrays,
Before starting to iterate these test conditions, setup FGEN and SCOPE for triggering, voltage range, sampling rate etc.,
Iterate over each element of the three parameters described above. During the dwell/deadtime, I would reconfigure the FGEN and SCOPE for the next chirp signal, especially the acquisition duration. I am not sure, but if FGEN and SCOPE permit you could even configure a stop trigger, in addition to the start trigger so that both acq and gen are paired perfectly.
Thanks Santhosh, I'll get working on some more of the details and come back with questions that come up. If I get through the program without more questions, I'll accept your previous post as my answer.
Millisecond timing accuracy for the duration between sine pulses and/or chirps is plenty, so I'll stick to software timing.