Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Acquisition boards synchronisation with digital outputs and analog i/o

Solved!
Go to solution
Hello everyone,
I wrote a script in MATLAB to perform an experiment with 3 NI acquisition boards (NI 6366) that need to be synchronized. Here is a minimal example of what I want to do:
session = daq.createSession('ni') ;
session.Rate = 2e6 ;
inch1 = addAnalogInputChannel(session,'Dev1', 'ai0', 'Voltage'); inch1.TerminalConfig = 'Differential';
inch2 = addAnalogInputChannel(session,'Dev2', 'ai0', 'Voltage'); inch2.TerminalConfig = 'Differential';
inch3 = addAnalogInputChannel(session,'Dev3', 'ai0', 'Voltage'); inch3.TerminalConfig = 'Differential' ;
addDigitalChannel(session,'Dev1','port0/line3','OutputOnly') ;
addDigitalChannel(session,'Dev2','port0/line4','OutputOnly') ;
addDigitalChannel(session,'Dev3','port0/line5','OutputOnly') ;
addAnalogOutputChannel(session,'Dev1', 'ao0', 'Voltage') ;
addAnalogOutputChannel(session,'Dev2', 'ao0', 'Voltage') ;
addAnalogOutputChannel(session,'Dev3', 'ao0', 'Voltage') ;
addClockConnection(session,'Dev2/PFI9','Dev1/PFI0','ScanClock') ; % Dev2/PFI9 and Dev1/PFI0 are physically connected
addClockConnection(session,'Dev2/PFI9','Dev3/PFI0','ScanClock') ; % Dev2/PFI9 and Dev3/PFI0 are physically connected
queueOutputData(session,zeros(2000,5)) ;
[output,time,~] = startForeground(session) ;
But when I run this script I get the following error:
Output underflow event: Last valid output was scannumber 2000.
When I delete an analog input or digital output on the Dev3 board, the script works. Also, the script works on another PC. I use R2020b.
 
Where does the error come from?

 

0 Kudos
Message 1 of 5
(916 Views)

While I don't know the Matlab text API, I think you may have minimized your example too much.

 

It sure looks to me like you're trying to combine AI, DO, and AO into a single 'session' which I take to be analogous to a task.  DAQmx will require distinct tasks for each distinct type of I/O.

 

But since the error you report is more subtle than that, I kinda suspect that you stripped too much code out of your posted example.  The error you report sounds like it's due to:

- a non-regenerating output task

- where you try to generate more samples than you've written to the task

 

Regeneration is enabled by default for continuous tasks.  I'm not certain about finite tasks so those might be non-regenerating by default.   You either need to allow regeneration (if appropriate for your app) or write enough data to the task often enough to keep up with the signal generation rate.

 

 

-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 5
(895 Views)

Thank you very much for your message.

 

I don't think the issue comes from regeneration because the task is not continuous: the acquisition is ran for 1ms at 2MHz, leading to a vector of 2000 points.

 

I just noticed that when I decrease the sampling rate from 2MHz to 1.5MHz or lower, I get no error message.

 

The script works fine when I remove the clock connection between each board.

 

Since the script works fine on another computer with same MATLAB version, is it computer related? Something wrong with the USB speed maybe?

0 Kudos
Message 3 of 5
(842 Views)
Solution
Accepted by wbriand

Sorry, I just don't have any familiarity at all with the Matlab-based API.  

 

I don't *see* anything in the code that selects between finite and continuous sampling.  You've configured 3 DO lines and 3 AO channels, but appear to be writing data to only 5 of the 6 destinations.  You're also writing all zeros, which isn't going to be very helpful for evaluating whether the signals are being generated properly or not.  It also doesn't make sense to me that *removing* clock connections would help code that depends on those connections.

 

It's possible that the "underflow" is caused by not writing samples to 1 of the 6 output destinations.  But the fact that things worked at a 1.5 MHz rate while not working at 2.0 MHz suggests to me that USB transfer speed limitations might be part of the problem.  One can expect USB performance to vary somewhat from one PC to another, that's why speed benchmarks tend to emphasize that performance is system dependent.

 

 

-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 5
(833 Views)

One can expect USB performance to vary somewhat from one PC to another, that's why speed benchmarks tend to emphasize that performance is system dependent.


I think you were right about this point. In my configuration, the 3 acquisition boards are connected to the same USB hub. I unplugged one of the NI from this hub and plug it directly to one of the laptop USB port. Now my script runs without error.

 

Thank you for your help.

0 Kudos
Message 5 of 5
(794 Views)