-
Version 5.1 Posted
03/06/2021 at 23:41 • 0 commentsI 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
10/28/2019 at 21:25 • 0 commentsI 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
09/25/2019 at 18:33 • 0 commentsI'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
04/20/2019 at 22:37 • 0 commentsLast 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
03/29/2019 at 16:34 • 0 commentsThe 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.
03/25/2019 at 00:57 • 0 commentsI'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.