Matthew Harrison

Fausto, In an effort to troubleshoot this, I spun up a virtual machine (VirtualBox) and passed the USB-231 through to it. Everything is running fine in that environment even though it is technically still on the same computer. So, based on this and all the other things we've checked, I'm assuming that my main machine has some driver or other software that is interfering with the ULx driver in some way. I'm not sure the best way to track that down, and there are many things that I cannot remove, but I would still like to solve this or at least know what was interfering. Could I just ask one last question: is there any known software incompatibilities with ULx that might help me to narrow this down? Best Wishes, Matt

Fausto, I did run a test of disabling the virus scanner completely, but I did not see any improvement. The serial number for my USB-231 is 217D963. Is is possible to update the firmware on the device? Can I check the current firmware version? I will work on setting up another machine to test on and see if that makes any difference. Best Wishes, Matt

Fausto, Again, thank you for your continued efforts to help with this frustrating problem. I definitely have virus scanning and there are numerous other background tasks running. I hope that does not turn out to be a showstopper for using this device. I am not seeing significant CPU or disk load, so I would hope that this level of background task execution is acceptable. I tried to quit or disable any background processes that I could, and while it may have increased the time until I would see an error, I am still typically hitting an error after around 1 - 5 minutes. If system performance is a significant factor, I can report that the laptop I'm testing on is an i9-8950HK, which is a 6-core 2.9 GHz processor and I have 32 GB of RAM. Perhaps you can clarify something for me about this error 29. Does it refer to buffers on the device itself, or buffers in the USB transfer that overflowing? In an effort to check for buffer overflows on the PC side of the USB interface, I have added code to the test VI to check for available samples. I was wondering if I would see a growing backlog of available samples as a lead-up to error 29. For what its worth, I do not see anything like that, but instead a very steady and small number of samples in the buffer. As you can see, I have the buffer configured at 100,000 samples (10 seconds worth at 10K acquisition rate) and we never get anywhere close to that. I also tried intentionally slowing my software acquisition loop so that it would overflow, and that leads to a different error 10017, but has the same explanatory text "Samples in the buffer were overwritten before they were read." So, this leads me to believe error 29 is an overflow on the device hardware buffer, but I would like you to confirm that if you can. Assuming that we're dealing with a buffer overflow on the device, it makes me wonder if I could be seeing an artifact of how the device is connected. I'm currently doing my testing with nothing connected to any of the IO connectors on the device. Are there certain signals that need to be grounded or connected in some other way in order to make things play nice? Along the line of thought that perhaps the hardware is not happy about the way I'm using it, I have also tried running the USB-231 off a powered hub to see if perhaps my laptop is not providing adequate current through the onboard USB connector. This did not make any difference that I could see- the problem persists. Best Wishes, Matt mcc-daq-overrun-error.vi

Fausto, Thank you for taking time to respond and for your efforts to reproduce this. I'm not sure why I'm seeing different behavior from you. The only difference I can see that seems possibly relevant is that you are on W10 and I'm on W11. I will try to see if I can find a W10 system to test on. Do you have access to a W11 machine to see if you can reproduce the issue? In an effort to troubleshoot on my end, I went ahead and uninstalled all the mccdaq components on my computer, and then reinstalled V6.75 as you suggested, which includes DAQami 4.2.1. Unfortunately, I'm still consistently seeing the same buffer overrun error. I apologize for the incorrect DAQami file that I sent previously. I've attached the correct file which is a 5 channel single-ended analog input with graphing display. Best Wishes, Matt 5 ch speed test.amicfg

I have been having consistent problems with data overrun errors acquiring data using Universal Library version 6.74. I have also had the exact same behavior on UL version 6.73. I'm using a USB-231, and I also saw the same behavior on an older USB-1208fs. Basically, what is happening is after acquiring for some time, typically a minute or two, but sometimes after only a few seconds, I will get a data overrun error (error 29). My primary use case is in a LabVIEW program, but I see the same error in DAQami (image attached). I'm running LabVIEW 2022 Q3 on Windows 11 22H2. I'm attaching a simple LabVIEW VI that demonstrates the problem as well as a DAQami configuration file that also shows the issue. I have found that if I lower the acquisition rate, it will take longer to get the overrun error, but it will still overrun. I'm running below the documented max acquisition rate and I have set an adequate buffer size, so I expect that this should not be happening. I'm hoping that there is some workaround for this behavior or a possible fix. If not, can you document what the actual max acquisition rate is so that I can stay under it without overflow? Best Wishes, Matt daqami.mcfg mcc-daq-overrun-error.vi