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?
bitrex <user@example.net> 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?
Daisy chain, no more than two connectors per unit as the accumulated weight gets problematic.
no more than two connectors per unit as the accumulated weight gets problematic.
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?
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?
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?
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"!
[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?
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
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"!
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-brandedThe 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.
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? >>
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...
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".
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
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.
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.
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!)
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.
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.
On 5/7/2024 7:16 AM, Chris Jones wrote:
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.
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? :>
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!]
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 415 |
Nodes: | 16 (2 / 14) |
Uptime: | 109:11:02 |
Calls: | 8,692 |
Calls today: | 1 |
Files: | 13,259 |
Messages: | 5,948,434 |