group/presentation title agilent restricted month ##, 200x atml instrument description feedback lynn...

Group/Presentation TitleAgilent Restricted Month ##, 200X

ATML Instrument Description Feedback

Lynn Wheelwright’s analysis


Background

Agilent hired an outside consultant (Lynn Wheelwright) to evaluate the impact of ATML on Agilent

• Concern that creation of Instrument Description files may be expensive

• Need to evaluate where Instrument Description files should be created within Agilent’s new product development processes

Lynn was asked to create an Instrument Description file for Agilent’s new spectrum analyzer (MXA)

• Not every spec necessarily included – just one of each type

Lynn came up with some good feedback for ATML. The following slides contain Lynn’s comments (with no editing).

• Anything that Lynn didn’t understand correctly is probably a shortcoming in the documentation


Lynn’s Overall Conclusions

• Many problems found. Documentation is incomplete. ATML is not ready for prime time.

• Agilent should not agree to supplying ATML Instrument Description files until there is a software application that makes it easier to create them

– Agilent should not write this application. The ATML group should be encouraged to find a way to create a standard application for industry-wide use.

• Agilent should never agree to supply Capabilities descriptions

– Estimate 3-5 person-years of work to complete Capabilities description for a spectrum analyzer


Driver Filename

o Driver Filename is not necessarily known to the manufacturer (the system integrator controls this). Also, for complex instruments with measurement personalities (like PSA, MXA, …) there are several files required, not just one for a given driver—the standard does not allow for this.

o Recommendation: put the IVI Driver Identification string in for the file name because it is used as the prefix for all the most important driver files.

o Resolution: Explain the intent of this entry in the documentation


Driver Type definitions

o Need the derived definitions for Driver/Type and control language. According to the comments the control language types are SCPI and Register, but I haven’t found where they are listed—there are other types of control languages beside these two.

o Resolution: Documentation to describe how to use abstract/derived types in XML.


Manuals

o URI’s for manuals (programmers reference, hardware service, calibration procedures, etc.) are required. This implies that they can be accessed from a non changing web location. Past experience has proven that Agilent cannot provide this—Agilent is unable to maintain fixed web locations for these items. There is also the minor problem that Agilent sells the service and calibration manuals, so they are not directly available on the web. It is possible to place text in the ATML file, but an entire manual seems to be prohibitive in light of the requirement to keep the ATML file small.

o Resolution: Location doesn’t have to be on the Web. Expand documentation to describe the possible use cases.


Operation Requirements

o There is no explanation detailing what is needed for the ‘operationalrequirements’ or how they are expected to be used. If you need to specify warm-up time, then this field is also required.

o Resolution: Finish the docs


Power

o ATML wants current draw for power, Agilent specifies Watts. I’m approximating the current draw from the power using low line voltage.

o Resolution: Will add power as a choice.


Configuration Options

How to link anything in a ConfigurationOption to another file. I assumed that these options were items that were sent to the hardware driver at driver initialization time. The use of ConfigurationOptions is less then clear.

Resolution: Finish the documentation.


Specifications

There are many specifications that specify a value with a tolerance, i.e. 3V +- .001V. If one thinks about the spec as the tolerance band then a Single Limit could be used (see Frequency Reference Error), but if one thinks about this as an upper and lower value then a Limit Pair has to be used. It would be clearer and easier to understand (and translate from data sheets) if there were a spec type with a value and a tolerance band. For want of a better name, call it a TolerancePair that has two children: the nominal value and the magnitude of the tolerance limit.

Resolution: TolerancePair doesn’t turn out to be sufficient. No change.


Specs versus multiple options

I don’t see how to write a Specification that applies if any of multiple options are present. The example is Input Attenuator Switching Uncertainty. One piece of this specification applies to all for frequency range options, the next to only three, the next to two, and the last to only one.

Resolution: Add an example to the documentation


Mandatory Options

It is not clear how to write a spec that requires the choice of one of several mutual exclusive options. The example is MXA which has four frequency ranges. You must choose an option to select the frequency range.

Resolution: Don’t think this is necessary to cover in ATML.


Using Signals

There does not appear to be a way of specifying a ‘Signal’ as part of a capability. The documentation supplied does not work. Xmlspy rejects all children of <hw:Description>. This appears to be a schema error.

• From Teresa Lopes:, you have to use the extension mechanism.

• I think that if Signals are as important to ATML as indicated in the documentation, then one should not have to resort to the extension mechanism to use them—this is error prone (no validation) and awkward.

