GPIB-USB, What functions would you like in one of these ?

[dimlow]

I have built my own GPIB USB adaptor board and was looking at how people would want to use such a device.

I just wanted to use it to access some features that are not available on my 6.5 digit Solartron Multimeter front panel. For example the meter is capable of taking readings every 6.66ms but when you use it from the panel you only get one update per second. For this reason i needed a cheap GPIB-USB controller. The cheapest i could find was around $50 US. So i built my own GPIB-USB Controller from a  PIC 18f4550 and used its onboard USB connectivity and made it a CDC RS232 port.

Last weekend i got to writing the firmware for it and decided i would use a Proligix compatible command set, this has now been mostly completed. But from my point of view there are a few problems with the prologix choice of commands and the way it works. For a start it does not have a pure binary mode for sending binary data to an instrument. You have to use escape characters in the binary data and extra software is needed to accomplish this. I would like to make my GPIB_USB capable of real binary data transmission, i have some ideas already, like a new ++binary send Command. Also in the prologix there are a few things it is not capable of like Parallel poll, and directly sending commands to the GPIB bus.

If i'm going to put some more effort into expanding the software i may make it available as open source, or even make a few boards available. It looks like it could be a nice project to take further as i have already put a lot of effort into it. For my uses, the project is finished i'm happy with it on vero board. It communicates with every instrument i have. But if there is a need for a cheap GPIB-USB board with real functionality i don't think I am that far off making this controller it. You could definitely build this for less than $20

So i'm looking for ideas, what would you like to see in a GPIB-USB controller?

[ve7xen]

Sounds like you've got a great start on this. It's something I looked into doing myself some time ago and got as far as doing a board layout, but never got further than that. I only have a couple GPIB instruments and not much use for an interface, but it would be handy for long-term drift and jitter measurements I've been wanting to do...

Ethernet would be nice .

[Wim13]

 I use the prologix usb to GPIB convertor, and i am very happy with it.

Works great made some software, that uses scripts to run various setups

The type of command set is not so important, as i use it with a program that talks to the prologix.
I only use direct commands in telnet when testing new measurements setups. After that
the software takes over and run automated from a script file.

[free_electron]

So i'm looking for ideas, what would you like to see in a GPIB-USB controller?

VISA compatibility.
GPIB32.DLL compatibility.

Meaning that, if you install it on a pc that the VISA framwork detects this as a valib GPIB provider and i can use the VISA calls to communicate with the instrument.
in order to do this you will have to provide a DLL file that exposes the GPIB32 API. This API defines about 18 commands to setup and control the GPIB transport.
Any industrial software out there , manufacturer supplied software , control software uses either VISA calls or calls against GPIB32.DLL.
VISA is the most flexible as it is supported by all the instrument manufactuers and the platform manufacturers ( Agilent , Tektronix, Fluke, National Instruments )
THe advantage of VISA is that it is retargetable. if you dump the GPIB link for an LXI link tomorrow you do not need to rewrite any code. just change the locale.

for example :

::GPIB0:22:DISP:TEXT 'Hello World'
::LXI:192.168.1.214:DISP:TEXT 'hello world'
::USB:VID0314&PID0217:1:DISP:Text 'hello world'

the locale pointer is the ::GPIB0:22   ( GPIB card 0 adddress 22 )  ::LXI:192.168.1.214 ( LAN machine implementing LXI at 192.168.1.214 ) or an instrument on my local computer at USB port with VID 0314 and PID0217 , instrument 1

This is what VISA implemements.

if VIDA detects a GPIB locale pointer it will invoke the calls to the VISA API provider. this is a DLL that you need to make that can respond to the visa function calls. typically they translate the visa API to the GPIB32  API (they are very similiar) , the GPIB32 API then hooks into your usb driver.

so

VISA API driver  <-> GPIB32 API driver <-> your custom USB driver <-> your hardware.
The most common entry points are going to be from the VISA or GPIB32 point. nobody will talk directly to your custom usb driver as it is non-standard.

That is the problem with all these homewbrew gpib converters : they don't implement any standard. they are contraptions with arbitrarily select command sets that are compatible only with themselves. they are incompatible on software level , and often at hardware level ( by omitting the real 75xxx series GPIB drivers ). while this may work for 1 or 2 machines, it is unreliable , not bulletproof and does not work with any software delivered by the instrument makers ( as these all use the standard VISA or GPIB32 interface )

[nctnico]

I have built my own GPIB USB adaptor board and was looking at how people would want to use such a device.

