Bug 1276 - A single front-line SCPI probe routine would be a good idea
Summary: A single front-line SCPI probe routine would be a good idea
Status: CONFIRMED
Alias: None
Product: libsigrok
Classification: Unclassified
Component: Common: SCPI handling code (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-07 17:20 CEST by Martin Ling
Modified: 2018-09-07 17:20 CEST (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Ling 2018-09-07 17:20:30 CEST
We need to be careful about the initial probe to an unidentified SCPI device.

Right now, if a USBTMC or other auto-detectable SCPI interface is connected and a general scan is run (as on PV startup or sigrok-cli --scan), all SCPI drivers will probe all SCPI devices. This has resulted in bugs #1272, #1273 and #1274 at least, all of which involve some individual driver doing an initial query which is not safe for some other SCPI device.

The problem of how to probe an as-yet unidentified SCPI device safely is tricky enough without scattering the logic to do so across all drivers such that any of them can unknowingly break things.

We also have the issue that currently every SCPI driver probes every SCPI device on a general scan. This is messy and inefficient, especially when multiplied across several devices connected at once and a growing number of drivers.

I propose that a better solution would be a single function that scans an SCPI device and tries to receive an ID? or *IDN? response, handling all the various quirks and things that could go wrong in that process. This puts all the tricky business in one "here be dragons" bit of code which would be known to need careful testing after any change. Things this code could address include:

- Using identity clues from transport type, USBTMC VID/PIDs, etc.
- Whether to send *IDN? or ID? (#1273)
- Local echo detection (see #1272)
- Firmware quirks that affect the SCPI transport level (e.g. #354, #617)
- Appropriate choice of timeouts
- Use of 'END ALWAYS' for old HP kit? (#1274)

Rather than each driver probing every device, this function could then be used to probe all SCPI interfaces and gather a list of ID responses which drivers could claim.

It is likely that this master probe routine would not be able to detect all possible hardware without sacrificing safety; it would need to be a "best safe effort" routine. As per now, users would need to specify a driver or connection explicitly for any device/transport combination that cannot be automatically probed.