unapproved meeting minutes - april 1999 - ivi foundation€¦ · web viewapproved meeting...

IVI FoundationApproved Meeting Minutes

April 20th – 23rd, 1999Fort Collins, University Park Holiday Inn

1. Meeting Attendees..............................................................................2

2. General Membership Meeting............................................................32.1 Voting Members Present.......................................................................................................................... 32.2 Review of January Meeting Minutes......................................................................................................... 32.3 Status of Working Groups........................................................................................................................ 32.4 Miscellaneous Working Group Topics......................................................................................................52.4.1 Discussion of Working Group Chairpersons.............................................................................................52.4.2 Process for Working Group Chairpersons.................................................................................................62.4.3 Digital Class Update – Wes Barnishan.....................................................................................................62.5 Interchangeability Checking..................................................................................................................... 72.6 Membership Review................................................................................................................................. 72.6.1 Membership Roster.................................................................................................................................. 72.6.2 New Members Approves.......................................................................................................................... 72.7 Treasury Report 72.8 Next Meetings Date and Time.................................................................................................................. 72.9 New Business 8

3. Class Specification Working Groups Minutes.................................93.1 IviFgen Working Group Minutes.............................................................................................................. 93.2 IviDmm Working Group Minutes...........................................................................................................123.3 IviScope Working Group Minutes.......................................................................................................... 143.4 IviPower Working Group Minutes.......................................................................................................... 173.5 IviSwtch Working Group Minutes.......................................................................................................... 223.6 IviSpcAn Working Group Minutes.........................................................................................................25

4. Architecture Working Groups.........................................................284.1 ActiveX Working Group Minutes...........................................................................................................284.1.1 Proposed ActiveX Agenda...................................................................................................................... 284.1.2 List of Issues (The italicized issues were discussed at the meeting).........................................................284.1.3 Discussion of Issues................................................................................................................................ 294.1.4 Action Items 334.2 IDL Working Group Minutes.................................................................................................................. 354.3 Leveraging SCPI Principals Minutes......................................................................................................364.4 Principles of Class Definition................................................................................................................. 384.5 IVI 3.1 Architecture Specification Minutes.............................................................................................394.6 MSA Working Group Minutes................................................................................................................ 414.7 IVI 3.2 Inherent Capabilities Specification Minutes................................................................................45

IVI Foundation Meeting Minutes 1 April 20- 23 1999

1. Meeting Attendees

Name Company Phone EmailHue Tran Anritsu Company 408-778-2000 [email protected]

mJohn Lukez Anritsu Company 408-778-2000 [email protected] Bode Bode Enterprises 619-697-1024 [email protected] Pittman CACI 210-735-1903 [email protected] Wright CACI 210-735-1903 [email protected] Johnson CACI-ASG 210-735-1903 [email protected] McComb CERP 916-643-0447 [email protected] Eriksson Ericsson +46-26-159232 [email protected]

omGary Lux Excalibur Systems 254-793-8186 [email protected] Lizotte GenRad 978-589-7508 [email protected] Stern HP 707-577-2886 [email protected] Mueller HP 970-679-9123 [email protected] Harvey HP 970-679-3535 [email protected] Hertzog HP 970-679-5281 [email protected] Faust HP 970-679-2141 [email protected] Hester HP 970-679-3048 [email protected] Oblad HP 707-577-3466 [email protected] Kinney HP 973-586-5435 [email protected] Suhoza Keithley 440-498-2830 [email protected] Ryland Keithley Instruments 440-498-3134 [email protected] Shah Lucent Technologies 614-860-5010 [email protected] Barnishan Marconi Integrated

Systems614-759-5312 wes.barnishan@marconi-

is.comPeter Richardson Marconi Test Systems +44-1383-822131 [email protected]

mRon Taylor Marconi, San Diego 619-675-1844 [email protected] Burnside National Instruments 512-683-5472 [email protected] Bellin National Instruments 512-683-5516 [email protected] Wolfe National Instruments 512-683-5466 [email protected] Rust National Instruments 512-683-5680 [email protected] Zirojevic National Instruments 512-683-5374 [email protected] L. Cole Northrop Grumman

ESSD410-993-5173 [email protected]

m.comGayle Matysek Northrop Grumman

ESSD410-765-9754 [email protected]

Dave McKay Racal Instruments +44-1202-87280 [email protected] Johnston Racal Instruments 210-828-5743 [email protected] Williams Racal Instruments 749-460-6885 [email protected] Smith Racal Instruments 210-828-5743 [email protected] Stevens Raytheon Systems Co. 972-344-5537 [email protected]


mailto:[email protected]













mailto:Ron.Taylor@Marconi_IS.com




























Name Company Phone EmailJochen Wolle Rhode & Schwarz +49-89-4129-3044 [email protected] Meredith Rockwell 319-295-6072 [email protected] Lopes Teradyne 617-422-3377 [email protected]

mDan Matthew TRW 916-339-4011 [email protected] Fertitta Vektrex 619-578-6787 [email protected]

2. General Membership Meeting

2.1 Voting Members Present

The following voting members were present at the General Membership meeting.

Name Company

John Lukez Anritsu CompanyPatrick Johnson CACI-ASGGary Lux Excalibur SystemsKen Lizotte GenRadJoe Mueller HPKeith Suhoza KeithleyNeil Shah Lucent TechnologiesWes Barnishan Marconi Integrated SystemsPeter Richardson Marconi Test SystemsJon Bellin National InstrumentsCraig L. Cole Northrop Grumman ESSDPaul Stevens Raytheon Systems Co.Jochen Wolle Rhode & SchwarzTeresa Lopes TeradyneKirk Fertitta Vektrex

8 Voting Member Representatives are in attendance at the General Business meeting which satisfies the requirements for a quorum.

2.2 Review of January Meeting Minutes Miscellaneous corrections were made to January meeting minutes. The group unanimously approved the amended January meeting minutes.

2.3 Status of Working Groups

The status of each working group was presented. For the complete meeting minutes for a particular working group see the meeting minutes for that working group later in this document.

IDL Working Group Decided to postpone any IDL discussions until the next meeting. At the next meeting, the group will

evaluate progress of ActiveX/COM working group and decide on the direction for IDL working group.








John Harvey will keep watch on ActiveX/COM working group progress. John Harvey will initiate IDL working group discussions before next meeting if he deems it necessary.

See the IDL Working Group Minutes section later in this document.

IVI-1: Charter Document and IVI-2: Operating Procedures

IVI-1 and IVI-2 are approved specification. No changes have been requested or made to these documents.

IVI-3.1 Working Group

Scott Rust (NI) gave a quick summary of the IVI 3.1 working group from the previous afternoon. See the IVI: 3-1 Architecture Specification Minutes section later in this document.

The group plans to continue the IVI 3.1 working group discussions at next meeting.

IVI-3.2 Working Group

IVI 3.2 was accidentally left off the agenda for this meeting. The specification was posted prior to the last meeting. Since then functions that were omitted from the original specification have been added. No other changes have been made. The group decided to hold an informal walk through of the specification Friday morning, April 23, 1999. See the IVI-3.2 Working Inherent Capabilities Specification Minutes section later in this document.

IviFgen Working Group

No additional status was given at this time. See the IviFgen Working Group Minutes section later in this document.

IviDmm Working Group

No additional status was given at this time. See the IviDmm Working Group Minutes section later in this document.

IviScope Working Group

No additional status was given at this time. See the IviScope Working Group Minutes section later in this document.

IviPower Working Group

The IviPower working group had not met at the time of the General Membership meeting. No additional status was given at this time. See the IviPower Working Group Minutes section later in this document.

IviSwtch Working Group

The IviSwtch working group had not met at the time of the General Membership meeting. The requested changes to the IviSwtch specification mainly involve clarification of the documentation and proposals to expand the capabilities of the specification. See the IviPower Working Group Minutes section later in this document.

IviCntr Working Group

There is not an IviCntr working group meeting scheduled for this week. The comments/edits that were generated at the April 1999 meeting have been incorporated into the specification. No other work has


taken place. The group agreed to postpone work on the IviCntr class specification until the review of the original five class specifications is complete or near complete.

There is no IviCntr working group meeting scheduled for the July 1999 IVI Foundation Meeting.

IviSpcAn Working Group

John Lukez (Anritsu) reviewed the work from the IviSpcAn working group. The spectrum analyzer specification is the only new class specification that is making progress while the first five class specification are being reviewed. See the IviSpcAn Working Group Minutes section later in this document. The group would like time at the July 1999 meeting to continue the IviSpcAn discussion.

Neil Shah requested that the IVI Foundation identify a new chairperson to lead the group.

IviPwMtr Working Group

No progress has been made on this specification since the October 1998 meeting. Michael Franklin has requested that the IVI Foundation identify a new chairperson to lead the group.

ActiveX/COM

Jon Bellin reviewed the work from the ActiveX/COM working group. Many action items have been identified and assigned by the group. The expectation is to complete the action items prior to the July 1999 meeting. See the ActiveX/COM Working Group Minutes later in this document. The group would like time at the July 1999 meeting to continue the discussions.

Leveraging SCPI Principles

The group identified several action items. The group plans to follow up on several action items at next IVI meeting

Fundamentals for Class Definition

The group identified several action items and issues. There was the general belief that the action items should be distributed over the existing specifications and working group. New specification might have to be created. Joe Mueller and Scott Rust will evaluate existing specs and make a proposal on how to accommodate the defined issues at next IVI meeting as to future direction