I just wanted to use it to access some features that are not available on my 6.5 digit Solartron Multimeter front panel. For example the meter is capable of taking readings every 6.66ms but when you use it from the panel you only get one update per second. For this reason i needed a cheap GPIB-USB controller. The cheapest i could find was around $50 US. So i built my own GPIB-USB Controller from a  PIC 18f4550 and used its onboard USB connectivity and made it a CDC RS232 port.

I have an ARM Cortex based design with the proper driver chips waiting for some firmware... This could be an interesting product. I already have several PCBs.

[ve7xen]

VISA API driver  <-> GPIB32 API driver <-> your custom USB driver <-> your hardware.
The most common entry points are going to be from the VISA or GPIB32 point. nobody will talk directly to your custom usb driver as it is non-standard.

That is the problem with all these homewbrew gpib converters : they don't implement any standard. they are contraptions with arbitrarily select command sets that are compatible only with themselves. they are incompatible on software level , and often at hardware level ( by omitting the real 75xxx series GPIB drivers ). while this may work for 1 or 2 machines, it is unreliable , not bulletproof and does not work with any software delivered by the instrument makers ( as these all use the standard VISA or GPIB32 interface )

How does this work on non-Windows systems? When I was looking into this I had a hard time finding any documentation on how this interface actually works, and certainly nothing comprehensive enough to actually implement it.

[nctnico]

VISA API driver  <-> GPIB32 API driver <-> your custom USB driver <-> your hardware.
The most common entry points are going to be from the VISA or GPIB32 point. nobody will talk directly to your custom usb driver as it is non-standard.

That is the problem with all these homewbrew gpib converters : they don't implement any standard. they are contraptions with arbitrarily select command sets that are compatible only with themselves. they are incompatible on software level , and often at hardware level ( by omitting the real 75xxx series GPIB drivers ). while this may work for 1 or 2 machines, it is unreliable , not bulletproof and does not work with any software delivered by the instrument makers ( as these all use the standard VISA or GPIB32 interface )

How does this work on non-Windows systems? When I was looking into this I had a hard time finding any documentation on how this interface actually works, and certainly nothing comprehensive enough to actually implement it.

NI Visa is also available for Linux. GPIB is basically an ASCII protocol with escape modes for binary transfers. The original parallel GPIB bus can be replaced with anything over which you can send text.

[free_electron]

How does this work on non-Windows systems?

Buy a scope, arbitrary function generator , multimeter or anything from any brand. Any software that comes with it is for windows... Like it or not. That's the facts of life ....
All that software talks VISA or GPIB32.DLL

you can get the GPIB32.DLL API by downloading the GPIB32.DLL users manual from national instruments or agilent or any other GPIB card vendor out there.
The functions are listed as well as what they import and export. All you need to do is write a DLL that has all those functions. what you do internally in the DLL to talk to your hardware is your domain. As long as you export that list of functions with the correct arguments it will work.

There are VISA ports for linux and even solaris but you can only use those with National instruments Labview. And then only on very specific distro's.
Their runtime can execute windows-built programs on linux. ( Labwindows / Labview are NOT native windows applications. They require a runtime ... they are pseudo-code internally. That runtime exists on Linux. But it is not free, neither is in 'open source, nor as in 'gratis'. its $$$ )

[Bored@Work]

How does this work on non-Windows systems? When I was looking into this I had a hard time finding any documentation on how this interface actually works, and certainly nothing comprehensive enough to actually implement it.

Not well. Yes, you get VISA for Linux, but that is about it. It already starts with the standards and the standard committees. VISA explicitly states they don't officially support for anything but Windows. That you get a version for Linux doesn't mean it is sanctioned. IVI is even worse. IVI driver specs explicitly rely on Windows features, although they gave up IVI-COM on 64 bit Windows. But the IVI common components are still Windows-only.

Other standards, e.g. LXI are tight to these ones. Although LXI is about Ethernet for instruments they e.g. request that instruments which need drivers come with IVI drivers. And those are tied to Windows ...

It is a small, close knitted community of companies who make the standards, almost a cartel. And they have agreed on 100% Windows only. It protects their investments and their eco system.

For other operating systems, like Linux or OS X you are basically on your own. Sometimes you have to start at the lowest level, finding or building adapter hardware, and then implementing every layer in the communication stack until you can talk to an instrument on Linux or OS X. It can get annoying at times.

[ve7xen]

NI Visa is also available for Linux. GPIB is basically an ASCII protocol with escape modes for binary transfers. The original parallel GPIB bus can be replaced with anything over which you can send text.

I know that's what GPIB is, but how does the interface between VISA and your GPIB dongle work? This part seems needlessly complicated and not well documented.

These are hardly standards if you can't actually implement them without the 'standard' toolkit', though I was genuinely interested if it was possible beyond what I was able to find.

I don't get why this has to be so complicated. If you want to make a standard for interfacing GPIB dongles, specify a few text commands and support char devices and TCP/IP sockets and you're done, no? Why is this all bundled up in proprietary DLLs and devkits and a bunch of other complexity that serves no purpose? Windows or not, you've still got to implement a bunch of shared library crap (that I can't really find documented anywhere) to build a simple character device.

