Firmware V1.5.2608231522 is available on the Firmware Updates page. The headline of this release is VXI-11: GPIBEE was already working well with the common VISA implementations, but "works with the VISAs I tested" and "implements the standard" are not the same claim. This build makes the second one true.
What changed
- Link locking on connect. Creating a new VXI-11 link with no lock
requested, against a connection that already had a link, returned a lock error.
VXI-11 rule B.6.6 says an unlocked
create_linkignores an existing lock. Fixed. - A VXI-11 conformance test suite was written for this project. It currently covers 104 rules of the VXI-11 specification, and all of them now pass. It is not a complete reading of the standard — a number of its statements cannot be checked from a client on the network at all, and the suite keeps growing. Earlier firmware already worked well with the common VISA implementations; GPIBEE is now genuinely VXI-11 compliant, with correct error code reporting, rejection of parameters the standard does not allow, and support for multiple links and sessions. VISA implementations use a single link per session, but multiple links now work exactly as the standard intends.
- Instance names now require one of the prefixes
inst,gpiborhpib, followed by0— see section 8.2 of the manual. This is part of VXI-11 compliance. - The asynchronous VXI-11 channel is now fully functional: VXI-11 operations can be terminated before they complete by issuing an abort call. More on this below.
- The VXI-11.2 low-level bus commands (
device_docmd) are implemented: Send Command, Bus Status, ATN Control, REN Control, Bus Address and IFC Control. Pass Control is not supported. More on this below, and in section 8.2 of the manual. - Fragmented ONC/RPC records in VXI-11 are now handled correctly. TCP/IP fragmentation was, as in previous versions, unaffected.
- USB network mode: the network stack was not serviced while a longer command was executing — a read running into a timeout, for example. This caused no malfunction, but it was not a clean way to handle it.
The abort channel
GPIB transactions can take a long time to finish. A read from an instrument that never becomes a talker, or a write to a device that never releases its handshake, only ends when the configured timeout expires — which may be several seconds or more. VXI-11 defines a per-operation timeout for exactly this case, and GPIBEE has always honoured it: every operation returns on its own once the client's requested timeout has elapsed. Reliable timeout behaviour does not depend on the abort channel.
What the abort channel adds is a way out before that timeout. It is a second,
asynchronous TCP connection running in parallel to the normal core channel — and
it needs to be separate, because the core channel is blocked for as long as the
operation runs, so a client cannot use it to cancel its own call. Over the abort
channel the client sends device_abort naming the link whose operation
should stop. As of this release that path is fully implemented: the GPIB transaction is
stopped at the next possible point, the blocked call on the core channel returns
immediately with VXI-11 error 23, and the link stays usable — no session is
dropped, no reconnect is needed, and the instrument does not have to respond for any of
it to work.
Since the thread doing the transfer is blocked, the abort is normally issued from a second thread. Typical uses: a "Stop" button that actually stops, cutting short a read into an unresponsive instrument when a long timeout was configured deliberately, and shutting an application down cleanly without waiting out a pending operation.
Low-level bus access: doCommands
Beyond reading and writing device data, VXI-11 defines a generic operation called
device_docmd for interface-specific, low-level transactions. VXI-11.2
— the TCP/IP to IEEE 488.1 interface specification — standardises the set
of these for GPIB; they are usually called doCommands. They give direct access
to the bus itself: sending arbitrary command bytes with ATN asserted, reading the state
of the bus lines, and driving ATN, REN and IFC.
This release implements Send Command, Bus Status, ATN Control, REN Control, Bus Address and IFC Control. Pass Control is not supported and returns VXI-11 error 8; it is reserved for a future firmware version. The exact behaviour of each command, and of each Bus Status selector, is documented in section 8.2 of the manual.
What this makes possible is the kind of thing a normal read/write interface cannot express. For example, addressing two instruments as listeners and triggering both at the same instant with a single Group Execute Trigger:
0x3F UNL Unlisten - clear all current listeners
0x25 LAD 5 Address device at primary address 5 as listener
0x27 LAD 7 Address device at primary address 7 as listener
0x08 GET Group Execute Triggerdevice_docmd, and several open the abort
channel only on demand or not at all. If you are driving instruments through a VISA,
you can ignore both. They matter when you want deep control of the bus, and the
practical way to reach them is a raw VXI-11 client library that implements the
VXI-11.2 command set — python-vxi11, for instance — rather
than a VISA.
device_docmd to be offered only on a link that is
not associated with a device: they are accepted on inst0,
gpib0 or hpib0, and rejected on an instance name carrying a
GPIB address such as inst0,22.
Updating
The build is on the Firmware Updates page, together with its own manual and release notes and the update instructions. GPIBEE appears as a virtual flash drive during an update — copy the firmware file onto it, no tools required.
If your setup is a VISA talking to instruments, this release should be invisible to you in the best sense: nothing you were doing changes, and the parts that were not strictly correct now are. If you use VXI-11 directly, it is worth reading the change list above properly.