HP-85 computer via HP-IB to Rigol Multimeter - Problem!

[compet17]

Hi there

I'm trying to connect my old HP-85 computer from 1980 with a HP-IB (GPIB) interface to my Rigol DM3068 multimeter. My problem is that the multimeter doesn't react to any command I send.
I sucessfully connected a LeCroy 9450A oscilloscope from 1991 to the HP-85 and that worked without a problem. Sending commands and receiving answers worked perfectly. But the Rigol dosn't do a thing.
I set both, the Rigol and the LeCroy to GPIB address "0", to have the same addressing syntax (700 on the HP machine, 7 is the interface card and 00 for the external device). What I don't understand is... the LeCroy changes to remote mode as soon as it receives a valid command. Do I need to set the Rigol to remote manually? There is no such procedure in the manual. And how does the Rigol switch between USB, GPIB and LAN? Automatically or manually? Again no clear instruction in the manual.

Can someone help me here?


Chris

[picburner]

In the D3068 the interface selection is not automatic, you have to set it to GPIB as per the User Guide on page 2/70.
You can also assign the same address to two different instruments as long as they are not connected to the bus at the same time.

[H.O]

I don't think the above statement is correct. I believe what's shown in the manual is how to access the settings for the various interfaces, not how to actually choose over which interface the instrument should communicate.

For example, if I "set" mine to GPIB using the suggested method it will still happily respond over BOTH Ethernet and RS232 at "the same" time.

In the top right hand corner of the display it shows "Local" when no interface is active. It will show "Rmt" when it receives a command over RS232 (and I suspect (but don't know) USB and GPIB). Once that happens you have to press the Single/Local button to get back local control.

If a network cable is attached it'll always show "LXI" in the top right corner no matter if you're in Local or Remote mode but again my unit happily responds over both RS232 and Ethernet.

I have a AR488 serial-to-GPIB interface but after messing about with it for half an hour I'm still not able to communicate with the DM3068. It does work with my frequency counter so it's not dead but I suspect it's one of the many settings of the adapter/interface.

[compet17]

@picburner
That manual page tells you how to set parameters for USB/RS232/GPIB/Net but it does not select any interface priority. I tried all possible methods...

@H.O
This is exactly the experience I have. My HP85 communicates happily with the LeCroy oscilloscope but the Rigol does nothing.

[rfclown]

I don't have a HP85 or Rigol, but have been using GPIB for many years. I've never seen address 0 used for an instrument.

Quote from Google search on "GPIB address 0": The GPIB address 0 is usually reserved for the controller (usually your NI GPIB card in your computer).

Also, some instruments need a less common command termination. The most common default is "Send EOI with the last character of the string." I have at least one instrument which needs "Append CR to the string but do not send EOI.". There are many options:

0 Send EOI with the last character of the string.
1 Append CR to the string and send EOI with CR.
2 Append LF to the string and send EOI with LF.
3 Append CR LF to the string and send EOI with LF.
4 Append CR to the string but do not send EOI.
5 Append LF to the string but do not send EOI.
6 Append CR LF to the string but do not send EOI.
7 Do not send EOI.

I never knew about the termination options until I ran across an instrument I couldn't talk to (I think on old HP power meter).

[H.O]

Just wanted to ask the OP if any progress has been made. I gave it another 30min today but the DM3068 simply refuses to speak to me. I, again, started to think there must be something wrong with the adapter so I tried connecting it to a Agilent 34970A and it worked straight away.

Is GPIB on the DM3068 broken....?

[compet17]

Thanks to all!
I don't see a problem with GPIB address "0". I set the LeCroy to zero and also the HP5340A (see below). The Computer interface has ID "7" and listener ID 21, factory setting.
There are a lot of parameters that could be changed. Parity bits, command termination etc. But I don't hope Rigol has messed with that.

Unfortunately I had no success with the Rigol. But I found another HP-IB device in my collection... HP5340A 18GHz counter  and that works without a problem, except I have no clue how to handle it. But I can send commands and set the device up for counting etc. The counter is quite interesting because it's from 1973, a few years before HP-IB was standardized, but it seems to work. It's only called "Digital Input/output"

The reason why I'm telling that is, the 5340A uses a command to select remote mode. Before that command is sent, it reacts to nothing. Maybe the Rigol also needs a command to go remote, but they forgot to mention that in the manual??
Or could it be a license issue? Do we have to buy a license for GPIB?

I wonder if someone uses the Rigol RC software? Maybe someone could snoop the GPIB bus to see what's going on?

[compet17]

ChatGPT recommends to send an *IDN? string to the multimeter. This should set the device in remote mode. If it is already in remote mode, it will return the device ID string: Rigol Technologies,DM3068,DSG1xxxxxxx,00.01.00

Hmmm... worth a try!

[H.O]

*IDN? is what I've tried most of the time. Also *RST since that should reset instrument to default state but not produce a response back to the PC (in case the error is/was with that). All the examples shown in the programming guide starts with *RST to reset instrument and then *IDN? to verify communication, needless to say the DM3068 seems totally deaf on the GPIB port.

Yes, it would be interesting to know if anyone has been able to use GPIB at all on this meter.

[Tony_G]

Unfortunately I had no success with the Rigol. But I found another HP-IB device in my collection... HP5340A 18GHz counter  and that works without a problem, except I have no clue how to handle it. But I can send commands and set the device up for counting etc. The counter is quite interesting because it's from 1973, a few years before HP-IB was standardized, but it seems to work. It's only called "Digital Input/output"

I don't have a HP-85 but I do have a DM3058 which I think is the same programming model as the DM3068.

Using HTBasic (A modern implementation that traces its lineage back to the BASIC in your HP-85) with this code:

Code: [Select]

10    OUTPUT 900;"*IDN?"
20    ENTER 900;A$
30    PRINT A$
40    END

I saw that it asserted a CR&LF and the DM3058 beeped. That beep means that it got something incorrect from the remote interface. if I add the keyword "END" to the output line:

Code: [Select]

10    OUTPUT 900;"*IDN?" END

Then only an LF is asserted and the meter returns "Rigol Technologies,DM3058,DM3L162550089,01.01.00.02.02.00.".

According to the HTBasic manual END is:

An optional END attribute may be used after the last data item.

If USING is not specified, then END:

1) suppresses the EOL sequence from being output after the last item,
2) sends an EOI signal with the last character of the last item sent to an IEEE-488 device, and
3) truncates a file. A comma before the END will output an item terminator (a comma for numeric items or a CR/LF for string items).

