HP8590E Series Option 103 Driver

[MarkL]

Oops sorry about that.  Glad you figured it out.  Cut and paste from the VM is not working, so a lot of that is re-typed.  I made a mistake on the cat.  It should be >> to append (a single > overwrites):

cat << EOF >> /usr/local/etc/gpib.conf

/* HP 8595E */
device {
    name = "sp"
    minor = 0
    pad =  18
    eos = 0x0a
    timeout = T30s  /* needed for slow print response */
}
EOF

I think you're close.  The error you're getting is that the perl script doesn't know what device "sp" is.  The above defines it.

It doesn't look like you have anything to speak of in memory.  You have a variable C_ONLV which is also in the EMC/QPD drivers and is 1.11654114713E3.  I don't see anything in the package that uses it, but do_cmds is going to set it.

[Miti]

I edited the conf file manually and I have communication. It doesn't work, however. Please see attached.

[MarkL]

Ok, add your current directory to the search path:

echo 'export PATH='.:'$PATH' >> ~/.bashrc
. ~/.bashrc

That's why it can't find "parse_a". Try ./do_cmds again.

I don't know what's going on with the error check.  I'll have to look at this tomorrow.  I think some characters might not be getting printed.  What is the output of:

spq CMDERRQ | xxd -g 1

[Miti]

I don't know what's going on with the error check.  I'll have to look at this tomorrow.  I think some characters might not be getting printed.  What is the output of:

spq CMDERRQ | xxd -g 1

It is:

00000000: 0d 0a                                            ..

[MarkL]

I think it should be working, but the error check is failing maybe due to some changed behavior in the new version of bash.

Edit do_cmds and change this line near the top:

  if [ "$res" != $'\x0d' ]; then

to this:

  if [ ! \( "$res" == $'\x0d' -o "$res" == $'\x0d'$'\x0a' \) ]; then

[Miti]

I changed the line and still fails. Perl_new is after changing the line.

[MarkL]

All kinds of old syntax...

In parse_a, change this:

shift $[$OPTIND-1]

To:

shift $((OPTIND - 1))


Looks like the forum made a total mess out of my other fix.  Maybe you caught it.  The line is supposed to be:

Code: [Select]

  if [ ! \( "$res" == $'\x0d' -o "$res" == $'\x0d'$'\x0a' \) ]; then
the "code" tag seems to preserve the backslashes.

[MarkL]

And in parse_a get rid of these two lines near the top:

Code: [Select]

# default options always given
args[i++]="-l"

I apologize for all the old junk in these scripts.

[Miti]

I get

Code: [Select]

