Re: GPIB bus topology

On 5/4/2024 8:15 AM, chrisq wrote:

On 5/2/24 01:42, Don Y wrote:

On 5/1/2024 2:54 PM, bitrex wrote:

I have several pieces of HP gear (DMM, counter, Agilent-branded triple-output supply) I'd like to connect to a National Instruments USB to GPIB adapter for some measurements.
>
IEEE 488 is somewhat before my time and I see that the connectors are stackable, is there a preferred bus topology for a few pieces of gear? Star, linear/daisy chain with the stack on the interface, linear/daisy chain with the stack on the first piece of gear? Does it matter much in this use case?

>
The bus is dog slow (by today's -- or yesterday's! -- standards) so topology
isn't that important.  The cables, though, are costly, short and constrain
how you can (re)arrange your kit.
>
Consider, instead, GPIB-ethernet adapter(s) as this gives you a lot more
freedom in siting your kit.  I move things around as my benchtop often
doesn't have space for prototype, power supplies, instruments, etc. so
things "come and go" -- even during a session -- as my needs change.
It's nice to only have to worry about a thin network cable (easily
disconnected with one hand, "blind") instead of a frigging "hose"!

 >
 Have gpib based test gear all around the lab, beyond the limit
of cables, which are clunky and heavy anyway.

They're also mechanically stressful for the devices to which
they attach; move a device with cable still attached and you
put lots of stress on the connectors, etc.

Solution here was
the Prologix lan to hpib adapter, which puts the test gear on
the local subnet, where it belongs.

I designed a GPIB-RS232 adapter many years (decades) ago.  (I
had been given a bunch of engineering samples of an MCU with a
fair bit of EPROM and RAM on-board in the mid 80's... when such
things were unusual and went looking for an application that
would be small enough to fit in them)
No "smarts", just a media converter, of sorts.  I now marry those
to one-port terminal servers so I can TELNET to the device.

Have written an os package

That's far more ambitious.  I resort to looking up the specific
commands/protocols for the device of interest and just writing
a script, on the fly -- mainly, to save myself the hassle of
having to keep re-typing the same command strings, repeatedly.
Being able to embed comments in the scripts helps me remember
what they are trying to do, for which device and where I found
the original information (manual X, page Y) used for the script.
(I use these things so infrequently that I need a mechanism
to job my memory)

to drive it, so that at top level, it's all shell scripts, and
Can be built and controlled by any unix with gcc and a shell,
even cygwin on  windows.

I am mainly concerned with setting controls on devices (e.g.,
set power supply output #3 to 12.3VDC with a current limit of
250mA; set DSO to 1V, 1us; etc.) and retrieving one-shot data
(to import into documents).  So, I don't need instruments to be
able to talk to each other (which would be tedious in my approach)

Prologix used to be quite low cost, but they have raised the
price considerably since, which is a pain, but still lower than
the lan / hpib adapters from HP or NI...

A modern implementation would find the cost of the connector to be
the single priciest item; you can get an MCU with onboard NIC,
RAM, ROM, etc. so could likely fit everything *in* the connector shell
The MCUs that I used in the serial bridge were in PLCC84(?) packages
and, by the time you added XTAL, power conditioning, RS232 level
translators, connectors, etc. it was a large package
I would be surprised if there isn't an existing "open hardware/software"
project to make such a device using OTS "modules".