MSA Working Group

The MSA working group had not met at the time of the General Membership meeting. No additional status was given at this time. See the MSA Working Group Minutes section later in this document.

2.4 Miscellaneous Working Group Topics

2.4.1 Discussion of Working Group Chairpersons

The following decsions were made with regard to various working group chairperson positions

John Lukez (Anritsu) is the new IviPwMtr working group chairperson.

Neil Shah (Lucent) will remain as the IviSpcAn working group chairperson. Neil will maintain his leadership role for the working group, but will distribute more of the tasks to other IVI Foundation members. Jochen Wolle (R&S), Joe Mueller (HP), Bob Stern (HP) promised to help Neil with specification work and general coordination.


Rick Hester (HP) volunteered to replace Paul Barton as the IviScope working group chairperson until the next meeting.

Wes Barnishan (MIS) will remain the IviPower working group chairperson

Srdan Zirojevic (NI) will remain the Switch working group chairperson

Glenn Burnside (NI) volunteered to take over the IviDmm working group chairperson position. Scott Rust will contact the existing chairperson to make sure that he agrees.

2.4.2 Process for Working Group Chairpersons

The group discussed the need to complete the review of the original five class specifications in a timely fashion as well as push some of the other working groups along. To do so, requires that each working group complete a large amount of work prior to the July 1999 IVI Foundation meeting. The group agreed upon the following process/milestones to help structure the work between meetings.

Milestone 1 (Completed within 2 weeks of last meeting, May 7th 1999) – The chairperson for each working group is to create and post a summary document. The summary document identifies each issue that the working group has agreed upon, is in general disagreement, or has not discussed. For each issue, the summary document: Assigns a number to the issue Gives the issue a title Assigns an owner Gives a description Describes the impact on the specification Gives the status of the issues (closed, work in progress, open with no work in progress, etc)

Milestone 2 (Completed 1 week after milestone 1, May 14th, 1999) – The working group members provide feedback on whether the summary document accurately reflects the issues. The owners of each issue agree to pursue it the issue.

Milestone 3 (Completed within 4-6 weeks after milestone 2, June 11th – June 25th) - Working group members provide feedback on open items. The working group chairpersons can use a variety of techniques to keep the working group moving – emails, conference calls, in person meetings.

Milestone 4 (Completed 2 weeks prior to next meeting, July 12th) – Update the summary documents and associated specifications. Post the documents to members only area of the IVI Foundation web site. Scott Rust will create an intuitive directory structure. Send out email notification of posting to the entire membership.

Scott Rust to monitor milestone progress.

2.4.3 Digital Class Update – Wes Barnishan

Wes Barnishan presented his proposal for the organization of working groups for digital instrument. He proposed three working groups: Bus emulators (protocol focus) Simple digital I/O (Fixed or limited programmable timing and voltage – Fixed blocks of data) Performance Digital (Programmable timing and voltage)

Wes clarified that protocols/interfaces fit in the Bus emulator class.


Wes identified possible chairpersons for the groups:Gary Lux(Excalibur), Bill Merideth(Rockwell) – Bus emulators (ARINC, 1553)Teresa Lopes(Teradyne) – Simple and Performance Digital

Action item is for chairs to press forward outside of general IVI meetings and present brief updates at the next general membership meeting.

The following people requested to be on the notification list for the digital working groups – HP (Joe Mueller), CACI (Pat Johnson), Vektrex (Kirk Fertitta), Marconi Test Systems (Pete Richardson), Teradyne (Teresa Lopes), Northrop Grumman (Craig Cole), Excalibur (Gary Lux), Rockwell (Bill Meredith), GenRad (Ken Lizotte), National Instruments (Kosta Ilic).

2.5 Interchangeability Checking

Scott Rust gave a presentation on the concepts of Interchangeability Checking. The group agreed that the concept is valuable and did not want to immediately give up on the feature. The group discussed whether the feature can be feasibly implemented. This is an open issue.

Interchangeability Checking is also related to Applying Class-Defined Values for Unused Extensions.

We need to discuss implementation and user scenarios. The group will consist of Paul Stevens, John Harvey, Joe Mueller, Jon Bellin, and Kirk Fertitta. This group will report to the IVI-3.1working group.

2.6 Membership Review

2.6.1 Membership Roster

Scott Rust passed around the current membership roster from the IVI Foundation Web page. The group was instructed to make edits to their contact information. Scott Rust will make the corresponding edits to the IVI Foundation Web page.

2.6.2 New Members Approves

The group unanimously approved the following new members to the IVI Foundation

Company Contact Level

Racal Instruments Terry Boyle Voting

Rockwell Collins Bill Meredith Voting

B Squared Technologies Jayson Beatty Voting

Ericsson Radio Systems AB Daniel Eriksson Associate

PX Instruments Patricia Dalton Voting

Note: Racal Instruments was previously an Associate member. They changed to the Voting member level by re-submitting a Voting Member Application.

Scott Rust will contact the new members to notify them that they have been approved, instruct them on how to access the IVI email list server and the members only area of the web page, and invoice them for their membership dues.


2.7 Treasury Report

Scott Rust passed out a summary of membership dues paid and the balance of the IVI Foundation account. As of April 22, 1999 all members have been invoiced for their 1998 and 1999 membership dues. Scott Rust will contact members who have not paid.

2.8 Next Meetings Date and Time

The next IVI Foundation meeting will be held July 26th – 30th in Columbus, Ohio. Lucent and Marconi Integrated Systems are the hosts for the meeting.

The following meeting is tentatively scheduled for November 2nd – 5th in Munich, Germany. Rhode & Schwarz is the host for the meeting. IVI Foundation Members have until May 7th, 1999 to propose changes to the November 1999 meeting dates or location. People wishing to propose changes to the November 1999 meeting should send an email message to the IVI email list server at [email protected]. If there are no objections, Scott Rust will confirm the November 1999 meeting dates and location on May 7th 1999 by sending a confirmation email to the members.

2.9 New Business

Non-Member Access to www.ivifoundation.org

The group agreed that non-members that are participating in IVI Foundation meetings should be given access to the members’ only section of the IVI Foundation web site. Any member can give access to a non-member that they feel has a need to access the documents posted to the web site. Please use good judgement in granting access. The intent is to give access to people that plan to attend IVI Foundation meetings and work on specifications.

The member that shares access to the web site with a non-member must notify the IVI Foundation at the next general membership meeting.


http://www.ivifoundation.org/

3. Class Specification Working Groups Minutes

3.1 IviFgen Working Group Minutes

Function Return Value Inconsistencies:

All error codes pertinent to IVI are defined in IVI 3.2. There does not appear to a need to further define these error codes. Rick Hester has concerns that an individual driver writer will not have enough guidance to ensure consistent return value behavior. Issues of driver developer guidance will be handled as appropriate in the other IVI documents such as the architecture document. We will further investigate specific instances and determine how to handle error code return values along with coercion behavior.

Fundamental Capabilities:

There is a general issue as to exactly what is meant by “fundamental”. Additionally, Rick Hester feels that the fundamental capabilities section is rather thin. Joe Mueller wants to explicitly define what is fundamental and what is not. Scott Rust suggested that renaming the fundamental capabilities group may be necessary, and define “fundamental capabilities” in some other fashion. It seems that more definition of capabilities and extensions will need to be handled in the IVI 3.1 document. Bob Stern suggested that a matrix would be constructed that correlates capabilities with various makes of instruments within the class. Perhaps instruments vendors could review the class documents and send in a table of what features are supported within the class. The current definition of IVI compliant requires the fundamental class to be implemented and at least one extension group. It was suggested that the IVI web site would contain a table that specifies what features the driver contains to provide an easy point of reference for customers and developers.

Implementation of Functions:

Currently, some functions are essentially paired such that one enables a feature while another disables a feature. It is felt by some that these “paired” functions should be combined into one function with a Boolean flag to enable / disable. Craig Cole expressed that the current implementation is fine, but single functions with distinct enumerations would be a nice solution. Further discussion revolved around creating new single functions in addition to the existing dual functions. Glenn Burnside does not feel too great about this idea. There is a consensus that future implementations should utilize only one function. For the existing 5 classes a dual interface will exist, with the use of dual functions being discouraged but retained for backwards compatibility. Further discussion of this quandary will be handled in the IVI 3.x documents.

C function prototype:

ViStatus IviFgen_ConfigureOutputEnabled (ViSession vi, ViConstString channelName, ViBoolean value);

Impedance Issues:

There is a duality between defining impedance from the aspect of the output terminal of the instrument versus the impedance of the system connected to the instrument. We will remove the 1 M defined value and add some text in the specification to explain the importance of impedance matching and how it affects the reading. The function name will retain the name “output” rather than changing to “source”.

C Usage Examples:


We will defer judgement on this issue as it relates to the Fgen, and address this as a higher level issue for IVI 3.x. There seems to be a consensus that more detailed examples would be a nice addition to the specs. We should either provide “good” examples, or eliminate the examples all together. Another question was brought up regarding whether examples should even be included in the spec.

Software Triggers:

Remove the software trigger function from the specification (7.4.2). Any type of future software triggering will be handled with instrument specific extensions. The attribute value will be retained and moved to the miscellaneous group.

Function Calls and Attributes:

Tighten up the specification to ensure that instruments which do not support output enabling / disabling will return an “invalid value error”. This issue also exists with initiate and abort, and should be dealt with in a similar manner. The definition of “implement” needs to be further enhanced in a higher level document such as IVI 3.x.

