E4980A GPIB Timeout when taknig multiple measurements

[skykelly]

My recent project is to add support for the E4980A LCR Meter to an existing C++ program.  This program has traditionally used the 4263B.  I have added the additional code to support the new meter but I am having some problems.  

1.  The measurement times do not seem to match the manual.  For instance, the manual states (on page 439-440) that the measurement time for a 100Hz measurement in Medium mode should be around 180ms when no DC Bias is used.  But I measure this to be around 230 ms and sometimes more than this.  I have verified that all the conditions on page 439 have been met corectly when setting up the meter.  I am using the NI Spy/Trace to verify the times.  There is no significant portions of code that should add any extra time to between the reading of one measurement and the triggering of the next.  I see a similar timing offset as I increase the measurement frequency.  Testing at 100kHz in Medium mode should be around 89ms, but I measure it to be closer to 131ms.

This leads to my next question.  

2. When i run multiple readings back to back continuously, the meter doesn't appear to be able to keep up over the long term.  The occassional error always comes when the program is ready to send another trigger.  The meter must not be ready to accept it (maybe it is busy handling another task?) and times out.  I have added some code to try to mitigate this problem by checking the measurement status using ":STAT:OPER:COND?" to verify that the previous measurement is complete before trying to send a new trigger.  Now instead of the timeout happeneing when the program tries to trigger, it happens when requesting the status of the operation status event register.

My guess is that these two issues are linked in some way.

Any ideas on these problems?

Thanks.

[NInjaneer_0]

Hi skykelly, 

What development environment are you using? (.NET, LabVIEW CVI, etc.)

Could you describe in more detail the test you're trying to perform? (e.g. how long is "long term")

[skykelly]

HI,

I am using (cough, cough) Visual Studio 6.0.  I need to upgrade, but that is a side issue.  I am using the NI USB-GPIB interface.

The test that I am running is fairly simple.  I am taking 10 readings back to back, throwing out the highest and lowest readings, and then averaging the remaining readings. There is a scanner setup to index through 20 test positions.  After testing 20 positions, the program then changes the test frequency and then does it again.  This pattern continues through 4 different frequencies.  Sometimes, the lcr meter makes it through all the readings without hanging up.  Sometimes it does not.

Thanks for your interest.

[JÞB]

Which usb-GPIB device? (model number!)

Have you disabled power management on the USB HUB from Device manager?  (Yup- the default is to allow Windows to shut down USB Power- that is bad for automated testing)

[skykelly]

It is the GPIB-USB-HS device.

Thanks for the good suggestion.  I have not disabled power management for the USB hub.

I don't think that is a factor in this case though.  I am right in front of the computer that is running the test when the failures occur.  It is not due to power management issues as the whole test takes less than 5 minutes and my power management settings are set to something greater than 15 minutes for all power scheme settings.

[JÞB]

---

@skykelly wrote:

It is the GPIB-USB-HS device.

Thanks for the good suggestion.  I have not disabled power management for the USB hub.

I don't think that is a factor in this case though.  I am right in front of the computer that is running the test when the failures occur.  It is not due to power management issues as the whole test takes less than 5 minutes and my power management settings are set to something greater than 15 minutes for all power scheme settings.

---

You mean this one?

Do you hve the latest driver?  What software enviornment are you programming your test in? [EDIT OH, VS6.0 yes you do need to upgrade! ] can you share the code that fails? DID your eyes pop-out when you actually read the highlighted text in the png?

[skykelly]

Yes, they did pop out!  When did NI make this statement about the "older" USB controller?  I am curious now to understand the limitations of this old device.

I will also check to make sure my drivers are up to date.

[JÞB]

---

@skykelly wrote:

Yes, they did pop out!  When did NI make this statement about the "older" USB controller?  I am curious now to understand the limitations of this old device.

I will also check to make sure my drivers are up to date.

---

Its probably some issue with the ASIC having indeterminate latency buffering parallel comunications to a serial interface (but thats just a guess):smileyvery-happy: