Multi-device DAQ system: USB-205

[toehead]

Hello!

We are in the process of creating a test system that will be using multiple USB-205 devices to acquire waveforms for devices under test. They will be acquiring at 100 KS/s, and the goal will be to have one USB-205 per DUT, with a goal of 12 devices being tested at one time. 

We are targeting a 2 Hz read rate, with a 250 ms. acquisition.  

We've been working to implement our code in LabView, and are able to successfully run up to 4 USB-205 units. 

When adding a 5th unit, we get error code 29 (Read buffer data being overwritten prior to being read). All devices were on a single USB 3.0 hub. 

At first we thought this was a bandwidth issue, so we tried the following: 

- Lowering the sampling rate from 100 KS/s to 10 KS/s: No effect. 

- Lowering the read rate from 2 Hz. to 1 Hz: No effect. 

- Adding additional USB hubs to split the devices over multiple hubs: No effect

- Adding a second USB controller card to the PC to split the devices over multiple USB controllers: No effect. 

It is seeming less likely that this is a bandwidth issue. 

 

We would appreciate any help that you can offer!

 

 

Edited November 27, 2023 by toehead

[toehead]

To add on: 

We are using the Analog 1D Wfm NChan Nsamp implementation of ULx Read. 

[JRys]

Our ULx LabVIEW support is not optimized for multiple devices, and we don't test applications such as yours, so it is difficult to provide support. A customer recently tried to use three devices to acquire 24 channels at 10 kHz and was having similar trouble. There are a couple of things to try that may improve the situation. On the ULx Timing VI, make the samples per channel very large and request large amounts in the loop that reads the data. And minimize what is done in the loop.

[toehead]

Thank you very much. We will try this. 

 

You mention that the labview integration is not optimized for such a use case. Are other implementations of the UL more targeted towards multiple devices?

[JRys]

Our other programs, like DAQami, TracerDAQ, and DASYLab programs, also use ULx and would perform the same.  You may get better results with a C program. Python has too much overhead, so avoid it.

[toehead]

Unfortunately, little luck as we are already very optimized in terms of what is happening in the loop. The data is tested and the count is checked. If need be, data is pushed off to a Data Processing Message Handling Loop to be processed and written to file outside of the acquisition loop. 

 

 

We tried also running separate EXEs of the individual program, with three modules launched by one of the EXEs and three launched by a separate EXE, with the thought that they would have separate memory spaces. 

 

The first three worked, and the second three launched had the same error. 

[toehead]

Any other ideas? Is there a way to launch multiple instances of the UL to avoid this issue? On paper the USB-205 is exactly what we need (and we already bought them) but it seems like this issue will prevent us from using them in this application. 

[toehead]

We also tried staggering the acquisitions between devices, by setting 3 units to acquire at a time and offsetting the timing so that the second set of three would start acquisition after the first three were completed. Timing delay between groups was 500 ms. delay.

 

Same issue: The first three modules worked, and the second three modules had overrun issues. We had the same result with a much longer delay (2 seconds).  It seems like this might be an issue with  quantity of parts, vs. the actual bandwidth/timing/etc. 

The error doesn't make a lot of sense to me. We are well under the stated part capability and adjusting the amount of data received or the timing between aquisitions makes no difference. 

Is this an issue with the ULx driver? Is there any potential improvements that can be made?

 

[JRys]

I modified my 3-device example to work with 6 devices. I have two running at 100k Hz, two at 50k Hz, and two at 25k Hz. It continues to run even when it writes the data to separate files. Error 29 means the driver was held up and the onboard FIFO buffer filled. It could be that your computer needs to be faster, or there's another program using up resources. 

I have a Dell Precision 5820 with an Intel i9-10920x 3.5 GHz and 8 USB 3.x ports. I've attached my test app below.

 

6x Devices.vi

[toehead]

Thank you! 

 

We were able to get this to work. Essentially, the first iteration had each DAQ running in a parallel loop. All loops were started at the same time. In this case, we could run up to 4 DAQs before issues. 

We changed the code to stagger the start of each loop by 100 ms. and were able to increase the number of DAQs to 6, which is the max that we had in house. We have 6 more just delivered, and we will report back. 

 

Also, do you know what ESD protections exist on the Analog Inputs of this USB-205? I think I damaged one with an ESD event (winter in new england) and want to understand if we need to add additional ESD protections 

[JRys]

The USB-205 uses the 0603ESDA surge suppressor to combat ESD. 

 

[toehead]

Thank you! That should be quite robust. I might add something extra on the inputs that will see a lot of handling in our application.

I accidently discharged into AI0, which is now reading only zero volts. 

[toehead]

An update and a further question: 

 

First the update: 

1) We were able to get this working robustly with 12 devices (at slightly less than 2 Hz. ) through the following methods

- Use semaphores to lock out the number of simultaneous acquisitions to 3. 

- Delay/stagger the start of each parallel loop such that we minimize overlap. We mathematically calculate delay that gives us the lowest amount of overlap for the desired acquisition rate and number of devices. 

 

This is working extremely well, and the hardware is impressively capable for the price. We're pretty thrilled with that. 

 

Next, the question: 

 

What sort of short circuit protection exists on the analog output of these devices is there a chance to damage the analog output if it is enabled into a dead short to analog ground. 

 

[JRys]

There's no protection other than an ESD suppressor. The analog outputs come directly from the AD5623 D/A chip. 

[toehead]

Thank you, we will reach out to Analog Devices to ask. 

 

Appreciate all the help!