There was also discussion regarding the abort generation function. Glenn Burnside indicated that while not all instruments can stop their generation, it would be necessary for instruments that cannot alter their waveforms until they have stopped generating a particular waveform. HP believes that the 1 state instrument model – that is where the generator can be configured in any state, is the level that should be exposed in the class driver, while NI believes that the 2 state instrument model – that is where there is a configure state and a generate state should be exposed in the class driver. For the moment, this issue is at an impasse with further investigation being performed.

Arbitrary Waveform Generator Issues:

Sample rate vs. frequency

Glenn Burnside of NI indicated that specifying frequency works well if one is using a DDS architecture, but sample rate works well for non – DDS generators (point per clock). See equation 1 for a relation between the two methods of specifying sample rate or frequency.

Either method seems equally troublesome under certain conditions, so it appears a choice between the methods will need to be made. More research must be done, particularly from the end-user side to determine which method seems more “normal” in everyday use. For the moment, we will table (Yankee Style) the issue and consult with more customers and experts, to get more feedback for making a good decision.

Order dependency will come out of the sample rate discussion, so it will be tabled as well, until we have more information.

In section 1.4, we will add the information presented by Peter Richardson regarding the normalization of waveforms. See the following text.

Many function generators allow the user to specify an arbitrary waveform for the function generator to produce. Before a function generator can produce an arbitrary waveform, the user must configure some signal generation properties. This specification provides definitions for arbitrary waveform properties that must be followed when developing instrument drivers. The definition of an arbitrary waveform and its properties are given in the following list:

Waveform – A user-defined series of sequential data points, between –1.0 and 1.0 inclusive, that describe an output waveform.


RF Specification

There does not seem to be much likelihood of swapping RF units for low frequency units even if either unit is equally capable. Furthermore, the various forms of digital modulation would be better served in an RF class, as it is unlikely that the low frequency generators will acquire these traits any time in the near future. The 50 standard of RF generators does not seem important distinction, as most low frequency units are 50 . Craig Cole indicated that they never think of function generators and RF signal generators in the same light and would rather not wade through a myriad of low frequency functions to get to their RF functions. The agreement was reached that the RF and W units will become a separate class and include digital modulation generators as well.


3.2 IviDmm Working Group Minutes

Topics For Discussion Front/Rear Read/Fetch MAXTIME Additional Functions Things not specified:

Voltage range for frequency Ohms Compensation TC Junctions

AC Min/Max frequency (Attributes not supported) DMMs with switches. Resolution vs Digits Software Trigger Auto powerline frequency* Autorange* Calculate Accuracy*(* Denotes open issues that were not discussed)

Front / Rear

The capability to select between Front/Rear input is not included within the specification. Concern is that it is possible to move the instrument input outside the test program/driver. A possible solution to this is to use the default setup section for the instrument within the IVI configuration file. This facility allows the user to define the power on configuration of an instrument.

Proposal is to either add this capability to the miscellaneous extensions if we can identify instruments which need this or leave it as something to be configured via the default setup of the IVI configuration file.

Resolution is to add an attribute (ACTIVE_TERMINAL or ACTIVE_CONNECTION) to the miscellaneous section. Values would be VAL_FRONT and VAL_REAR.

Keith Suhoza (Keithley) volunteered to spec the addition.

(Note: Scott Rust to see if Ken Mills will continue to chair this specification)

Read / Fetch MAXTIME

General discussion over the use of timeouts in READ, FETCH and I/O operations. Why do other function not specify a timeout value ? Some functions, such as Configuration should never timeout and that is why they do not have associated timeout values.

The use of timeouts for functions should be referred to discussion of specification 3.x as a general policy statement.

Additional Functions

Some functions have been missed out in the current specification.

Keithley and HP to supply a list of what is implemented in their current DMMs.

The attribute values VAL_SIEMENS should be VAL_CONDUCTANCE and VAL_COULOMBS should be VAL_CHARGE.


Consider adding 4-Wire conductance.

Things not specified

General discussion regarding the use of one general or individual functions to perform the instrument configuration. Review the programmatic interface for measuring temperature to determine additional information that is required to be specified.

Group to research what additional functions may be required.

Group to research frequency/period & temperature measurements.

Users within the general membership to review the resultant proposal for the modified API.

Resolution vs Digits

Proposal to specify absolute units instead of digits for resolution. General discussion on methods of specifying resolution.

Absolute Resolution:

10V Range, 0.001 resolution

Relative Resolution:

10V Range, 0.01% resolution (10V * 0.01 = 0.001)

Digits:

10V Range, 4 Digits (10V * 10-4

)

Proposal to change resolution to be expressed in absolute units.

DMMs with switches.

Problem with the specification is that there are two specs in existence which cover a scanning DMM, DMM and SWITCH.

Need to understand the general philosophy of how to handle hybrid instruments. This to be passed up to the 3.x discussions.

Rick and Keith to research features, attributes and API of a switching DMM, produce draft specification.


3.3 IviScope Working Group Minutes

1. Setting Attributes Individually (Section 3.2.2)Attributes can be set individually using Ivi_SetAttribute() calls. It is discouraged to perform this operation as there can be dependency issues on doing this.The statement “All of the horizontal attributes can be set individually” is to be removed from the specification.

Remove all occurrences of this within the entire specification.

2. Trigger Delay (Section 3.2.3)Suggestion was that Trigger Delay should be in the Horizontal Subsystem and not part of Triggering. The IVI specification is not based on a Window paradigm, but provides facilities to define a window.

HP to look at how this is presented in current scopes.

Reword the description of the TRIGGER_TYPE attribute.

3. IviScope Attributes (Section 3.3)Discussion of the attributes defined in table 3-1.

HORIZ_SAMPLE_RATE Add “of the acquired waveform” to the description of this attribute.

BANDWIDTHModify the description of this attribute to clearly state the intent and limitations on use. This issue is not resolved and requires further discussion.

INPUT_IMPEDANCEThe compliance section has to be modified to state that at least one of the defined INPUT_IMPEDANCE values must be supported for the driver to be compliant.

TRIGGER_COUPLINGVERTICAL_COUPLING should take precedence over TRIGGER_COUPLING settings where there is dependency. Add some text to section 12 (Guidelines).

TRIGGER_SOURCEHP model views the external input is just another channel that can take input. Evaluate what can be done on getting information on scopes to see what we have in the instruments for probe attenuation.

VERTICAL_COUPLINGCompliance issue.

Table 3-2 attribute defined values

TRIGGER_SOURCESoftware trigger already identified as a general problem in 3.x. Software Trigger and Trigger Immediate to be added in compliance section.

4. IviScope_ConfigureChanCharacteristics (Section 3.5.2)


Bandwidth parameter should be a ViReal64

5. IviScope_ConfigureVertical (section 3.5.1)Took common vertical settings and put them in a function. To stop users calling attributes directly defined a second function (ConfigureChanCharacteristics). The coupling parameter of IviScope_ConfigureVertical would appear to belong within ConfigureChanCharacteritics. The reason for this being in the former function was accepted.

6. ActualRecordLength (section 3.5.4)Channels can have different record lengths. Common situation is that record lengths are the same on all channels.Add to guidelines for specific driver development how to handle the situation when record lengths can be different.

Clarify within the specification that coercion for MIN_NUMBER_POINTS should be up to the next available value that the instrument supports.

7. ConfigureTriggerSource (Section 3.5.5)Dependency between trigger type and source, what should be set first, source or type. IVI uses two calls to define the trigger, configure source followed by type.NI & HP to research a different approach to triggering from what is currently specified. Result of this should be a written proposal for discussion by working group.

Additional application developer information is required to document dependency.

8. ReadWaveform (Section 3.5.7)For the xIncrement output parameter, replace length within the description with effective.Move the ConfigureInterpolation and ConfigureAcquisition attributes and functions into fundamental capabilities.

9. AcquisitionStatus, Abort (Sections 3.5.9, 3.5.10)Define good return values…Add to compliance that at least VAL_COMPLETE or VAL_ACQ_STATUS_UNKNOWN must be supported.Return an error from Abort if the instrument cannot abort.

10. SendSWTriggerRemove function from specification

11. Behaviour Model“enough waveforms” is ambiguous when attempting to define what denotes acquisition complete. Need to provide a better definition of what acquisition complete is.

12. FetchWaveform (Section 3.5.11)Add function name after IviScope_ i.e. IviScope_FetchWaveform(). In the purpose change acquires to acquired.

13. TvTrigger (section 4.5.1)Glenn to review the implementation on other scopes, agree with the coments made by Dan.


14. GlitchTrigger Attributes (Section 6.3)Agreed to leave GLITCH_WIDTH name as is.Add GREATER_THAN to the model. Add attribute GLITCH_CONDITION with defined values VAL_GREATER_THAN, VAL_LESS_THAN.

15. WidthTriggerAttributesLeave THRESHOLD as is in table 7-2

16. WidthTrigger ComplianceIn table 7-4 GLITCH should be WIDTH_POLARITY. For WIDTH_CONDITION component, add that attributes are required only to support two of the defined values.

17. WaveformMeas Extension Group (Section 8)Current definition does not handle multi channel measurements. This is a subject for a new extension and not discussed here.

Dan to supply a definition of the single measurements.

18. WaveformMeas Attributes (Section 8.3)Determine what is the best method to indicate coercion of the reference level.

19. MinMaxWaveform Behaviour Model (Section 9.6)

