The SCPI (Standards Command for Programmable Instruments) protocol is exceptionally popular in lab and workspace tools, letting you configure and fetch data from oscilloscopes and lab scales alike in a standardized way. However, when interfacing with a SCPI device, you need to use a programming guide document if you want to know the commands for any of the inevitably extended features; essentially, SCPI isn’t as human-friendly as you might want. [MisterHW] argues that SCPI could use more discoverability by proposing a HELP? command.
This proposal is so intuitive, it makes you wonder why it isn’t in the base spec. It adds a built-in command that provides information on other commands. Internally, the description is just an extra string parameter that you add to your command definition code, and you can use it to describe the parameter types and ranges it takes. The output is both human-readable and machine-parseable, and as it’s stored within your code, it’s way quicker to update the description string than it is to re-release programming guides. Which are themselves prone to being outdated as-is, so decreasing reliance on them is a win-win.
The proposal makes a lot of sense, and [MisterHW] is willing to back it up with a pull request to the most popular SCPI library, libscpi. Whenever the pull request finally goes through, you will have the option to easily add the HELP? command support to whatever SCPI-connected device you might have brewing.
While the old devices will eventually fade, SCPI is not about to die out – hackers keep building devices with SCPI as the communication protocol, as the spec is quite powerful. For instance, here’s this fancy temperature logger, or this Source Measurement Unit – both of them use SCPI for hacker-to-device data transfer, and it’s likely to be libscpi under the hood. Ever wondered what SCPI is all about? Check out our overview!
“SCPI is not about to die out – hackers keep building devices with SCPI as..”
Huh? Where on earth did this come from? Was there any implication that SCPI is about to die off? In what way is the hacker community keeping it alive, other than many of the engineers for little known concerns like Keysight, Fluke, Keithley, Rigol, etc. may be hackers.
agreed. And if you want it to be better, add local echo as a requirement. I hate SCPI with a burning passion. I *WISH* it would die off. The syntax is horrible, and without local echo, I hit enter alot rather than try to fix mistakes. Generally, I use a text editor, type what I want, correct it, and then paste into the device.
I mean, seriously *idn? Really? So we’re going to be verbose with “how many field seperators can we fit”, but we’re going to shorten the identity command, require a special character up front, and end with a question mark? If I never have to touch SCPI again, it will be too soon. I can’t imagine why anyone thinks this garbage is any good at all.
If you want local echo then set your Telnet client to do it. I would, however, expect an instrument or library to handle backspace/delete properly in all cases.
“makes you wonder why it isn’t in the base spec” no, not really; SCPI is an _old_ standard, a help command would have been considered a resource waste on some of those old machines; protocol documentation can be put in the manual! They put considerable effort into manuals back then…
+1
Additionally, the core design intent isn’t interactivity with a human, but for automation. The host software doesn’t need a help command (noting that I deal with a lot of instruments via the RS232/HPIG/net socket even when I can touch the front panel, as I can type the SCPI message faster than I can find the right menu selection in many cases, and I would appreciate a help service on a couple of them at times)
Yup. SCPI started out as derived from IEEE 488 commands, which originally started out as HP-IB back in the late *60s*. Even the base SCPI standard was only first released in the 1990.
And it’s not just “resource waste” – a help command would’ve been extremely *hard* on some systems back then because the output buffer would’ve had to have been *gigantic*.
Also: why in the world would you suggest “HELP?” Just look at the other commands. There’s a structure. If you’re going to propose anything, it would be “*HLP?” to match the three-letter pattern used for the required commands.
I see another point, It doesn’t make to much sense. Some SCPI commands are standardized over all device (the one listed above), however a lot more commands are normally available to control complex Devices. To get al this information in a terminal would not be very useful.
Thanks for that. I spent a bit of time on my own implementation over Xmas and was already potentially translating ‘help’ and a blank string to SYSTem:HELP:HEADers?
My focus in doing this was not so much having something which could be embedded in an instrument, as having something which could be added- with minimum fuss- to an axisting program which was supporting e.g. a multimeter which had a thoroughly non-standard control protocol. As such, it works by registering commands together with a handler when the command is recognised.
Having done that, it was easy to add SYSTem:HELP:SYNTax? which can be used to query a registered command’s parameter expectations.
https://github.com/MarkMLl/scpisrv