viFindRsrc() command sometimes returns faulty description?

[NicOfTime]

When using viFindRsrc(dfltRM, "GPIB0::?*INSTR", fList, nList, desc), the "desc" value returned, for some instruments, comes back as "xPIB0::##::INSTR", where the "x" should be a "G" (i.e., "GPIB0::##::INSTR").  The "x" is some other unknown character (just shows up as a little square).  This causes an error with vifindnext(flist, desc) because the desc parameter is corrupted.

So, viFindRsrc finds the instrument okay, but returns a faulty description.

Any clue why this might be happening?

[Chris G in AE]

Howdy NicOfTime,

This corrupt bit could be caused by a corrupt VISA driver.  I'm curious what development environment you're using as well as the version of VISA you have.  Also, how often does it return this bad bit?  Is it on the order of once per month or once per day? You could try upgrading to the latest version of VISA, but if the error happens infrequently, it would be difficult to tell if this fixed the issue.  Thanks, I look forward to hearing back from you.  

[NicOfTime]

Hi, Chris.

Ty for your response.  I'm using VB6 with the latest version of VISA.  The instrument that returns the questionable description is an Agilent 53150A Frequency Counter.  When powered up for the first time, the freq counter responds as expected.  Every time after that, a faulty description is returned.   This occurs in a setting where there are mulitiple instruments.  When the test station is fired up, it looks for all the instruments needed for the test.  If all of them aren't turned on or connected, the system tells the user which instruments are missing.  After connecting/powering up those instruments, the system re-initializes to make sure that everything is still there, and finds any instruments added since the last initialization.  It's at this point that the system loses the freq counter, because it re-passes through viFindRsrc() when it is re-initializing, obtains a corrupted desc value, passes this corrupted value to flist, then fails viOpen().  Apparently, when the counter is first found, it sets some flag on the GPIB that immunizes it against any further communication.  We have several of these counters here, and all of them do the same thing.  I've tried "remembering" (in software) that the counter is active, and then sending *RST, *CLS, *ESE 0, *SRE 0, and STAT:PRE (as well as viClose / viClear) to try to reset it to a cold-start state before exposing it to another viFindRsrc() -- but so far to no avail.  It's the only instrument I've ever used that responds this way.  All other instruments remain in a passive mode, accept commands, and respond predictably without complaint even after multiple viFindRsrc().  The only way to clear the counter appears to be physically powering it off.

But I'm continuing to beat my head against the wall on this one, hoping that some as-yet-untried combination will demonstrate -- once again -- that it's an operator and not an equipment or software error.  The vast majority of the time I find out that it's some simple thing that I could have found if I just stayed with it.  But this is going into extra innings here.  So I thought I'd post something here to see if anyone might have run across something similar...

Respectfully,

DRS

[Chris G in AE]

DRS,

Thank you for the lengthy problem description - it clarifies the situation a great deal.  This sounds like something that is wrong with the instrument, especially if it is the only thing that is behaving in this manor and can be fixed with a power reset.  I would definitely suggest talking to Agilent to see if there is a firmware upgrade for your frequency counter.  If you cannot get a firmware upgrade, you could try swapping out the instrument with another of the same type (if you have other ones) and see if the behavior is repeatable.  In either case, I suggest contacting Agilent about this issue and asking if they have ever heard of anything like it.