20. MinMaxWaveformCompliance (Section 9.7)Compliance grants exception if envelope can be acquired on at least one channel.

21. Miscellaneous Attribute Value Extensions (Table 10-1)PROBE_ATTENUATION further discussion required.

22. Miscellaneous Attribute Values (Section 10-2) NUM_AVERAGES


3.4 IviPower Working Group Minutes

Issues

1. Slew rates

2. Required attributes not supported by the instrument

3. Status values and where they are defined

4. The name of the DisconnectOutput function and its expected behavior

5. Confusion about the fundamental operation Behavior Model

6. Exclusion of multi-phase power (specifically 3-phase AC power)

7. The effect of normalized data supplied by the user on the arbitrary waveform generated by the power supply

8. Using the word “waveform” when discussing transients

9. The organization of Fundamental, DCV, DCC, ACC, and ACV groups

10. The Transient Extension group

11. The Measurement Extension groups

AC supplies vs. DC supplies Correctness of current measurement model Interchangeability of different measurement modelsSimultaneous measurements of different types

12. How do you set Source Range?

13. How do you set Measurement Range?

14. Instrument Status -- for example, how is OCP/OVP reported? The current status check seems to pertain to an instrument configuration and not to the status of the power generation.

15. Discussion about phase. What it means and what the driver does.

16. Multipoint measurement API. Not clear why you would do a multi-point on an AC supply. For DC, this is used to watch something charge.

For an AC measurement more likely to want to see the actual waveshape (voltage and current) can also get RMS voltage.

Is multipoint something that should be instrument specific instead of common to power supplies.

17. Use waveform and the range of values that it takes. The function requires that the used scale it between -1 and 1. The function itself does scaling as well --- why should the customer have this burden?


18. Not clear how to use a controller module that drives other supplies. They can:

- trigger multiple supplies- do sequences and stepping (user asks for a specific sequence)

Perhaps this can be done with channels (at least in part).

Discussion

Issue 9 - The organization of Fundamental, DCV, DCC, ACC, and ACV groups

All of the important limits are represented in the standard. In the current spec OCP and OVP each have a programmable limit.

Proposal is to model as follows:

Provide a Voltage/Current mode -- in each mode the attributes that apply are as follows:In voltage mode have attributes of:

- output voltage- current limit (may only be able to set to a single value)

In Current mode have attributes of:- output current- voltage limit (may only be able to set to a single value)

The following attributes apply independently of the mode you are in. These represent hardware faults as opposed to the other limits which are load failure.

- Over voltage protection - Over voltage Enable/Disable flag (does nothing when disabled)- Over current protection - Over current Enable/Disable flag (does nothing when disabled)

Include the following in fundamental capabilities:- Mode- Over voltage protection limit- Over current protection limit- Over voltage protection enable- Over current protection enable

Include in voltage extension group the API for the two attributes for sourcing votlage. Include in the current extension group the API for the two attributes for sourcing currrent.

The waveform attribute would be more appropriate in IVI_PowerAC extension group.

Ryan Kinney will propose to the working group names for the attributes and functions by 5/1/99.

Is there a need for an AC current API? Do these products really exist? HP does not (have some ideas how it would work) Keithley does not Kepco does


Potential use is characterizing semi-conductors or driving magnets, large transformers.

Group agrees to drop this extension, while keeping the IVI_PowerAC.

Wes Barnishan will eliminate this from the specification.

