Buffered, triggered analogue capture

[marv_mcd]

Hello there,

I am hoping someone might be able to help me with my problem please.  I'll try and describe the situation.

- I have a pulse train from a motor encoder attached to counter 0 of my 6211 USB-daq card.  This is set up to calculate pulse-periods.  In my read loop I am reading 10 samples at a time.  This is working great.

- I also want to read say 4 analog samples on each rising edge of this encoder pulse train. I have set up a finite-sample sample clock with a a fast sample time. I have set up the trigger to be off PFI0 and I have fed the pulse train into that pin as well.  

- In the loop I then read 4 samples per iteration.

- When I turn the motor shaft slowly by hand I confirm that all is working as it should - I get 10 period calculations every 10 edges and I get 4 analog values every single edge.

Now for the problem.  

Depending no motor speed in the time it takes for me to iterate around my loop 5 (for example) rising edges may have occured.  This is no problem for the period count - they are being buffered anyway.  But, I only receive the latest 4 analog readings - I will have missed 4 sets of data.

What I need to be able to do is read a 2D array of (for example) 4 sets of 4 data points.  I can't figure out how to do this though...

Please can anyone help?

Thanks very much for any assitance,

Martin

[ZachHindes]

What you want to do is generally referred to as a retriggered finite acquisition.  For every pulse from your encoder you want to acquire 4 samples from analog input.  What you have coded is a retriggered finite acquisition of 4 samples, which is a great start.  Unfortunately, as you've discovered, this is software timed!  If you start going fast, then you'll almost certainly miss samples, etc.  Also, unfortunately, your hardware doesn't support this natively.

Generally, the best idea is to use a counter to produce 4 sample clocks for AI off of a start trigger from your encoder.  Unfortunately, this takes 2 counters, and you're already using one.  What I would like to suggest, though, is using the pulse from your encoder as your sample clock for AI.  Now, we'll use the fact that this is a multiplexed device to our advantage.  Look at the screenshot I've posted, and I'll try to describe what this is doing.

 

First, create a task.  Now, add ai0 to the task 4 times with a different name each time.  NOTE: If you want to sample 4 separate channels, you could do this with a single AI Voltage Channel vi and the string "Dev1/ai0:3" or whatever you need.  Now set up the Sample Clock to sample off of PFI0 (your encoder).  Finally, set up your AIConv.Rate to whatever rate you want to sample at every pulse of your encoder.  From then on, reading 1 sample at a time gives you a sample from all 4 of your channels that you care about!

Edit: This post made me realize I need to install LabVIEW 2009 and DAQmx 9.0 on my main machine so I could post a snippet!

Message Edited by Zach Hindes on 08-12-2009 09:52 AM

[marv_mcd]

Hello there Zach,

Thanks very much for taking the time to reply.  I have implemented this and it seems to be working perfectly, thank you.

The only thing I was unable to do was find the AIConv.Rate property within the DAQmx Timing property node.  Or rather I could find it in the Class Browser but for some reason when I selected it it didn't have any effect - I can't get it to display in the box.   I notice our license server has given me a Full rather than Professional license today, I don't know if that has anything to do with it.

Also,  I'm trying to figure out what the time interval is between the 4 samples I get.  Is it set by the AIConv.Rate property?  And if so what effect does the Rate property have in the Timing node?  No doubt these are newbie questions but I'm not too sure on them.

Thanks again for your help, I had all but given up hope of it being possible.

Best regards,

Martin

[ZachHindes · Accepted solution]

The LabVIEW version you have shouldn't matter with respect to DAQmx Properties.  On the DAQmx Timing Property Node it should be "More > AI Convert > Rate".  The time interval between your 4 samples is now governed by this property, AIConv.Rate.  The rate property on the DAQmx Timing.vi doesn't really mean anything since you're using an external sample clock (PFI0 from your encoder).  If you read multiple samples at a time as a waveform, it would modify the time between samples based upon that rate, but its really a best guess since we can't be certain what you're actually providing.  In the VI I posted, we're only reading 1 sample at a time anyways, so it really means nothing.

Hopefully you can get the AIConv.Rate attribute working, and if so, it looks like this should work for you!

[marv_mcd]

Hello,

I found the cause of my property node woes, or rather the NI tech support line did - the options become available if I go to Select Filter -> All Attributes in the context menu.

It seems that if I change the number of samples to read from 1 to say -1 or 20 etc, then I get the 2d array of points that I missed since my last call.  This is spot on.

Thanks for your help,

Martin

[marv_mcd]

Here is the code as I have it at the moment...

[marv_mcd]

I'm not sure how much difference synchronising the starting of the two tasks will have, if any, but I've added it in to the attached code snippet.

[ZachHindes]

Huh, you shouldn't need to disable filtering to show that attribute for your device.  It should recognize that your device supports the attribute and show it be default.  What version of DAQmx do you have installed?  I'll investigate why that attribute wasn't showing up, and hopefully we can fix it (if it hasn't already been fixed in a later release)

I'm glad everything worked out!