You'd think the scientists buying this equipment would want standards that are actually simple, easy to implement and interoperable...but I guess NI is better served by forcing everyone to use LabView.

Anyway this is venturing off topic. I would be interested in a 'dumb' GPIB dongle that can present as a character device in Linux or accept TCP/IP sessions, regardless of support for the $$$$$ proprietary stuff. The SCPI commands are pretty straightforward to use, it's the hardware interface that's the annoyingly 'difficult' part.

[nctnico]

Google for USBTMC. If your device is equiped with it (which is almost any piece of modern equipment) you should get a character device under Linux where you can send the GPIB-like commands to. I'd like to find a driver for Windows which does this...

[Bored@Work]

Google for USBTMC. If your device is equiped with it (which is almost any piece of modern equipment) you should get a character device under Linux where you can send the GPIB-like commands to. I'd like to find a driver for Windows which does this...

This is also not without problems. The USBTMC driver was completely broken in older kernels. Then it got fixed, but the Linux USB driver big cheese himself removed features. Because he either didn't get them or didn't like them.

The main issue is that USBTMC is message-oriented and has no notations of lines or characters, it is just messages. SCPI is line-oriented and the Linux device interface they want on top is stream (character) oriented. Three different views that need to be glued together. And that glue, e.g EOL triggering the sending of a USBTMC message, buffering received messages until EOL is received, and/or seperating received messages by inserting artificial EOF into the device's stream was removed.

The end result is you can't trust the driver and can't simply script communication.

Anyhow, cheap rubbish instruments, for example the popular Hantek stuff, typically does not  support USBTMC, but uses some USB UART or HID interface. And doesn't use SCPI, but propritary binary protocols.

[Wim13]

The point is then, how do want to use the interface..

If you want to use standard software from the shelf, you want a compatible interface.

But if you want to make programs by your self, then you want a simple interface,
that was the reason for me to buy the Prologix. It was easy to fit in my
own software, just talk to the Prologix interface as a text device. No difficult drivers.

I dont need any Visa stuff for my programs.

[dimlow]

Wow, lots of interesting info here. I had a quick google and there is already some sort of GPIB32 driver for the Prologix. See here http://sourceforge.net/projects/opengpib/?source=recommended there is also this http://sourceforge.net/projects/serial-gpibnicl/ probably something like what you are looking for ? No doubt there are others too.

I am not a windows / linux  programmer and a have never made a driver or a dll. I would not know where to start with this. VISA, never used it. Never had the need to. VISA GPIB 32 its a great idea but for me, i don't need it. I was only asking if there were any improvements that could be made to the prologix command set. I few little tweaks here and there for the controller. I think what you are asking here is too much for me to handle.

Im having an easter holiday so will not be doing much on this for a while , but i have enjoyed reading these suggestions even if i don't quite understand the need for them. I will come back to this later when i feel more in to mood of programming. This has made my head hurt.

[free_electron]

Google for USBTMC. If your device is equiped with it (which is almost any piece of modern equipment) you should get a character device under Linux where you can send the GPIB-like commands to. I'd like to find a driver for Windows which does this...

That is what GPIB32.DLL and GPIB.SYS do.
GPIB32.DLL is an API into GPIB.SYS.
GPIB.SYS creates a Device that can be accessed using IOCTL commands. just like you have a COM1 COM2 , LPT1 LPT2 you will have a GPIB0 on your computer.

open a command prompt , and type ECHO GPIB0 <enter>
you can now talk directly on the gpib bus. the command set is ASCII

IBOPEN 22 <ENTER>
IBWRITE 22,"DISP:TEXT 'hello world'" <ENTER>
IBCLOSE 22<ENTER>

and so on.

