Close
0%
0%

GPIB Instrument Control Console

Silly simple GPIB console for U/Linux & Mac OS

Similar projects worth following
I've slowly been acquiring a collection of GPIB enabled instruments for my bench and that allows me to do more sophisticated testing. Now all I need is a way to interface it to my MAC and software to control them.

The commercial software - like LabView - is awesome but very expensive. Some vendors like Keysight offer free or limited versions but all require specific and/or expensive hardware which limits what platforms you can use them on.

Prologix (prologix.biz) takes care of the hardware interface with their GPIB to USB adapter. It enumerates as a virtual serial port which in Unix-like operating systems is great. Basically a character device that you can access with standard file stream I/O. This makes it easy to write your own software to control instruments, heck you can even do it with a terminal emulator or even the call-up (cu) command. Best of all it's platform agnostic.

I created GPIBCON as a first step toward an extensible control program.  This version is very simple and only talks to a single instrument. but multiple instances can be run.  It's text-based and runs in a standard terminal window.  You configure it for the specific instrument via an ASCII config file.

Source code & config file comments provide the details.  Basically you add the GPIB commands to the config file and run the program with the name of the virtual serial port device.  It displays a 'console' of data from the instrument along with a command prompt to control it.

The program is written in ANSI C and distributed under the MIT license.  It should compile without problems on Mac OS and most U/Linux distributions.  Dunno about Windows.

Feel free to use as-is or a starting point for something more capable.

gpibcon-v5_1_b5.zip

Version 5.1 contains fixes to the serial tty interface and allows the semicolon to be used within a field using the backslash or escape (\) character.

Zip Archive - 46.61 kB - 03/06/2021 at 23:23

Download

gpibcon-v5_0_b16.zip

Version 5.0 contains several enhancements for display control and logging. See log post for details.

Zip Archive - 44.43 kB - 10/28/2019 at 21:11

Download

gpibcon-v4_1_b34.zip

Version 4.1 is a maintenance release to fix compile on Linux systems and corrects a related bug.

Zip Archive - 38.61 kB - 09/25/2019 at 18:16

Download

gpibcon-v4_0_b87.zip

Version 4 adds ability to address multiple instruments on two device interfaces, timeout handling, and numerous optimizations.

Zip Archive - 38.43 kB - 04/20/2019 at 22:32

Download

gpibcon-v3_0_b8.zip

Version 3 adds data logging & the use of constants in calculated fields.

Zip Archive - 27.32 kB - 03/29/2019 at 16:30

Download

