Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Experiencing issues when wiring an analog output directly to an analog input

Solved!
Go to solution

Hello friends,

 

I am working with an NI USB-6229 BNC device.

 

I am attempting to connect the Ao0 bnc terminal directly to the Ai0 bnc terminal so that I can read whatever samples are delivered out the Ao0 pin and log them to a TDMS file after being read back in via the analog input. But, with Ao0 hooked up directly to Ai0, all the samples that get logged to the TDMS file have values that are 0 or very close to it.

 

If I hook Ao0 to an oscilloscope and provide a continuous sine wave using a function generator on the Ai0 terminal...the output shows on the oscilloscope as expected and the TDMS file contains the sample values that resemble the provided sine wave.

 

What might be causing this behavior? If I need to provide more information about my setup and the problem at hand lmk!

 

Edit: Changed title

0 Kudos
Message 1 of 4
(2,385 Views)
Solution
Accepted by topic author b!tmaster

Speculative guess: your AO task (and maybe also AI) is a finite sampling task and your program runs your tasks in sequence instead of in parallel.  Thus the AO is generating when the AI isn't looking and the AI is looking when the AO isn't generating.

 

Rationale: the scope & fn generator test you did suggest pretty strongly that the right kind of single goes out of AO and that AI can read signals coming in.   One of the remaining suspects would be timing issues due to programming that wouldn't necessarily be obvious in your test.

 

If you think this guess is wrong or you're unsure, post your code.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 4
(2,372 Views)

Kevin,

 

You are correct that my AO task & my AI tasks use finite sampling quantity mode. It is possible that the tasks are not being ran in parallel. Below is the configuration code for my analog output task & multi channel writer.

 

_task = new Task("AnalogOutputTask");
_task.AOChannels.CreateVoltageChannel(_deviceLocator.DeviceName + "/ao0", "ao0", -10, 10, AOVoltageUnits.Volts);
_task.AOChannels.CreateVoltageChannel(_deviceLocator.DeviceName + "/ao1", "ao1", -10, 10, AOVoltageUnits.Volts);
_task.Timing.ConfigureSampleClock("", 5000, SampleClockActiveEdge.Rising, SampleQuantityMode.FiniteSamples, _deliverySamples[0].SampleCount);
_task.Triggers.StartTrigger.ConfigureDigitalEdgeTrigger("/" + _deviceLocator.DeviceName + "/PFI1", DigitalEdgeStartTriggerEdge.Rising);
_task.Control(TaskAction.Verify);
_writer = new AnalogMultiChannelWriter(_task.Stream);

Below is the configuration code for my analog input task & multi channel reader.

 

_task = _taskFactory.GetTask("UptAnalogInputTask");
_task.AIChannels.CreateVoltageChannel(_deviceLocator.DeviceName + "/ai0", "ai0", AITerminalConfiguration.Differential, -10.0, 10.0, AIVoltageUnits.Volts);
_task.AIChannels.CreateVoltageChannel(_deviceLocator.DeviceName + "/ai1", "ai1", AITerminalConfiguration.Differential, -10.0, 10.0, AIVoltageUnits.Volts);
_task.Timing.ConfigureSampleClock("", 20000, SampleClockActiveEdge.Rising, SampleQuantityMode.FiniteSamples, _numberOfSamplesToRead);
_task.ConfigureLogging("C:\\tmp\\input.tdms", TdmsLoggingOperation.OpenOrCreate, LoggingMode.LogAndRead, "Group Name");
_task.Triggers.StartTrigger.ConfigureDigitalEdgeTrigger("/" + _deviceLocator.DeviceName + "/PFI1", DigitalEdgeStartTriggerEdge.Rising);
_task.Control(TaskAction.Verify);
_reader = new AnalogMultiChannelReader(_task.Stream);

It should be noted that _numberOfSamplesToRead is guaranteed to be exactly 4x greater than _deliverySamples[0].SampleCount. The input is sampled 4x as fast as the output (and therefore reads 4x the number of samples that are output) in order to prevent under-sampling of the output signal.

 

Given the configuration code above, I expected my analog output and analog input tasks to run in parallel since they are both using the same digital input start trigger, despite them not using the same clock source.

 

*** While writing a response to your question I figured out what the issue was ***

The code that was controlling the starting of these tasks is shown below.

 

_inputTask.Start();
ReadSamples = _reader.ReadMultiSample(_numberOfSamplesToRead);
_writer.WriteWaveform(false, _deliverySamples);
_outputTask.Start();

There are a couple problems with this code. Firstly, I f'd up by starting the analog input task before the analog output. It makes sense that I was never seeing the analog output samples on the analog input because the analog input task was executing and completing (or getting blocked and throwing a timeout exception) before the analog output task was even started. The second problem I see with this code is that even if the order of statements weren't an issue, I should really be doing a non-blocking read here by using the BeginReadMultiSample() method instead.

 

I was able to get my code to receive samples on the analog input from the analog output by manipulating the order of the statements in the previous code block as shown below.

_writer.WriteWaveform(false, _deliverySamples);
_outputTask.Start();
_inputTask.Start();
ReadSamples = _reader.ReadMultiSample(_numberOfSamplesToRead);

So, I believe Kevins speculative guess was spot on. The previous sequence in which I was starting my tasks was preventing the tasks from being ran in parallel. I had to start my tasks in a different sequence in order for the tasks to be ran in parallel. Is this correct? Are my tasks being ran in parallel now?

 

Message 3 of 4
(2,363 Views)

Sorry, I don't know the specific meaning of any of the text API calls.  I only use the LabVIEW API.  I know stuff about *what* the devices can do, but not how to make it happen through the text API.

 

Specifically, the stuff about blocking and non-blocking Reads sounds sensible, but I have zero actual knowledge.  All I can say is that the final code section *looks* better b/c both tasks get started before making a call that *might* block and wait for finite task completion.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 4
(2,357 Views)