There's a decent OSS USB-GPIB controller AR488 by Twilight Logic. However currently there's no OSS available to acomplish some basic automated data acquisition through GPIB. That's why I opted to write my own 'General purpose GPIB data collection server'. It's much more limited than, for example, EZGPIB, however it's open-source and (should be) cross-platform thanks to .NET Core 3.1 and SerialPortStream IO library. It also doesn't have the annoying quirks of EZGPIB that made it unusable for me, namely: unavoidable "probing" of all serial ports during startup that not only disturbes some of my hardware that can't be disturbed, but also fails to detect AR488 due to Arduino's DTR reset behavior. The last one could be fixed by either modification of the Arduino (that results in inability to hardware reset the device and complicates it's reflashing process) or editing EZGPIB executable, but all of this makes learning how to use EZGPIB unfeasible altogether.
- Simple command script execution;
- Parallel execution of multiple scripts (note to self: only useful when multiple controllers are present, otherwise a deadlock is pretty much guaranteed);
- Multiple controller (with multiple addressable instruments) support;
- Configurable data output (as formatted text files and/or through a named pipe);
- JSON-serialized controller and instrument databases;
- Simple controller/instrument simulator project available to assist debugging.
- No branching or jumps in the script are supported (intentional choiсe to keep things simple, conditional branch and jump implementation would require a complete rewrite of script execution logic and probably a storage format reevaluation);
- Currently, all controllers are expected to be identified as serial ports (though this is not that hard to generalize, I just don't happen to have any non-serial-port controllers to work with);
- This project is a work in progress. No extensive testing was done under any OS but Windows, though all the dependencies are cross-platform.
- Run the application with option "-g". This will generate example configuration files (inside the working directory) from which you can infer their structure.
- Edit the configuration files to match your setup and task. You can verify that a correct sequence of commands is produced with the instrument(s) OFF and all script commands (temporarily) set to "AwaitResponse = false". The commands sent will be visible in the console.
- You can perform a more extensive behavior validation using InstrumentSimulator project. It contains an almost barebones implementation of a JSON-serialized GPIB controller/instrument simulator that can be customized to fit your particular needs. Out-of-the-box it offers only a simple string reply dictionary and address matching.
- Try it with a real connected instrument.