GPIB bus topology

[bitrex]

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?

[piglet]

Post by bitrex
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?

Daisy chain, no more than two connectors per unit as the accumulated weight
gets problematic.

[Phil Hobbs]

Post by piglet

Post by bitrex
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?

Daisy chain, no more than two connectors per unit as the accumulated weight
gets problematic.

Not to mention the torque, when someone tugs on a cable.

I believe that folks have been known to do a star connection, with the
center node being just cables, for that reason.

The interface speed is less than 1 MHz, even when externally clocked, so
it’s all the same electrically.

Cheers

Phil Hobbs

[Grant Taylor]

no more than two connectors per unit as the accumulated weight gets
problematic.

That's a mechanical problem, not a bus signaling problem.

Phil H's comment seems to support that they can electrically be stacked,
mechanical support problems aside.

[Don Y]

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

[I suspect it is also more future safe than any other bridge product.]

What are you planning on using in the host (PC) to talk to the instruments?

[bitrex]

Post by Don Y

Post by bitrex
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"!
[I suspect it is also more future safe than any other bridge product.]
What are you planning on using in the host (PC) to talk to the instruments?

Hoping to use SciPy/Numpy with a National Instruments GPIB-USB dongle on
a Linux machine.

There's a wonderful tech-surplus warehouse of the old fashion in the
Boston area, they sell the USB interfaces at $50 and 1 meter
L-com/Belkin/assorted brand GPIB cables at $10 a pop

[Don Y]

Post by Don Y
What are you planning on using in the host (PC) to talk to the instruments?

Hoping to use SciPy/Numpy with a National Instruments GPIB-USB dongle on a
Linux machine.

Be sure the dongle is on the end of a USB cable and not supported
by the USB port on the host!

There's a wonderful tech-surplus warehouse of the old fashion in the Boston
area, they sell the USB interfaces at $50 and 1 meter L-com/Belkin/assorted
brand GPIB cables at $10 a pop

Like Hefrons'?

I get most of my rescues as freebies from discards that aren't
"mass marketable" (e.g., not many mainstream folks want 50 pound
servers, SAS drives/cables, PoE switches, etc.) so have only "scrap"
value (e.g., 10c/pound for a computer; 21c/pound for a VRLA battery;
etc.).

As a result, I have a shitload of boxes full of assorted cables:
SCSI1, SCSI1-SCSI2, SCSI2-VHDCI, SunSCSI, Apple SCSI, USB2/3/c,
25pin parallel, DB9 serial, eSATA, CAT5/6, 13W3, composite video,
..

Many years ago I discarded the GPIB cables as "too bulky for
the functionality they provide" and moved to GPIB-over-enet.
I can leave test equipment piled out of the way until needed
and then just poke a patch cord into the GPIB adapter and be
up and running.

My only (partial) regret was discarding all the 10Base2 stuff
as it was *so* much easier to route a shitload of hosts than
the star topology used by *BaseT. Yeah, I could never have lived
with the 1MB/s transfer speed but the hassle of having to run
individual drops to each piece of kit is REALLY annoying...
especially when you want to rearrange stuff! SWMBO has a cartoon
of some guy crawling around under a bench amidst a tangle of
wires... with my initials written above him!

(My body is way too old for this sort of shit)

[chrisq]

Post by Don Y

Post by bitrex
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. Solution here was
the Prologix lan to hpib adapter, which puts the test gear on
the local subnet, where it belongs. Have written an os package
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.

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

Chris

[Don Y]

Post by chrisq

Post by Don Y

Post by bitrex
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.

Post by chrisq
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.

Post by chrisq
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)

Post by chrisq
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)

Post by chrisq
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".

[Chris Jones]

Post by Don Y

Post by chrisq

Post by Don Y

Post by bitrex
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.

Post by chrisq
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.

Post by chrisq
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)

Post by chrisq
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)

Post by chrisq
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

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

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.

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.

[Don Y]

Post by Don Y

Post by chrisq

Post by Don Y

Post by bitrex
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.

Post by chrisq
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.

Post by chrisq
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)

Post by chrisq
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)

Post by chrisq
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.

[Chris Jones]

Post by Chris Jones

Post by Don Y

Post by chrisq

Post by Don Y

Post by bitrex
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.

Post by chrisq
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.

Post by chrisq
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)

Post by chrisq
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)

Post by chrisq
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.

Post by Chris Jones
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!

It's to go on the back of a GPIB instrument. It doesn't need to be
small, but it is no bigger than a normal GPIB connector. It uses a small
arduino "pro micro".

If someone had intergated all of the components onto the same PCB as the
GPIB connector I would have avoided that design. It is easier to buy an
arduino than to build one, and probably cheaper too if you only want
exactly one of them. The adapter PCB was very cheap and building the
whole thing was very quick. That is what I wanted. I just wanted to back
up the SRAM in my DMM before its battery went flat and lost the
calibration settings, or before I accidentally erase the SRAM in the
process of replacing the battery.

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!)

Post by Chris Jones
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*)

Yes, and if you're doing that, it is cheaper to use the arduino adapters
than National Instruments, software permitting.

Post by Chris Jones
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.

I don't like USB, but a lot of software and hardware is set up to use
it, so as long as someone else deals with the details of the USB stack
and it works, I won't complain too loudly. If I have to write the low
level software I will try to use something else.

[Chris Jones]

https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg3360670/#msg3360670

[Don Y]

Post by Don Y

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!

It's to go on the back of a GPIB instrument. It doesn't need to be small, but
it is no bigger than a normal GPIB connector. It uses a small arduino "pro micro".

My point is more generic than that. I am often approached by clients
wanting to design a "daughter card" to some existing "module". But, there
is no *win* to using the module if you're designing (and having produced)
a daughter card -- it's just another dependency (and constraint) that you've
baked into your design.

