Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Don Y 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: References: <6632ba30$0$8096$882e4bbb@reader.netnews.com> 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: 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.