toehead

Is there any plan to support AOUTSCAN() on this hardware with future firmware updates? Is it a hardware limitation that prevents this from working?

Thank you for the response. That is what we figured but wanted to check with the experts. I assume the same is true for the Analog output?

Hello. We are using the USB-205 as the heart of a DAQ system. This includes generating a DIO trigger signal (length is 200 ms. ) to drive some actions. The timing of this is controlled by software (NI Labview) and is working correctly for the most part. However, being a software trigger, this has inherent variability that is dependent on the CPU load of the host computer. Is there any option to have a hardware-paced DIO signal on the USB-205? Basically, tell the USN-205 to drive DIO1 to be 5 V for 200 ms (or whatever number of cycles) ?

Thank you, we will reach out to Analog Devices to ask. Appreciate all the help!

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.

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.

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

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?

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.

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.

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?

To add on: We are using the Analog 1D Wfm NChan Nsamp implementation of ULx Read.

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!