So I'd look at the HP-85 BASIC manual to see if there is an equivalent or the DM3068 manual to see if you can change the termination characters.

[UPDATE] - I found this over on HPSeries80 Groups that might help you get the DM3068 working - https://groups.io/g/hpseries80/message/8516

TonyG

[Tony_G]

*IDN? is what I've tried most of the time. Also *RST since that should reset instrument to default state but not produce a response back to the PC (in case the error is/was with that). All the examples shown in the programming guide starts with *RST to reset instrument and then *IDN? to verify communication, needless to say the DM3068 seems totally deaf on the GPIB port.

Yes, it would be interesting to know if anyone has been able to use GPIB at all on this meter.

I would wager that what you're seeing is what RFClown referred to earlier.

Now, I don't have an AR488 or a Prologix adapter, so I defer to anyone with one. However, a quick look at the manual suggests that you could use "++eos 2" to set the "End Of Send" to just an LF.

If you hear a beep when issuing the "*IDN?" then that is meter saying I see something on the remote interface but I don't understand what that is.

TonyG

[H.O]

Thanks Tony!
That's the thing, it's never responded in any way shape or form. No beeps, no display indicator lighting up, no nothing. I'm pretty sure I tried all four options for eos but now that you've confirmed it does work, albeit on a 3058, I might give it a third go. Then again, when you had the wrong termination character it did beep while mine's never shown any sign of life thru GPIB.

[Tony_G]

Thanks Tony!
That's the thing, it's never responded in any way shape or form. No beeps, no display indicator lighting up, no nothing. I'm pretty sure I tried all four options for eos but now that you've confirmed it does work, albeit on a 3058, I might give it a third go. Then again, when you had the wrong termination character it did beep while mine's never shown any sign of life thru GPIB.

I took another look at this as I was not specifically using the GPIB port (I was using the TCP/IP connection) so I hooked it up to my GPIB-ENET/1000 adapter and then tried it again from HT Basic to make sure that there wasn't some difference in the TransEra drivers between GPIBNI and VISA.

Lo and behold! There seems to be a difference between how the DM3058 does IP and GPIB as it doesn't beep at all.

If I execute this then it basically hangs (I would assume it'd hit a time out but I didn't bother to find out what that was):

Code: [Select]

10 OUTPUT 707;"*IDN?"
20 ENTER 707;A$
30 PRINT A$
40 END

but if I add the "END" statement to the OUTPUT line then it works correctly and returns the ID String. It does beep for an incorrect SCPI command though.

Have you tried:

• Changing the device address to some other number e.g. 7 in my code example
• Asserting and releasing control of the unit to see if it is responding to GPIB (++llo and ++loc)
• Try issuing commands to switch modes e.g. between DC voltage ":function:voltage:DC" and AC ":function:voltage:DC"

It is absolutely possible that your GPIB port is broken but I really think what you're seeing is a termination issue. Especially if #2 above works but #3 doesn't. If #3 works and *IDN? still doesn't then the hang is probably on the receiving termination (++eor).

TonyG

[Tony_G]

So I'm killing a bit of time before I head out and thought I'd look a bit deeper with what is going on with my DM3058 and termination.

TL;DR; This probably doesn't mean much for your situation but I'd like to understand what is happening here just in case.

