Hello,I have a test project, while interact with the UUT/DUT and doing a series of measurements, I need to monitor an analog signal to know if that signal ever drop under a thresold voltage. I only need to get if it happens at the end of the test.
In fact I can use a 555 timer to do it, where i need to use AO to set the threshold, and end of the test, use AI to check the 555 timer output. The crons of this solution is that it need extra HW circuits.
Today it suddently come to my mind that perhaps DAQ trigger function can do it purely by SW. Can anybody familiar with advanced DAQ functions, like triggerring; offer some advice?
I use Labview to control DAQ; and TestStand to call the vis to integrate the test sequence.
If all you need to do is take one "sample" (where this could mean "take 100 readings at 1KHz and report their mean, range, median, and standard deviation"), why not simply create a sub-VI with the following DAQmx functions: Create Task, Configure Channels, Configure Timing, Start Task, Read, and Clear Task? Depending on what you specify for the Read, the VI might take a fraction of a second to run, but if that's a problem, you could run it as an Asynchronous VI (Start Asynchronous Call, perhaps with Return).
P.S. -- I used to advocate an even simpler way to do these simple DAQmx "tasks", namely to create a Task in MAX or the Project, but never to use the Dreaded DAQ Assistant. I recently had a slightly complex "set of tasks" and got burned by my own shortcut, so I spelled out, above, the entire lengthy sequence. However, if the only thing you will do with this AI "task" is this one "task" (hmm, I'm overworking this word), then you might consider using New Task in Project to "bundle" the Device, Channels, Timing, Voltage Settings, Mode, etc. into a single Task Constant, allowing your DAQ code to become Start Task (with a Task Constant wired to Task In, you click the little downward triangle and choose the Task you just created from the Drop-down list), Read, and Clear Task. This works nicely, simply, and even in an Executable.
Thanks Bob for the reply.
Asynchronously Calling a VI to keep measuring and check the analog voltage signal seems a valid SW approach; meanwhile my main VI can continue its jobs(I don’t use ‘task’ here as they may be other tasks, not DAQ tasks), and after the jobs finish, the main VI collect flag (of whether the voltage dropped under a level) from the asynchronously called vi.
The question arises from this method is, no matter how big my sample frequency is, there is theoretically possibility that it may not able to detect a very short period of the voltage drop. Example, if sample rate is 1000/S, then it may not detect a short drop of 0.1mS. Also, when the computer is compare the voltage measured and the threshold, there could be a voltage drop happened but not detected.
End of the day if I have no other solution, I will implement this solution with possibly high sample frequency. Thanks in advance.
But before that I’d still ask, are there any possible methods that the DAQ can help to detect and compare in the HW manner?
By the way, I wonder should I put this in the DAQ forum instead….
You ask a very good (and fundamental) question about digital sampling of analog signals, and the realization that you cannot digitally represent frequency data that is higher than your sampling frequency.
Sometimes, what one does is to build (out of "analog" components) a circuit that will "shape" the signal for you. For example, a recent project involved sampling (at 1KHz) responses arising from a stimulator that had no easily-recorded "trigger" output. We built a photo-diode circuit that we taped near the LED that flashed when the pulses were emitted. We ran the resulting pulse through a circuit that made a TTL pulse -- I requested that the pulse be 2 msec wide (anything longer than 1 msec would have been sufficient) to ensure that if we, say, sampled this pulse with a Digital Input, we'd be certain that if we sampled at 1 KHz, we'd be guaranteed to see at least one TTL "High" when the pulse occurred.
Think about your requirements, and see about designing a TTL circuit with analog inputs that will similarly provide a "wide" TTL pulse when the Event of Interest occurs.