Dealing with AC Voltage (still re. Issue #9)

OVP and OCP still applies to AC sources.We already agreed to move WAVEFORM to AC.

Term "instantaneous" should be removed from the standard term "peak" is appropriate.

Agree to the following groupings:

Fundamental -- still use OVP/OCP -- these will always be interpreted as peak.

AC -- WAVEFORM

ACV-- ACVoltage Offset- Amplitude- RMS_CURRENT -- output will hold in an RMS sense to this limit- PEAK_CURRENT -- output will clip to this value

Srdan will do some research to determine if the PEAK limit needs to be included.

Agree to add the two attributes subject to research indicating PEAK is unnecessary.

Wes Barnishan to do the editorial changes outlined in this section of the notes.

Issue 15 -- Phase

Current definition of phase in the standard creates a phase discontinuity.

Two things two change. Some of the phase discussion in the spec should move. Other parts should be done a little differently

Generally defining a phase in power stuff is very difficult therefore an API that syncs to the current phase is somewhat easier.

One application is to program an output to change at a particular phase. For instance this could be used to simulate a drop-out. Note that the phase then indicates when the amplitude will change.

Need to research if the phase needs to be disabled/ignored for some supplies.

Proposal:


Add two attributes. One to enable phase control, the other to specify the phase where the configuration should take affect.Attributes:

ENABLE_PHASE_CONTROL -- Boolean. If true configuration changes occur when the output is at PHASE setting selected. If phase control is not enabled then output has continuous phase.

PHASE -- The phase where the change should occur.

Eliminate start phase from the existing configuration call. Also eliminate the corresponding attribute.

Agreed

Wes Barnishan will make the above changes.

Issue 11 Measurement Extension group

Issue includes simultaneity issues and applicability to AC and DC supplies. Includes issue of providing multipoint measurements appropriately.

AC sources must sense voltage and current at the same time. Additional measurement (e.g., RMS) are derived from these data sets. If a measurement is requested, all of the measurement data is collected. However, certain measurement operations must be defined a priori.

On DC side the values are characterized as the same, even if it is done with a single A/D so the situation is similar.

Problem is that the current spec does not allow for simultaneous measurements either in configuration or triggering.

Existing API has Initiate/Read/Fetch. Need an API that allows the user to specify what measurements they want (define a group measurement). Perhaps define a measurement group some way.

On the surface, it appears that the AC and DC API can be the same.

Srdan will propose an API that satisfies the simultaneity issues.

Some of the multipoint measurements in the spec do not make any sense for AC. For instance multipoint frequency has little meaning.

On the other hand, waveform acquisitions do make sense in both AC and DC.

General lack of clarity on what is needed and what is commonly implemented. There does seem to be some blur in the current spec between multi-point and waveform measurements. Note that for a waveform measurement the sample rate is smaller (faster) than the frequency. For multipoint the sample rate is higher (slower) than the supply settling time (cap charging measurement).

NI will research the heritage of the spec -- why are things like this?, what is needed by the instruments they used for research fodder.

Issue 12 – How do you set Source Range?

Both HP and Keithley allow the customer to specify both a measurement and source range. This has the advantage of preventing the output from being interrupted when the set-up changes.


Regarding source ranging:

Proposal:

In the DC voltage extension add attributes for Voltage Range and Voltage Auto-Range

In the DC current extension add attributes for Current Range and Current Auto-range

In the DC Voltage and DC Current extensions add appropriate API's

Agreed:

Wes Barnishan will write this up and add to the spec.

Wrap-up discussion

What are the most important additional issues?- Status reporting. Over Current, Over Voltage, Over Temperature,

Unregulated. The broader group has agreed per other meetings that something for asynchronous status reporting needs to be provided.

Then there may be a need to take this out of return values from calls (ConnectOutput). May be appropriate to do queryOutputStatus, (however other groups are doing thing). Query Output Protection should be taken out. The inclusion where it exists could interfere with what is provided as an instrument specific solution.

- Transients. General feeling the model for transients provided does not reflect their application. Keithley does this by outputting a list of values. Also may need to distinguish between DC and AC transients. For an AC transient need to supply shape, frequency, amplitude, and others. In some cases this is done with an ARB generator. Generally this stuff needs attention.

- Create user waveform. Range; should the range just be from -1 to 1? The issue is that the instrument has to scale the waveform that has been programmed. Why should the user be required to scale the input since the power supply is doing so as well? The user provides the RMS level and a DC offset. This is an AC source issue. If for some reason the instrument does not support this, it could still be done in the driver.

- The function description uses "waveform" to talk about both the shape and the combination of all of the attributes. Need to be precise on terminology.

- Multiphase power - Seems like this should be handled as an extension of its own. Comment: this should not be done naively -- there are several issues that make this different from "just another AC source".

- Ken from Genrad will write-up a proposal on multichannel and multi-module with a controller.


3.5 IviSwtch Working Group Minutes

Attendees:Srdan Zirojevic NIDarren Kwock HPDave McKay RacalLes Hammer HPTerry Leeper HPKen Lizotte GenradKeith Suhoza KeithleyGlenn Burnside NIRick Hester HPJoe Mueller HP

General issues that need to be discussed re. IviSwitch

1. Speed and performance issue.

Issue with strings and performance and routing algorithm (especially for very fast switches).

2. Scanlist and scan list syntax. Scanning in general

3. Discovery

4. Analog bus switching

5. General purpose switch extension

Would be useful to have an extension group to just open and close a simple switch. Typically just open and close a switch which is logically a channel.

Srdan will propose an extension group for this functionality.

6. Architecture for multiple modules (card cage type instruments)

7. SendSWTrigger

Does not belong here anymore? Do we need something more here for synchronization? This function works different from other specs.

8. TypographicalThings missing description, behavior model out of place, …The information on this was distributed before the meeting.

Forward to IVI 3.X group: can we get away from 8.3 filename requirement? Primarily a question for the future.

9. Use model of scanning functions

10. SetPath does not have an inverse function. How does the user disconnect a path that was established with SetPath?


General discussion on the switch driver

Should this cover data acquisition?

Original design was based on a few customers that were not very interested in data acquisition. The only company interested in this was NI -- but the customers in the group did not have this need. NI has used this driver with their data acquisition switch models.

Intent was to have a driver for every "switching unit" in a box.

If you have an IVI switch driver which is a very low level piece with a higher level switch manager, then may want to minimize some of what is in the low level driver.

The architecture right now is that in the driver you must have a mechanism to open and close physical switches that are in the instrument. The driver for one card abstracts this and expresses to user. This specification should not eliminate the possibility of writing a driver for a group of different switches that may be connected.

The idea of having a switch manager and a low level driver. Everything needs to have a switch manager and a low level driver that is part of the switch internally. This means that if you have a specific application that you want to control, if you can control switch individually, or a driver for a specific topology of switches. This is possible. Need to discuss how that is done with this specification.

Under this specification could have a switch or mux.

Current spec say's that driver must have a connect function to close the path between two channels.

General position/model of the current IVI driver is to expose to the customer only one API with a simple "connect" "disconnect" interface. This is what we want to give to the user. Need to deal with levels of:

- box- switch unit (some predefined capability -- may be a card or fixed

set of cards)- underlying capability of open and close a switch

Concern that this model does not provide interchangeability. Need to deal with:

- choosing how the labeling is done on the switches.

There is a basic IVI capability for re-naming channels proposed in IVI 3.*.

Question about performance on this method. Keithley FET's switch in about 300usec. HP builds switches that do 14000 scans per second along with multimeter measurement -- voltmeter takes


~70us. The FET switch here is almost instantaneous. Name look-up algorithm is very small compared to instrument I/O.

Conclusion: as long as we rely on the IVI channel name mapping, there should not be a interchangeability problem or performance problem based on switch labels; at least where instrument I/O is in the loop. This leaves the primary issue as being register based VXI/PXI/PCPI.

- If a customer receives a switch system from HP and Racal and Keithley, how will they get interchangeability?

One alternative is to keep the CONNECT/DISCONNECT at a level that does not directly control the switches. The customer would then interchange a driver that exists below the driver that knows about CONNECT/DISCONNECT.

Note: Connect does not imply anything else is disconnected.

Based on a substantial amount of general discussion, the group concluded that:

1. Will need to have a driver for each card. For GPIB based mainframes there is some challenge in how this will be done.

Action item: Keith will look into a proposal for this along with Srdan.

2. So a general system has two layers. Each layer can be an instance of an IVISwitch driver. -- Some reservation on how wise this is. This can be done, but there is some concern that a lot of overhead is incurred. So the action item of doing some benchmarking should answer if this direction is appropriate for IVI.

Action item: Do some benchmarking to establish if the IVI name mapping is a real performance problem in these memory mapped systems. Srdan volunteered to do this. Need to understand how this two layer architecture, where each is an IVI driver, impacts performance also --- specifically, if the lower level were some dumb thing would the performance improve significantly. If the dumb driver is necessary then we need that spec as a part of IVI.

3. Some topology needs to be specified. Research is needed on how much should be specified. Basically this is needed to insure interchangeability.

Action item: Srdan will look at this. Someone from HP and Genrad will be available to work with Srdan on defining needs and reviewing results.

Issue #10 - SetPath does not have an inverse function

Given that the SetPath has a path list, the disconnect with channels seems like an inconvenient way to do the disconnect with disconnect. For instance, just specifying the end points may not be enough information to fully open what was closed with SetPath.


The spec needs to clearly explain that, e.g., a connect(A->B) following by connect(B->C) followed by disconnect(A->C) should be an error. Srdan will go through the spec and try to insure that these things are very tight.

SetPath and GetPath are available as a way to improve performance over connect. So connect dynamically determines the path then SetPath can be used to set up the path.

One difficulty is if a source is to be connected to multiple destinations. How can one destination be disconnected? For this case the spec is incomplete and something additional needs to be done.

Spec needs to capture any rules that constrain disconnect and connect. For instance, from the discussion it appears that disconnect uses some amount of intelligence to determine what to disconnect. The way this algorithm works -- or at least behavior needs to be documented in the spec. It would appear that the currently implemented algorithm might limit switch topologies. For example source to multiple destinations -- might happen if you go through a matrix to a mux.

Srdan will look into an API to disconnect the path

Need to specify the syntax of a path list. If the customer connected A to C the path would look something like this: "A->A1;A1->C". This is a semicolon separated list. Currently NI implementation requires that this list be "in order". Some question on this…

Srdan will provide documentation of the order and syntax for the spec

Issue #3 Discovery

This generally ties into how the customer determines the topology of the switch and system. So this issue should show up in the topography discussion.

Issue #4 - Analog Bus Switching

There may be a analog bus internal to a switch module. The next connect call is responsible for not openning the analog bus connection. Primarily this is a scanning issue where each item in scan list may not require reprogramming analog bus switch.

The current implementations download the scanlist to the instrument.

Gary Stadele (HP) will write something up that describes the issue and proposes a solution.

Issue #7 SW TriggerCan we just eliminate this? Part of the problem with switches is how this impacts a particular switch module which may only one switch in a particular instrument.

Further research to be done by Srdan


3.6 IviSpcAn Working Group Minutes

Where are we?There does not seem to be a clear ending point for specification review. We need to determine when exactly the spec is slated to be completed. We would like to have the spec completed by the end of the year, but this is only a tentative goal that could change depending on the complexity encountered.

Fundamental Capabilities Section 3.0

How do we specify vertical units? Currently, we use units per division, but this may not be correct. Bob Stern will investigate this issue.

Craig Cole has a concern about the sign convention related to REF_LEVEL_OFFSET. “Negative numbers correspond to a loss (ie: cable loss), while positive numbers correspond to a gain (ie: amplifiers).”

In table 5, FREQ_MULTIPLIER will be moved to the external mixing extension group.

Strike frequency multiplier attribute from function 3.4.3.

In section 3.3, there is an ambiguity as to what is meant by “relative power in absolute units”. Strike the PCT attribute for now.

In table 9, more description must be added to describe the AUTO_PEAK and AUTO detector types. Additionally, we need to determine who uses AUTO, and if so why.

Under detector type, POS should go to MAX, and NEG should go to MIN.

In table 6, drop all references to the miscellaneous attributes group. Additionally, remove the software trigger function. Finally, a new extension group will be added for non – fundamental capability triggers.

Add the video trigger to page 11, table 9.

Added a note to 3.4.2 to describe how center and span affect start and stop of the instrument. This is important for interchangeability.

Strike all example C usage cases as they are not very helpful.

Further review will be performed on section 3.4.4.

Add a sentence to 3.4.6 to note that configure reference level offset will not change the reference offset. Additionally, we added an example to describe the offset level process.

In sections 3.4.7 and 3.4.8, ReadTrace will be renamed to ReadXYTrace, while ReadSimpleTrace will be replaced with ReadYTrace.

In sections 3.4.10 and 3.4.11, FetchTrace will be renamed to FetchXYTrace, while FetchSimpleTrace will be replaced with FetchYTrace.

Descriptions for fetch and read must be modified to clarify the difference between the two functions. Additionally, a comment must be made regarding synchronization when using the read command.


Issue for 3.1: We may need some kind of synchronization command.

3.4.13 is eliminated.

The initiate trace command aborts a current sweep, moves the instrument to the idle state, and begins a measurement.

The behavior model (3.5) needs to be modified to reflect the different trigger types. Jochen Wolle has agreed to look into the trigger model.

Strike the note on page 32 regarding the sweep complete signal.

Further review of exactly what functions must be supported for compliance is required.

Issue for 3.1: Further clarification of compliance.

Section 5

MARKER_RESOLUTION should be changed to MARKER_FREQ_COUNTER_RES to reflect that this applies to the frequency counter. Additionally, the resolution will be in units of Hz. The frequency sets the gate time as the reciprocal of the frequency.

Add more explanation of the SIGNAL_TRACK attribute.

Add a new attribute to table 12 named MARKER_THRESHOLD. This sets the lower limit for the marker search function.

Craig Cole will come up with a function for Marker Threshold. 5.5.6 and 5.5.14 is a potential candidate for adding this parameter.

Marker on off will be left as 2 functions, as many times users will turn markers on one-by-one, but turn them off all at once.

In 5.5.5, change the function name to IviSpcAn_MarkerRefPosition. Additionally, the input parameter markerPosition will change to markerHorPosition. Additionally, the description was clarified somewhat.

5.5.7, markerResolution was changed to markerFreqCounterRes.

5.5.8, Reword the purpose to reflect the description used for the signal track attribute.Furthermore, the state cache should be invalidated when this command is used.

5.5.11 and 5.5.12, Strike absolute from the purpose.

5.5.13, Add “Hor” to the delta marker position input.

5.5.15, Marker resolution attribute is changed to be consistent with 5.5.7.

5.5.16, State caching should be invalidated here to prevent potential problems.

5.5.17, This function will be eliminated, as it is rarely used anymore, and if so it would probably be not very useful.


4. Architecture Working Groups

4.1 ActiveX Working Group Minutes

4.1.1 Proposed ActiveX AgendaI. Review Goals for the ActiveX Working GroupII. Review Posted Documents

a. HP - Concept Paperb. NI - Applying ActiveX/COM to IVIc. NI - IVI Driver ActiveX Automation Interface Exampled. NI - Wrapper Code Examplese. NI - Interface Usage Examplesf. HP - COM Terminology

III. Brainstorm on Issues the Group Must SolveIV. Benchmarks

a. Need to understand ramifications of any decisionb. What benchmarks must be performedc. Who will execute the benchmarks?

4.1.2 List of Issues (The italicized issues were discussed at the meeting)1. What is the basis for the object model hierarchy?

NI used function tree approach in examplesCapability groups is another alternative

2. Is there room for interface inheritance?Can standard interfaces be created to reflect standard IVI architecture definitions?

3. Which types of COM interfaces will we specify?Performance, data types

4. How to handle groups of channelsWhere do collections make sense?

5. Class and Method naming conventions6. Enumeration naming conventions7. Implications for using enumeration / constants in ADEs8. What is the relationship between compliant class interface and specific driver

interface?


Start with review of NI IDL definitionFocus discussion on practical example

9. Proper place in object model hierarchy for attributes10. How to handle arrays

Should we us variants?11. How to handle error handling12. What counts as a guideline for naming13. Interface flexibility to allow for implementations inside the "box"

What affect does DCOM approach have on interface details14. What benchmarks must be done

What are the variables / different cases15. What are the target ADEs and their restrictions on ActiveX interfacing

CVI's approach to supporting COM / development of ActiveX serversMore generally - focus on COM development issues independent of ADE

16. What is the relationship of the C interfaces IVI currently defines to ActiveX interfaces17. Different use cases for the drivers

How to reuse driver code (binary, source code, etc.)18. Threading models19. What are the target OSs and availability of COM for these OSs?

4.1.3 Discussion of Issues

What are the target ADEs and their restrictions on ActiveX interfacing?

HPVEE Restrictions (Must) Not recognize unsigned short, long, integer / integer / signed char Requires automation through idispatch LabVIEW Restrictions (Must) Requires automation Need to get more info on data-type restrictions LabWindows/CVI Restrictions (Must) (Client side wrapper) Wizard currently requires automation Need to get more info on data-type restrictions Calling IDispatch directly through is difficultJscript Requires automation


Cannot pass parameters by refVB script Restrictions Requires automation Can pass by ref but param type must be variant*VC++ Restrictions (Must) Calling idispatch directly is difficult C Restrictions (Must) Vtable and idispatch is awkward in C (native C interface superior)VB Restrictions (Must) No unsigned char, long, int (data-types supported by variant) Vtable and idispatch supported well Most VB users access ActiveX with "ActiveX controls"Java Restrictions TBDJ++ Restrictions TBDVBA Restrictions (Tentative Must) TBD

Which types of COM interfaces will we specify?Decisions Agreement on using dual interfaces Don't need to support complex data-types Data type restrictions are long, double, string, boolean, arrays thereof, enumeration (32

bits), interface reference pointers. Treat sessions as long.

