EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: JJalling on August 17, 2015, 07:18:54 pm
-
Hi,
I'm not able to get readings from the DMM in BenchVue. I can change the settings of the instrument (Meaurement type, range, integration time ...) from the software, but the measurements are not sent to the software?
Is live readings enabled by some option in the software/DMM?
/Jonas
-
If I connect to the DMM via RS232, it works just fine. Maybe the USB->GPIB is just crap.
/Jonas
-
Can you use command expert to send say *IDN? over GPIB, to confirm if GPIB is working at all?
-
Can you confirm the GPIB channels match? That is common enough and easy to fix.
-
Did your setup work before?
Under the I/O menu, is the Language set to "SCPI"? Also, I've had trouble with Benchvue having communications problems. I endued up uninstalling and reinstalling BenchVue and the Keysight IO suite.
-
Hi all,
I just got the GPIB cable today, so I haven't tried it before.
GPIB is definitely working. I can send *IDN? and read back "HEWLETT-PACKARD,34401A,0,10-5-2\n". This also confirms that it is the correct address. I can also change range, integration time and so on via. GPIB.
I have attached a log from BenchVue communicating with the DMM.
Everything is fine until I press "Start".
It looks like the error occurs when the command "*SRE 176\n" is sent (on page 18). The DMM never replies, and all communication stops - I have to restart the DMM to communicate with it again.
/Jonas
-
Is it a genuine 82357? Some good fakes are about, with significant internal chip differences. If a possible fake, see the eevblog forum post about this issue.
-
It looks like the error occurs when the command "*SRE 176\n" is sent (on page 18). The DMM never replies, and all communication stops - I have to restart the DMM to communicate with it again.
Check that the instrument is set to clear byte status on power-on, which you probably do want it to. "*PSC 1" will make it do that. This setting is non-volatile and can be queried with "*PSC?" *SRE enables GPIB/HPIB SRQ for the specified event mask (128+32+16). That's kind of an odd thing to send actually since 128 is always 0 on the 34401A and presumably ignored, but maybe it's common code for an entire group of DMMs. Most likely what happens on the *SRE is that there is a pending message (it's a queue) that immediately causes it to assert SRQ, which BenchVue isn't expecting. Once SRQ is asserted, if I understand correctly, the GPIB device becomes a talker, not a listener, and won't respond until the event has been cleared and it's put back into listener mode. (Or maybe I got it all wrong; I find the entire SRQ business very confusing and an endless source of problems.) So BenchVue sends a command the instrument never responds to. Or something along those lines. Or maybe trying to set 128 itself causes an error and SRQ is by default configured to assert on error? I'd factory reset the thing.
-
It looks like the error occurs when the command "*SRE 176\n" is sent (on page 18). The DMM never replies, and all communication stops - I have to restart the DMM to communicate with it again.
Check that the instrument is set to clear byte status on power-on, which you probably do want it to. "*PSC 1" will make it do that. This setting is non-volatile and can be queried with "*PSC?" *SRE enables GPIB/HPIB SRQ for the specified event mask (128+32+16). That's kind of an odd thing to send actually since 128 is always 0 on the 34401A and presumably ignored, but maybe it's common code for an entire group of DMMs. Most likely what happens on the *SRE is that there is a pending message (it's a queue) that immediately causes it to assert SRQ, which BenchVue isn't expecting. Once SRQ is asserted, if I understand correctly, the GPIB device becomes a talker, not a listener, and won't respond until the event has been cleared and it's put back into listener mode. (Or maybe I got it all wrong; I find the entire SRQ business very confusing and an endless source of problems.) So BenchVue sends a command the instrument never responds to. Or something along those lines. Or maybe trying to set 128 itself causes an error and SRQ is by default configured to assert on error? I'd factory reset the thing.
Hi bson,
That sounds interesting!! I will give that a try, when I get back from work.
/Jonas
-
Is it a genuine 82357? Some good fakes are about, with significant internal chip differences. If a possible fake, see the eevblog forum post about this issue.
I'm actually not sure if it is genuine. I bought it from eBay, but it looks genuine.
BR Jonas
-
Hi,
I think your adapter is ok, as everything else is working, but maybe is not working correctly with BenchVue.
I did not find any hint in the B.V. documentation, which GPIB adapters are supported, but in the 82357B manual, BenchVue is not mentioned.. maybe due to the later appearance of B.V.
In the 82357B manual, page 43, I found a hint that SRQ is slower than with an PCI adapter (DMA for example is also not supported, by HW limitations, I assume).
That might be the reason , why B.V. hangs. Maybe there's another hint, how to speed up the USB adapter.
There should be an FAQ for B.V. somewhere, maybe other people also encountered problems.
My 34401A works fine with B.V., but I use a National Instruments PCI adapter..
Frank
PS: I'm using B.V. 2.7 with Windows 10, and it works, despite the hint on the Keysight forum.
-
I've got BenchVue working with two 34401As using a (possibly fake) 82357B. It worked in windows 7 and now Wibdows 10.
Sent from my iPhone using Tapatalk
-
If you search the Keysight forum, there are other problems with this adapter.
One user had contact problems. Unplugging both sides several may help.
Then Keysight assumed problems with the IO library and recommended complete Deinstallation of BenchVue and reinstallation.
Frank
-
Try to post your question on http://www.keysight.com/owc_discussions/category.jspa?categoryID=77 (http://www.keysight.com/owc_discussions/category.jspa?categoryID=77)
People from Keysight are really trying to help!
Michel.
-
I have several 34401A and several of the 82357B adapters and all of them worked on BV perfectly.
But at one time suddenly BV would not recognize the 82357B adapter and the 34401A
I had to re-install BV completely and it worked again afterwards and never had a problem since.