Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: GPIB bus topology
Date: Sun, 5 May 2024 09:09:22 -0700
Organization: A noiseless patient Spider
Lines: 121
Message-ID: <v18avj$1uiv4$1@dont-email.me>
References: <6632ba30$0$8096$882e4bbb@reader.netnews.com>
 <v0uni4$3f29c$1@dont-email.me> <v15je9$17ofg$1@dont-email.me>
 <v15t9t$1b1ir$2@dont-email.me> <u1KZN.15850$v2Kc.2089@fx03.ams4>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 05 May 2024 18:09:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="71bf07d94cae0f075707248629149f94";
	logging-data="2051044"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX196rUIgFcpL3OCiNqk7EEqH"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:zumJnxDHIjja6m5xzm5WQtO7Vdk=
Content-Language: en-US
In-Reply-To: <u1KZN.15850$v2Kc.2089@fx03.ams4>
Bytes: 7147

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.