1.ATML Instrument Description
1.1General Meeting Info:
Date of Meeting:January 17, 2007
Location:LMC – Orlando, FL
Chairperson:Teresa P. Lopes
Minutes Prepared By:Teresa P. Lopes
1.2Meeting Attendees:
Name / EmailTeresa Lopes /
Tamara Einspanjer /
Dennis Beaugrand /
Steve O’Donnell / Steven.J.O’
Jacob Perry /
Jose M. Gonzalez /
Stephen Osella /
Ion Neag /
Scott Misha /
Ron Taylor /
Joe Stanco /
Tim Tavis /
Scott Kearney /
Matt Cornish /
Anthony Estrada /
Hugh Pritchett /
Dan Pleasant /
1.3Topics to Be Discussed:
1.3.1Review Action Items
1.3.2Walk-through 1671.2 Standard Specification
1.3.3Discuss SIWG & ATML Instrument Description
1.4Record of Discussions:
1.4.1Review Action Items
Issues / comments are in italics
Action items are highlighted in blue
Responses to comments/issues are highlighted in gray
20.a Instrument Description Example – Options
Not complete – no resource identified to work on examples. Need all examples by April 1st in order to include them in the standard.
20.b Instrument Description Example – Capabilities
Complete – need to determine whether issues are to be addressed in Instrument Description or 1641.
[Dan]Update capabilities document to use correct node path syntax
[Teresa]Update documentation to describe where in the capability description the 1641 XML snippet goes.
[Chris]Determine whether issues with describing capabilities need to be addressed in the Capabilities document/schema or in 1641
20.c Instrument Description Example – Triggering
Complete – assign action items to address issues
What is the "qualifier" attribute for /Identification/IdentificationNumbers/IdentificationNumber?
[Teresa]Make sure that schema documentation describes the use of the qualifier attribute.
On connector pins, how do we distinguish between "AND" and "OR" relationships when multiple pins are listed?
a. Use ConnPinSets -> ConnPins -> ConnPin
b. all multiple "ConnPins", that is a sequense of "ConnectorPins"
i. The ConnectorPin items under each ConnectPins element are "ANDed" with each other
ii. Each ConnectorPins item is "ORed" with the other ConnectorPins elements
[Steve]Follow up with Nick on this issue
Assuming that "port" is how the outside world interacts with the instrument.
if this is the case, why is "connector" optional?
Shouldn't we have to define where to connect to the listed port?
If there is no physical connection, is it really a port?
There are examples of ports that don’t map to connectors, for example, software and optical
Is the software port type necessary? Do we need to state this when this is how drivers will always interact with the device? I think this came out of the trigger discussion and the desire/need to link up a software imitated trigger to a "physical port" on the device.
[Teresa]Document an example of where a software port would be used
I don't understand the "Constraints" section under Identification, may be my lack of understanding XML
The constraints section is used to identify the attributes and elements used when establishing key/keyref relationships
Assume the "type" for connector is BNC, SMB, etc.
should this be an enumerated list? - may be too many options to quantify
since there is a "mating connector" option, do we need the detail of BNC-F, BNC-M?
Yes, it’s free from
I don't see why "Identification" has to be required under Connector. For the simple case, do really need to ID the connector beyond that it is an SMB named CH 0 on the front of the device? In addition, none of the attributes or sub-items are required, so I can just have an empty element - doesn't seem good.
“Identification” is required because Connector inherits from ItemDescription
I think there should be a "name" attribute for Driver, in addition to Version
[Teresa]Add optional name attribute to Driver element
Driver needs to be of type hw:VersionIdentifier, as is used under Tool -> Dependencies -> Driver
Not really. The driver specified under control is supposed to identify individual versions of the driver. VersionIdentifier is used to identify a range of driver versions.
What is "prefix" for IVI-C type driver:
<hw:Type xsi:type="hw:IVI-C" fileName="nidmm_32.dll" filePath="%IVIROOTDIR%\bin" prefix="TODO:WHATGOESHERE?"/>
The prefix is used to document the function prefix used by the driver. In the example above, use “nidmm” for the driver prefix.
Could use an optional "Qualifier" attribute for Tools->tool, since we list version. I think if Version is an attribute, as we are referencing SW, need to have min/max qualifier, at least optional.
This structure is meant to identify a specific version of a tool that is included with the driver. It describes a single version. If multiple version exist, then multiple entries should be specified.
At this time, a factory calibration procedure is not available (as with some other scopes) so I linked/showed the help document that has the software calibration procedure in it for all the HW.
What is really expected in "unitQualifier" in Tolerance Values?
See Common documentation in 1671 specification
How are "toleranceMinus" and "tolerancePlus" expected to be listed?
For a temp range of 0 to 55 , is it: nom=25, minus = 25, plus = 30?
[Teresa]Add something to documentation to clarify how this gets used
On "Power" only listed DC, since the AC power is not applied directly to the PXI module.
Does this mean I need to include a PXI chassis as a dependent item somewhere? or can that be "assumed" from Bus = PXI?
You don’t need to include a PXI chassis – it is assumed from Bus = PXI.
I assume that would also be the same for PCI or VXI devices.
Yes.
VXI and PXI power should be described in the PXI or VXI structure. Make sure that there's a place for PXI power
[Teresa]Make sure that there is a place to describe PXI power
For Power (DC) for instruments like a PXI/PCI hardware, there are many DC rails, each with Volt & Amp values, but there is also a "Total Power" value that does not have a place holder.
Instrument description should only capture the power draw from the instrument
For errors - option for a document that already lists them out instead of re-entering data...
Or, could just list "error Doc" under the Documentation section...
Don’t reference a document – the intent is to have an explicit list of errors
TriggerPort seems to redundant and extra - if the Trigger is a subComponent of the Resource, then it is wholly contained and thus the interaction for that trigger is with the Owning resource, so there is not a need to list Ports under the Trigger item.
After further review: Now, I can see a use case for there being TriggerPort, they will map to the ports on the resource. Therefore I think they should be of the same type, that is we
don't need a "hw:TriggerPort" type any more, can just use "c:Port" as is used in resource Interface section.
[Teresa]Review with Nick and Steve. Make sure that the documentation includes a description of how they are different.
Is there a way to make sure that a list that is defined in the xsd shows up in the specified order when entering the data in XML?
For example, PulseUnits in HardwareCommon. The data items are S, mS, uS, nS, pS, fS, in that order. But when I am entering data in XMLSpy, the list comes up as fS, mS, nS, pS, S, uS (alphabetical order.) This may be something specific to XMLSpy, but it is annoying.
We can’t control what XmlSpy does
When filling in "Capabilites", the examples show "<hw:Description> as the element containing the 1641 signal details, but this will not validate. So, use <hw:Extension> instead.
Using <hw:Extension> was the right thing to do. Already have an action item to document this.
[Teresa]Make sure doc describes where the 1641 XML goes
NOTE: when filling in <hw:Capabilities>, I did not try to fill out the 1641 details, as I did not have access to that standard to know what needed to be used.I only filled in a subset of <hw:Capabilities> to do a proof of concept on the element.
For a scope, all of the measurements (capabilites) can be done on each of the channels, and the actually list of capbilities could be very long, so to me, it seems that this document could get long and complicated.
Does the number of ports in a capability have to match exactly to the # of ports in the resources(s) it is mapped to?
No. Some capabilities may use more ports than others.
For my scope, all 8 channels are synchronized when data is acquired, so when I mapped the capability to resource, I created one resource with all eight channels. How do I define the capability so that it describes that the instrument can measure the Vpp on any set of the 8 channels? As it is now, from the Capabilities document, the XML seems to imply that all 8 channels are always measured synchronously.
20.d Instrument Description Example - Synthetic Instrument
Not complete – Need all examples by April 1st in order to include them in the standard.
20.e Instrument Description Example - Instrument Instance
Not complete – Need all examples by April 1st in order to include them in the standard.
20.f Instrument Description Example – Calibration
Cal Procedure should be 0 to many instead of 1 to 1. In the instrument I used for my example there is a calibration test procedure in a manual and Cal software on a CD, both required for calibration.
[Teresa]Allow multiples
This instrument conforms to the environmental requirements in MIL-PRF-28800F. The humidity requirements have a tolerance and different ranges at different temperatures which the schema does not allow.
RH 5 to 95 +/-5
RH 5 to 75 +/-5 (above 30 degrees C)
RH 5 to 45 +/-5 (above 40 degrees C)
[Teresa]Figure out how to model different tolerances at different temperature ranges
It would be helpful to have a place for additional text information for certain environmental requirements, such as “half sine shock pulse” for Shock requirement.
[Teresa]Add description or comment element
Vibration Frequency should have a range, the schema has one value. The instrument I used has a vibration frequency range of 5 to 500 Hz.
[Teresa]Look at how to model this to be more flexible
Consider allowing a range for temperature instead of just a value and tolerance.
[Teresa]Look at how to model this to be more flexible
Frequency of calibration – not sure what the format is
[Teresa]Provide an example of how to specify duration
Instance schema – calibration due date
Can derive from last cal date and frequency
20.g Instrument Description Example - Environmental Requirements
Complete - See 20.f
20.h Instrument Description Example – Specifications
Not complete – Need all examples by April 1st in order to include them in the standard.
20.i Instrument Description Example - Simple Instrument
Complete
20.j Instrument Description Example - Simple Instrument with Relays
Complete
20.k Instrument Description Example – Switch
Complete – see 20.c
20.l Instrument Description Example - Multi-Channel
Complete – see 20.c
1.4.2Walk-through 1671.2 Standard Specification
Mike Seavy walked through the IEEE standard document for 1671.2. All the “.” Standard documents are in a draft state. Private Groove workspaces will be created for the standards document development. This will allows us to control access – need to be an SCC-20 member to have access to the draft standard.
The document does not contain any schema figures – we can’t use the figures generated by XmlSpy.
Everything has a description. If an annotation existed in the schema, that text was used. Mike added text if none existed.
Mike is concerned that the VXI bus got more attention than the other buses. What other information should be included for PXI, LXI (Dan thinks we’re OK on LXI), VME.
[Mike]Ping Tony Estrada for info on PXI and PXIe
1.4.3Discuss SIWG & ATML Instrument Description
The SI WG would like to use Instrument Description instance documents to formalize their work. The SI WG would generate templates for Instrument Description instance documents that could be used by instrument manufacturers to describe their synthetic instrument components. These template instance documents would be included in the 1761.2 standard.
Ion is concerned about tying the SI work to this standard.
[Mike]Continue discussion with Ion and Chris about folding SI into ATML Instrument Description
1.5Action Items:
# / Action Item / Who / When1 / 20.a Instrument Description Example – Options / Dan / 4/1/2007
2 / Update capabilities document to use correct node path syntax / Dan / 2/15/2007
3 / Update documentation to describe where in the capability description the 1641 XML snippet goes / Teresa / 2/28/2007
4 / Determine whether issues with describing capabilities need to be addressed in the Capabilities document/schema or in 1641 / Chris / 2/28/2007
5 / Make sure that schema documentation describes the use of the qualifier attribute / Teresa / 2/28/2007
6 / Follow up with Nick on this issue regarding connector pins / Steve / 2/28/2007
7 / Document an example of where a software port would be used / Teresa / 2/28/2007
8 / Add optional name attribute to Driver element / Teresa / 2/28/2007
9 / Add something to documentation to clarify how toleranceMinus and tolerancePlus get used / Teresa / 2/28/2007
10 / Make sure that there is a place to describe PXI power / Teresa / 2/28/2007
11 / Review Trigger Port issue with Nick and Steve. Make sure that the documentation includes a description of how they are different. / Teresa / 2/28/2007
12 / Make sure doc describes where the 1641 XML goes / Teresa / 2/28/2007
13 / 20.d Instrument Description Example - Synthetic Instrument / Tom / 4/1/2007
14 / 20.e Instrument Description Example - Instrument Instance / Tamara / 4/1/2007
15 / Allow multiple calibration procedures / Teresa / 2/28/2007
16 / Figure out how to model different tolerances at different temperature ran / Teresa / 2/28/2007
17 / Add description or comment element to environmental requirements / Teresa / 2/28/2007
18 / Look at how to model Vibration Frequency so that it is more flexible / Teresa / 2/28/2007
19 / Look at how to model temperature using a range instead of a value with tolerance / Teresa / 2/28/2007
20 / Provide an example of how to specify dur / Teresa / 2/28/2007
21 / 20.h Instrument Description Example – Specifications / Dan / 4/1/2007
22 / Ping Tony Estrade for info on PXI and PXIe / Mike / 2/28/2007
23 / Continue discussion with Ion and Chris about folding SI into ATML Instrument Description / Mike / 2/28/2007
ATML Instrument Description Meeting Minutes1January17, 2007