3458A

[flow]

I'm having a problem with the 3458A when I run TME the interface can't see the dmm although it puts the unit in remote,I'm running a E4428C all other test pass except  the test with the 3458A. I'm using the 82357B USB/GPIB interface. I've tried this interface on all the 3458A we have in the Lab with the same result any help would be appreciated.

[Hawaii596]

Not an answer, but it seems a lot of 3458A's have a problem with GPIB syntax.  I have a 3458A on a GPIB bus that when I tell IO Suite v16 to refresh the bus, the 3458A gets an error.  One thing is that the HP 3458A has been around for a long time, and I am guessing there are a number of firmware revs that make a difference on how they interpret commands.  I think some of the older units firmware may be pre-SCPI..

User Cal Lab Solutions on this website is one of the more expert on this topic.  Maybe send him a detailed message about it.  In my circumstance, the 3458A gets errors and the bus acts like it can't see it.  But then when it comes time to make measurements on the GPIB bus, the 3458A does make the measurements.  My guess has always been that it may be an old firmware issue, or an incorrect driver.  I am not the one to answer the question though.

But I would like to find out why this is happening.  Not sure if this is like your issue or not.

[CalLabSolutions]

Not a complete answer.. But an instrument in remote only means that the remote line on the GPIB interface card went HIGH.  ALL instruments on the GPIB bus go into remote with that line goes HIGH.  Its just one of the digital communications lines in the GPIB interface model.

[flow]

My thing is IO Library connection expert and TME does not see the uut and that's concerns me that all the 3458a in our lab response the same way! I believe it has to be firmware issue. Any thoughts.

[silv3rstr3]

I didn't see any available firmware updates on the Keysight website.  I have noticed in the past using Met/Cal that when it initially tries to send the *IDN? query the 3458A errors out.  However you can click continue anyways and it will take the measurements. 

I think the 3458A was designed using the old IEEE-488.   IEEE-488.1 specified the physical and electrical bus, and IEEE-488.2 specified protocol and data format, but neither specified instrument commands.  Now I just use the 8508A and it's been smooth sailing ever since. 

[scottbp]

We used to have errors using 3458As with MET/CAL (specifically EABO timeout errors) until someone from Fluke MET/Support told us that whenever we install the drivers for the GPIB interface hardware, it defaults to using 500 nanoseconds for the bus timing; and that slowing the timing down to 2 microseconds allows it to communicate with older instruments. I did this, and now we have no problems with our 3458As, new and old.

From National Instruments technical support:
"Problem:
I recently upgraded from an old computer to a faster, newer computer. I may have also upgraded my GPIB board. On the old computer, I used to be able to communicate with my instrument just fine, but on the new computer I experience EABO timeout errors with the same program.

If I use the Interactive Control (IBIC) to talk to my instrument, everything works fine. The problem only seems to occur when I access my GPIB device programmatically. What might be happening?

Solution:
If you are experiencing intermittent timeouts or other communication problems, and you are using an older GPIB instrument, then your device may not be fully compliant with the IEEE 488 specification. This is usually the case if communications worked fine on slower computers, but timeout errors occur on faster computers.

Certain older instruments communicate with the GPIB board in such a way that they indicate they are able to receive data before they have the capability. This behavior makes them appear faster with older computers, but throws off the bus timing with faster computers.

You may be able to resolve the timing problems, either by introducing delays between GPIB commands, or by changing the GPIB bus timing to the slowest setting in the GPIB Configuration Utility. The second option is less effective because it only affects the time the GPIB controller waits before valid data is on the bus and the data valid (DAV) line is asserted."

[CalLabSolutions]

The3458A does not support *IDN?.
It will not show up in NI or Agilent's manages like new pieces of test equipment.

Keep in mind, the 3458A was engineered way before they ever came up with *IDN? or other 488 standard commands.

Mike

[flow]

There has to be a fix for this issue when running TME, I need to know if there is an upgrade for the 3458 or a service note that I could go by to correct this communications problem?
It is obvious that Agilent/Keysight is running their own program w/o any issue and other Labs as well. What's the answer!

[RFCAL]

We have not experienced that problem

[flow]

Thanks everyone for your input but just like in life the simplest answer is most likely the right one.
I had too many GPIB cable on the bus and once I cleaned that up the problem went away.