If someone had intergated all of the components onto the same PCB as the GPIB
connector I would have avoided that design.

Why? Unless you want to be able to salvage the arduino *from* the daughter
card at a later date. Eschew unnecessary connectors, dependencies, etc.

It is easier to buy an arduino than
to build one,

But, did YOU have to build the daughter card?

and probably cheaper too if you only want exactly one of them.
The adapter PCB was very cheap and building the whole thing was very quick.

Ah, that answers the previous question. (I am talking about BUYING
a product that "does it all" instead of hacking something together)

That is what I wanted. I just wanted to back up the SRAM in my DMM before its
battery went flat and lost the calibration settings, or before I accidentally
erase the SRAM in the process of replacing the battery.

Understood.

Post by Don Y
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*)

Yes, and if you're doing that, it is cheaper to use the arduino adapters than
National Instruments, software permitting.

Ah, but Arduinos didn't exist in 1988 -- did they? :>

Post by Don Y

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.

I don't like USB, but a lot of software and hardware is set up to use it, so as

Now. But not in the past -- or likely in the future. In much the same
way that printer (and, soon, serial) ports went obsolete, consider how
everything USB-related will fare when The Next New Fad comes along?

long as someone else deals with the details of the USB stack and it works, I
won't complain too loudly. If I have to write the low level software I will try
to use something else.

I've decided that network interfaces represent the future of most
interconnects. It's silly to keep reinventing new stacks for each
different (competing) interface. Better to standardize on an external
interface in a device-independent manner. Look at the mess it leaves
each time some *interface* is deemed obsolete (just because of the
specific hardware device that required it)...

[I'm looking at an external disk enclosure with three different
interfaces on it when one SHOULD have sufficed. Or, bare disk
drives with ST506, ESDI, IDE/PATA, SATA, SCSI, Wide SCSI, SCA,
FC-AL, SAS, etc. Needless variety. And, that's not to mention
the cabling involved!]

[Jeroen Belleman]

Post by Chris Jones

Post by Don Y

Post by Chris Jones
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!

It's to go on the back of a GPIB instrument. It doesn't need to be
small, but it is no bigger than a normal GPIB connector. It uses a
small arduino "pro micro".

My point is more generic than that.  I am often approached by clients
wanting to design a "daughter card" to some existing "module".  But, there
is no *win* to using the module if you're designing (and having produced)
a daughter card -- it's just another dependency (and constraint) that you've
baked into your design.

Post by Chris Jones
If someone had intergated all of the components onto the same PCB as
the GPIB connector I would have avoided that design.

Why?  Unless you want to be able to salvage the arduino *from* the daughter
card at a later date.  Eschew unnecessary connectors, dependencies, etc.

Post by Chris Jones
It is easier to buy an arduino than to build one,

But, did YOU have to build the daughter card?

Post by Chris Jones
and probably cheaper too if you only want exactly one of them. The
adapter PCB was very cheap and building the whole thing was very quick.

Ah, that answers the previous question.  (I am talking about BUYING
a product that "does it all" instead of hacking something together)

Post by Chris Jones
That is what I wanted. I just wanted to back up the SRAM in my DMM
before its battery went flat and lost the calibration settings, or
before I accidentally erase the SRAM in the process of replacing the
battery.

Understood.

Post by Chris Jones

Post by Don Y
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!)

Post by Chris Jones
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*)

Yes, and if you're doing that, it is cheaper to use the arduino
adapters than National Instruments, software permitting.

Ah, but Arduinos didn't exist in 1988 -- did they?  :>

Post by Chris Jones

Post by Don Y

Post by Chris Jones
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.

I don't like USB, but a lot of software and hardware is set up to use it, so as

Now.  But not in the past -- or likely in the future.  In much the same
way that printer (and, soon, serial) ports went obsolete, consider how
everything USB-related will fare when The Next New Fad comes along?

Post by Chris Jones
long as someone else deals with the details of the USB stack and it
works, I won't complain too loudly. If I have to write the low level
software I will try to use something else.

I've decided that network interfaces represent the future of most
interconnects.  It's silly to keep reinventing new stacks for each
different (competing) interface.  Better to standardize on an external
interface in a device-independent manner.  Look at the mess it leaves
each time some *interface* is deemed obsolete (just because of the
specific hardware device that required it)...
[I'm looking at an external disk enclosure with three different
interfaces on it when one SHOULD have sufficed.  Or, bare disk
drives with ST506, ESDI, IDE/PATA, SATA, SCSI, Wide SCSI, SCA,
FC-AL, SAS, etc.  Needless variety.  And, that's not to mention
the cabling involved!]

The variety is there because of a long history of changes to
induce people to buy new things. Thus it will ever be.

Jeroen Belleman

[Martin Brown]

Post by bitrex
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?

IEEE488 is surprisingly tolerant of abuse and unless you have very fast
(for the day) transient recorders you won't be pushing the speed limits.
The whole thing is good for about 1MHz flat out if your drivers are up
to it. Most DVM and test kit is pretty slow but fast enough to be handy.

At 1MHz topology hardly matters but mechanical considerations do! We
used to use custom IEEE488 cables much longer than the approved length
on big kit with only a minor slowing down (that was on the HP chipset).
ie. One longish 5m cable and a few 1m/2m ones at the far end.

Just beware of stacking them more than 3 deep or the stress on the
connector can pull the board out of the PC. Also beware of metal
turnings or be sure to have plastic caps on all the stackable backs.

[Chris Jones]

Post by bitrex
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?

By the way, if anyone is after a GPIB to USB adapter that is cheap, look
at the AR488 arduino firmware. I used it to back up the battery backed
SRAM in my HP3478A.