Sync quadrature input with analog in

[DMJeff]

Hi all,

LabVIEW 2015 (User is on older computers)

Windows XP, 7, 10

NI DAQ USB-6212

SCB-68A

I have an application I've been using/modifying for years.

The application reads a number of analog inputs, charts them for the user to see, and allows the user to save them to a spreadsheet if anything interesting is happening.

Now, they want to add a 'position sensor' that provides a quadrature input.

I found the example code, got what I needed, and I can display the position data from the linear encoder.

All good.

The next task is to add the new position 'waveform' to the output file.

Since the data is read with different tasks, I figured I would just take the array of positions from the quadrature, make it into a waveform, add that waveform to the end of the array of waveforms returned from the analog in read, and then write all that to the file.

However, the data isn't adding on 'below' (as you'd expect from time stamp data in a spreadsheet), but is added as a parallel set of data.

I get an spreadsheet with 75 rows, but lots of columns.

See the example code and spreadsheet.

What I'd like from this overly simplified example is 3 columns, 1 for time, 1 for 'pressure' and 1 for position.

Thoughts?

Thanks,
Jeff

[cbutcher · Accepted solution]

I think the simple solution is to take your Shift Register initialization and replace it with a Waveform Constant, Initialize Array and a size that you expect for all tasks (i.e. N Positions + N Analog Inputs).

Then inside your loop, rather than using Insert Into Array, use a For loop with autoindexing (hence the requirement to initialize the array before starting to the correct length, even if they're all empty) and use Append Waveforms.vi.

Then your Array Size on the outside of the Shift Register (after you click stop) will be 2 (in this example), not e.g. 75 if you run it for ~(75/2)*0.01 seconds.

Note that this doesn't "sync" your outputs - your Position task has no t0 for the waveform and so the 'time' values won't necessarily be accurately the same. If you're happy to simply measure them at the 'same' time and then use the Analog timestamp, that's probably fine. Otherwise you could, for example, output a waveform directly from the position task.

[DMJeff]

Hi cbutcher,

Thanks, that worked.  I knew there had to be a straight forward approach to this.

Just an aside, the DAQ Mx Read, from a counter, doesn't offer a waveform output option, just different arrays.

So, I grabbed the t0 and dt values from the pressure analog in (1st item waveform components) and 'built' a waveform with the position array data.

Thanks for the help,

Jeff

[BertMcMahan · Accepted solution]

Your data isn't going to be synchronized with your code as-is. First of all, each loop should have just a single timing source- that should be your DAQmx Read function, not the Wait until Next Ms Multiple.

Second, your quadrature input channel has no sample clock, so you're just grabbing 75 samples in a row. Your analog sample rate is 1 kHz but you're sampling 75 samples per 10 ms, or 750 Hz- which means you're building up a ton of old analog input samples that aren't being read. You'll run into a buffer overflow with this method. Also, your quadrature data will drift by 1/4 of a second each second it runs, as you're getting new data from its buffer each time it loops, but you're getting old data from the analog channel.

DAQmx Read is a blocking function- it will take however long it needs to take to read its data, so you don't need another loop timer.

Use this sample code:

https://forums.ni.com/t5/Example-Code/Synchronize-Encoder-Counter-Input-and-Analog-Input-with-DAQmx/...

You need to export your Analog Input sample clock to be the sample clock for the Counter Input channel, then read the same number of channels from both of them. I do this exact same thing all the time and I can tell you your code will not give you good timing synchronization, and it will in fact break when you run it too long.

[DMJeff]

Hi BertMcMahan,

Thank you for the added information.  I certainly would have run into the overflow in short order.

I appreciate your anticipation of the looming data collection issue.  : )

Thanks,
Jeff