Interfacing multiple devices with non-standardized communication protocols is a never-ending struggle. In the mid eighties, the US Air Force tried to create a universal translator between the instruments they used, but abandonned the project when it started sucking up significant development costs. HP, seeing an opportunity and having already made a lot of money by licensing its GPIB cable standard, invested in standardizing a communication protocol known as SCPI.
Though SCPI (often pronounced "skippy") enabled a lot of instrument functionality to be accessed with educated guesses, it did not guarantee that manufacturers were perfectly compliant with SCPI commands, and as more and more devices switch to USB interfaces, fewer and fewer devices allow string-based communication, instead relying on manufacturer drivers. This means that, until we're all living in our robot-controlled virtual reality future, looking up manufacturer's manuals and driver APIs will be a frequent chore.
While we've developed configuration forms for most common settings, such as triggering settings, offsets, and sampling modes, GradientOne recognizes that our default data capture configuration options will not be sufficient for all users, and so have developed an "Editor" where you can write simple scripts. To access it, click on the "Settings" drop-down next to the config or run button, and select "Editor".
When designing our command language, we tried to pull out the features we liked from previous languages. SCPI has an elegance to it in that it recognizes that the two most common operations done on instruments are retrieving values from the device - using the question mark (?) and configuring settings (no question mark). However, like Python, we want our language to be human readable. Thus, the three most common commands used in our command language are likely to be QUERY, SET, and WRITE, written as:
SET is used to put the instrument into specific states, such as switching between enabled and disabled, while WRITE is used to configure settings. Certain commands are instrument-specific. These commands are expressed in all-caps words, and are colored pink in the syntax highlighting.
Settings and states can be referenced by their addresses or abbreviations in the instrument manuals or APIs. Since we had to read the documentation in order to generate the data capture form, we can save you time by making human-readable versions of every state and setting.
Values can be expressed as lists or single items of integers or hex bytes. For example, 1000, [3, 255], 0x3e8 and 0x03 0xE8 are all valid ways of expressing values. Correctly parsed values are coloured purple in the syntax highlighting.
We have also provided a few expressions to chain and repeat commands: while, for, and if. These expressions follow the syntax of Python. For example:
Finally, each instrument has its own specific functionality. For example, in CANOpen devices that support trace tools, such as those developed by Copley, entering "WAIT FOR TRACE" will halt CANbus execution until the trace tool has acquired data; "DOWNLOAD" will acquire the trace data. On Tektronix devices, calling "DOWNLOAD", or "GET WAVEFORM" will transfer the current waveform to the current test run.
To see all available command types available to your current instrument, click on the "Show Cheat Sheet" link on the editor. You can also get hints as to valid completions of any line in the editor by moving your cursor to the end of the line and pressing ctrl+space.