the GPIB standard is owned by 2 companies : Agilent ( who, when they were still Hewlett Packard invented HPIB , which got ratified as IEEE488 / IEC625. as IEE and IEC do not want company names in there it was called GPIB . HPIB : Hewlett-Packard Instrumentation Bus. : GPIB General Purpose Instrumentation Bus. )
IEEE488 has gotten 2 extentions over the years : .1 and .2 . 488.1 brings a common command set while 488.2 brings an additional layer and speed boost.
SCPI ( Standard Commandset for Programmable Instrumentation) is part of 488.2 i believe. this is the ascii texts flying back and forth.
The common command set are commands like *IDN? *RST *CLR *REM etc. they are bus/instrument management commands.

The 488.2 was co-authored by National instruments , Keithley and some others.

There are only a few chips out there that implement the GPIB master and they are subject to licencing. ( buying the chip includes the licence to use )
NEC : upd7210 
intel :  8291 + 8292 + 8293  (91 is the base interface , 92 adds host capability , 93 is the io drivers)
TI : TMS9914
Signetics HEF4788
Motorola 68488
NI : TNT488 or other ASICS

these chips interface with two GPIB bus drivers  SN75460 and SN75461 (i believe)

Agilent uses the implementation in a CPLD or the M9914 which is a custom built 9914 ( All the above chips are discontinued. Agilent bough tthe masks to the 9914 and has it fabbed by Rochester ). Their PCI and USb solutions are cypress68013+ cpld or cpld based.
NI has their own asics for USB / PCI / RIO / VXI MXI and others
ICS uses the CPLD solution.

All the boards out there in the field are essentially a TI9914A  with an interface wrapper. the 9914 A is a very simple chip ith 16 config registrs. no more complex to deal with than a beefy uart.

Agilent, NI , ICS, Keithley and others have standardized on a common interface towards the programmer : GPIB.SYS and GPIB32.DLL.
GPIB.SYS implements the IOCTL driver (GPIB0 , or GPIB1 , GPIB2 etc oif you have multiple cards ) and GPIB32.DLL gives you an API into it.
the commandset of GPIB32.DLL is very short. there's like 20 commands or so.
Irrespective of the board vendor / hardware , if you rprogram can load GPIB32.DLL it will work. the rest is shielded.

Now, the problem is that machines can sit on GPIB , on LAN on , PCIE on USB or wherever. That is what VISA solves.
you still send the ASCII strings to the machines and the command strings ( SCPI or *IDN ) but using VISA you can change your target to whatever. you can change it to GPIb , LXI , USB or anything else. without having to rewrite code.

VISA is a vailable for free from National instruments, Agilent and a few others.
for what GPIB is concerned : if the VISA engine detects a GPIB32.DLL it will hook into that one and off it goes. you don't need to bother with anything else.

So long story short : wanna make a really compatible gpib controller : write that GPIB32.DLL for it... it will be picked up by any existing software out there whetehr that software calls GPIB32 directly or goes through VISA.

[jucole]

Sounds like a great project!

I found someone who has done a similar project using a 18F2550; i'm not sure how complete the implementation is but here is the link.
http://cluster.physik.uni-freiburg.de/~kuhnen/pic/pic_usbgpib/

[ecat]

Sounds like a great project!

I found someone who has done a similar project using a 18F2550; i'm not sure how complete the implementation is but here is the link.
http://cluster.physik.uni-freiburg.de/~kuhnen/pic/pic_usbgpib/

And this looks to be a spin on that project but with a much, much more pretty schematic and possibly other changes
http://www.dalton.ax/gpib/

I tracked down a few options when putting together a simple listen only arduino interface.

[dimlow]

Yes, i too found these and a few others. In fact my controller does use the same pinout as another 18f2550 based version. But the firmware was not great and i could only get it with work with  my HP scope. So thats why i decided to make one myself. It really only started off as a test bread board and after a couple a days i found i have almost completely written the prologix command set. So decided to finish it.

[quantumvolt]

Yes, i too found these and a few others. In fact my controller does use the same pinout as another 18f2550 based version. But the firmware was not great and i could only get it with work with  my HP scope. So thats why i decided to make one myself. It really only started off as a test bread board and after a couple a days i found i have almost completely written the prologix command set. So decided to finish it.

I am making an adapter for Atmega, but the structure and timing loop for the interface management and handshakes (5+3 wires) are hardware and software independent. Since it seems that you have both commercial code and your own decent code, would you like to share it? (if you can't post the commercial code, please give a link).

Thanks.

[rudolf]

Hello quantumvolt,

I have build an working USB to GPIB interface with an Arduino Nano 3 module (ATMega328).
Please see for details http://www.rudiswiki.de/wiki9/GPIBtoUSB_Nano3

Now I want to go to the USBTMC standard under Linux. Are you interested in such a project?

Regards, Rudolf