Open Issues Languages where you cannot pass parameters by reference except through variant

(VBscript) Languages where cannot pass parameters by reference at all. ( Jscript) Languages where you have to put safe arrays in variants (Vbscript, Jscript?) Desirability of strongly typed parameters in C/C++ Do we have different interfaces for variant-only languages?

What are the target OSs and availability of COM for these OSs? See paper by Christian Gross @ microsft.com for more information -

http://msdn.microsoft.com/library/techart/msdn_unixcom.htm


http://msdn.microsoft.com/library/techart/msdn_unixcom.htm

CORBA COM interoperability spec also available Win32, Linux, Unix(HP-UX, Solaris) Price?

Decisions Availability of COM needs to researched

What benchmarks must be done?What are the variables / different cases? Threading model (marshalling) In process, out of process on host, over network Automation vs. Vtable Arrays and strings, Variants vs. strict typing Wrapper overhead between C and ActiveX Impact of varying array sizes up to 100Mbyte

Decisions Investigate different threading models further What are the possible use-cases for multithreading? Benchmarks done with Visual C/C++

What is the basis for the object model hierarchy? Is there room for interface inheritance? NI used function tree approach in examples Capability groups is another alternative Proper use model for the application programmer? How to reuse interface definitions where possible?

Discussion Gayle Matysek does want to know if she is using an extension or instrument specific

capability, but does not want to have to look for that capability in different places. It is OK if it is just in the documentation.

Kirk pointed out that it would be inconvenient when using Microsoft’s intellisense feature if all of the configuration methods where not in the same group and you had to traverse multiple groups to find a method.

Kirk asked what would the effect be if the foundation moved an instrument specific method to an extension or moved an extension method to the fundamental capabilities.


The answer is if we base the object model on the function hierarchy then there is no effect. If the object model is based on the capability groups, then programs break.

John Harvey’s investigation of interface reuse and response to the NI document - Applying ActiveX/COM to IVI Enumerations that vary from specific driver to specific driver prevent interface re-

use Interface pointer properties that vary from specific driver to specific driver prevent

interface re-use Interface inheritance in COM is single inheritance only Capabilities group approach for organizing the hierarchy imposes limitations on re-

use

Decisions Look at examples that compare function tree and IVI capabilities group approaches Investigate how to take advantage of interface reuse in the context of the function-tree

approach

Proper place in object model hierarchy for attributesDiscussion Want to promote the use of the high-level methods rather than attributes. Generally,

only the power users should use instrument attributes directly. Expose all instrument attributes through high-level functions. The same does not apply to inherent attributes.Decisions Keep instrument attributes isolated in the object model. Have a separate interface for the inherent attributes. Possibly in the Utility class.

Possibly combined with Utility methods.

How to handle groups of channels. Where do collections make sense? NI - Not opposed but concerned about using collections wherever channels appear.

Concerns about return value data types depending on type of application - single channel vs. multiple channel

Kirk - Simplifies operations on multiple (noncontiguous) channels - Good for Digital applications (switches).

John H. - Proposes that collection decisions be made on a class basis. In SCPI, he saw six places that have repetition for the spectrum analyzer


Decisions Examples using collections (Teresa)

Open Issues How do collections interact with the C interface How do collections interact with IVI channels?

What is the relationship between compliant class interface and specific driver interface? Discussion Jon Bellin reviewed the relationships between the class interface, compliant base class

interface, and specific driver interface in the NI IDL example definitions. The group agreed that there should not be an inheritance relationship between

compliant base class interface and specific driver interface in NI IDL. The relationship between the specific driver definition and the class definition is not an "is a" relationship. It is a "sorta is mostly" relationship. Examples of this are the missing extension groups and different sets of enum values.

What are the implications for using enumeration / constants in ADEs? IDL allows definition of enumeration in type lib. Type lib gives info about COM objects in

DLL. VB / Intelli-sense makes use of this information Defined constants do not appear in type libraryIssues What's the best way to handle defined real and string constants in the IVI.h?

Enumeration Naming Conventions When defining enumerations, cannot have same names across different sets of

enumerations Instrument prefixes differentiate enumerated types across different specific drivers

within the same class Need to decide on a standard convention (upper/lowercase issues)Decision General agreement on approach to enumerated names in NI doc.

4.1.4 Action Items

ADE Restrictions on Using ActiveX Interfaces LabVIEW – Data types? Owner: NI


LW/CVI client side wrapper – Data types? Owner: NI VBA – Require Automation? Data types? Pass by ref? Arrays? Owner: Teresa J++ – Require Automation? Data types? Pass by ref? Arrays? Owner: John Harvey Java – Require Automation? Data types? Pass by ref? Arrays? Owner: John Harvey Importance of variant-only languages vs. strongly-typed parameters in C/C++?

