Should the instrument suffix be included in the Driver Identifier?

[joseph-mueller]

We have a historical, informal, agreement within IVI that the Driver Identifier should omit the instrument suffix. We have agreed that we would like to formalize this agreement in the new ANSI-C and Python specifications.

However, there is some question exactly what we do with this, and perhaps what it means. The problem is:

• in some cases, things like "B" versions of instruments may be entirely independent of previous versions -- with different capabilities and different programming languages. I guess we could conclude that in such cases the "B" is not a suffix?
• in many cases the instrument model (or perhaps just the driver name) uses an alphabetic name ("Infiniium" or "X-series"), and the meaning of a suffix is unclear.

I suspect the original authors of the 'informal agreement' were under the impression that:

• a model name is always a number and only a number
• it has an easily distinguishable trailing letter that indicates minor updates or capabilities that do not impact the software model of the device

I don't think the IVI specs can safely assume either of these. For instance, some Keysight have letters that indicate major groups of models within a trade-name ("V-series" or "EXR series"). I don't know details. NI DAQ has designations like (cRIO-904X Sync). Where is the suffix in that?

I don't want to represent that, in fact, all of these have distinct drivers, but IVI must not assume that none of them do. It is also presumptuous for IVI to dictate how a vendor would want to name a driver to support these groupings of instruments (I believe there are words in the spec to give pretty broad permission to driver authors).

I guess we could refine the agreement to be that "suffix" means "trailing letters that indicate models that will not have differing software models" -- probably the original intent. But that will still leave us with ugly compositions.

Conclusion: I don't see any practical approach for IVI to legitimately limit how a driver vendor may choose alpha-numeric designations for their drivers (beyond requiring a leading alpha).

If this means we need to re-introduce an optional separator between the model/family and the driver vendor, that is OK. We should definitely plan on pure alpha instrument model/family names.

[joseph-mueller]

In addition to the question about specifying the instrument version in the instrument model field, there is also the need for the driver vendor to also incorporate characters to differentiate two different actively supported drivers. Of course in Python, the names can be imported using 'import as...', but it seems to me we may want to have the ability to identify differing packages.

The draft ANSI-C specification specifies the "model" part of the instrument identifier as:

The following characters shall identify the instrument models supported, and any other driver identifying information the driver vendor chooses. If a vendor expects multiple versions of a driver to be used in a single application, the vendor must differentiate the identifiers by incorporating the driver version into the vendor-provided string. These additional characters shall not include underscores ('_') due to the use of underscore to separate the '<DriverIdentifier>' from other identifiers.

The current version of the Python spec has:

The second token is the Instrument Model. This token indicates the instrument model, or the family of instruments supported by this driver. It shall not include the underscore ('_') character.

The ANSI-C spec observes and resolves the need for a single driver vendor to have two drivers in the field that are both actively supported and the vendor does not want the names to conflict.

[joseph-mueller]

Finally, I suspect the genesis of the rule regarding eliding the instrument version, was that the authors wanted to ensure that the characters that identified the instrument model (or family, or other group) would be syntactically distinct from the <optional> driver vendor. I am guessing that they incorrectly assumed that the instrument model would always end in trailing digits, so that any trailing alphabetics would be the driver vendor.

In the current world, I think there are probably several drivers that support families and instruments that are identified with alphabetics (for instrument "Infiniium"). So for the DriverIdentifier of KTInfiniium we can't tell if it is:

• A driver from KT for the family Infiniium
• A driver from "um" for the Keysight Technologies instrument family "Infiniium" (unless we use case)

If this is the problem we are trying to solve, we could:

rule	example for KTInfiniium
1. Add an optional separator back in (between model and driver vendor). Driver vendors can insert it where an ambiguity may crop up.	Example becomes: KTInfiniium_NI OR KTInfiniium_NationalInstr
2. Use the case - require the driver vendor be upper case	KTInfiniiumNI OR KTInifiiumNATIONALINSTR
	for the special Cable TV version: KTInfiniiumCATVNI or KTInfiniiumCATVNationalInstr
3. Ignore the problem -- figure the ambiguities are rare

I think the first choice is probably best. The optional underscore is unfortunate, but probably the right compromise.

[bkeryan]

Finally, I suspect the genesis of the rule regarding eliding the instrument version, was that the authors wanted to ensure that the characters that identified the instrument model (or family, or other group) would be syntactically distinct from the driver vendor.

I looked through the Instrument Driver Network, and under the historical naming scheme, the instrument model/family/group is usually syntactically distinct, but not always. Some NI drivers for HP/Agilent/Keysight instruments end in "xni", "kni" or "dni", but this is relatively rare. If the letter suffix was not dropped, I think most NI drivers for HP/Agilent/Keysight instruments would appear to have an "ani" suffix.

Example 1: ag5313xni
Supported models: 53131A, 53132A
The 'x' means this digit varies.

Example 2: agn6k7kni
Supported models: N6950A, N6951A, N6952A, N6953A, N6954A, N6970A, N6971A, N6972A, N6973A, N6974A, N6976A, N6977A, N7950A, N7951A, N7952A, N7953A, N7954A, N7970A, N7971A, N7972A, N7973A, N7974A, N7976A, N7977A
The 'k' means 1000: this driver supports N6000 and N7000 series. (This is not entirely precise: it supports the N6900 and N7900 series and there is a separate agn6700 driver for the N6700 series.)

Example 3: agn453xni and agn453xdni
Supported models: L4532A, L4534A.
The 'x' means this digit varies.
The 'd' means "digitizer": agn453xni supports IviScope and agn453xdni supports IviDigitizer.

[bkeryan]

The second token is the Instrument Model. This token indicates the instrument model, or the family of instruments supported by this driver. It shall not include the underscore ('_') character.

I assume this gives the driver vendor enough freedom to replace a digit or two with 'x', or to replace the last 3 digits with 'k'.

Does this give the driver vendor enough freedom to drop a letter suffix that is repeated across multiple models, such as the 'A' in N6950A, N6951A, N6952A, N6953A, N6954A, N6970A, N6971A, N6972A, N6973A, N6974A, N6976A, N6977A, N7950A, N7951A, N7952A, N7953A, N7954A, N7970A, N7971A, N7972A, N7973A, N7974A, N7976A, N7977A?

[Miloslav-RS]

PR134 #134