LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

hp4275A driver works only half of the time

I have the evaluation version of Labview with the GPIB-USB-HS interface cable communicating between the Labview code, a Honeywell barcode scanner, 2 x Agilent 34401 DMMs, and an HP4275A LCR meter.  All of the drivers that I am using were "official" NI vi's and downloaded directly from the NI website. 

 

My problem is this:  I can see all 3 meters in max, and the Agilent vi's are working with the DMM's as expected (I can initialize, measure, read, close, etc).  The vi for the HP4275A does not work all of the time - maybe 50% of the time at best.  I can't seem to find a reason for this.  At first, I thought maybe it had to do with delay times in the code, or the power up sequence (computer, DMM's, 4275A  vs. 4275A, DMM"s, computer, etc).  It does not seem to matter which order I power up the devices - sometimes this instrument is not being initialized and hangs up my code, and sometimes Labview is working as expected.  

 

When this fails, it will not communicate in consecutive runs - I have to literally shut everything down, then reboot and try again (with another 50% probability that it will work this time).

 

When this successfully initializes the HP4275A, I have no problem running this vi consecutive times as long as I don't close Labview inbetween the times or as long as the computer is not shut down or goes into sleep mode. 

 

The run time is even worse than 50% success, but on occasion will indeed work as expected. It would be one thing if this did not work at all, then I would assume that I have a problem with my code.  The fact that this is inconsistent - this leads me to believe that it may be a driver, vi, VISA, or HP4275A issue.  Please advise.  And please spell everything out for me (even basic steps/ideas) so your explanation is understandable.

 

Thanks in advance.

 

-Jon S.

0 Kudos
Message 1 of 6
(2,339 Views)

Sorry - let me specify, the Honeywell barcode scanner runs USB, as does a relay board from Lightsosoft to switch the leads in and out of the different meters.  The GPIB is only connecting the 2 DMM's and the LCR meter.

 

Thanks again for any insight that may help my problem.

0 Kudos
Message 2 of 6
(2,331 Views)

Are there any error messages or codes that occur?  How do you know the driver is not working, do you get blank data? 

 

Are you using the close instrument VI?  leaving the reference open can cause issues.  Sometimes I have to unplug my GPIB dongle to re-set a lost communication.

 

 

 

 

-------
Mark Ramsdale
-------
0 Kudos
Message 3 of 6
(2,319 Views)

There are not any error codes, nor does the vi from the NI website have any kind of GPIB/HPIB address passed to the vi.  It has very little documentation and is a single vi that both initializes/sets parameters AND reads the 2 displays.  Is there another vi, possibly from a third party, that might work better?  There is a 8.0 version and a 2010 version.  Originally, I was trying to use the 8.0 version with my full suite of Labview 8.5, but that did not work at all, so I tried it with the eval version of Labview 2011 and that seems to work half the time (as described above).  Maybe the newer driver does allow addressing and error codes - I will look into this and reply to this tomorrow.

0 Kudos
Message 4 of 6
(2,311 Views)

The newer version of the driver (2010) contains 2 files; DIR.MNU and HP4275A.LLB.  So does the old one (version 8.0).  The older one is a bigger file, 43 KB rather than 20 KB.. exactly the opposite of what I would have expected.

 

 

0 Kudos
Message 5 of 6
(2,310 Views)

Hello Jon S,

 

At their heart, these drivers are just VIs.  I spent some time looking through both the 8.0 and 2010 driver, and the code looks very similar (all the way down to the (c) 1993 on the front panel).  I suspect the 2010 driver is just an upconverted version of the 8.0 driver.

 

Have you tried running NI-SPY or NI-IO Trace while you communicate with your HP4275A LCR meter?  It may be easier to work around the failure if we know at what point in the communication things are breaking down.  Do the failures still occur when you are only communicating with the LCR meter?  The driver basically puts together a GPIB command for the device, and then polls for a response, so it is possible that one of the "presets" within the driver unintentionally sends a request or a command to one of the other devices.  Again, a trace of the actual communication going on will give us a better idea of what isn't happening the right way.

 

Thank you for patience.

Matthew H.
Applications Engineer
National Instruments
0 Kudos
Message 6 of 6
(2,295 Views)