06-30-2010 01:05 PM
To make sure that the problem is not with the other program, the developers gave me a short testing code which reads analog input in a loop and measures timings.
I ran it with various timeout values. While typically the DAQmxReadAnalogScalarF64 call lasted about 1 ms, occasionally it was much longer.
Runs with timeouts up to 500 ms in some cases ended with timeout errors. The longest recorded call duration in a run with 1-s timeout was about 700 ms. Is this normal? USB polling rate is typically 250 Hz which makes 4 ms, windows scheduler AFAIK uses 20-30 ms slices, so I'd maybe understand something on the order of 50 ms, but 700 ms?
06-30-2010 06:00 PM - edited 06-30-2010 06:04 PM
Unfortunately, we don't really have any control over when the host controller is able to check our endpoints, nor do we have control over when Windows decides to service the Interrupt that comes from the controller. Explaining exactly where the latency that you are seeing is coming from is a bit beyond my experience--700 ms does seem high to me but I'm not sure if it is unreasonable, what are your system specs and OS?
For fun, I took a few different boards that I have at my desk and ran a simple test (10 Million iterations for PCI and PCIe boards, 1 Million for USB):
These were the results I got:
*EDIT: Average time is a bit misleading since I am using the Windows system clock to measure the results. sub-ms acquisitions are typically measured as 0. However, if the clock tick happens to occur during the read, I would read 1 ms. Averaging this out over so many iterations gives a pretty good idea of what the average read time is.
This is on Windows 7, Dell Precision T3400 with Core 2 Duo E6550 @ 2.33 GHz. My USB host controller is an Intel ICH9. Of course, I am doing absolutely zero processing or display during the loop which would add to the loop time.
Again, the latency of USB is going to be very system dependant. I'm not sure if there is much you can do to improve your situation. If you have other stuff running inside the loop that needs to continue to iterate during the latency of your read, it might make more sense to put this code in a parallel loop running in another thread if at all possible.
Best Regards,
08-02-2010 12:11 PM
Hi, i'm also facing the same error for this particular device. i've tried resetting the hardware using the Measurement & Automation Explorer software but the error keeps coming up. i believe my programming has nothing to do with it because i just try to run the hardware using Test Panels and the error keep coming up.
Fortunately i have two NI USB-6218, when i swapped the DAQ (using same USB port, USB cable, same PC, etc.), there's no problem at all, the Test Panels runs as it should without any error, and my programming also runs as usual.
Unfortunately i need to use both NI USB-6218. My NI-DAQmx is version 9.0.2.
Please help me, Thank you.
08-03-2010
11:07 AM
- last edited on
06-12-2024
08:11 AM
by
Content Cleaner
Hi miskoL,
I would encourage you to contact NI by phone or email for further troubleshooting. Your board may be damaged and require an RMA which is typically handled by phone.
Best Regards,
11-20-2014 09:12 AM - edited 11-20-2014 09:14 AM
Hi John,
I have a similar problem. We use NI USB-6210 for data acquisition of dilatometer machine. The machine has been working well for 3 years approximately. Now, after 4 to 5 hours of work, the client recieves the run-time error message shown in the attached printscreen photo. The client has resetted the machine as mentioned in this thread but unfortunately the error still comes up. Could you please point out how can I fix such error?
Best regards,
Ahmed.
11-20-2014 05:21 PM - edited 11-20-2014 05:22 PM
What does the block diagram look like? What is the timeout set to? Have you tried increasing it?
Best Regards,
11-21-2014 02:45 AM
In fact we use the VB.Net function shown below to deal with that module. It works within a loop that calls it every 100 ms approximately.
DAQmxErrChk DAQmxReadAnalogScalarF64(lngTask, 10#, dblLectura, ByVal 0&);
The time-out is set to 10 Sec. We haven't tried to increase it because it is already too long.
11-21-2014 12:13 PM
Yes, 10 seconds should be more than long enough...
Have you changed anything on that computer between when it was working and now? My only suggestion would be to check the computer's power settings and turn off sleep, hibernate, and usb selective suspend to see if that makes any improvement.
Best Regards,
11-24-2014 02:21 AM
Thanks John for your interest and your informative answer. We will check the settings mentioned in your reply.
Best regards,
Ahmed.