• GPIB bus topology

    From bitrex@21:1/5 to All on Wed May 1 17:54:56 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From piglet@21:1/5 to bitrex on Wed May 1 22:05:12 2024
    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.

    --
    piglet

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to piglet on Wed May 1 22:34:23 2024
    piglet <erichpwagner@hotmail.com> wrote:
    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.


    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

    --
    Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to piglet on Wed May 1 19:08:14 2024
    On 5/1/24 17:05, piglet wrote:
    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.



    --
    Grant. . . .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to bitrex on Wed May 1 17:42:38 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to bitrex on Thu May 2 12:09:03 2024
    On 01/05/2024 22:54, 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?

    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.

    --
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Jones@21:1/5 to bitrex on Fri May 3 00:14:31 2024
    On 2/05/2024 7:54 am, 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?

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to Don Y on Thu May 2 18:52:16 2024
    On 5/1/2024 8:42 PM, 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"!

    [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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to bitrex on Thu May 2 17:15:00 2024
    On 5/2/2024 3:52 PM, bitrex wrote:
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chrisq@21:1/5 to Don Y on Sat May 4 16:15:21 2024
    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. 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to chrisq on Sat May 4 11:03:30 2024
    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".

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Jones@21:1/5 to Don Y on Sun May 5 21:26:17 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Chris Jones on Sun May 5 09:09:22 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Jones@21:1/5 to Don Y on Wed May 8 00:16:31 2024
    On 6/05/2024 2:09 am, Don Y wrote:
    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!

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Jones@21:1/5 to All on Wed May 8 00:21:05 2024
    https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg3360670/#msg3360670

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Chris Jones on Tue May 7 08:23:13 2024
    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!]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeroen Belleman@21:1/5 to Don Y on Tue May 7 17:43:38 2024
    On 5/7/24 17:23, Don Y wrote:
    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!]


    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)