Re: GPIB bus topology

On 5/5/2024 4:26 AM, Chris Jones wrote:

On 5/05/2024 4:03 am, Don Y wrote:

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".

 As I already posted, there is an open source project called AR488 which uses an Arduino to convert USB to/from GPIB. google AR488

As I said, "I would be surprised if there isn't...".  It's a trivial hardware
and software problem.

There is a board which you can get made at OSHpark cheaply which adapts the arduino pinout to the connector.

What I don't understand is why someone would go to the trouble to make
a daughter card and NOT just add the rest of the necessary components
TO that card and package the whole thing better/smaller!
OTOH, learning how to miniaturize entire products is a skill that takes
time to learn.  And, anticipating each potential future "shoe-horning"
activity is a challenge (I have a design that fits in WoW characters
but won't fit in Furbys, to my chagrin!)

There are relatively cheap connectors without the jack screws and daisy-chaining capability that you can use because you do not require the ability to daisy chain other cables onto the back of your USB adapter.

I just used an IDC-terminated connector as my PCB was largeish (old
technology) and didn't want it supported by the instrument's connector.
And, as I said, have tossed the GPIB cables opting for an adapter
per device (I suspect most folks don't really need the ability for
devices to talk to each *other*)

One shortcoming it has is that it will draw current from the GPIB bus if the USB cable is not powered, but it is easy to avoid doing that.

I would eschew anything USB-related; it often requires drivers
and places limits on where the USB host can be located.  E.g.,
I can talk to my adapter from an old SPARCstation, NeXT cube,
cell phone, etc. instead of having to add USB capabilities (and
cable) to each.