USB-6211

[Zuc_Lab]

Hi,

I have read the specifications, the data sheet and some questions around the net but i still have a doubt about the USB-6211 device. In particular my question is on trigger. Because, if i have got it right, this device can't trigger on analogic signal, but can trigger on the digital ones, is it correct?

Because in my vi I need to measure the delay between two digital signal. One is generetad by the device, the second, with a short delay, is measured on another channel, so a measure the propagation of the first high state. I was sure that the trigger of the measure, when the first signal goes high, was allowed by the USB-6211, but now i don't think so.

Thank you for the help!

Best regrad,

Zuc

[Kevin_Price]

I don't fully understand what you're wanting to do, and can't look at your code unless you "Save for Previous Version" back to, let's say LV 2016.

I think I recall that the USB-6211 device is bus-powered and more limited in capabilities and features than the typical desktop M-series board or the more expensive USB M-series devices.   No support for hardware-clocked DIO for example.

But it does have counters that support "two edge separation" timing measurements if you have signals that are compatible with digital logic (in terms of high/low voltages and rise/fall times).  It kinda sounds like that's how you might want to approach things.

-Kevin P

[Zuc_Lab]

Hi,

Thank you for the post and sorry if I created some confusion. The DigitalT.vi is only a try, the true aim is to create a bigger vi. In particular the example here only tries to synchronize the digital generation on a line to the acquisition of the digital signal on another line. This is because the step generated to close the contact is propagated to another device and I need a precise measure of this delay.

Then, the PTT.vi vi needs to synchronize the rising edge of the digital signal also with the generation of a tone and a measure of that tone (obviously using different channels), in order to measure the delay in propagating the signal and its possible distortion.

Checking the USB-6211 data sheet I have only found information about an external trigger. Anyway I want to understand better how and when using the DAQmx Trigger.vi and Create Timinig souce.vi.

A last doubt: since I have read that the time duration of an iteration of while loop change a lot since Windows is not a RTOS. Is it worth to use it when I need to read or write data with a DAQ?

Thank you very much for the help because it’s really important having a full and deep comprehension of Labview and how it works!

Best Regards,

Zuc

[Kevin_Price]

I understand somewhat now, still not 100%.

1. To measure a time delay between digital signals, you should use a counter task, and probably configure it to do a two-edge separation measurement.  Then you just specify which signal 7 edge starts the measurement and which one ends it.

2. To sync the generation and measurement of a "tone" sounds like a pair of analog tasks -- one for output, one for input.  I generally advocate the use of a shared sample clock to sync tasks that want to sample at the same rate.   For example, consider your AO task to be the master, configure its sample clock the normal way, but configure your AI task to use "/Dev1/ao/SampleClock" as the 'source' input to DAQmx Timing.  Then be sure to start the AI task *before* you start the AO task.

3. I *think*, but am not quite sure that you want to further sync these AI tasks to one of the digital signals you're using for the delay measurement.  You can manage this by configuring the AO task to use that digital signal as a Start trigger.  You don't need to bother setting up triggering for AI b/c it depends on the AO sample clock which won't start until AO gets triggered.

You probably shouldn't get involved with "Create Timing Source".   That has to do with Timed Loops which most of us consider to be pretty rarely helpful under Windows and even more rarely necessary.  Its elevated priority and single-threading can even be a hindrance.

When you are doing buffered, hardware-clocked DAQ you generally don't need to be very concerned with Windows' timing variability.  That's what buffering is *for*, and DAQmx manages it quite well.

-Kevin P