Resolution: Teresa will figure out a way to do this better.


Name space problem

The target name spaces for STDBSC and STDTSFLib are not correctly qualified (according to xmlspy). They are missing the prefix http://www.ieee.org/ATML/2007/02/. This needs to be fixed before these two files are released.

Resolution: 1641 issue number 50 (resolved).

http://www.ieee.org/ATML/2007/02/


Capabilities versus instrument options

There does not appear to be any legitimate way to segregate or select capabilities based on instrument options. There is a theoretical loop hole in the 1641 syntax where ranges are expressed as numeric expressions. If one of the expression elements tests for the presence of an option then ternary expressions can be used. I have used this in some of the signals I created. Logically, this makes sense, but it may crash the ATML interpreters.

Resolution: Use separate option description files to handle this. Will add example to the documentation.


Abstract <Driver> problem

The element <hw:Driver> is annotated as an abstract type with derived types for IVI-COM (among others). In fact, <hw:Driver> is NOT an abstract type. Therefore, the derived types cannot be successfully used (xmlspy throws validation errors). Since I could not use the <IVI-COM> element, the driver specification is incomplete.

Resolution: Typographical error in the schema will be fixed.


<Map> by any other name

The Capabilities documentation does not match the schema. In particular <hw:map> does not have a ‘name’ attribute.

Resolution: Capabilities document is behind the schema and needs to be changed.


Multi-Port Names

The Capabilities documentation shows an example with multiple In ports (the 2 channel oscilloscope). In examining the attribute In, it appears to only allow 1 name (because the ID type must match the ‘name’ production from xml, which would mean only one input is allowed to the <Signal> element. IDREFS might be a more appropriate type if you need this behavior. Xmlspy didn’t flag this as an error, but someone’s parser probably will.

Resolution: Known issue in IEEE 1641. (Issue 32A)


<Signal> documentation

The documentation of the <Signal> attributes (as well as many others) is sadly missing. I find no description of what they are supposed to be used for, nor on the interaction between these attributes and the attributes of other elements (<Ports> comes to mind, as do <Triggers>). This is definitely not ready for alpha testing.

Resolution: Hugh will ask some of his people to clarify their troubles in understanding this mapping.


Triggers

ATML (or the writers) do not understand trigger multiplexers and / or trigger state machines. All actions and signals are always triggered by something, even if it is an immediate trigger (also one of the selections in the trigger multiplexer) because they are state machine driven and have to have an input from somewhere in order move to the next state. It appears that if I have 8 different trigger inputs that can be routed to any measurement function, then I have to have a separate capability or signal to cover each of these different triggers. I might point out that a Class A, or Class B LXI device has thousands of possible triggers (thanks to the LAN trigger capability).

Resolution: Use a switch to route the triggers


Parallel Measurements / Multiple Traces

I do not find a practical way to have several parallel measurements on the same input that can route their results to any of several outputs (traces 1 .. 6). Multiply this by 10 measurement suites and you have a huge problem.

Resolution: Use switches to route the signals. Add an example to the documentation.


More Trigger Stuff

• Why are there two (or more) separate places to define the trigger ports? <hw:Interface>, Resource/Triggers/Trigger/TriggerPorts/TriggerPort But there is only one place to specify the physical connector. – Resolution: For the same reason that we have connectors & resources

• IEEE 1671 says next to nothing about triggers. Nor does it say much about the significance of their attributes. It really only talks about VXI Triggers (ECL and TTL) and how many of them are present. – Resolution: The entire annex is being rewritten. Triggers are being added.

• IEEE 1641 is likewise very sparse in its descriptions about trigger usage. It relies on the fact that signals are somehow triggered, but doesn’t go into much detail other than splitting triggers into gating and sync functionality.– Resolution: 1641 Users Guide has far more documentation

• To understand 1641 correctly you also need to be an expert in the programming language Haskell, specifically the derived version used in 1641 (for which I couldn’t find documentation).– Resolution: Not necessary if you have a good toolset. Only needed if you want to

create something new from the ground up. Nothing we can do about it.


Multiplexer switching element

o ATML needs a multiplexer switching element—and N to 1 switch to deal with triggers. It wouldn’t hurt to have it for other things also.

o Resolution: Would appear that we’re covered. Can build a switch that has this functionality.

group/presentation title agilent restricted month ##, 200x atml instrument description feedback lynn...

Documents

impact of atml

atml group

atml file small

control language types

important driver files

standard application

types of control languages

changing web location