When I was learning about industry standards for electronics test and measurement equipment automation, I quickly came across GPIB which has its roots in something Hewlett-Packard developed for their equipment. It made sense, then, that they would have a software suite to run on a PC and talk to these instruments via GPIB. This turned out to be something called VEE, but it is no longer a HP product. It has had multiple custodians. From HP it moved to Agilent, and now it is in the hands of Keysight Technologies.
So it was no surprise the focus would be on professional equipment with GPIB or the closely related USB-based successor USBTMC. There is also built-in support for a few other instrument standards, all packaged together in the IO Libraries Suite of a full VEE installation. However, I had a hard time finding any mention of how to communicate with custom-built equipment outside of supported protocols. It certainly wasn’t covered in their Quick Start Guide (PDF), so I moved on to Advanced Techniques (PDF).
I thought perhaps I would have to create what they call a “panel driver” for installation into VEE in order to support custom equipment, but a search for “How to write a VEE Panel Driver” failed to retrieve useful links. How do instrument manufacturers create and release VEE Panel Driver for their equipment? So far that is still a mystery.
In the absence of a custom panel driver, the next option is to specify a custom communication protocol directly in VEE, and such a thing can be built from their Transaction I/O mechanism. Suitable at least for query/response types of interaction. The exact commands being sent out and expected to be received are crafted step by step using VEE GUI. This seems very labor intensive but has the advantage of avoiding annoying and common byte processing bugs typical when such serial byte stream processing are written in C.
It’s not obvious from reading the document what happens if the VEE transaction specification is wrong and incoming serial data doesn’t match. This is not encouraging, neither were there any mechanisms to help support development of transaction I/O. There’s just trial and error. Seriously. This is a direct quote from the manual:
Many times the best way to develop the transactions you need is by using trial and error
(Chapter 4: Using Transaction I/O / Creating and Reading Transactions / Editing the Data Field / Suggestions for Developing Transactions)
I didn’t find any mention of how to deal with continuous data stream from devices that do not perform transaction-based communication. For example a thermometer that continuously reports temperature without prompting, or the Neato LIDAR. VEE does have a data polling feature, but that seems to be restricted to devices on specific subset of supported protocols and not arbitrary serial communication.
From this brief survey, it appears VEE support for arbitrary USB serial communication is quite limited. The next step is to look at how VEE support displaying arbitrary data.