Match SCPI short and long form when resolving a reading's unit - #132
Merged
Merged
Conversation
Found on live hardware, not in a test. Querying an E4438C for :FREQ? came back with the value parsed but NO unit, and the same for :POW? - which is the entire point of the structured-output work (#113) missing on the instruments most likely to use it. The database documents SCPI in the specifications own notation - ":FREQuency?", where the capitals are the short form - while the wire carries ":FREQ?". The lookup compared those literally, so it only ever matched instruments whose documented query IS the wire string, i.e. the legacy HP boxes with "CF?". Every SCPI instrument in the catalogue silently returned no unit, and "no unit" is indistinguishable from "not audited". A documented form now expands to the strings that mean it - short and long spellings, with optional [:SOURce] style nodes present and absent - and the wire command has to equal one of them. Still exact after expansion: a fuzzy match would attach a confident unit to the wrong reading. Verified against the bench: E4438C :FREQ? -> 3000000000 Hz, :POW? -> -136 dBm. An E4406A :FREQ:CENT? still returns no unit, and correctly: that model has 28 documented commands and centre frequency is not among them. A database gap, not a matching failure, and saying nothing beats guessing - it is also exactly what the manual library (#120) is for, and manual_search finds it in the E4406A Programmers Guide, page 89. 8 tests.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found on live hardware, not in a test — the first thing the bench found after the instruments came up.
Querying an E4438C for
:FREQ?returned the value parsed but no unit, and the same for:POW?. That is the entire point of #113 missing on exactly the instruments most likely to use it.Cause
The database documents SCPI in the specification's own notation —
":FREQuency?", where the capitals are the short form and the lower-case tail is optional — while the wire carries":FREQ?". The lookup compared those literally, so it only ever matched instruments whose documented query is the wire string: the legacy HP boxes with"CF?". Every SCPI instrument in the catalogue silently returned no unit, and "no unit" is indistinguishable from "not audited" — so it looked like a data gap rather than a bug.Fix
A documented form now expands to the strings that mean it — short and long spellings, with optional
[:SOURce]-style nodes present and absent — and the wire command must equal one of them. Still exact after expansion: a fuzzy match would attach a confident unit to the wrong reading, and the reading is a measurement someone may act on.Verified on the bench
E4438C :FREQ?→value 3000000000,unit "Hz"E4438C :POW?→value -136,unit "dBm"E4406A :FREQ:CENT?→ value parsed, still no unit — correctly. That model has 28 documented commands and centre frequency is not among them: a database gap, not a matching failure, and saying nothing beats guessing. It is also precisely what the manual library is for —manual_searchfinds it inE4406A Programmers Guide.pdf, page 89.Tests
8 new, over a SCPI fixture shaped the way the database really stores one: short form, long form, case-insensitivity, optional nodes spelled out, a neighbouring command that must not match, and an over-abbreviation that must not match either.
Full suite green: 453 GpibMcp + 113 Hpgl, 0 failures (Release|x86) — was 445 + 113.