GroupPresentation Title

1
ATML Instrument Description Feedback

• Lynn Wheelwrights analysis

2
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 Agilents new
  product development processes
• Lynn was asked to create an Instrument
  Description file for Agilents 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 Lynns comments
  (with no editing).
• Anything that Lynn didnt understand correctly is
  probably a shortcoming in the documentation

3
Lynns 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

4
Driver Filename

• 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 driverthe standard does not allow
  for this.
• 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.

5
Driver Type definitions

• Need the derived definitions for Driver/Type and
  control language. According to the comments the
  control language types are SCPI and Register, but
  I havent found where they are listedthere are
  other types of control languages beside these
  two.

6
Manuals

• URIs 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
  thisAgilent 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.

7
Operation Requirements

• 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.

8
Power

• ATML wants current draw for power, Agilent
  specifies Watts. Im approximating the current
  draw from the power using low line voltage.

9
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.

10
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.

11
Specs versus multiple options

• I dont 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.

12
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.

13
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 lthwDescriptiongt. 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 themthis is error prone (no
  validation) and awkward.

14
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.

15
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.

16
Abstract ltDrivergt problem

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

17
ltMapgt by any other name

• The Capabilities documentation does not match the
  schema. In particular lthwmapgt does not have a
  name attribute.

18
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
  ltSignalgt element. IDREFS might be a more
  appropriate type if you need this behavior.
  Xmlspy didnt flag this as an error, but
  someones parser probably will.

19
ltSignalgt documentation

• The documentation of the ltSignalgt 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
  (ltPortsgt comes to mind, as do ltTriggersgt). This
  is definitely not ready for alpha testing.

20
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).

21
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.

22
More Trigger Stuff

• Why are there two (or more) separate places to
  define the trigger ports? lthwInterfacegt,
  Resource/Triggers/Trigger/TriggerPorts/TriggerPort
  But there is only one place to specify the
  physical connector.
• 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.
• IEEE 1641 is likewise very sparse in its
  descriptions about trigger usage. It relies on
  the fact that signals are somehow triggered, but
  doesnt go into much detail other than splitting
  triggers into gating and sync functionality.
• 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 couldnt find documentation).

23
Multiplexer switching element

• ATML needs a multiplexer switching elementand N
  to 1 switch to deal with triggers. It wouldnt
  hurt to have it for other things also.