As I mentioned, I'm using a NI GPIB-ENET/1000 to talk to the DM3058 from my PC so I'm using the latest NI VISA libraries and their tools. Using the NI VISA Test Panel and issuing an *IDN? the buffer on the call is "2A 49 44 4E 3F 0A". So you can see a LF termination.

But I thought, well I could try the KE5FX command line tool to issue the talk and then use the VISA Test Panel to listen to it (I never got the KE5FX listen tool to work on my setup) and I see this as the buffer "2A 49 44 4E 3F 0D 0A". It has a CRLF termination and the Test Panel read went just fine.

So both LF & CRLF terminations work over GPIB to the Dm3058 apparently. So what is going on with the read I'm trying to do in HT Basic??

If I use the OUTPUT 707; "*IDN?" END statement, it produces a buffer of "2A 49 44 4E 3F". No termination character at all but returns the correct result. If I remove the END statement then there is a second async write call that has a buffer of "0D 0A" which is a CRLF.

So looking back at the first HT Basic call there is async ibcmda call with:

Code: [Select]

<call type="NI-488.2" description="ibcmda" process="0x000017F4" thread="0x00006744">
<status type="success" code="0x00000000">Operation completed successfully.</status>
<input time="13:19:41.6022">
<parameter name="Board Name">GPIB0</parameter>
<parameter name="ud">31000</parameter>
<parameter name="&amp;buffer">0x7B3B8DF0</parameter>
<parameter name="count">3 (0x3)</parameter>
<buffer size="3">47 3F 35</buffer>
</input>
<output time="13:19:41.6032">
<parameter name="iberr">0</parameter>
<parameter name="ibcntl">0 (0x0)</parameter>
</output>
</call>

So that async call must tell either the device or the VISA libraries to terminate the command so that the read can take place.

Interesting but I've run out of time - Will check back in later - Good luck.

TonyG

[Tony_G]

Ok, this makes sense now I think, HTBasic is doing things in a multithreaded way, and thus all the aysnc command stuff. When using the END statement, HTBasic issues an "Unlisten" (UNL command) that terminates the command to the DM3058, and thus it is ready for when HTBasic asks it to send the result of the command.

Without the END command and the terminator, when the code finally gets around to reading the result, as far as the DM3058 is concerned the command was never finished sending.

To try that out, I did:

• Execute the code "OUTPUT 707; "*IDN?"
• Confirm that HTBasic was hung on the read
• Using the VISA Test Panel, send "*IDN?" as a Query operation (combined write/read)
• See 2 IDN results in the Test Panel buffer

So the Test Panel did, which effectively ended the first IDN and issued a second IDN as though the entire command was "*IDN?;*IDN?".

TonyG

[rfclown]

I learn new things about talking to instruments mainly when things don't work. The suggestion I made before was something I found when I bought an old power meter with GPIB and it didn't seem to respond to commands. I mainly use LabVIEW, and the GPIB function had a "mode" input which let you specify the termination (the list I showed earlier). I haven't dealt with any other instrument where I needed anything but the default value (and I've dealt with many instruments from many manufacturers). The latest learning experience for me was with a Siglent scope. With that I learned that there is synchronous and non-synchronous I/O mode for VISA. In LabVIEW, it isn't even a variable in the VISA functions; you have to change the functions! In 30+ years of dealing with remote instrument stuff, I hadn't run into that one. I had to change my generic function call routines that I wrote decades ago to account for the fact that Siglent went against the grain.

[Tony_G]

RFClown - I have only used GPIB adapters from HPAK and NI so I don't really have any experience with corner cases they may have but I have run over termination character issues before when writing code to drive some older instruments (from memory something like a HP 5342A or that era).

HO - I looked at the termination character stuff using some C# code and the NI VISA library directly. For strings, it didn't matter if the buffer was terminated with a 0A, 0D or 0D0A.

So that seems to me to state that the DM3058 itself doesn't care what the string termination character is.

I'm really only left with these suggestions:

• Check the setting for EOI (++eoi) - Try both
• Reset the adapter to factory default (++default)
• Post to the main AR488 thread to see if anyone knows there - https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/

Sorry, I couldn't help more but not having the interface is a tad limiting.

TonyG

[H.O]

Hello,
Thank you both, you've done more than enough. I only tried this myself in an effort to help Chris figuring out why his HP-85 doesn't "work" with DM3068 (or rather the other way around, I suspect). Personally I don't really need it, Ethernet for the win...but it would be nice to know what the issue is.

Using the AR488 I've tried both ++eoi options, all four ++eos options and various ++eor options although they (the ++eor options) really shouldn't matter for commands that doesn't produce a response, like *RST.

I've also reset adapter to default state and I've tried different GPIB addresses (1 & 7), making sure ++addr matches that of the instrument. Needless to say the DM3068 remains silent.

[compet17]

I just got an answer from Rigol support...
They asked me if I put a \n at the end of each instruction. I haven't tried that yet.