09-27-2017 03:40 PM
I haven't had much luck finding a suitable labview vi replacement for what I was doing with data acquisition using Component works CWAI acquire in VB. I have a tube line with variable speed and wish to sample at a fixed distance along the tube. Currently I sample every 1 mm of tube length independent of the linespeed (Capstan driven). The examples I have tried that utilize PFI0 as the trigger and/or clock are still asking for a sample rate and then recording the data to TDMS or Excel in units of the input sample rate not a variable rate which would come from a variable rate PFI0 if it was truly controlling sample rate. Perhaps someone out there can point me to a better example. (My PFI0 is sourced from an encoder pulse attached to a variable speed capstan. I am testing with X series USB-6356. Successfully been using PCIe 6023-6025 for last 20 yrs on production line with CWAI acquire)
Thanks.
Solved! Go to Solution.
09-28-2017 07:00 AM
While I haven't used PFI 0 to generate a single sample point, I have used it to trigger DAQmx to collect a set of N Samples from M Channels at some fixed clock rate (i.e. 100 samples at 1KHz from 4 channels). "Reasoning by analogy" (a sure-fire way to screw up!), I see no reason it couldn't trigger 1 sample from M channels. I was using a USB-6009 or USB-6002, a fairly simple DAQ device.
What I'm less certain about (without doing some tests, and who has time?) is what the frequency limits on the PFI 0 pulses would be. Should be simple to write a tiny program and test it, I would think ...
Bob Schor
09-28-2017 08:29 AM
1. It should be fine to use PFI0 or PFI-whatever as an external sample clock signal. You'll get one sample per active edge. With the clocking signal coming from an encoder, you get data that's equally-spaced in *position* rather than in *time*.
2. You need to step in and take control over what's being written to file. Wherever you see a waveform dt or a time vector being generated, step in and override it with your own dx of 1.0 mm. Then train yourself to think of the data as it relates to *position* rather than the typical *time* seen in most examples.
3. [Advanced]. If necessary, you'd also be able to capture timestamps for those encoder pulses with a counter task. It takes a little learning curve to get the tasks configured and sync'ed correctly, but it's very possible if it turns out you also need timing or speed information.
-Kevin P