View all 7 files

  • Version 5.1 Posted

    Brian Cornell03/06/2021 at 23:41 0 comments

    I picked up a newer (as in still in production) instrument for my bench and had problems getting it to talk. After lots of teeth gnashing and resorting to Wireshark to dissect the USB I found that subtle changes on the GPIB bus were causing the Prologix controller to stop sending data. The kernel was also messing with CR & LF in the received data stream. Using termios functions solved the problem: all flow control, echo, and character translation is now disabled. Performance seems crisper with all of my instruments.

    Most SCPI implementations use the semicolon to allow related commands to be sent together which is much more efficient. I've worked around this in the past but it is a hassle. This version recognizes an escaped semicolon (\;) in any of the fields but it is mostly intended for commands.

    All of my development work is now done on Linux so I can't say for sure that it will compile without modification on Mac OS X or other Unix systems.

  • Version 5.0 Posted

    Brian Cornell10/28/2019 at 21:25 0 comments

    I guess I'm not done with this and probably won't be for a while.  Every time I use it I find more things for it to do.  This is the curse of writing your own software.

    This release provides more display control & handling, and improves the logging.  The source is well documented and I've expanded the detail in the sample config file.  From the source:

        + Change default display timing flag - added '-u' flag.
        + Run commands in display that don't display but still log by setting
          <row> to zero.
        + Clear receive buffer after initialization to prevent display data sync
          problems:  gpibInit repetatively reads stream after each 'basic' command.
        + Clear receive buffer after off commands to prevent subsequent read
          problems:  gpibInit repetatively reads stream after each OFF command.
        + Added flag to force the reset of displayed data by purging any pending
          data in the stream at start of display sequence:  '-f' flag.
        + Added flag to reset displayed data when an I/O error was encountered on
          the last display loop by purging any pending data in the stream at start
          of display sequence:  '-r' flag.
        + Added Mark Comment field when logging.  Typing text after the mark command
          will be placed in the Comment field of the record where the mark value
          changes.  It is enclosed in quotes to accommodate punctuation that might
          be interpreted as a field separator.
        + Added record numbers to log file to make it easier to identify 'missing'
          records during analysis.
        + Added option to log config (console) commands to a file.  Helpful to
          correlate configuration changes to logged data.

    I had problems with data getting out of sequence because of problems with the DUT that GPIBCON was talking to and this would garble the data in the log file.  The clear buffer options help eliminate this but might not work in all situations.  The default display update frequency can now be changed from the default of one second.

    Logging now includes record numbers.  I found this handy when filtering records to size the gap since the time stamps aren't that reliable (depends on instrument response).  The Mark command also allows brief text after it that is written to the log so you have an idea of why you turned it on / off.

    Config commands can now be logged to a separate file so it's easy to correlate performance data to configuration changes.

    Last, v4 config files should work.  Enjoy!

  • Version 4.1 Posted

    Brian Cornell09/25/2019 at 18:33 0 comments

    I've been moving off of OS X to Ubuntu (18.04) and ran into problems when trying to compile v4.0.  Some of the string functions used are specific to *BSD systems so LIBBSD is required.  I added a compile pragma to test for Linux to set the correct include paths.  Make sure you have the headers installed (LIBBSD-DEV).

    I also ran into a problem with stream reads.  When reading a response from the GPIB device (Prologix USB adapter) an extra line feed exists.  Example:  <string><LF><LF>.  This didn't happen on BSD platforms.  So display fields would be blank or have the wrong data.

    Not sure what is doing this or if there's a setting to correct?  Ideas welcome.

    The workaround during a read is to ignore a null (LF only) string.  Using the above example the behavior is now:  read string to LF, process & return, leaving second LF in stream (unread).  On next read call the LF is consumed & ignored, and reading continues until a non-null string is read or timeout value is reached.  This seams to work well and shouldn't have any adverse consequences except in situations where a null (LF only) return is expected.  So far I haven't run into this with my gear.

  • Version 4 Posted

    Brian Cornell04/20/2019 at 22:37 0 comments

    Last version, I promise.  Bharbour was right, it gets quickly gets very complicated.  Nonetheless I needed the ability to talk to multiple instruments and at least two device channels for my test setups.

    This version adds both along with some bug fixes and optimizations.  Existing config files will need some updating to work properly but the same general syntax is used.  The zip contains a working example config.

  • Another Version Update

    Brian Cornell03/29/2019 at 16:34 0 comments

    The bane of writing your own software:  you're never done.  I keep finding more things I need to do with this.  Version 3 allows you to use constants in calculated fields.  Useful if you're reading data rendered in units of something - like a temperature sensor producing 10mV/C.

    Recording the data is essential and I don't know why I didn't include this in the original.  Anyway, it's there now.

  • New version with calculated field support.

    Brian Cornell03/25/2019 at 00:57 0 comments

    I've posted a new version that includes calculated fields using data acquired from the GPIB device.  It's very basic - add, subtract, multiply, and divide on two fields and no grouping.  The config file documents how it works in the display (dsp) section.

View all 6 project logs

Enjoy this project?

Share

Discussions

flanneltuba wrote 05/13/2022 at 00:03 point

Greetings Brian. Impressive looking code. I'm eager to give it a spin. Do you know if this might work with the Agilent 82357B USB-GPIB adapter? 

  Are you sure? yes | no

curiousmarc wrote 04/07/2020 at 19:46 point

Very nice project. Very well documented, clean code, clear variable and function naming. Not a hack at all!

  Are you sure? yes | no

Brian Cornell wrote 03/30/2019 at 18:41 point

Yeah, that's quickly becoming apparent.  I'm hoping that with this framework I can quickly modify the base for specific tasks as you suggest.  Thanks for the tip on LabView, I will definitely check it out.

  Are you sure? yes | no

Bharbour wrote 03/30/2019 at 14:02 point

There is a "Home" version of Labview available for about $50US if you are interested. It will not compile to a .exe file, but it can run stuff as long as you have the Labview program open.

That said, I have done a few command line GPIB tools. The most ambitious was designed to run several instruments like a power supply, function generator, DVM and an electronic load box. It was intended to allow script control for automated testing. It quickly got so cumbersome to use that I never finished it. Keeping a program small and limited to a single instrument, or a very specific task seems like the way to do this. 

Good Luck,

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates