Yet Another USB GPIB Interface (yaugi)

[artag]

GPIB is dead because it is so awfully slow, except for reading old DVMs and frequency counters. If you ever downloaded a DSO screen dump via GPIB you know what i mean.

For new designs it may well be dead. USB, Ethernet, or VXi are likely to be interfaces of choice for a modern system design, and in any case a system costing thousands of dollars can easily afford the best existing commercially available interfaces. There is no economic valuie in rolling your own.

However, although many of the people in this community are professional engineers we fill our home and self-employment labs with excellent secondhand equipment, often far superior to cheap modern replacements yet bought at bargain prices. This, to me, is the use-case for cheap home-made GPIB interfaces  - allowing us to use that equipment to build more complex systems and acquire the data off them to process using cheap computing power.

I think these yaugi projects are for somebody interested in learning details of this legacy data bus. Implementing it on a professional level including some API including reasonable exception handling is more than a man year. Also i remember that it needs to be largely configurable to work with all/many different devices, not just the ones you happen to use for test. One needs a logic analyzer and a HP 59401A or NI Measurement & Automation Explorer.

I agree with the educational aspect. But I disagree that it's otherwise useless. The vast majority of those instruments are slow, low data throughput and are entirely usable. A 6.5 digit DVM probably isn't going to read any faster than a tiny bitbanged interface can transfer data. There may well be some cases where it's a handicap but they can be considered on their merits. They don't need a blanket condemnation.

I have a selection of HP logic analysers and an HP59401A. The 59401A is charming (reminds me of a 70's era minicomputer) but I think the most useful thing for GPIB debugging is probably a $5 Cypress FX2 board and Sigrok's protocol decoder. Perhaps add a scope for noise margin measurement and some adjustable bus loading (the 59401A documentation even encourages you to build your own bus loads).

If you have an application where you can't avoid using GPIB, keep away from the troubles of a partial implementation, but get one of those used HP USB adapters or a NI GPIB-ENET. My personal opinion.

The chinese clones/refurbs are worth considering if you want convenient compatability with existing host software, and I'm all for buying (and perhaps fixing) used equipment. But I don't think the prices on many of the more useful interfaces (like the ethernet ones) are worth paying. Bear in mind that NI in particular offers poor support for its hardware - the linux drivers are out of date and the NI programming environment ridiculously proprietary. They've failed to keep up to date with modern OSS thinking and are stuck in a windows-only timewarp. I do have a couple of NI interfaces but I can't see an advantage in using them.
 

[james_s]

GPIB is dead because it is so awfully slow, except for reading old DVMs and frequency counters. If you ever downloaded a DSO screen dump via GPIB you know what i mean. I think these yaugi projects are for somebody interested in learning details of this legacy data bus. Implementing it on a professional level including some API including reasonable exception handling is more than a man year. Also i remember that it needs to be largely configurable to work with all/many different devices, not just the ones you happen to use for test. One needs a logic analyzer and a HP 59401A or NI Measurement & Automation Explorer.

If you have an application where you can't avoid using GPIB, keep away from the troubles of a partial implementation, but get one of those used HP USB adapters or a NI GPIB-ENET. My personal opinion.

Regards, Dieter

GPIB is alive and well, hence the proliferation of hobby interfaces for it. There is tons of old gear out there that lacks anything better, I've mostly used the interface I built to unlock options on older Tek scopes.

I suppose from the perspective of modern gear in professional settings there is little need for GPIB anymore but that doesn't mean it's dead, rather it has achieved legacy status.

[artag]

The feasible ways to make an open-source VISA-compatible GPIB adapter without needing to write any host-side driver code, seem to be (1) Reuse an existing adapter USB interface, like that of the NI or Keithley USB adapters, (2) use USBTMC with a single connected instrument, or (3) Use Ethernet, having an array of ports (one for each instrument), exposed as VXI-11 devices or repurposing the interface of an existing gateway.

Agreed. And a convenient way to make a multi-device ethernet adapter is to have a system controller (perhaps a raspberry pi or x86 SBC) that provides a clean network interface to the programmer and connects with USB or legacy (ISA or PCI) bus devices to the actual instruments.

[dietert1]

A quick look at ebay showed several GPIB ENET devices at 50 to 130 bucks.
Another reason why GPIB is dead: It does not use differential signals like USB and Ethernet. So it generates a lot more noise.

Of course GPIB will exist some more time, similar to RCA connectors on high end audio equipment, that should be all digital nowadays. Last saturday a neighbour came by with a Technics receiver he had bought at the local flee market for 5 € and asked if i can fix that in case it doesn't work. I haven't been listening to analog transmissions for years, except in the car.

Regards, Dieter

[james_s]

Ironically in the US digital radio is essentially dead, it has managed to gain some foothold in cars but the majority of radio here is analog and most of the companies that were making non-car digital receivers have stopped. It was a silly proprietary system that never should have been allowed in the first place, a solution in search of a problem, it usually sounds like crap because they crank up the compression to fit more channels.

[pigrew]

Agreed. And a convenient way to make a multi-device ethernet adapter is to have a system controller (perhaps a raspberry pi or x86 SBC) that provides a clean network interface to the programmer and connects with USB or legacy (ISA or PCI) bus devices to the actual instruments.

One could bit-bang from a SBC, but I think it would take a FPGA or MCU to do things efficiently. For the protocol, I've been reading about VXI-11.2, VXI-11.3 and HiSLIP.

However, I should bring the conversation back to the yaugi. I had the idea to write a VXI-11.2 server (in something portable like C or python), that would interface with the USB->GPIB adapter using the prologix protocol over USBCDC. This should be portable to most VISA implementations (and even handle the escaping of binary data). Or maybe HiSLIP would be a better protocol choice than VXI-11.2. Security would be easier as the server would only need to listen to localhost.

[tkamiya]

My understanding is that GPIB protocol itself is standardized but not how hosts communicate with it.  No standard API exists for example.  That means the application software or a custom made driver for that device in conjunction with custom application has to talk to it. 

So what happens to application for custom made DIY device like these?  Are you limited to making your own applications, or can you use it with existing lab software of some type?  I'm very much interesting in making it and that's why I'm asking.

[maxwell3e10]

essele,
What is the current consumption of your adapter when running? I looked briefly at the chip specs, it should be only a few mA for the chip? This would be easy to get by stealing power from GPIB lines with diodes and a DC-DC boost converter.
For testing GPIB speed I was playing with a PTS frequency synthesizer. It has a simple gate-based listen-only GPIB adapter and should be quite fast.

[pigrew]

My understanding is that GPIB protocol itself is standardized but not how hosts communicate with it.  No standard API exists for example.  That means the application software or a custom made driver for that device in conjunction with custom application has to talk to it. 

So what happens to application for custom made DIY device like these?  Are you limited to making your own applications, or can you use it with existing lab software of some type?  I'm very much interesting in making it and that's why I'm asking.

There are two different interfaces involved. The first is the command language used by the instrument (often SCPI). This is unique to each instrument used, though sometimes abstracted with an Ivi driver interface which translates generic commands to the instrument-specific command.

The other layer is the method of sending the commands to the instrument (like GPIB). Most commercial interfaces provide a VISA DLL which lets commands be sent using a standardized interface. VISA can be configured to use alternate transports like USB, serial, or TCP/IP. This project tunnels GPIB commands through a USB serial port (USBCDC) using a protocol created by Prologix for their commercial adapters. Note that there are no drivers written that let your end user software use standard VISA interfaces to perform IO through the prologix transport, so it isn't yet a drop-in replacement for a standard GPIB adapter. A translation layer (HiSlip server) to make it compatible with software that uses the standard VISA API could somewhat easily be written.

[dietert1]

Ironically in the US digital radio is essentially dead, it has managed to gain some foothold in cars but the majority of radio here is analog and most of the companies that were making non-car digital receivers have stopped. It was a silly proprietary system that never should have been allowed in the first place, a solution in search of a problem, it usually sounds like crap because they crank up the compression to fit more channels.

We are using a digital TV satellite that yields all audio channels which used to be radio in the past or CD/DVD media.

By the way, some ten years ago we also made a USB-GPIB adapter, based on a XILINX CPLD and a FT245. It has a real bus interface and supports all the special GPIB functions. It achieves several MBytes per second when used as a pair to transfer data from one workstation to another. We made a C++ library with a high level API. So i know we can run independent of Microsoft and independent of NI, that was the main motivation behind it. But i also know our solution is still not mature. E,g, due to its near real time requirements it is not exactly "nice" to other processes on the machine.
Smaller projects like this one here may be useful to abandon GPIB in the sense of the bus being replaced by a USB hub, with a separate 10 $ USB converter on each GPIB device.

Regards, Dieter

[essele]

essele,
What is the current consumption of your adapter when running? I looked briefly at the chip specs, it should be only a few mA for the chip? This would be easy to get by stealing power from GPIB lines with diodes and a DC-DC boost converter.
For testing GPIB speed I was playing with a PTS frequency synthesizer. It has a simple gate-based listen-only GPIB adapter and should be quite fast.

It's currently using about 30mA ... but that includes a couple of unnecessary LEDs and absolutely no power optimisation.

I did consider trying to power from the GPIB interface, but if the device is using 3K pull-ups as per the spec, then you're not going to be able to get much, even from all 16 lines. I had ruled that out in favour of PoE for an ethernet based device.

[essele]

I've just started looking at USBTMC ... it actually appears pretty straightforward for basic use (although as pigrew pointed out there are quite a lot of exception situations if you want to do it properly.)

So the device is detected fine in Linux and OSX and I can get a request to it ... I haven't done anything with responses yet.

In Windows it's picked up as a USB Test and Measurement device but it's then not showing up in any of the tools (I've been using "NI-VISA interactive control".)

The behaviour changed when I added the serial number string to the config, it's now stuck saying "device setup in progress" in the control panel which it wasn't doing before, so I'm pretty sure it's something fairly minor with the config that I've missed.

I'm comparing with a 34470a which works fine.

Looking at a Wireshark USB trace everything appears to be identical, loads of descriptors gathering ... then the 34401a seems to respond to a URB_CONTROL_In message, where my device doesn't ... there there is a SET_DESCRIPTOR and a set of string queries on the 34401a where I'm just stuck.

I am seeing a load of "URB_Interrupt In" messages on my device, so I may try without the interrupt endpoint as a test.

EDIT: I was missing a SetPowerStatus() call, this seems to have cleared up the "device setup in progress" problem, so it all looks ok in Windows now, but still doesn't show up in NI-VISA. The device properties look identical, as do all of the events relating to the device, but still the same kind of traces. The interrupt messages are from a difference source, so not relevant here.

EDIT2: If I try to open the device directly in NI-VISA using the "USB::0x....::0x....::MY12345678::INSTR" address I get an "unknown system error", if I change the serial number to something incorrect, then I get a "device not in the system" error. So despite not finding it in a scan, it knows it's there!

EDIT3: Ok ... think I've figured it out ... the URB_CONTROL message seems to be a USBTMC specific message to EP0 which I need to trap and handle. Maybe next time I'll read the spec first ;-)

EDIT4: Yep ... now working ... gets to the same place as with Linux and OSX, it was the USBTMC GET_CAPABILITIES request. Onwards and upwards!

[pigrew]

For USBTMC, here are some other quirks I found:

• If you declare supporting 488.2, NI MAX will always send a *IDN?. If the IDN takes too long, it'll send a device clear. Issues will crop up if you don't implement device clear.
• CONTROL OUT transfers often don't go through in NI VISA on Windows (gives an error or data is corrupted).
• custom CONTROL IN transfers seem to work. I'd suggest implementing special features like address switching, etc, with INTERFACE CONTROL IN transfers, though you only have a few bytes to use for parameters (wValue). VISA has API functions to perform control transfers.
• Transfers in USBTMC are all half-duplex. You don't need to support having a bulk in active during a bulk out.
• You may want to override the behavior of the CLEAR_FEATURE EP on the bulk endpoints, but it isn't completely necessary.
• There's a special control transfer to request that a LED be blinked. NI MAX sends it when you connect, if you declare you support it.
• USB488 support requires that the interrupt endpoint be implemented.
• You want to implement USB488 so that you can READ_STATUS_BYTE
• Poll the SRQ line using a control IN transfer?
• The Prologix interface doesn't have any abort commands. Reads only stop at timeout or EOI from the instrument. So, there may need to be some code divergence between USBTMC and prologix here.

[essele]

Thanks pigrew ... I don't think I'm quite at the stage where I need to worry about some of those yet.

I've just got a proper request/reply setup working and can do basic queries with NI-VISA interactive control. I've got quite a few class requests to still implement, and I need to refactor a chunk of the older code to work better with the way the usb api works on PSoC ... which is actually a good thing since it's needed to get to a good place for higher speed binary transfers and will hopefully save a bit of memory.

Is there a reason why you wouldn't just send the ++ commands and interpret them as normal? That way you don't need to setup anything special??

[pigrew]

Is there a reason why you wouldn't just send the ++ commands and interpret them as normal? That way you don't need to setup anything special??

The reason would be compatibility with software that was written for other GPIB adapters (since they don't use the ++ syntax). It'd be nice if I can use the same pyvisa script to talk to instruments, independent of which adapter is being used.

Unless the plan is to write a gateway server (perhaps using HiSlip) which would translate VISA queries to Prologix commands? In that case, it might be a good idea to keep the ++ syntax. I'm actually leaning towards this solution, but it also means that that there is less of a reason to use USBTMC instead of USBCDC.

[essele]

I’m not sure I really follow ... there’s only really a problem if you are trying to connect to multiple devices via a single interface, otherwise it’s just config commands (which would persist via the EEPROM) ... and if you are trying to connect to multiple devices then you are deviating from USBTMC anyway and therefore you would have to be doing something different, ++ commands just seem a really easy way to do it.

Actually you could probably present two USBTMC instances via a composite device, or up to four if you ditch the interrupt endpoints - that may be a better option for multi-device use.

Anyway - I’ll focus on getting everything cleaned up first, we can worry about these details later.

[niner_007]

Also, for note, the symbol and footprint you can get from Mouser is wrong ... firstly the pin numbering is incorrect, and when corrected (based on pin 1) it's then back to front.

I though the same thing, but then I double checked, the pin numbering is correct, but it's from the front, not from the back: https://www.norcomp.net/rohspdfs/SCSI-050Ribbon/11Y/112/112-YYY-113R001.pdf

[JohnG]

GPIB is not dead even in some professional environments.

There are a number of reasons for this:

Not all companies can justify buying new equipment for everything. Furthermore, some used equipment is commonly available, so spares are no problem. Maybe in 10 years...?

New equipment is not bug-free, and worse, its bugs are not well documented on the web. Even equipment from Tier I vendors is not immune.

USB does not have high noise immunity, especially if you have to use hubs. If you are working on switch mode power supplies, do yourself a favor and go buy yourself a great big bag of ferrite clamps up front. Also, expect to switch out hubs until you find one you trust. Ethernet is much better in this regard, since many routers have transformers.

Finally, if you have a flexible test system where you are moving equipment around, USB is terrible. It can pull right out, or worse, just a little bit out. Ethernet is better unless the little tabs break off. GPIB doesn't have that issue, although the cables are cumbersome.

John

[pigrew]

I started implementing a HiSLIP gateway for Prologix (in Python using asyncio, even though I don't have any Prologix adapters...), but am now stuck. The HiSLIP protocol doesn't have an interface to request a read; it expects the device to immediately "push" responses. There appears to be no way for the gateway to know that it needs to address the GPIB device to talk. VXI 11.2 seems to be the appropriate solution to present a GPIB interface to VISA without writing an actual VISA implementation.

Anyone interested in a partial implementation of a HiSLIP server in Python? I'm not sure if I should post it on github or not, since I'm abandoning the code. I've implemented connections and dispatching write & readSTB() requests to a worker thread (to synchronize them)

[macboy]

...Smaller projects like this one here may be useful to abandon GPIB in the sense of the bus being replaced by a USB hub, with a separate 10 $ USB converter on each GPIB device.

Regards, Dieter

I agree. Writing software to efficiently and asynchronously talk to multiple devices sharing a single GPIB bus is a real pain. It is much easier to have one GPIB bus per device, and just communicate synchronously (i.e. allow a "READ" command to block the bus until the data is ready, etc.). Not only is the software much simpler, but you also avoid other troubles with multiple instruments on a bus... the slowdowns due to capacitance of the many cables, problems caused by too many powered-off instruments, etc..  Then there are the GPIB cables: thick and bulky, hard to route, hard do disconnect (held on with screws), and always expensive if you even can find them. One GPIB adapter per GPIB instrument is best, and the only practical way to do this is with these small, cheap yaugi or AR488 type devices which plug directly into the instrument GPIB connector.

[essele]

One per device was certainly my original plan -- and the more time I spend working on the USBTMC stuff, the more it makes sense.

My shielded connectors have arrived -- it's going to be fairly tight, but I think I should be able to get a board into the shield with a little creativity about how the connector is attached.

 dfb5b078460261d8d55a7988d6d14230 .gif (19.36 kB - downloaded 150 times.)

I'm hoping to finish the first cut of USBTMC and USB488 at the weekend ... implementing this has been great, it's really helped to clean up the approach since there is a lot less 'interference' with the data, so I'll need to retrofit to the UART side of things.

[essele]

I've put quite a few updates on GitHub now ... short summary:

1. You can now select from USBUART, USBTMC, or a composite device on the TopDesign (composite is not implemented yet)
2. USBTMC is done enough to test with NI-Interactive.
3. Serial is tidied quite a bit, should be good for binary now.
4. ++interact [0|1] added to switch between interactive mode and non-interactive mode

I'm still working on USB488, and a number of GPIB features (like serial poll), but I think there's enough here now to test for both UART and TMC modes and it seems to work ok with Windows, Linux, and OSX.

I'v also just designed and ordered a small board 33mm x ~14mm that should fit into the shielded connector ... on slow delivery though, since I want to get a few other things done first.

[pigrew]

I've made some progress on writing a Python/asyncio VXI-11 server, which I had mentioned above.

My code likely will only run on Windows, since it's implementing its own portmapper (instead of using the system's). I'm able to connect to it and execute read/write commands using both KeySight and NI IO libraries. The server is written to be single-threaded which makes the design easier to analyze (it does support multiple simultaneous connections and links). I have not implemented either a USBTMC or prologix adapter, but this is the logical next step.

Of note is that the KeySight IO libraries have a VXI-11.2 client (support for GPIB operations/commands on the bus) while it seems that NI does not. The KeySight libraries "prefer" to connect to (and lock) the entire bus, exposing it as a GPIB bus to VISA (so you use resources like GPIB1::5::INSTR). Internally, it's creating a single link, and sending raw 488 commands like ATN or REN to talk to the instruments.

On the other hand, NI IO libraries may connect to the VXI resources over multiple links "gpib0,#" (# is primary address), and relies on the server to arbitrate the various link's access to the bus. "aborting" is seemingly not implemented. This mode seems more portable, and is what I'd normally want to use.

See my source code at GitHub. (This is my first non-trivial python project.... I'm figuring out coding styles as I go....)

PS: If this is too irrelevant to the adapter designed here, let me know and I'll create a new thread. I'm hoping to the server to a state where it could be used with the YAUGI and related hardware.

[essele]

Hi Pigrew -- this sounds very interesting, although I would have thought getting it to work with Linux would be useful then it opens up the option to use a Pi etc. If it's a dedicated system then you could just kill the normal portmapper as a starting point!

I've got most of the bits now to build a few devices to ship to people to hopefully help with some testing ... I just need to sort the bootloader side of things to remove the need for the PSoC programmer -- that's the plan for this weekend.

So if you'd like a device to help with this then I should be able to ship you one soon.

[essele]

Ok, first attempt at the Yaugi that fits in the shielded connector...




... all was looking good, power was fine, programming was fine, but the UART wasn't recognised .. turns out the bloody Amazon USB cable I had butchered used the opposite colour coding from the reference I had found, and then I pulled a pad off the board trying to fix it.

My intention of using a cable tie as strain relief doesn't look like it will work as the head of the cable tie is too big and gets in the way of the plastic strain relief that's in the connector ... for this version I just got creative with a few bits of heat-shrink sleeving, which was ok, but it may need a bit more.

It's really fiddly to put together, but I think it's going to be great ... will have a go at number two tomorrow ... although I might use a thinner USB cable, the Amazon one is a bit chunky, seems to be more general purpose and has other conductors in.