Re: HPIB bus commands

From: Greg King (
Date: 2004-04-19 20:41:21

-----Original Message-----
From: Larry Mollica
Date: Monday, April 19, 2004 04:04 AM
> I don't know why HP thought that certain things deserved to be bus
> commands, while most of the instrument control is done with regular
> data.  Maybe they had a reason, but for us it's just a big pain.

When an HPIB controller sends a command to an instrument, it might be
saying, "listen to only the HPIB bus; we're more important than local
control."  Then, when it sends an "unlock front panel" command, it is
saying, "listen to local commands; they are more important than anything
that comes from the bus."  That kind of thinking might be how HP justifies
claiming that some device-commands are bus-commands.

>>I vaguely remember that OPEN keeps ATN set to "active" while it sends the
>>file-name string.  If I'm correct, then you could pretend to open (and
>>close) a file.  You would use the device-command that you want to send as
>>the name of that phony file.
> That should be easy to try. I will give it a shot next weekend, maybe.
> One potential problem is some of the HP bus commands were control
> characters, although many were printable. I'll have to get my hands
> on manuals before I can tell if this method would do us any good.

You can put any eight-bit number into a string-expression by using the
CHR$() function.

OPEN 6, 27, 0, CHR$(1): CLOSE 6

> If you set the HP dip-switch to a value of 5, then
> OPEN 1,5
> will give you control. (The front panel locks upon the first PRINT#,
> and stays that way until you turn off or reset the instrument. Either
> of which destroys any setup the PET may have done.)
> Most of the functions, like say, entering a frequency value, are
> normal data, as in a PRINT# command. We have been able to get this
> kind of stuff (mostly) working.
>  PRINT#1, "A1";
> will, for example, select a specific relay in an HP switch-box.

I'm glad to see that two obvious problems don't exist:
1. You can choose an instrument.
2. You can talk to it.

But, I see another problem:  different sets of character-codes.  The CBM
uses PETSCII, while HP's devices use ASCII.  So, your BASIC programs must
translate letters.

-----Original Message-----
From: Marko Mäkelä
Date: Monday, April 19, 2004 04:45 AM
> BTW, there is some magic in the high-order bits of the file number, and
> possibly device number.  One of them controls CR to CR/LF transformation,
> and setting another bit avoids sending the secondary address,
> if I remember correctly.  This is on the Commodore serial bus; I haven't
> disassembled the PET firmware.

Yes.  When the logical-file-number is greater than 127, PRINT# appends a
line-feed to carriage-returns.  ( It doesn't translate to ASCII, though,
which is a shame. :-/ )

When the secondary-address is higher than 127, it is not sent over the bus.
Also, OPEN and CLOSE act locally only; they do nothing (including sending
file-names) to the bus.

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.