miti@miti-System-Product-Name:~$ cd ~/Downloads/gpib-dlp-poc
miti@miti-System-Product-Name:~/Downloads/gpib-dlp-poc$ ./do_cmds
--- trdef Q_TRA (xfer) ---
reading from stdin
read 809 bytes
./do_cmds: 9: [: closing paren expected
--- trdef Q_TRA (define,mov) ---
./do_cmds: 9: [: closing paren expected
--- trdef Q_TRB (xfer) ---
reading from stdin
read 809 bytes
./do_cmds: 9: [: closing paren expected
--- trdef Q_TRB (define,mov) ---
./do_cmds: 9: [: closing paren expected
--- trdef Q_TRC (xfer) ---
reading from stdin
read 809 bytes
./do_cmds: 9: [: closing paren expected
--- trdef Q_TRC (define,mov) ---
./do_cmds: 9: [: closing paren expected
--- trdef _ONE (xfer) ---
reading from stdin
read 809 bytes
./do_cmds: 9: [: closing paren expected
--- trdef _ONE (define,mov) ---
./do_cmds: 9: [: closing paren expected
--- vardef _ADF ---
./do_cmds: 9: [: closing paren expected
--- vardef _AMPEND ---
./do_cmds: 9: [: closing paren expected
--- vardef _AT ---
./do_cmds: 9: [: closing paren expected
--- vardef _AUI ---
./do_cmds: 9: [: closing paren expected
--- vardef _AVAMP ---
./do_cmds: 9: [: closing paren expected
--- vardef _AVFRQ ---
./do_cmds: 9: [: closing paren expected
--- vardef _AVGF ---
./do_cmds: 9: [: closing paren expected
--- vardef _AVLIM ---
./do_cmds: 9: [: closing paren expected
--- vardef _AVLMF ---
./do_cmds: 9: [: closing paren expected
--- vardef _BOXIDF ---
./do_cmds: 9: [: closing paren expected
--- vardef _CHS ---
./do_cmds: 9: [: closing paren expected
--- vardef C_ONLV ---
./do_cmds: 9: [: closing paren expected
--- vardef _CPYRGTF ---
./do_cmds: 9: [: closing paren expected
--- vardef _DBNS ---
./do_cmds: 9: [: closing paren expected
--- vardef _DREF ---
./do_cmds: 9: [: closing paren expected
--- vardef _DSPAD ---
./do_cmds: 9: [: closing paren expected
--- vardef _DSPF ---
./do_cmds: 9: [: closing paren expected
--- vardef _FA ---
./do_cmds: 9: [: closing paren expected
--- vardef _FALG ---
./do_cmds: 9: [: closing paren expected
--- vardef _FASV ---
./do_cmds: 9: [: closing paren expected
--- vardef _FB ---
./do_cmds: 9: [: closing paren expected
--- vardef _FBLG ---
./do_cmds: 9: [: closing paren expected
--- vardef _FBSV ---
./do_cmds: 9: [: closing paren expected
--- vardef _FFAA ---
./do_cmds: 9: [: closing paren expected



[MarkL]

Can you post the first 20 lines or so what you have in do_cmds?

That should not be an error.  I did try it.

[Miti]

Here they are:

Code: [Select]

#!/bin/sh

SP=sp
SPQ=spq

check_err()
{
  res=$($SPQ "CMDERRQ")
  if [ ! \( "$res" == $'\x0d' -o "$res" == $'\x0d'$'\x0a' \) ]; then
    echo "**********   CMDERRQ: $res   **********"
  fi
}


### trdef

trdefs=$(cd var_a && grep -l '^#A' *)

# echo trdefs $trdefs

for i in $trdefs; do

  echo "--- trdef $i (xfer) ---"

  # use trace C to transfer
  echo -n "TRC" > tmp
  cat var_a/$i >> tmp
  $SP - < tmp
  check_err

  echo "--- trdef $i (define,mov) ---"
  $SP "TRDEF $i,401; MOV $i,TRC;"
  check_err

done

[MarkL]

This is rather strange.

I didn't notice Mint (and maybe other recent distributions) are using dash for their system shell.  The systems I have all use bash.

So we better call for bash explicitly.  On the first line of do_cmds and parse_a change "/bin/sh" to "/bin/bash".  Then give it a shot.

[Miti]

 

It worked!!
Thanks a lot Mark. Sorry to keep you awake so late...

[MarkL]

Great!  Have fun with the EMC and QPD!  And goodnight!

[Miti]

Great!  Have fun with the EMC and QPD!

Thanks, I will...

And goodnight!

Are you kidding me? Time to play... 

[Miti]

I wanted to post some pictures with my SA's newly added menus but then I thought, can I capture the screen from HP8594E through the GPIB? I think technically it should be possible but then, probably, this model may be too old for that.

[MarkL]

I wanted to post some pictures with my SA's newly added menus but then I thought, can I capture the screen from HP8594E through the GPIB? I think technically it should be possible but then, probably, this model may be too old for that.

Absolutely it can do screen captures.  It's one of the main uses of GPIB even in old equipment.

Now that Linux has done its work for you, you might want to go back to windows.  There's a very nice package here that is popular:

  http://www.ke5fx.com/gpib/readme.htm

It supports your NI PCI-GPIB card.

Of course I have my Linux way of doing it, if you want to experience some more crufty old code.

[Miti]

Excellent tool, thanks Mark!
I played for half hour at work with an HP8591E and GPIB-USB-HS.
I couldn't figure out how to take a screen shot though. Maybe I will play a bit more tomorrow if I have time.

[Bicurico]

https://vma-satellite.blogspot.com/2019/02/vma-simple-spectrum-analyser-version.html

https://vma-satellite.blogspot.com/2019/03/vma-spectrum-analyser-for-hp-8590.html

Regards,
Vitor

[MarkL]

Excellent tool, thanks Mark!
I played for half hour at work with an HP8591E and GPIB-USB-HS.
I couldn't figure out how to take a screen shot though. Maybe I will play a bit more tomorrow if I have time.

It looks nice but windows only (although some people have had success running it in wine).

It would appear that 7470.exe would do a "screen capture" for you.  And I put that in quotes because the 8590 series and a lot of this older equipment emit HPGL, which is a vector drawing language where the original target was a plotter.  7470.exe interprets the HPGL commands and makes a raster image out of it.

[Bicurico]

Hi MarkL,

I have briefly looked at your scripts and what I understand is that you use some GPIB commands to list (CAT) the files and then transfer them back and forth.

I was considering hacking a Windows tool to replicate this, so that I don't have to struggle with Linux, but I don't understand exactly how/what you are doing.

Could you please elaborate on this:

- how do you extract a file from RAM memory of the HP
- how do you send a file
- how do you know which files to copy/move
- wouldn't it make sense to backup ALL files to PC, in order to be able to restore all of them in case the battery runs out? I could imagine writing a tool that does a CAT* and then extracts each file individually...

Thanks!

@Miti:

From what I understand, spectrum analyzers don't send the whole screen over GPIB, they rather just send the samples that compose the current spectrum sweep. It is the local PC software that then mimics the screen based on this trace. At least that is what my software does (among other things). This means you won't get the menu items, etc.

At this point I did not understand if the HPGL data is only output through the parallel port or if it can be read out over GPIB. That would be cool, as you could indeed, as already said, draw the vectors on a bitmap.

Regards,
Vitor

[Bicurico]

I am just reading the Programmer's Guide.

I seem to have understood that one can actually create programs inside the device memory, in order to carry out tasks - much like a macro.

This can be associated to a soft-menu button!

Cool stuff!

And I now understand why it is better to have to script language, as each command of the macro is send as an individual GPIB command.

I could easily am going to write a small tool that uses the Keysight Connection Expert and sends the contents of text files containing such programs.

This HP 5894E is a cool device...

Regards,
Vitor

[MarkL]

Hi MarkL,

I have briefly looked at your scripts and what I understand is that you use some GPIB commands to list (CAT) the files and then transfer them back and forth.

I was considering hacking a Windows tool to replicate this, so that I don't have to struggle with Linux, but I don't understand exactly how/what you are doing.

Could you please elaborate on this:

- how do you extract a file from RAM memory of the HP
- how do you send a file
- how do you know which files to copy/move
- wouldn't it make sense to backup ALL files to PC, in order to be able to restore all of them in case the battery runs out? I could imagine writing a tool that does a CAT* and then extracts each file individually...

Thanks!
...

Take a look at this post:

  https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1021445/#msg1021445

That describes how I extracted items out of the analyzer's memory.  In that same thread, this post also points to a tar file:

  https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1030583/#msg1030583

If you haven't already done so, download it and take a look at the files in notes/.  It has some additional explanations of the procedure.

And yes, it would make sense to have a tool.  As I've said in many posts, there is a command called "USTATE" that I was never able to get to work.  It is supposed to do exactly what you want and create an archive of all the DLPs, KEYDEFs, traces, etc etc in the analyzer's memory.  Maybe you can give it a try before heading down the much more difficult path that I took.  The backup procedure with USTATE would be trivial if you can make it work.

[Bicurico]

I have downloaded your TAR quite a while ago! Thanks, by the way!

I played with the USTATE command and extracted everything using the Keysight Interactive IO to send the command and IO Monitor to actually capture the data.

I imagine that this data needs to be treated as binary data (individual bytes).

I will look into that.

My question: how/when did you realize that the upload of the captured file did not work? I am asking because I obviously don't want to corrupt the memory of my unit...

The manual says:

"The contents of user memory can be restored by executing USTATE followed by the A-block
data retrieved by a previous “USTATE?;” command."

So this means that one needs to send the exact same data back, but how are the control characters dealt with?

Again, the manual gives an example in HP Basic (or what ever that is):

ENTER 718 USING "#,-K";User$

"-K" allows control codes to be treated as characters.

Attached is my dump.

Regards,
Vitor

[MarkL]

It does need to be 8-bit clean on both input and output, I know that much for sure.

The first four bytes are "#A<LEN1><LEN0>" where LEN1 LEN0 form the 16-bit big-endian length of bytes to be read in by the analyzer (the so-called A-block format).  The USTATE captures I've done always have valid lengths that match the length of the GPIB transfer, so I'm thinking it's something with the playback.

When I playback the USTATE output, it dies almost immediately and starts reporting errors and other garbage in the title area on the screen.  It doesn't get near reading in the majority of the data.

I've done binary I/O with other devices with my GPIB scripts, so I'm fairly confident it's not the scripts.  I haven't done the next step of clamping a logic analyzer on the GPIB interface to verify the exchange.

I also haven't tried pacing the output going to the analyzer to slow it down, but I think that would be unnecessary since GPIB, by its very protocol, is a three-way handshake to prevent buffer overruns due to one side not being ready.  But if anything, it might be useful to track down exactly where it dies.

The USTATE capture you posted doesn't look valid to me.  It doesn't have the #A header, and it seems to be lacking data in the range of 0x00-0x20 which I see a lot in the USTATE dumps I have.  Something is probably not being 8-bit clean.