OS Availability Investigate and summarize (See

http://msdn.microsoft.com/library/techart/msdn_unixcom.htm) Price? Defer

Object Model Hierarchy Develop examples that compare function tree and IVI capabilities group approaches

Owner: NI Investigate function-tree approach further in addressing re-use Owner: NI+HP+Kirk

Collections Examples using collections Owner: Teresa How do collections interact with the C interface Defer How do collections interact with IVI channels? Defer

Threading Models Investigate different threading models further Owner: Kirk take first pass, John,

Jon, Teresa, Daniel review List possible use cases for multithreading Owner: NI

Using Enumerations and Constants in ADEs What's the best way to handle defined real and string constants in the IVI header files

Defer

Benchmarks Define matrix Defer until threading model investigation done - John will take

lead once investigation completeWrite and execute benchmarks Defer


4.2 IDL Working Group Minutes

Overview of IDL document written by John Harvey Originally used in DCE world (Distributed computing) - abstract communications layer

on programs running on different machines. Defined to facilitate remote procedure calls between machines that had differences such as big endian - little endian, others…

Provide neutral description of data to facilitate cross platform communications DCE IDL, CORBA IDL, COM IDL - Different implementations Need translator for COM and IVI interfaces Please see "IDL Starting Point" document for further detailsNI wrote a similar document. See "IDL as the IVI Specification Language" Add IVI specific keywords that a translator would understand to translate back into an

IVI ansi C interface Translate from Microsoft IDL to IVI ansi C interface.

Decision After review by subcommittee working group, the conclusions was to follow NI approach Defer additional IDL work until ActiveX issues more firmly defined

Open Issues Constant and enumeration definition, organizing methods into interfaces, creating

interface properties to define relationships between interfaces (to build hierarchy), adding type library definition

Peripheral issues of help file implementations - For each method or property, we can identify that with an index into a help file utilized by the object browser

Someone must provide and maintain translation tools


4.3 Leveraging SCPI Principals Minutes

Presentation by Jochen Wolle, SCPI president, R&S1. Need for expressing “class definition” version – for tracking new capabilities,

obsolescence, etc.2. Looking for more commonality (predictable) way to assign mnemonics – more what

a user would expect when working with multiple IVI drivers3. Open issue: SCPI allows multiple copies of functionality on each level of the

command tree. Need to see how IVI could or should allow for similar capability4. Would like to see a syntax and style guide for extending or writing new IVI drivers.5. SCPI has a units subsystem – believe that it has merit. Like to see IVI leverage this

work if possible, especially as we move to Active X.6. Use of High, Mid, Low - concern with using these (don’t leverage this from SCPI)

because the meanings can change as time moves ahead.7. Error reporting – like to see a strategy for reporting soft errors (i.e. syntax) vs. hard

errors (i.e. power fail) SCPI makes no recommendations on what should be reported only how to accomplish it. SCPI does provide a powerful, flexible status subsystem. Need an API for accessing the status reporting system.

8. Open issue: how to handle asynchronous exceptions.9. Instrument classes – defines a minimum required set (like fundamental) of functions

for some instrument classes. You can query an instrument to determine what capabilities that it has. Scott says that this is part of the class driver.

The power point file that Jochen Wolle presented is posted on the IVI Foundation web site as \memfiles\April99MeetingDocs\IVI-SCPI.ppt.

Group DiscussionQ. What does SCPI consortium say about using AUTO functions for best

interchangeability? R. Action: SCPI doesn’t have a position – will have to look into this. Other comments:

Ericsson says that they don’t trust instruments to set up measurements properly.

Q. What classes has SCPI defined that IVI has not yet tackled?R. RF SigGens

Q. How does/should IVI handle the situation when multiple assets have overlapping capabilities?

R. Scott, quick first look assessment – that this is a really tough problem. With driver approach currently handle a box to box direct replacement only.

Q. Kirk. Should the IVI trigger system reflect (more) of the SCPI trigger system. Are there other instrument (subsystem) behavior models that should be reflected in IVI?

R. SCPI trigger model is more extensive.

Action List follow-up items1. Versioning of class specifications (Scott R. and 3.2 working group)2. General naming conventions (Jochen Wolle, John Lukesz, HP TBD, Scott Rust)3. Guidelines on handling “AUTO” functions (Scott Rust, Jochen Wolle, John Harvey)4. How best to get asynchronous event handling, especially hard errors. (Kirk

Fertitta., Roger Oblad, Dan M. Ryan HP, Daniel Eriksson)5. How does/should IVI handle the situation when multiple assets have overlapping

capabilities? (Jochen Wolle, Jon Bellin, Ron Taylor, John Harvey )


6. Propose an IVI API for the status model using SCPI as the starting point (Kathy Hertzog, Dan M., Teresa Lopes)

7. Across class consistency guidelines for common tasks – configure triggers, etc. (NI willing to examine existing class drivers: Glenn Burnside – NI)

8. Syntax and style guide (Overall for IVI but with SCPI learning’s where possible) - (Jochen Wolle, Scott Rust, John Harvey)


4.4 Principles of Class Definition

Scott Rust gave a presentation on the principles of class definition. The power point file that he presented is posted on the IVI Foundation web site as \memfiles\April99MeetingDocs\Principles of Class Definitions.ppt.

Group Discussion Group decision to eliminate miscellaneous extension groups – in favor of including

these functions into respective class drivers extensions or individual extensions. Guidelines on what kind of exceptions are acceptable for compliance. Some would like

to see a more precise write-up of what compliance means Interchangeability checking – is mainly intended catch programming errors – ie.

Compliance to IVI driver requirements.

Follow-up Action Items1. Develop Guidelines on what kind of exceptions are acceptable for compliance.

(Scott R. +)2. Group decision to eliminate miscellaneous extension groups – in favor of including

these functions into respective class drivers extensions or individual extensions (Scott R. +)

3. Ensure that Attribute ID values, and completion codes and ID value are unuque across all classes. (Scott R.+)


4.5 IVI 3.1 Architecture Specification Minutes

Meeting Agenda Review Flowcharts (done) Relationship of IVI and SCPI COM Impact of COM-in-the-box Resolving issue of exporting attribute functions Interchangeability issues Architecture diagram and responsibilities and interfaces Outline for specs Continuation of work

Current IVI features Specific Driver

Simulation (with range checking) State caching (optional) Range checking (enable/disable) Status checking (enable/disable) Virtual channel names Multithreaded safety

Class Driver Interchangeability Interchangeability checking Advance simulation Ability to call class and specific features

Candidates from Requirements (Agreed to if no “???”) Simulation

Reasonable range checking (e.g., don’t have to take second-order effects into account)

Accommodate simulation of output values either in specific driver or elsewhere. Good performance

Accommodates state caching in specific driver Accommodate enabling/disabling of optional range checking in specific driver Range checking required in specific driver when instrument does not handle errors

properly Accommodate automatic status querying in specific driver (with enable/disable

capability) Virtual channel names Multithreaded safety Interchangeability

Swapping without changing source code Applying default setup from configuration file Interchangeability checking ??????? Apply class-defined values to unused extensions ???????

Ability to get value of all attributes (?????) Ability to call class and specific methods on same session Don’t prevent specific driver from exporting all programmable instrument features Open to various HW interfaces and I/O APIs Support for all popular ADEs for T&M Accommodate DCOM instruments (COM-in-the-box)


Multiplatform: Allow for Win32-only drivers or drivers that can run on other platforms without extra licenses(Need to clarify wording)

Not requiring a product in addition to the ADE and driver. (Need to clarify wording)

Agreed Changes

Rename CLASS_MAJOR_VERSION to CLASS_DRIVER_MAJOR_VERSION, etc. Add separate SPECIFICATION_MAJOR_VERSION, etc, attributes for both the class and

specific drivers. Version number of driver number is independent of version number of spec.

Open Issues

How do we assign version numbers? Do we update version numbers of all specs at once?

Action Items for Next Meeting

Relationship of IVI and SCPI COM (HP) Impact of COM-in-the-box (John Harvey and Jon Bellin) Resolving issue of exporting attribute functions (???) Interchangeability issues (???)

Unfulfilled Agenda Items

Architecture diagram and responsibilities and interfaces Outline for specs Continuation of work


4.6 MSA Working Group Minutes

Subgroup Chair: Roger Oblad

Bob Stern and Roger Oblad presented the current status and directions of the IVI-MSA subgroup and lead a discussion. The presentation that was used along with a FAQ document will be posted on the member area of the IVI web.

The following were in attendance of the subgroup meeting:

Attendees CompanyKirk Fertitta VektrexTerry Smith Racal InstrumentsPatrick Johnson CACI-ASGRoger Oblad HP – SRSDMathew Wright CACIBill Meredith Rockwell Ron Taylor Marconi (former GDE Systems)John Ryland Keithley InstrumentsJohn Harvey HP – SWTCJim Bachman HP – MXDAmar Patel National InstrumentsGayle Matysek Northrop Grumman (former

Westinghouse)Teresa Lopes TeradynePeter Richardson Marconi Test SystemsDaniel Eriksson Ericsson Jochen Volle Rohde & SchwarzNeil Shah LucentJohn Lukez Anritsu WiltronKathy Hertzog HP – SWTCBob Stern HP – SRSD

Expectations and comments of subgroup members:Several of the expectations were sent in advance e-mail. These comments are in the power point presentation used for meeting and not copied below.

Jochen Volle -- Wants us to determine what is really achievable?

Teresa Lopes -- Wants a measurement level of abstraction.

Patrick Johnson -- We are in the systems business. In putting systems together for customer we would like to see another layer above IVI. I tend toward a single interface.

Mathew Wright --How do IVI and MSA fit together? “If you say you are MSA compliant and are you IVI? Or if your are IVI are you MSA compliant?

Keithley -- We want to learn.

Gayle Matysek – I’m very interested in virtual instrument driver. “ I watched ABBET duplicate ATLAS and then throw it out. Let’s learn from ATLAS but don’t waste your time “


Peter Richardson -- We have used Stimulus models for years. Concerns over linking MSA and IVI too heavily. I don’t want them so coupled that to do one you have to do the other. MSA should not rely on IVI. MSA is not open; We need open things. I want to see all interfaces documented and open. Concerned about how ATLAS tried to do this for years. So I’m concerned that we are doing another ATLAS. Another TPS language that will be as big as mess as ATLAS was. I don’t like the term MSA because it does not include Stimulus. When will we see new diagrams, you have shown the same slides over and over. We want to see some [new] details.

Daniel Eriksson -- most people get a specification that have to do with measurements not the instruments, we are currently working on a new GSM capability, HP, RS, and Anritsu are in our test systems. We are looking forward to what MSA will bring to IVI.

Neil Shah – We want a higher level of interchangeability. We have achieved this for our tests but not at the measurement level.

Kirk Fertitta -- Mission statement has to be architecture independent… I haven’t signed to accept an asset control module or server as part of IVI. How can it be part of a measurement server. Don’t allow the mission statement to be implementation specific We want interchangeability of classes not just within classes.

Teresa Lopes -- if we can’t get code we will throw it out and go another way.However, if instrument vendor would fix the driver in 24 hours that would work Daniel Eriksson – That would work for Ericsson too!

Peter (Marconi Test Systems) that his MoD customers require source code whenever the British govn’t pays for S/W development.

Jochen Volle – Is there a formal way to find out what are the ACM interface specifications. I.e. specs that the test assets must meet to make the measurement.

Kirk Fertitta --Concern over where do ACM’s come from and how do you know what are the specs to the asset control module.

Peter Richardson -- Reuse code means only one entity has control of the source. Is this really an open approach? Open has specific meanings. Roger Oblad – We will need to find an industry mechanism to use common code

Are there special needs of COM that you need to take advantage of to make MSA work? (FAQ candidate)

Kirk Fertitta - Any reason that you couldn’t do stimulus servers not just measurement servers? Answer No.

LRU – is line replaceable unit (don’t forget to comment on WRA, weapons replaceable assembly of rthe US Navy)

Amar Patel -- You said that you used COM for MSA, yet IVI still allows use of C. Is this a problem?

Roger Oblad -- An assumption is being made that IVI-MSA, which is COM based and IVI-drivers, which are ANSI C based, will eventually both use COM when Active-X technology is adopted for IVI drivers. MSA does not require COM based drivers but customers would


have a better overall common “look and feel” if all components shared the same underlying technology.

Roger suggested bringing asset server, ACM examples, and event server documentation to the next IVI meeting.

The initial IVI-MSA specificaion work should be modles after IVI 3.1 and should cover Principles of design.

A request was made to provide some sample application code.

It was noted that a name different than IVI-MSA should be selected and done soon. Roger will sent a memo to the team asking for suggestions for a name that solve two problems with the current name… The name should include Stimulus and it should refer to a resultant deliverable and not an architecture.

Time allocation for next meeting – people wanted the same or a little more (4 to 6 hours) A request was made to bring a demo of real interchangeability using the Phase Noise solution.Jochen asked for examples of how one would “describe the measurements and capabilities.”

A new IVI-MSA FAQ was distributed and reviewed during the meeting. A few additional questions were added.

There was a discussion on the terms IVI-MSA and IVI-drivers. It was agreed that both terms need new wordy descriptions that will position them in relation to each other and be easy to understand. It was discussed whether IVI-MSA and IVI-divers should be completely distinct as one extreme or be totally integrated as another. The conclusion that was drawn was than they are approaching the problem of interchangeability from two directions. One is from the top down and the other from the bottom up. Keeping them distinct was preferred however the value of some shared components is desirable. Due to the current issue over COM and C-API’s, IVI-MSA with its dependency on COM technology can not be used in an environment where COM is not available. However this technology difference does not preclude IVI-MSA from fully utalizing ANSI C IVI-drivers. If IVI-driver specifications eventually embrace COM there will be benefits that come from sharing common components such as the event server and the asset server.

ISSUE: A clean technical solution is needed to the current problem that makes it difficult for a customer to use I/O devices from multiple companies. This is a result of the current VISA specification. MSA in its current form as exists at HP, has a solution for this, which does allow I/O interfaces to be mixed from different vendors. Though it works, it involves doing tricks that are not supported by the VISA specification. . Also this solution however won’t work with current IVI-engine behavior. The correct forum to work this issue and find a good solution that will allow full interoperability of I/O devices from multiple vendors needs to be identified and this work needs to be initiated.Why does VISA have to be loaded to use the IVI engine? This is just the way it is for now. Input was made to change this.

There was a discussion on the creation of semantic standards for Measurements Servers or General Purpose Asset Control Modules.

General purpose ACM’s could be created with a semantic interface that is measurement rather than instrument focused. These would be used where a measurement only requires a single physical asset to perform the required functionality. It would allow using an asset of one type to be interchanged with another of a different base type.


(i.e. 2 channel scope for 4 channel scope) The IVI foundation could start a subgroup to determine semantic standards for these however the IVI-MSA roadmap shows this as something that will not be considered until a lot of other work is done. Alternatively, solution providers or system integrators could create these internally or others could pursue them as products.

Semantic standards for Measurement Servers also are considered a long-term opportunity and not something that the IVI-MSA subgroup would work on in the short term. Solution providers or system integrators could create these independently of the IVI foundation. There were several comments made on ATLAS. If a signal oriented interface were to be developed as a follow on activity, making sure the experience and lessons learned from ATLAS, was considered important.

The work that is needed initially is in specifying the key interfaces and the development of common shared components such as the asset the server and event server. Semantic standardization is a future activity.

Action Items 1. Send Roger’s 1997 Autotestcon paper and slides to Scott for posting2. Demo request (do only if we can show the software operating)3. Send out FAQ’s, PP-presentation, minutes, and glossary to Scott for posting on the IVI

web site. 4. Work with the broader IVI Foundation to refine the clarify the terms IVI-drivers, and IVI-

MSA5. Identify the correct forum to solve VISA interoperability problems.6. Roger ask Scott Rust to assign a document number for IVI-MSA7. Send Scott the minutes from this meeting to post on the IVI web site.8. Propose a new mission statement from the notes taken below.9. Roger send e-mail to the IVI distribution list that covers the following

Provide a pointer to the submitted material Provide a proposed mission statement and ask for feedback Initiate a poll of ideas for a name change from MSA to IVI-xxx?

10. Resolve MSAs use of the registry and IVI-drivers use of .ini files.11. Bob Stern to make sure some DOD folks come to the next meeting in July12. Peter Richardson to ask UK MoD people to attend IVI meeting to discuss the source code

topic further 13. Jochen to do the same with German MoD.

Preparations for next meeting1. Request 4-6 hours meeting time2. Bring a physical example to demonstrate real interchangeability with IVI-MSA3. Bring an initial draft of the IVI-MSA specification that captures glossary, FAQ, and

tutorial information4. Bring some sample application code.5. Bring an example showing multiple roles and how these roles are defined.6. Bring an example of how a measurement server’s API is specified.

Notes on content of new mission statement:Create an IVI Specification document that will provide all of the detailed information a solution provider will need to do the following:

Create Measurement Servers Create Asset Control Modules Use common components Understand the requirements of a solution that can “guarantee” the “same answer”

after an interchange of a test instrument.


Provide visibility of this work to the industry in general. Create a measurement abstraction above IVI-driver instrument view. Provides an architecture that provides a level of interchangeability that is

independent of instrument type, Implement reusable measurements that require more than one instrument at a time. A solution that addresses 2nd order effects. Provision of how to deliver the “same answer”, guaranteed by the solution provider.

Not instrument vendor.

Roger Oblad's IEEE paper on the Measurement Subsystem Architecture is posted on the IVI Foundation web site as \memfiles\WorkingGroups\MSA\Autotestcon_MSA_PAPER97.ppt.


4.7 IVI 3.2 Inherent Capabilities Specification Minutes

1. Need to beef up the entire Section 1. Overview of the IVI Inherent Capabilities Specification . Need complete the list of definitions. Scott Rust will take the action item. To be done as specification approaches completion.

2. Roger Oblad – Wants a way to specify which I/O library (specifically VISA) for the specific driver to use.

3. This specification defines the common exported functions and attributes from class drivers and specific drivers. Therefore, hidden attributes of the class and specific driver should not be documented here. I believe this is the case for the VISA_RM_SESSION and that it should be removed from the document.

4. John Harvey pointed out that some of the inherent attributes don’t make since for COM-IN-THE-BOX instruments such as caching. ACTION ITEM – John Harvey will identify attributes and functions that don’t make sense for COM-in-the-box implementations and send to the group. Deadline: May 23 rd, 1999.

5. Some of the inherent attributes control optional IVI features. The group agreed that there should be a standard way that all driver implement to control these features even if they are optional. For example, it is allowed to not implement the state-caching feature and not report an error when the CACHE attribute is set to VI_TRUE. Need to make sure that the behavior is accurately defined for these cases.

6. The group likes the idea of a way to identify the capabilities of a specific driver. This includes which capability groups are supported as well as the optional IVI features such as CACHING. An example approach is proposed in the DRAFT of IVI 3.1.

7. Daniel Eriksson – Needs a way to invalidate the cache if caching is implemented. Important when the user is required to access the front panel of the instrument. This is an open issue with a couple of thoughts on how to handle. We could export a specific function that specifically invalidates the cache or have a more general approach where the application identifies when the user is bypassing the specific driver.

Well written instrument drivers could use an event mechanism to identify when a user pushes the local button on the front panel of the GPIB device.

8. Need to investigate whether IVI_ATTR_MODULE_PATHNAME is a specific driver attribute. Scott Rust will take the action item.

9. ATTR_LOGICAL_NAME should probably be a specific driver attribute as you can initialize a specific driver with a logical name.

10. NUM_CHANNELS may need to change based on discussions regarding how we handle channels. The discussion is currently taking place in the ActiveX working group and has implications on the 3.X Specifications. This is totally open. No alternatives were discussed.

11. John Harvey believes that capability attributes should be at least part of the class compliant base class for the ActiveX interface if not also the specific driver interface as well. For ANSI C, he feels that it should be part of the specific driver. This is consistent with the desire to have a text file ship with the driver that contains similar information. The class driver could implement a feature that validates the information that the specific driver exports. The group can go either way on this issue.

12. Open issue: How do we add attributes that return the class specification versions that the class and specific drivers are compliant with? We believe there is some discussion of naming options in the ActiveX meeting minutes.


13. John Harvey asked the question to the users as to whether it is necessary to have major, minor, and revision attributes. May want to add additional required information to these attributes such implementor company name, model number, description of the device(s), options of the device etc. Discussion of whether to collapse all of these attributes into a single string. The group generally agreed that they want to have separate attributes so that they can more easily access the information and that it makes it easier to add new information in the future.

14. How to map the error attributes to the COM error object. Secondary error may have a problem with COM. Also need to understand how the error attributes relate to asynchronous status report.
