Meeting Summaries

IVI Foundation Meeting Summaries December 10-13, 2001 Hyatt Regency, Austin TX

1. Table of Contents

1. TABLE OF CONTENTS...... 1

2. MEETING ATTENDEES...... 2

3. BUSINESS MEETING...... 3

4. TECHNICAL COMMITTEE...... 6

5. CONFIGURATION SERVER WORKING GROUP...... 15

6. CONFORMANCE WORKING GROUP...... 18

7. SIGNAL INTERFACE WORKING GROUP...... 24

8. LEGAL/SHARED COMPONENTS WORKING GROUP...... 27

9. SHARED COMPONENTS DISCUSSION...... 30

10. DISCUSSION OF SPEC RELEASE MEETING...... 32

11. DRIVER ARCHITECTURE WORKING GROUP...... 35

12. DEVELOPER’S FORUM WORKING GROUP...... 38

13. IVIDIGITAL WORKING GROUP...... 41

14. VISA WORKING GROUP...... 43

15. IVI FOUNDATION, INC. MEMBERS (12/01/2001)...... 50

16. IVI FOUNDATION, INC. FINANCES (9/30/2001)...... 54

IVI Foundation Meeting Minutes 1 September 10-14, 2001 2. Meeting Attendees

Name Company Phone Email Mon Tue Wed Thur Hob Wubbena Agilent Technologies 970-679-3363 [email protected] X X X Joe Mueller Agilent Technologies (970)679-2348 [email protected] X X X X John Harvey Agilent Technologies (970) 679-3535 [email protected] X X X X Mel Petty BCO, Inc. 978-663-2156 [email protected] X X Fred Bode Bode Enterprises 619-297-1024 [email protected] X X X X Don Davis Boeing 314-234-2722 [email protected] X X m Steve Wegener Boeing 314-234-3801 [email protected] X X m John Ryland Keithley 440-498-3044 [email protected] X X X X Bankim Tejani National Instruments 512-683-5323 [email protected] X X X X Dany Cheij National Instruments 512-683-5286 [email protected] X X X X Glenn Burnside National Instruments 512-683-5472 [email protected] X X X X Jon Bellin National Instruments (512) 683-5516 [email protected] X X X X Noel Adorno National Instruments 512-683-5071 [email protected] X X X X Scott Rust National Instruments (512)683-5680 [email protected] X X X X Zulfiqar Haider National Instruments 512-683-8374 [email protected] X X X X John Rosewald Racal Instruments 210-699-6799 [email protected] X X X X Jochen Wolle Rohde & Schwarz +49 89 4129 [email protected] X X X X 13044 schwarz.com Johannes Ganzert Rohde & Schwarz +49 89 4129 [email protected] X X X X 13405 -schwarz.com Keith Rule Tektronix 503-677-4338 [email protected] X X X X Badri Malynur Tektronix, Inc. 503 627-5880 [email protected] X X X X om Andy Hutchinson Teradyne 978-370-1277 [email protected] X X X X eradyne.com Teresa P Lopes Teradyne 978-370-1377 [email protected] X X X X Chris Corringe Racal Instruments +44 1202 872800 chris @racalinst.co.uk X X X X Thomas Gaudette The Mathworks 508-647-7759 [email protected] X X X X Ion Neag TYX Corporation +1 703 264 1080 [email protected] X X X X Rengan Rajendran Vektrex Electronic 858-558-8282 x20 [email protected] X X X X Systems Melissa Ford Vektrex Electronic 858-588-8282 [email protected] X Systems Jeff Hulett Vektrex Electronic 858-558-8282 x11 [email protected] X X X X Systems

IVI Foundation Meeting Minutes 2 September 10-14, 2001 3. Business Meeting

3.1 General Meeting Info: Date of Meeting: December 10,2001 Location: Austin TX Chairperson: Joe Mueller Minutes Prepared By:

3.2 Meeting Attendees:

Name Company Phone Email

3.3 Topics To Be Discussed:  Ron Wolfe: re. VXIplug&play  Update from Marketing Committee re. Trademarks  Fred Bode: Financial and membership update  Product demos during IVI Meetings  Future meeting planning

3.4 Record of Discussions:

3.4.1 Ron Wolfe: re. VXIplug&play

Ron presented on history/charter of VXIplug&play. Group has been fairly inactive for several years except for VISA. VISA group has been meeting in conjunction with the IVI Foundation on and off last couple of years. Ron distributed proposal for merging the groups that was discussed by VXIplug&play group (balloted in August along with VISA and update driver spec).

(document to be entered into notes).

Questions about legal issues? - Who owns the VXIplug&play copyrights if not legal entity? - Are there legal issues associated with convergence? - Is there trademark ownership issue? - Would the IVI charter have to be modified/extended to encompass VPP work.

IVI Foundation Meeting Minutes 3 September 10-14, 2001 Regarding changes to IVI charter etc, have the VPP committees defer to their charter. If there were any charter conflicts with IVI, just have the IVI foundation resolve appropriately.

IVI Foundation by-laws indicate things that the consortium “plans to do”, however they say specifically that the BoD can extend as it see’s appropriate.

Would this be a technical committee under the IVI technical committee? Need to check with IVI foundation attorney if there are any issues.

Could potentially absorb other activities (SCPI, VXI, …).

Do we need to make sure that membership proposal is OK?

Should we try to includeVXIpnp and SCPI at one time, or sequentially?

Get a legal opinion by the next meeting and be able to move by the meeting after that.

Ron will provide a list of VXIpnp specs and active committees & chairmen and a suggested transition plan. Ron will forward to legal committee.

Dany will discuss with attorney.

3.4.2 Update from Marketing Committee re. Logos Marketing committee discussed logos at the last meeting. Decided on three logos  B&W logo  Color logo  Compliance logo – decision on this depends on results of conformance WG.

3.4.3 Fred Bode: Financial and membership update Fred distributed membership lists and the financial reports. Please see attachments at the end of the minutes.

3.4.4 Product demos during IVI Meetings How do we handle requests to do demos?

Allow an hour or so to allow people 5-10 minutes to present what they are doing, then have demos during off hours.

Users forum wants to have demos of what is being developed.

Possible Guidelines for Product memos:  Avoid marketing pitches & focus on technology in formal WGs.  Defer product questions to after to formal meeting.

IVI Foundation Meeting Minutes 4 September 10-14, 2001  In the developers and users forums, allow 5-10 minutes per to present what they are doing, then have the demos during off hours.  Make sure that the membership is informed and interested in the presentation. This should involve some level of polling of the group.  May have presentations in other groups by invitation. A vote of members present indicated 8 in favor of the above guidelines, 0 against, 0 abstaining

3.4.5 Future meeting planning Plan is for next meeting in Ft. Collins, March 18 – 22. We decided to revisit this during the technical committee meeting on Wednesday to take advantage of the discussion of technical progress. Meeting June – San Diego September – consider Europe.

IVI Foundation Meeting Minutes 5 September 10-14, 2001 4. Technical Committee

4.1 General Meeting Info: Date of Meeting: December 12, 2001 Location: Austin, Texas - Hyatt Chairperson: Scott Rust Minutes Prepared By: Dany Cheij

See General Attendance chart.

4.3 Topics To Be Discussed: - Introductions - Review Agenda - Review Voting Members In Attendance - Approve minutes from the Boston Technical Committee Meeting - IVI Working Groups - IVI Driver Architecture, Class Specifications, and Shared Components - Review the spec approval timeline document - Review John Harvey’s pert chart and conclusions from the Class Spec Review meeting - What work remains and what is our plan - Discuss motion from the Conformance WG - IVI-MSS - Review outcomes from last meeting - Progress to date - Discuss changes to plan - Consider establishing an appropriate board for review and maintenance of shared code - Discuss what work to pursue after this round of specifications - New class specs - Extensions to existing classes - New architectural work - New Business - Discuss agenda for March meeting, Ft. Collins, March 18 - 22 - Are the dates appropriate? Should it be earlier or later - Adjourn

4.4 Voting Members In Attendance

IVI Foundation Meeting Minutes 6 September 10-14, 2001 Company Voting Representative Agilent Technologies Joe Mueller BCO, Inc. Mel Petty Boeing Don Davis Keithley Instruments John Ryland National Instruments Jon Bellin Racal Instruments John Rosenwald Rohde & Schwarz Jochen Wolle Tektronix Badri Malynur Teradyne Andy Hutchinson The Mathworks Thomas Gaudette TYX Corp Ion Neag Vektrex Electronic Jeff Hulett

There are 12 voting members in attendance. Being more than 25% of the total voting membership (22 members), this satisfies the requirements for a quorum.

4.5 Approve minutes from the Boston Technical Committee Meeting No issues were brought up with the minutes. The TC chairman accepted the minutes.

4.6 IVI Working Groups

4.6.1 IVI Driver Architecture, Class Specifications, and Shared Components

4.6.1.1 Review the spec approval timeline document Architecture Specs: - SC3: John Harvey stated that there are tweaks needed to the spec that came out of the class review process. There is no need for handling nested repeated capabilities in this round of the spec. Steve Greer is responsible for making the changes. - Event server, floating point shared, and C shared components do not require any changes and are ready for vote. - IVI 3.2: minor tweaks needed. Noel Adorno is responsible for making the changes. - API Style: requires small tweaks to be made before the first vote, and will require more modifications after the first round of specs are voted on and approved. o Discussion ensued about the purpose of the Style guide, and whether driver developers should be required to read it before developing drivers. o Consensus is to leave the specification a little looser in some areas and add to it in later rounds of the specs. - MSS: not included in this round of specs. Will be discussed later in this meeting. - IVI 3.1 (minus installer portion): was posted through final review on Nov 29. When should the review period extend until? Four attendees have reviewed this spec. The group will discuss the spec later in the meeting.

IVI Foundation Meeting Minutes 7 September 10-14, 2001 - IVI 3.1 installer portion: not reviewed and not ready for review. - Config server: not reviewed and not ready for review. - IVI session factory: review period began on Dec 6 and will extend until Dec 28.

Class Specs: - Scope, Fgen, DMM, DC power, Switch: Should not have a formal second review, and any subsequent reviews should be restricted to the issues brought up in the first review. - Power Meter: minor changes made. Restricted review needs to occur. - Spectrum Analyzer: many aesthetic changes need to be made. Work divided up between Bankim Tejani, Neil Shah, and Anne Faveur. Needs second review. - Digital I/O: only two people commented on the spec. Teresa feels it needs a second review. - RF Signal Generator: Jochen received many comments from Agilent (2), and NI (2). Jochen can post a second voting candidate on 12/21/2001.

For all class specs, the class spec review meeting earlier in the week decided that all class specs except for the Spectrum Analyzer and Digital I/O can be ready for a second review by Dec 21. The group wants to follow this timeline:  Post specs on 12/21/2001  Review period until 1/21/2002  Two weeks to make changes and post updated spec (2/4/2002)  Voting period to be determined by the Technical Committee in conjunction with the rest of the specs.

The group discussed 2nd review periods for all architecture specs and discussed possible voting periods for all specs. One approach is to logically group specs together into logical voting periods. Another approach is to pre-determine several voting periods and vote on specs that are ready at that time. The second approach was chosen and three voting periods were determined: Feb 14 – Feb 20, Mar 14 – Mar 20, and the next IVI Foundation meeting. Summary table to be inserted in the minutes.

Needs 2nd Review 3rd Review Name Spec # Review Period Second Ready? Voting Period Period Period Review? Standard Cross Class Capabilities IVI- 3.3 July 9 - July 27 Rest Oct 15 - Nov 2 n Dec 21 - Jan 21 Feb 14 - Feb 20 Floating Point Shared Component IVI- 3.12 July 9 - July 27 No N/A Y Feb 14 - Feb 20 C Shared Components IVI- 3.9 July 9 - July 27 No N/A Y Feb 14 - Feb 20 Event Server IVI- 3.7 July 9 - July 27 No N/A Y Feb 14 - Feb 20 Inherent Capabilities IVI- 3.2 July 30 - Aug 17 Rest Feb 8 - Mar 1 n Mar 14 - Mar 20 Guidelines for API Style IVI- 3.4 Aug 20 - Sep 7 Yes Oct 15 - Nov 2 n Jan 10 - Feb 8 Feb 14 - Feb 20 Architecture Overview IVI- 3.1 Nov 29 - Dec 12 Rest Feb 8 - Mar 1 n Mar 14 - Mar 20 Installer Portion of 3.1 IVI- 3.1 Feb 8 - Mar 1 ? N Mar 14 - Mar 20 Configuration Server IVI- 3.5 Feb 8 - Mar 1 ? N Mar 14 - Mar 20 IVI Session Factory IVI- 3.6 Dec 6 - Dec 28 No N/A Y Mar 14 - Mar 20 IVI Glossary IVI- 5.0 Mar 10 - Mar 31 ? N Next Meeting Oscilloscope IVI- 4.1 July 9 - July 27 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20 Function Generator/ARB IVI- 4.3 July 9 - July 27 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20 Digital Multimeter IVI- 4.2 July 30 - Aug 17 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20

IVI Foundation Meeting Minutes 8 September 10-14, 2001 DC Power Supply IVI- 4.4 July 30 - Aug 17 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20 Switch/Matrix/Multiplexer IVI- 4.6 July 30 - Aug 17 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20 Power Meter IVI- 4.7 Oct 15 - Nov 2 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20 Spectrum Analyzer IVI- 4.8 Nov 13 - Dec 7 Yes Jan 10 - Feb 8 N Feb 14 - Feb 20 Digital I/O IVI- 4.9 Nov 26 - Dec 14 Yes Jan 10 - Feb 8 N Feb 14 - Feb 20 RF Signal Generator IVI- 4.10 Nov 21 - Dec 7 Rest Dec 21 - Jan 21 n Feb 14 - Feb 20

4.6.1.2 Review John Harvey’s pert chart and conclusions from the Class Spec Review meeting John Harvey discussed his proposed plan about what the IVI Foundation needs to provide once the specs are completed in order for people to be able to start creating IVI drivers. The steps required are:  Complete all class and architecture specs  Complete corresponding shared components  Create shared component installer o Completion of IVI legal framework for shared components o Availability of appropriate license agreement o Completion of appropriate logo for the installer

Jon Bellin made a comment that the actual shared components are also dependent on the legal framework because of source code review issues.

Scott Rust also noted that in the shared component lifecycle WG earlier in the week, there was talk that the shared components should also go through review and voting like the specs.

Joe Mueller pointed out that we should create the shared component installer and get it to members and customers while also creating a review board to evaluate and potentially fix bugs that arise in a pre-determined review period.

Jon Bellin said that there was a need for the legal work to be completed soon enough so that the source code review can be completed no later than the completion of the testing.

The group discussed the necessity for a review board to be formed to review the shared component binaries and source code and manage the process for testing and releasing the shared components and maintenance in the future. For this go around, this process can be started without the legal framework in place making the source code available to all members and not just the people on the review board.

The group discussed how to create the shared component management working group. The volunteers are:  Joe Mueller, Agilent  Rengan Rajendran, Vektrex  John Ryland, Keithley  Dave McKay, Racal  Glenn Burnside, NI

IVI Foundation Meeting Minutes 9 September 10-14, 2001  Tom Gaudette, Mathworks  Johannes Ganzert, Rohde & Schwarz

Rengan Rajendran from Vektrex volunteered to chair this WG if it is created.

John Harvey moves to create the shared component management working group with Rengan Rajendran from Vektrex as its chairperson and the working group is tasked with creating a charter and a schedule for shared component release plan by January 21st, 2002.

Jon Bellin seconds the motion. No discussion. Motion passed unanimously.

The legal working group needs to complete the legal work and create the IP policy and appropriate license agreements in time to be adopted by the BoD and the appropriate licenses signed and executed by the appropriate donators before the IVI shared components can be officially released.

4.6.1.3 What work remains and what is our plan This topic has already been covered.

4.6.2 Discuss motion from the Conformance WG Jeff Hulett summarized the work of the conformance WG and made the following motion…

We resolve that the IVI specifications that precede the completion of IVI-3.13 shall not include required testing and test plan documentation as part of IVI conformance requirements. When we add those requirements in the future we will include a grandfather clause that relieves existing IVI conformant drivers and minor revisions of those drivers of conforming to those new requirements.

The motion was approved unanimously.

4.6.3 IVI-MSS

4.6.3.1 Review outcomes from last meeting The following is from the September Technical Committee minutes:

Joe Mueller suggested that instead we work on a motion to direct the MSS working group to:  Bring the style of the document in line with the other documents  Add a compliance section in the document and expand other sections to have more information regarding compliance  Create a prototype of a simple MSS solution that everyone can review  Use the prototype to verify that the compliance is accurate and complete  Examining the COM requirements from the IVI-COM and config server specs for example of the kinds of requirements we might be missing  Investigate the C implementation of an MSS solution

IVI Foundation Meeting Minutes 10 September 10-14, 2001  Potentially inflammatory text about user implementation of MSS should be corrected

Joe Mueller moved that the MSS working group be directed to address and work on the above bulleted list. Gayle Matysek seconded motion. Motion was unanimously approved.

Roger Oblad is still the chair of the MSS working group. Jon Bellin and Dany Cheij (NI), Mel Petty (BCO), Kirk Fertitta (Pacific MindWorks), John Harvey (Agilent), Ion Neag (TYX), Teresa Lopes (Teradyne).

4.6.3.2 Review progress to date Joe Mueller summarized progress. Roger Oblad and Joe Mueller made a lot of progress on making grammatical and style updates to the spec but did not call any meetings or make any progress on the other commitments above because of work happening on other specs. Joe feels that with the aggressive schedule that we set for the other specs, he feels that maybe we should not tackle the work required for MSS until after the other work has been completed. Joe solicited input from the rest of the group.

Jon Bellin said that it may be better to wait until the 3.1 and config server conference calls are completed before scheduling a set for MSS. This would be around mid to late February of 2002.

Jon Bellin requested that once the work gets started, the group should stick to the plan and motion set forth in September.

4.7 Discuss what work to pursue after this round of specifications

4.7.1 New class specs & extensions to existing classes

The following is from straw poll regarding new class specifications that was conducted during the November 1999 General Membership meeting:

Identified but Not Started  Network Analyzer (10)  Bus Emulator (8)  Vector Signal Analyzer (8)  Logic Analyzer (5)  Simple Analog I/O (4)  Synchro/Resolvers (2)  Precision DAQs (1)  Noise Figure Meter (1)  Audio Analyzer (1)

IVI Foundation Meeting Minutes 11 September 10-14, 2001  Set Point Controller (0)  Voltage Comparator (0)  Time Stamp (0)

Joe Mueller asked whether the group is ready to start working on new classes before or at the next meeting.

Jochen Wolle also noted that we should poll users not present at this meeting about what classes they would like.

Jon Bellin also said that we should take into account whether someone is willing to take charge of leading a working group for a new class. Joe Mueller also added that the chairman should be willing and able to put in a lot of work into making sure the spec progresses.

Jeff Hulett wanted to point out that some of the simple instruments listed in the table are simple and common enough in test systems that even though they are not popular among this group, they should be considered to fill holes in the overall IVI coverage.

Scott Rust opened the floor for nominations:  John Ryland nominated Scanning DMM, Counter/Timer, and AC power supply

Nominations at this meeting Scanning DMM () John Ryland Universal Counter / Counter-Timer () John Ryland AC Power () John Ryland Phase II of Digital I/O (xtns for vltg levels and timing) Teresa Lopes Generic Bus Controller (e.g., 1553, RS232, etc.) () Steve Wegener Network Analyzer () Jon Bellin Bus Emulator () Jon Bellin Vector Signal Analyzer () Jon Bellin Logic Analyzer () Jon Bellin Simple Analog I/O () Jeff Hulett, Jon Bellin Synchro/Resolvers () Jon Bellin Precision DAQs () Jon Bellin Noise Figure Meter () Jon Bellin Audio Analyzer () Jon Bellin Set Point Controller ()Jon Bellin Voltage Comparator ()Jon Bellin Time Stamp () Jon Bellin

Joe Mueller made the observation that from an Agilent standpoint, he would feel uncomfortable asking instrument divisions within Agilent to make a commitment to creating new instrument specs, before the current specs are completed and there are drivers and products on the market.

IVI Foundation Meeting Minutes 12 September 10-14, 2001 Jochen Wolle observed that he also thinks that once we have the current specs completed, customer input would drive us to extend existing classes to satisfy customer demand.

Scott Rust asked if anyone in the room would volunteer to put the required energy to lead one of these working groups within the next 6 months. John Ryland said that Keithley would be willing to chair the Universal Counter and Scanning DMM but not in the next 6 months. Jochen suggested that we poll users as to what their preferences are and whether they are willing to participate in the groups.

Jon Bellin moves to stop this discussion and postpone until the next meeting.

Seconded by Tom Gaudette. Motion approved 10-0-0.

4.7.2 New architectural work Jon Bellin wanted to discuss architectural work. John Harvey suggested that resource locking would be a possibility, although he would like to postpone it at least until the next meeting.

Jon Bellin asked whether the Foundation should define an approach to support .NET languages. Jon suggested that we have a slot at the next meeting where members can come prepared to discuss how to handle .NET. Joe Mueller and John Harvey thought it was a great idea. Everyone else agreed that it was a great idea.

Joe Mueller moves that the TC chair adds this to the agenda. Jon Bellin seconds the motion. The motion was approved unanimously.

Jon Bellin volunteered to lead the discussion.

4.8 New Business No new business to discuss.

4.9 Discuss agenda for March meeting, Ft. Collins, March 18 - 22 - Are the dates appropriate? Should it be earlier or later? Discuss the sessions required before determining these questions.

Agenda for the next Meeting should have the following WG meetings:  .NET ½ day (Track 1)  MSS ½ day (Track 1)  Legal & Shared Components ½ day (Track 2)  Interoperability/Developers forum 1 day (Track 1)  Conformance Group ½ day (Track 2)  Board of Directors ¼ day (Track 1-2)  Technical Committee ½ day (Track 1-2)  Marketing Committee ¾ day (Track 2)  Signals WG 1 day (Track 2)  Users Committee ?? ½ day (Track 2)

IVI Foundation Meeting Minutes 13 September 10-14, 2001  Annual Meeting 1 hour (Track 1-2)

Considering the above schedule, when is an appropriate time for this meeting. Should it be postponed for a month? April 15 or April 22 are Mondays. Does April 22nd work for everyone? The group decided that the next meeting will be in Fort Collins, hosted by Agilent and that everyone should reserve Monday through Thursday of the week of April 22nd for this meeting.

Vektrex would be happy to host the next meeting after this in San Diego. Jeff Hulett noted that depending on the timing, hotel pricing may be expensive. Jeff will look into some possibilities. The meeting should occur at the end of July/beginning of August. Tentatively schedule the meeting the week of July 22nd. If this seems unlikely, this meeting can be canceled and we can hold the next meeting in October and only have 2 meetings in 2002.

4.10 Adjourn Meeting was adjourned

IVI Foundation Meeting Minutes 14 September 10-14, 2001 5. Configuration Server Working Group

5.1 General Meeting Info: Date of Meeting: September 11, 2001 Location: Boston, MA – Teradyne Facility Chairperson: John Harvey Minutes Prepared By: John Harvey

5.2 Meeting Attendees: Name Company Phone Email Qi Gao Agilent 707-5772152 [email protected] John Harvey Agilent Technologies (970) 679-3535 [email protected] Stephen Greer Agilent Technologies 970 679-3474 [email protected] Jon Bellin National Instruments 512-683-5516 [email protected] Zulfiqar Haider National Instruments 512-683-8374 [email protected] Kirk Fertitta Pacific MindWorks (858) 587-8876 [email protected] Johannes Ganzert Rohde & Schwarz +49 89 / 4129 - 13405 [email protected] schwarz.com Badri Malynur Tektronix, Inc. 503 627-5880 [email protected] Teresa P Lopes Teradyne 978-370-1377 [email protected] David G McKay Thales Instruments +44 1202 872800 [email protected] (aka Racal) Melissa Pike The MathWorks, Inc 508-647-7493 [email protected] Rengan Rajendran Vektrex 858.558.8282 x20 [email protected] John Ryland Keithley 440-498-3134 [email protected]

5.3 Topics To Be Discussed: Introductions 9:00-9:10 Progress 9:10-9:20 UML Changes 9:20-9:40 Demo 9:40-10:10 Break 10:10-10:20 Document Review 10:20-5:00 Future Plans 5:00-5:30

John Harvey reviewed progress on the specification and the tools. Both are essentially complete, with some work to be done on error reporting.

John Harvey reviewed changes to the UML diagram. We need to add description to Logical Name.

IVI Foundation Meeting Minutes 15 September 10-14, 2001 Qi Gao gave a demonstration of iteration 6 of the Configuration Server. She has CDs for those interested. She will release a new version to the web with changes from this WG meeting ASAP after the meeting (ASAP depends on how many changes we have). Error reporting from the XML schema does not give full description of problem needed to find and fix problems. Error checking from Config server will be one at a time. We will use parser messages as is (no other choice) Use COM error object. More error info is better than less (object name & class, missing/invalid values, etc.)

Qi also reviewed details of XML and demo code. XML parser install needs to be part of the shared component installation. Teresa Lopes has experience with installing XML ver. 3

Jon Bellin would like to see a benchmark plan to evaluate performance and how that scales with XML file size and number of objects. Perhaps one test of 1-2 drivers and one with ~100 drivers and more complex data components. Focus on benchmarking deserialization.

Kirk mentioned memory footprint when using the XML parser was very high for a 2 Mb file. We should also look at this for an IVI Configuration Store file.

Review of document Glossary entry for configuration classes Don’t capitalize configuration store, shared components. Do capitalize Configuration Server. What is the use model for current configuration store – does every driver have to deserialize it each time Initialize is executed, and if so, what is the performance impact? For now we will do it as described in the spec, but we need to benchmark.

Action Items

Modify Configuration Server error handling to use COM errors and use expanded error messages. (Qi) Performance and memory benchmarks. (Qi or John or whoever gets to it first) Add packaging info to installation section. (John) Refer to “full pathname” when describing file location in the file system. (John) 3.2 – make sure that the Initialize function (or other functions that access the configuration server) returns an error if the configuration server deserialize fails. Also document the order in which the software module tries to open the current and master configuration stores (talk to Glenn B.) (John) Standardize the format for section references. (John) Test the behavior of deleting and re-adding a software module – do sessions stay connected? (Qi) Be consistent in use of English names for syntactical elements. (John) Call class drivers IVI class drivers – and don’t capitalize class or driver. (John) Examine what info from this spec goes into 3.1 or 3.4 (r.e. installation, repeated capabilities, etc.) (Noel & Steve consulting w/ John)

IVI Foundation Meeting Minutes 16 September 10-14, 2001 5.5 Config Server Notes From 9/13/01

1) Add packaging info in config server spec. But, what goes into IVI 3.1 vs. config server spec? 2) Entries that need to be added by driver installers to config store when they install a driver? General info currently in config server spec. But what needs to be transferred over to the IVI 3.1 spec? 3) Repeated capabilities needed to be added to 3.4 and 3.1. 4) IVI 3.2 initialize() requirements for opening the config store.

1) The WG needs to identify the packaging of the master config store. 2) The overall design of the config store agreed upon, so need to get to specifics. J. Harvey volunteered to create the specifications for driver installation to go into IVI 3.1. J.Harvey will put it into the context of the classes used within the Config Server specification. 3) J. Harvey will also provide IVI-COM registry entries for IVI-COM drivers. Then include into IVI 3.1 – installation section. 4) John & Jon will work on getting the repeated capabilities right. John Harvey and Steve Greer will work on IVI 3.4 material. 5) Need app note & code snippets for what you do during initalize with the config server. Also need code snippets for a driver installer to use for accessing the config server.

IVI Foundation Meeting Minutes 17 September 10-14, 2001 6. Conformance Working Group

6.1 General Meeting Info: Date of Meeting: Tuesday December 11, 2001, 9:00am CST, 3.5 hours Location: Hyatt, Austin, TX Chairperson: Jeff Hulett Minutes Prepared By: Joe Mueller

Attended First Last Company Phone Email Noel Adorno National Instruments (512) 683-5071 [email protected] X Fred Bode Bode Enterprises (619) 697-8790 [email protected] X Glenn Burnside National Instruments (512) 683-5472 [email protected] X Dany Cheij National Instruments (512) 683-8374 [email protected] Don Davis Boeing (314) 234-2722 [email protected] Kirk Fertitta Pacifc MindWorks (858) 587-8876 [email protected] Steve Greer Agilent Technologies (970) 679-3474 [email protected] X Tom Gaudette Mathworks X Kavch Ghadianipour National Instruments X Chris Gorrenge Racal Instruments Zulfigar Haider National Instruments (512) 683-8374 [email protected] John Harvey Agilent Technologies (970) 679-3535 [email protected] Dennis Hecht Boeing (314) 233-0194 X Andy Hutchenson Teradyne X Jeff Hulett Vektrex (858) 558-8282 [email protected] Patrick Johnson Racal ATE (210) 828-5743 [email protected] X Badri Malynur Tektronix (503) 627-5880 [email protected] Gayle Matysek Northrop Grumman (410) 765-9754 [email protected] X Joe Mueller Agilent Technologies (970) 679-3248 [email protected] Vesna Mutevelic National Instruments Roger Oblad Agilent Technologies (707) 577-3466 [email protected] Dave Ptacek Rockwell Collins (319) 295-0198 [email protected] X John Rosenwald National Instruments X Scott Rust National Instruments (512) 683-5680 [email protected] X John Ryland Keithley Kristin Stewart Vektrex (858) 558-8282 [email protected] X Bankim Tejani National Instruments (503) 683-5323 [email protected] Steve Wegener Boeing (314) 234-3801 [email protected] X Jochen Wolle Rohde & Schwarz 49 89 41 29-13044 [email protected] X Hob Wubbena Agilent

IVI Foundation Meeting Minutes 18 September 10-14, 2001 6.3 Agenda:

Introduce everyone; recap progress from last meeting (20 min) Discuss 1st round driver conformance (40 min) Break (20 min) Discuss grandfather clause for existing drivers (40 min) Review next version of specification (60 min) Action item review & wrap-up (10 min)

6.4.1 Overview of key decisions

 Outside testing beyond our means  No foundation-owned tools or test suites  The first round of drviers will be released without conformance spec in place.  IVI Brand is the reward for Conformance.  IVI Will require tests for cut&dry things  Require test plan for everything else

The last two points were our conclusions from the last meeting. Note that we have not generated the requirements surrounding the test plan.

6.4.2 Driver conformance specification

Joe presented the following:

The IVI specifications define three types of compliance, they are:

- IVI Class Compliance - IVI-COM Architecture Compliance - IVI-C Architecture Compliance

A driver is IVI-C Architecture compliant if  it conforms to all of the requirements set forth in IVI-3.1 section 5, except for 5.14 (note or appropriate section)  the vendor assures that required testing has been done per ABC.1  The vendor provides a test plan per ABC.2 IVI-C Architecture compliant drivers are allowed to use the IVI trademarked logo XYZZY.

A driver is IVI-COM Architecture compliant if:  it conforms to all of the requirements set forth in IVI-3.1 section 5, except for 5.13 (or appropriate section)

IVI Foundation Meeting Minutes 19 September 10-14, 2001  the vendor assures that required testing has been done per ABC.1  The vendor provides a test plan per ABC.2 IVI-COM Architecture compliant drivers are allowed to use the IVI trademarked logo XYZZY.

A driver is IVI Class compliant if it conforms to all of the requirements set forth in an IVI Class specification and it is either IVI-COM Architecture compliant or IVI-C Architecture compliant. IVI Class drivers, and only IVI Class drivers are allowed to use the IVI trademarked logo XYZZY.

Discussion:

- Marketing committee thinks there should be a single logo, so the conformance criteria above needs to point only to a single logo. - It is not clear if this material should go into IVI 3.1 or the conformance document (3.13). Alternatives o Put prose along the above lines into 3.1 o Go ahead and create a conformance spec

- Need a way to allow drivers to ship with logo and claims of conformance before the completion of the conformance specification (at this point this just means adding required testing).

We can handle this by either leaving the test requirements out of conformance or by putting in a place holder for the incomplete specifications, regardless we will not have the testing requirements in time to include them in the first round of specifications.

6.4.3 Report regarding adding an appropriate “Grandfather clause”

Scott presented the following:

Justifications:  It is likely that approval of the final Conformance specification will occur after the approval of the IVI driver architecture specifications and class specifications.  It is likely (and desirable) that IVI drivers will exist from multiple vendors prior to the approval of the Conformance specification. These drivers must follow the rules in the IVI architecture specification and the appropriate class specification.  It will not be possible for the suppliers of these initial IVI drivers to predict the requirements of the final Conformance specification.  We need a mechanism or policy that allows the suppliers of these early IVI drivers to continue to claim compliance and use the IVI Logo after the Conformance specification has been approved.

IVI Foundation Meeting Minutes 20 September 10-14, 2001 Options:  Grandfather Clause: Allow suppliers of IVI drivers that are released after the approval of the IVI Architecture and Class specifications but prior to the approval to the Conformance specification to continue using the IVI logo and claiming IVI compliance after the Conformance specification is approved.  Grace Period: Give the driver suppliers a reasonable grace period (1 year?) after the approval of the Conformance specification. o During the grace period, the driver suppliers can continue to claim IVI compliance and use the IVI logo. o At the conclusion of the grace period, the supplier can continue to claim compliance and use the IVI logo only if they have followed the rules in the Compliance specification.

Discussion: based on the above definition, do we want a ‘grandfather clause’ or the ‘grace period’?

After some discussion, group concluded they would prefer a grandfather clause that extends to minor driver revisions as well as original code. (use the definition of minor revision per the 3.1/3.2 definitions used for driver revision number).

After some more discussion concluded that the form in which to capture this in the first round of specs: 1. The specs will have logo requirements as outlined above, but without any reference to required testing or other conformance driven requirements. 2. We will update the specifications when the conformance work is complete to reflect the new requirements and include the grandfather clause. 3. We will pass a resolution in the context of the first round of specifications in the technical committee indicating our intent to establish required testing and include a grandfather clause as outlined above.

Outstanding issues:

1. Where do we put the prose for the first round of specifications? 2. What is the prose for the first round specifications? 3. How do we designate the IVI-C Class drivers (that is, what is the logo usage)? 4. Can the logo be used in any other ways, for instance for containers for drivers. 5. Review the prose 6. Create resolution to be passed to the technical committee

6.4.4 Where do we put the prose for the first round of specifications? Discuss with 3.1 working group.

6.4.5 What is the prose for the first round specifications?

IVI Foundation Meeting Minutes 21 September 10-14, 2001 We will request the 3.1 group add the following prose at an appropriate location:

An IVI driver is IVI conformant if it complies with the requirements set forth in section 5, Conformance Requirements. Only IVI conformant drivers are allowed to use the IVI Conformance logo. The IVI Conformance logo is a trademark of the IVI Foundation.

Note, we think that 1.4.1 should be promoted to 1.5. Should include in this overview paragraph that the use of the logo is defined in section 5.

6.4.6 Create resolution to be passed to the technical committee

The conformance committee will unanimously make the following resolution to the technical committee:

We resolve to release a set of specifications that does not include required testing and test plan documentation as a part of IVI conformance requirements. When we add those requirements in the future we will include a grandfather clause that relieves existing IVI conformant drivers and minor revisions of those drivers of conforming to those new requirements.

6.4.7 Can the logo be used in any other ways, for instance for things that use drivers

We feel that the “conformant” logo should only be used to designate a product (“driver”) that complies with IVI 3.1 section 5 (per our earlier discussion).

Could create another logo that could be used generally to indicate a product that in some way “works with IVI”. For instance a development environment that has tools for working with IVI.

Suggest that the marketing committee look into: - Establishing a “conformance logo” to be used as described in this meeting - Look into a “work with IVI logo” that could be used generally. This might be the same as the “I’m a member of IVI” logo. - Dany will check into trademark issues, especially trademark registration.

IVI Foundation Meeting Minutes 22 September 10-14, 2001 6.5 Action Items:

Who What By Status Jeff Hulett Take motion to Technical committee December 12 Done Jeff Hulett Request changes for IVI 3.1 December 11 Done Dany Cheij Take issue of logo use for IVI enabled December 12 Done products to marketing comitttee Dany Cheij Check into trademark issues By next meeting

IVI Foundation Meeting Minutes 23 September 10-14, 2001 7. Signal Interface Working Group

7.1 General Meeting Info: Date of Meeting: December 13, 2001 Location: Austin, TX Chairperson: Ion Neag Minutes Prepared By: George Geathers, Ion Neag

Name Company Phone Email Bankim Tejani NI [email protected] Chris Gorringe Racal Instruments [email protected] Don Davis Boeing [email protected] George Geathers TYX [email protected] Glenn Burnside NI [email protected] Ion Neag TYX Corporation [email protected] Jeff Hulett Vektrex [email protected] Jochen Wolle Rhode & [email protected] Schwarz Mel Petty BCO [email protected] Noel Adorno NI [email protected] Steve Wegener Boeing [email protected] Teresa Lopes Teradyne [email protected] Thomas Gaudette Mathworks [email protected] Zulfiqar Haider NI [email protected]

7.3 Topics To Be Discussed: 1. discussion on standardization scope: including signal type definitions in the standard 2. review of design Iteration 2, based on the new version of the Design Document 3. discussion on terminology: parameters vs. attributes (overflow from Iteration 1)

IVI Foundation Meeting Minutes 24 September 10-14, 2001 7.4 Record of Discussions: The discussion with a review of the iterative development process for the Signal Interface spec. The following 4 iterations are considered:  1st Iteration – Design principles for control interface.  2nd Iteration – Design principles for resource model  3rd Iteration – Revisit design in context of Bus Testing and Digital Testing  4th Iteration - Finalize the IDL

The current development stage is review of Iteration 2.

A comprehensive design review for Iteration 1 occurred over the phone with an Agilent team since the September meeting.

The discussion continues with Item 1 of the agenda: standardization scope. Ion introduced the question: Should the standard include definitions for signal types? Previous proposals by TYX relied on definitions provided by ATLAS 95 or ATLAS2K. Recent discussions in the IEEE SCC20 committee indicate that the first version of the ATLAS2K standard to be released will not include definitions for signal types (except for basic signals types, which are insufficient for practical applications). On the other hand, the design work performed until now for Iterations 1 and 2 indicate that additional data must be provided by signal type definitions, besides what is specified in ATLAS 95. These data would be provided in a section/annex of the SI standard. Given the above, Ion expresses the opinion that it may be worthwhile considering the inclusion of complete signal type definitions in the SI standard. Such definitions would be provided only for domain-independent electrical signals and would be obtained by simplifying ATLAS95 definitions.

Questions from Don Davis and Mel Petty. Comments from Chris Gorringe – signal type definitions will be provided in an ATLAS2K Annex. Ion recalls a different outcome of SCC20 discussions.

Action item (Ion): check availability of signal type definitions in ATLAS2K. Assess timeframe necessary to create signal type definitions vs, referencing external documents.

Next discussion topic refers to specifying signal type information (signal type, signal parameter) in control interfaces and the resource model. Ion describes the two approaches currently identified: identify signal types and parameters string names or via enums.

The next discussion topic refers to the need and benefits of defining of a C interface, complementary to the COM interface. Glen Burnside made comment that Technical Committee would like for all MSS Specs to support both COM and C interface. He stated that this is the normal practice within the IVI Foundation.

Discussion continues with review of design principles in Iteration 2, based on slide presentation given by Ion.

IVI Foundation Meeting Minutes 25 September 10-14, 2001 Discussion on integration of Signal Drivers in the IVI Architecture. Usage of Configuration Store in different application scenarios. Usage of IVI Instrument Drivers from Signal Drivers.

Discussion of interface type for resource data. Alternatives: (1) COM/C API, Used to retrieve programmatically information on capabilities; (2) modeling language, may be XML-based; (3) no special API; use the IVI Configuration Server API to retrieve programmatically information on capabilities. Clarification provided by Glenn about the resource model being a “meta representation” of capability information.

Discussion on usage of resource information. Glen and other point out that the SI spec should not specify the behavior of resource allocators using resource information. Ion indicates that the design document describes a possible behavior of a resource allocator in order to identify use cases for the resource information. Decision: the final specification should not specify the behavior of resource allocators.

Description on the semantics of resolution/precision information not being specified. Ion presents a possible interpretation. Several use cases are discussed. Idea: use special floating point values such as Inf and NaN to describe special cases like “unspecified resolution” or “continuous resolution”. Action item: rework the topic of resolution/precision semantics, including use cases; investigate the use of Inf/NaN.

Discussion on supporting multiple units for signal parameters. Ion makes the point that unit conversions represent a generic task and implementing it in each Signal Driver in ineffective. Implementing this functionality in the upper level of the architecture (Signal Library) is preferable. Decision: support only default units for signal parameters.

Discussion on supporting multiple dimensions for signal parameters. Example: W and dB for Power. Alternatives presented by Ion. Pros and cons discussed. Outcome of discussions: using units to indicate the dimension is the preferable approach.

Action item: review of design iteration 2 to be continued between meetings via phone/web.

IVI Foundation Meeting Minutes 26 September 10-14, 2001 8. Legal/Shared Components Working Group

8.1 General Meeting Info: Date of Meeting: December 10, 2001 Location: Austin, TX Chairperson: John Rosenwald for Pat Johnson Minutes Prepared By: John Rosenwald

Name Company Phone Email John Rosenwald Racal Instruments 210-699-6799 x 212 [email protected] Joe Mueller Agilent Technologies Hob Wubbena Agilent Technologies Dany Cheij National Instruments Scott Rust National Instruments Jeff Hulett Vektrex Jochen Wolle Rhode Schwartz Badri Malyur Tektronix Andy Hutchinson Teradyne

8.3 Topics To Be Discussed: Intellectual Property Policy Shared Components Management

8.4 Record of Discussions: Legal and Shared Components Subcommittee, 10 Dec 01.

Attendees:

John Rosenwald, Racal Instruments Joe Mueller, Agilent Tech Hob Wubbena, Agilent Tech Dany Cheij, NI Scott Rust, NI Jeff Hulett, Vektrex Fred Bode, IVI Jochen Wolle, Rhode Schwartz Badri Malyur, Tektronix Andy Hutchinson Teradyne

IVI Foundation Meeting Minutes 27 September 10-14, 2001 8.5 1. Legal Meeting - Primary discussions were associated with the Intellectual Property Policy.

DECISION: The committee decided that the two existing documents presented were both close to what we wanted the policy to govern, except for the items mentioned below. The decision was to arrange a conference call among the corporate lawyers that have concerns and have them resolve the remaining concerns over the text of the policy.

ACTION: Dany Cheij will moderate a teleconference at 10:00AM Tuesday 18 Dec or Wed. 19 Dec. The conference call number is: 816-650-0641 Pin#24345.

ACTION: If a member company attorney wants to be involved, notify Dany and he will contact you with the final date and time of the conference call. Initial confirmed attendees:

Agilent National Instruments Others.

Points for clarification to be discussed on the teleconference with the lawyers:

1. When is IP actually disclosed (at which vote for 1.1.2) and become owned by the foundation? We recommend…at the time of Technical Committee Vote.

1.1.2a Does this apply to all members and what is the provision for voting on the solution actually mean (what do you have to do to NOT vote). Can a member get exception from this clause.

2. Once an IP licensing fee is requested for the first time, will any other property be submitted without fee agreements? This could result in a large request for fees, resulting in a risk that all future IP will have a fee associated with it usage, undermining the intent of the foundation to offer useful technologies to the test community. An additional concern was raised to whether there can be retroactive fees charged? Can this option actually be eliminated to avoid this?

3. Capture the minimum language that would be included users licenses. A standard “non-compensation” license agreement should be drafted to accompany the final IP policy and submitted at the time the IP Policy will be approved by the BoD. This should be formatted as a separate license agreement will be generated and signed for each IP submission. It should address issues of membership resignation or foundation dissolving. The committee recommends that all licenses should remain in place through as long as the IP is essential to the foundation.

4. What happens to shared components that are initially submitted to the foundation for review by the foundation? - This code is conditionally submitted, and if it is NOT accepted by the foundation for whatever reason, the IP to revert back to the original author.

5. ACTION: Fred research the copyright text that will be included within the specification and make it available for the legal group teleconference scheduled for 18-19 Dec. This text, once approved will be included in all specifications and match with the Spec source code appendices (IDL & C Include).

Other non-lawyer discussion associated with IP Policy.

DECISION: The committee should draft an expected behavior of IVI members. This document will establish certain good faith behavior that associated with identifying intellectual property that is brought to a working group and is freely submitted at the time of discussion.

ACTION: The committee needs a volunteer to draft the outline of this policy.

IVI Foundation Meeting Minutes 28 September 10-14, 2001 Summary Points of IP Coarse Alignment general notes:

Come to a quick conclusion so that we can move forward and resolve specific existing IP issues with the parties involved.

IP policy is agreed upon at the time that member joins the foundation, not at the time a specification vote takes place. Is there disincentive to voting? Is working on the subcommittee implying agreement to release IP? IP Policy submission is binding for all time, even after resignation from the foundation. Is IP required for the implementation of the standard? Is voting abstention count as a vote? Voting on a specification does not imply agreement with IP policy. New membership agreement after IP Policy is defined.

A shorter license agreement to be included with IVI property when provided to end-users. Essential IVI IP license statement that can be added to a standard corporate agreement. What are the statements? Do IVI components need their own license “click”? Developers license agreement statement. Users license agreement statement.

IP, when submitted, will be accompanied with an actual license agreement. The language of this agreement must be developed. General notes

IVI Foundation Meeting Minutes 29 September 10-14, 2001 9. Shared Components Discussion

The group reviewed the meeting notes from the June meeting, summarized and provided answers and decisions to the outstanding questions as documented below:

Questions from June/Comments and Decisions from Dec:

How will IVI Foundation make shared components available to the public? - We will not generally provide components directly to the public, but it will be available to the members and the public, as required via the IVI website. When required by the public, on the binaries/executables will be directly available to non-members.

What costs will be associated with accessing the components? - No cost other than membership.

Will the foundation keep previous versions on the web (at least 3)? - Yes, and these will be complete software packages only. Versions beyond the latest three will be maintained off-line.

What does this imply for support and/or availability of install? - Installs will be available and the general consensus was that the conformance testing, the Technical committee reviews of the shared components will minimize the need for the support. This is very hopeful, but in lieu of writing an extensive policy at this time, the group decided to table this issue to collect data.

Referencing the DoD’s need for source code, the foundation will consider selling source code at the time where we have a customer whom cannot become a Foundation member. - This is a non-issue at this point, but can be re- addressed with a real test case.

How are bugs fixed?

Consensus from the June meeting:

The Foundation will establish a web site for bug reporting. The web site will allow members and non-members to post trouble reports. All trouble reports will be reviewed by the Technical Committee for assignment to a working group to address. The web site will contain a list of all reported bugs, a revision history, and a list of outstanding issues with the shared components.

Non-members may not modify shared component code. Members may modify source code. To maintain compliance with the Foundation, a member must submit the changes for evaluation and approval/disapproval of the Foundation Technical Committee. A Framework for change submittal will be established to accommodate this.

The Foundation will maintain a formal change board for the purpose of fixing problems or making enhancements to the shared components. The change board will be maintained indefinitely at the discretion of the Foundation Board of Directors.

To avoid creating more infrastructure, the June session decided the technical committee should manage and control shared components with the same process used for specifications.

ACTION: The public software error reporting process needs to be developed and implemented to facilitate the change process. This will involve some website development.

June discussion seems to support Foundation test suites – this does not seem possible at this time because of the need for working group personnel time and potential cost associated with s/w tools required.

What is the formal foundation verification test? - There will be no formal verification policy at this time.

IVI Foundation Meeting Minutes 30 September 10-14, 2001 We presumably need a support policy. - The December session decision tabled the need for a support policy at this time and will revisit this as data is collected about the reliability of the components released.

Consensus from June meeting:

The Foundation will not worry about people trying to “sell” shared components, stand-alone or as part of other products. Although the foundation will make the components freely available (which will presumably make it difficult to sell them).

A member vendor must provide the Foundation with any modifications or enhancements made to shared components for Foundation approval before they are disseminated as part of a complete IVI Foundation compliant solution. Such modifications or enhancements must pass a Foundation verification test and be approved before the vendor may disseminate them as an IVI approved solution.

Summary of December discussions:

ISSUE: Common/Shared component version control and accessed/distributed.

DECISION: The Technical Committee will manage the shared components with the same process as the IVI specifications.

ACTION: Fred and Dany will establish the file and page structure of download page with appropriate deliverables. The initial sections will be: Create the following sections: Source Code - Password protected Binary Files - Open access Installer for Shared Components - Open access Other shared objects (type libraries, etc) - Open access

ACTION: Implement a password protection for access control. Dany and Fred will set up the password protection on the website.

QUESTION: Since the configuration and version control is not automated, the Technical Committee will roll the version numbers of Shared Components.

DECISION: The Technical Committee will maintain control of the shared components. The TC will have approval authority for any changes to the shared components, this means that any changes requires a vote from the TC. This decision could be a temporary measure. After a one year trial period and based on the workload generated from this activity, the process can be changed at a later date.

DECISION: IVI foundation will only maintain complete code releases. Releasable packages will be delivered to Fred for website publication.

DECISION: Table the writing of a support policy for one year to gather data on the real need for such a policy. Conformance verification specs and installers are suspected as being solutions to most of the potential issues. And of COURSE the code suppliers will address any bugs in a timely manner.

Pat, there was a legal question as to the licensing of MS XML 4.0 component to be freely distributed with our shared components.

IVI Foundation Meeting Minutes 31 September 10-14, 2001 10. Discussion of Spec Release Meeting

10.1 General Meeting Info: Date of Meeting: December 11, 2001 Location: Austin TX Chairperson: John Harvey Minutes Prepared By: Jeff Hulett/Rengan Rajendran

For attendance, see overall attendance list.

10.3 Topics To Be Discussed:  Category Ids  Outstanding issues  Overall progress for voting

10.4.1 Category Ids

John has added text to every class spec recording the Category ID.

John proposed that Category Ids be required of all IVI-COM drivers.

There were some questions about the fact that the same information can be in the Config Store, but it is not required.

Another issue raised about whether the same information should be available for IVI-C drivers and that all information should be in Config Store.

Decision: Revisit the issue with the Config Server discussion and require that the information be a requirement in the Config Store. The Cat Ids will still be a requirement for IVI-COM drivers.

John is sending out a document with all the Category Ids for the different classes and the spec owners will need to update the spec. A poll was conducted to make sure that a representative from each of the specs is in attendance.

Note: Steve needs to update the style guide for Category Ids

IVI Foundation Meeting Minutes 32 September 10-14, 2001 10.4.2 Other outstanding issues Comments from Serge on IVISwtch spec that might affect all specs – There was a discussion about the meaning of the word implement in the spec – whether it is ambiguous in the spec. A suggestion was made that there be some information added about how specs need to be interpreted. The decision was made to remove the ambiguity in the switch spec by removing the reference to IVI-C.

Switch spec 4.3.1 (compliance notes section) – item 3, term recommended change to shall? Serge said the justification is because of COM wrappers. There was a discussion on what was agreed to in the Boston meeting. There was a discussion about extensions to a class and where enum values need to start. Serge explained how he modified the Scope spec, Bankin explained how he did the SpecAn spec.

Decision: Make the following change to the specifications:

If an IVI-COM specific driver implements this attribute with additional elements in its instrument specific interfaces, the actual values of the additional elements shall be greater than or equal to …

Ian brought up an issue with 4.2 – attribute hierarchy was indicated as IVI-C only. Should the reference to IVI-C be removed? There was a discussion about deleting all the references to attribute hierarchies.

Decision: Delete for each capability group the reference to hierarchy in attributes, introductory section, and function introductory sections.

Serge brought up an issue with the name parameter in the Item repeated capability property. In some prototypes the parameter is listed as name, some list them as capabilityName, … There is an inconsistency in the specs. Noel brought up that it would take a lot of time to fix the issue.

Decision: In repeated capability definitions in section 2, delete the paragraphs that specify the names of methods, properties, and parameters.

Jochen brought up that in the API style guide that name (GetChannelName) is listed as a method and should be a property.

Decision: Move the equivalent of the COM prototype into the properties/attributes section. Issue: This needs to be changed for the SC3 spec and style guide

Noel stated there are issues with consistency in the style guide. Naming of interface reference properties in some specs does not match the rules in the API Style guide. John updated the style guide to allow for more flexibility in the naming. Section 4.6.1 – Naming of functions that have arrays. The specs need to follow the style guide. Section 8 – Timeout parameters. The specs need to follow the style guide.

IVI Foundation Meeting Minutes 33 September 10-14, 2001 10.4.3 Overall progress for voting Changes need to be made as a result of discussions during this meeting.

IviFgen – ready by 12/21 IviDMM – ready by 12/21 IVI 3.2 – ready by 12/21 IviPwrMeter – ready by 12/21 (second voting candidate) IviRfSigGen – ready by 12/21 (second voting candidate) IviSwtch – ready by 12/21 would help if SC3 spec is updated asap IviDigital – ready by 12/21 ?? Noel expressed concern over the amount of changes and the amount of review of the digital spec. Teresa stated that most of the changes were in the descriptions and not the API. IviSpecAn – ready by 1/10/2002 There are issues with markers. John expressed concern that the date is aggressive. IviScope – ready by 12/21 (second voting candidate)

John presented a pert chart with schedules for the different specs. The chart will be reviewed in the technical committee.

Issue was brought up that the supporting specs needs to be done before the class specs can be completed (e.g. 3.1, 3.2, SC3, API Style).

Issue with the number of specs that are being completed at the same time and availability of resources to review the specs.

Noel recommended that the spec owners thoroughly review the documents (especially new class specs). John pointed out that all the specs have gone through an initial release candidate / review process. John stressed the importance of getting the interfaces right.

Does there need to be a review period before the voting period? Plan: Post 3.2 and all the class specs except SpecAn and Digital by 12/21 and have a review period until 1/21. Two weeks to post an update. Assume a one-month review period for Digital and SpecAn after they are posted. The voting period will be discussed in the TC meeting.

IVI Foundation Meeting Minutes 34 September 10-14, 2001 11. Driver Architecture Working Group

11.1 General Meeting Info: Date of Meeting: December 11, 2001 Location: Austin, TX Chairperson: Noël Adorno Minutes Prepared By: Noël Adorno

Name Company Email Zulfiqar Haider National Instruments [email protected] Teresa Lopes Teradyne [email protected] Rengan Rajendran Vektrex [email protected] Badri Malynur Tektronix Keith Rule Tektronix Johannes Ganzert Rohde&Schwarz [email protected] John Harvey Agilent [email protected] Jon Bellin National Instruments [email protected] Noel Adorno National Instruments [email protected]

11.3 Topics To Be Discussed:

1) Review WG actions since Boston meeting 1. Posted Boston minutes in September 2. Conference call 10/11/01. Reviewed IVI 3.1 3. Conference call 11/8/01. Reviewed IVI 3.1 (main doc; emphasis on repeated capabilities) 4. Conference call 11/29/01. Reviewed IVI 3.1 (main doc; emphasis on repeated capabilities) 5. Posted IVI 3.1 (non installation sections) ver 1.0a on 12/6/01 for final review. 2) Review installer draft specification. 1. Review changed items. 2. Continue review from section 1.4 3) Discuss following open issues (see highlighted sections; items from installer interoperability session). 4) New open issues

IVI Foundation Meeting Minutes 35 September 10-14, 2001 Record of Discussions: Monday (December 10 th ) & Thursday (December 13 th )

1. John Harvey mentioned that section 5.20 of the spec (conformance) should include whatever the conformance group comes with it. Jon B. said we will not hold up the spec for the conformance spec. coz its not a required spec. 2. Noel recommended that we review only modifications up to section 1.4; start detailed read through in 1.4. 3. Action Item: Check complete document for forward slashes in path names. (change to \). 4. John Harvey mentioned that the type libraries should go under the Component directory? Discussion on where do the help files go? RenganS? suggestions of having an ‘IVI’ subdirectory to Components not to confuse with vendor specific. Consensus: No change to existing directory structure in spec. 5. Action Item: Remove all references to ‘manually remove’. 6. Zulfiqar brought up issues in section 1.3.4 and section 1.7.2 that needed changes. These were to not allow 'manual deletion of files'. The other was to allow a re-install mode. Both changes were made in the spec in the meeting. 7. Started reviewing section 1.4. 8. What do we want to do for restoring state on Standard install and update? -> Remove ‘any traces’ of the driver. 9. Do we want to require restore? Yes. If you don’t know how to upgrade without doing it properly, tell the user to uninstall. We decided that a driver installer does a rollback only if it is doing an upgrade. If it can’t restore the system to the previous state in case of a failure, then it should not implement the option to ‘upgrade’ the driver. 10. Action Item for IVI 3.1 main: The spec does not make clear what features are required and which are optional. Jon says it should be in section 3. 11. Action Item for IVI 3.1 main: Does our requirement on coercion (5.4.4) require the software to coerce or allow it to be done in the instrument? Need to make clear. Scott agrees that the driver doesn’t have to coerce if the instrument does. 12. Action Item: Research where this should be documented. How is coercion ‘Up’ and ‘Down’ defined in the class specs. This is not clear or defined anywhere. Look in the style guide for the table. A class spec reader needs to understand how to interpret ‘Up’ or ‘Down’, and should not have to look in the style guide. 13. Defined two modes for cleanup utility: partial and complete. Partial required for users who want to downgrade to an earlier version of the shared components. 14. Action Item to check in IVI 3.1 main: Section 5 needs to refer to installation section. 15. Action Item for IVI 3.1 main: Add the paragraph suggested by conformance group in section 5. Near the beginning. 16. Action Item for IVI 3.1 main: Promote section 1.4.1 to section 1.5. Include reference to logo as reward for conformance. 17. John Harvey went over section 5.20. to make sure that the wording is consistent to what is in section 1.4.5. What is the approach to first generation drivers? There are exceptions in 5.20 for first generation drivers. These drivers cannot use the logo after the specs have been finalized and they will not comply with secs. Joe Mueller asked why there is an exception section (5.20) for these drivers?

IVI Foundation Meeting Minutes 36 September 10-14, 2001 18. Action Item for IVI 3.1 main: Decision: Remove all references to first generation IVI drivers. 19. Action Item: Installer Section 1.5.1.2 has formatting issue: use 1,2,3 not a,b,c. 20. Zulfiqar could not find ShGetSpecialFolder in MSDN. Johannes showed an MSDN page where it is called SHGetSpecialFolderPath. Double check. Section 1.5.3 21. From Jon: In dialog mode, the installer should ignore directory inputs on command line. Should we add this anywhere? 22. Need to define MSI. 23. Update 1.6.1.3 to include reference to COM packaging section. 24. Fill in Section 1.6.1.5.1. Zulfiqar needs to make a proposal. 25. Remove ‘the’ in front of IVI Specification references. 26. For section 1.6.2, #7, compare wording with packaging sections in main IVI 3.1 for text on what readme.txt file has in it. 27. Ended just before Installer section 1.7 (IVI Shared Component Requirements).

IVI Foundation Meeting Minutes 37 September 10-14, 2001 12. Developer’s Forum Working Group

12.1 General Meeting Info: Date of Meeting: December 10,, 2001 Location: Austin, TX Chairperson: John Harvey Minutes Prepared By: Teresa Lopes

12.2 Meeting Attendees: Attendance was not taken at this session.

12.3 Record of Discussions:  What happens when the real world is different than the class specification? o Scope: time base - some channels are channel dependent and some are not o Behavior of attributes different than class specification specifies . Agilent chose to implement the instrument specific behavior as expected by the instrument . Want the instruments to look and behave like the instrument  JH thoughts are that you need to plan for interchangeability - if you don’t there are going to be surprises when you do replace one instrument with another. Need to understand what you are doing to plan for interchangeability  People that use the specific interfaces have chosen to not be interchangeable  The differences in behavior are only an issue with COM. Not really an issue with C since the line between the class and specific interface is not as clear cut. There isn’t a separate interface for the class versus the specific.  In the C world there is not way to expose the instrument view of the world without creating a parallel set of functions o Can be a problem - what do you call the parallel function  In the COM world the class interface function is equivalent to the C class driver function and the specific driver function that implements the class driver function.  Typically the specific driver interface is extended to expose behavior that is not present in the class spec, not necessarily for packaging behavior that is slightly different  IVI 3.1 (3.3.2) states something about the specific driver interface be the same whenever possible as the class specific interface - “consistent with class defined capabilities”  It is almost like you need a 3rd interface  Need a way to at instrument specific behavior so that users can access innovative instrument functionality  Channel based versus instrument based capability o Would expect the class interface to be channel based and that the specific instrument driver would enforce the fact that the setting can only be applied once for the instrument o Don’t want to automatically say that if it can be channel based in any instrument than it must be specified as channel based - if we took this to the logical conclusion then all settings would be channel based  There is a problem with taking the lowest common denominator approach in all cases because then you can only write lowest common denominator interchangeable application

IVI Foundation Meeting Minutes 38 September 10-14, 2001  The case where the specification specifies that the setting is instrument wide and the specific instrument is channel based is easier - in most cases can just provide an instrument specific interface for setting it channel wide  Another approach is to model each of the channels as a separate instrument - then only need to worry about the few shared settings  Instrument supports every capability in a group, except one o Don’t support it at all - don’t include it in the interface . Driver isn’t compliant, but you still want provide a class interface . Provide as much of the functionality as you can . Won’t be able to interchange that capability, but will provide a consistent interface to the user . Don’t lie - state that you support almost the entire capability group. In COM would provide the method/property in the interface and return IVI_NOT_SUPPORTED. Probably want to do something similar in C - provide the function and return an error. o Support the fixed value that the instrument does support and return an error for any other value o Support the value if you can compute the value from other settable values  Have found that it is better to cache values at the instrument level and not at the class level o Easier to keep the cache information consistent o Simpler - one less layer to manager  What you get by using the class interfaces is syntactic interchangeability (can swap instruments without having to recompile) - not getting semantic interchangeability - not standardizing on instrument behavior  Design your instrument specific interfaces to match the behavior of the instrument. Then build the class interfaces on top of those. Allows the user to swap back and forth between the two interfaces. Works well when the instance match is the same. Becomes a bit more difficult when the instances are different - but still doable.  Even if you are not using the IVI drivers for interchangeability the fact that you can go from IVI DMM to IVI DMM driver and know where to find certain functions is important  Two computers sharing one instance of an instrument (sequentially) - does this conflict with the initialize state of the instrument? o Locking across machines o From the initial design days - IVI was trying to not be multi-process safe o One of the things that has been on the list of things to do but we haven’t had the resources was a generic resource locking component to provide cross-process/cross-pc software locking of different arbitrary resources o For this to work , the software that is accessing those resources would have to be aware of the resource locking component o When a process lets go of a resource and then gets it back, does it have to re-initialize? o Need to manage the state switch between applications  Techniques for supporting a family of instruments in a single IVI driver o Table driven technique - a table that holds the SCPI commands for different the different models as well as the spec information o OO approach - although never implemented one o Grunt coding approach o OO approach requires that you set everything up at the front end of driver development o Do as much as you can at initialization to setup the tables/objects  Wrapper techniques

IVI Foundation Meeting Minutes 39 September 10-14, 2001 o NI: haven’t been able to completely automate the wrapper generation process. Usually requires a bit of hand tweaking. Could be done - but haven’t been expanded the energy o Both VC and CVI have options for generating C interfaces for COM objects but neither generates an interface that would be considered IVI C compliant or usable. o Can you really stay consistent between C and COM? Yes - but the process of automatically generating one from the other can be pretty hard - can’t be done without additional information  CATIDs o Primarily an installation issue o Why do we need them? . Show up in OleView . Can use MS category API to find out what instruments are in which classes o Will need to add a section to the class specs (3 or 4 lines) that specifies the category GUID for that class  Install time entries in the Configuration Store o Delay until John gets his example done  Testing IVI Drivers o Is everybody just using their own home grown testing procedures? o A lot of testing is white-box testing where it’s done knowing something about how the driver was implemented o There will not be a canonical set of tests that everybody will run  Editing IVI-COM IDL for drivers o Vektrex Tool Demo  Feedback to John as to whether or not this was useful.

-Teresa [email protected] (978) 370-1377

IVI Foundation Meeting Minutes 40 September 10-14, 2001 13. IviDigital Working Group

13.1 General Meeting Info: Date of Meeting: September 12, 2001 Location: Boston, MA – Teradyne Facility Chairperson: Teresa Lopes Minutes Prepared By: Teresa Lopes

Name Company Phone Email Teresa Lopes Teradyne 978-370-1377 [email protected] Zulfiqar Haider National Instruments 512-683-8374 [email protected]

13.3 Topics To Be Discussed:  Review version 0.5 of the Digital Class Specification  Discuss prototype work

13.4 Record of Discussions: The Digital working group meeting was “lightly” attended. The time was used to sit down with Zulfiqar Haider from National Instruments and review their comments on the specification.

This was the first review by someone not familiar with digital instruments and pointed out some problems with the specification, mostly related to terminology which may not be familiar to a non-digital instrument user.

One suggestion was to add a section in the overview that describes what digital instruments are, how they are used, etc. Another was that the descriptions for the attributes and methods should include more information for the driver writer.

The following tasks need to be completed before the specification is complete:  Incorporate NI feedback into specification  Review IDL and incorporate into specification  Format specification to comply with the latest version of the style specification.

The following are some of the detailed comments from National Instruments. They will be incorporated into an open issues document which will be posted to the working group by October 8, 2001.

IVI Foundation Meeting Minutes 41 September 10-14, 2001  The target audience of the specification is a driver developer, no necessarily someone familiar with the instrument or the class of instruments.  The document needs an over view section that describes what patterns are and how they are used.  Need to add comments to the code examples.  Rather than describe the different types of digital instruments in the overview section, describe the capabilities and how the class addresses them  In the diagrams, need to describe the symbols used and the meaning behind the arrows.  Need to describe what a driver and detector are.  Need to describe how the attributes affect the instrument.  Make sure all examples appear in the examples section and not inline. If there are examples that show specific examples of usage, document those with the function or attribute.  Use English names for functions and attributes.  Remove static/dynamic text from compliance sections, information already stated.  Use two different tables to describe what other classes need to be implemented for results and data.  In handle descriptions, add the name of the function that provided the handle.  Need more details in the descriptions for the driver writers not familiar with digital instruments.  Need a table that describes the defined values for group opcode  Need to describe what it means to create a pattern.  Explain how values don’t get applied until Execute or Load  Need a table of class error codes  Need to define exception codes, make clear that exception codes are not error conditions.  Move use mode, currently in the behavior model section, to overview.

IVI Foundation Meeting Minutes 42 September 10-14, 2001 14. VISA Working Group

14.1 General Meeting Info: Date of Meeting: December 13, 2001 Location: Austin, TX Chairperson: Dan Mondrik Minutes Prepared By: Keith Rule and Dan Mondrik

Name Company Phone Email Dan Mondrik National Instruments (512) 683-8849 [email protected] Eric Singer National Instruments (512) 683-5438 [email protected] Scott Rust National Instruments (512) 683-5680 [email protected] Keith Rule Tektronix (503) 627-4338 [email protected] Badri Malynur Tektronix (503) 627-5880 [email protected] Joe Mueller Agilent (970) 679-3248 [email protected] John Harvey Agilent (970) 679-3535 [email protected] Steve Schink Agilent (970) 679-2196 [email protected] Andy Purcell Agilent (970) 679-5976 [email protected] John Ryland Keithley Instruments (440) 498-3044 [email protected] Fred Bode Bode Enterprises (619) 697-8790 [email protected] Rengan Rajendran Vektrex [email protected]

14.3 Topics To Be Discussed:  Errata of VISA COM Spec (VPP 4.3.4)  Sharing Components  VISA errata for VXI-11 exclusive lock/shared lock  .NET Discussion  Getting USB support into VISA C/COM specs

14.4.1 Errata of VISA COM Spec

1) VXI Trigger ID property is in the IDL but not in spec. Should also be in the spec. 2) ReadIEEEBlock in formatted I/O interface. What happens if a device sends an END before expected size of the block? Clarify spec that if it receives an END that is assumed correct for the instrument and it should not cause an error.

IVI Foundation Meeting Minutes 43 September 10-14, 2001 3) IDL and spec that says how to register disagree. Dan is not sure which fields in the IDL and spec disagree. Dan suggests that we don’t change the IDL, but rather fix the spec. 4) One more errata that Dan remembered after the meeting is one that Dave Gladfelter brought up in an email. The VISA COM spec requires IProvideClassInfo2 but this is only really useful for an outgoing dispinterface. It seems that implementations might return E_FAIL for the GetGUID method since the VISA COM spec does not define any outgoing dispinterface. So is this useful? At least leaving it in won’t hurt anything.

Action Items Dan would like to make these minor fixes for items 1-3. Dan will post the errata document on the VXIpnp website.

Comments NI VISA 2.6 will include VISA COM components. The new VISA release should be posted on the NI website by Christmas.

Will there be some interoperability testing between VISA COM implementations? There are two kinds of testing: 1) Shared component testing (Global RM, Conflict Manager, Formatted I/O) 2) Continued interoperability testing, especially with drivers. The shared component testing needs to be planned. Continued interoperability testing is assumed to be part of instrument driver interoperability testing.

Is it necessary to include VISA C in the VISA COM interoperability testing? VISA COM is not necessarily tied to VISA C. Mixing VISA COM and VISA C from different vendors may not work correctly. The degree of interoperability is left up to the VISA COM vendors at this point.

14.4.2 Shared Components What is the next step? 1) Exchanging components between vendors. NI is open to sharing them with vendors. 2) The IVI foundation will adopt an IP policy. We currently don’t have a foundation license. It is suggested that we use the IVI IP policy for VISA COM shared components.

The plan is that members will have access to source code. Binaries are released to everyone. It’s unclear what the relationship is between the legal group and the VISA group. Does released binaries mean DLL or installer? The TWG needs to decide this, but the TWG needs to define the installation procedure. There is no need to make these generally available. It seems that only VISA vendors will need access to the binaries. The suggestion is only IVI members have direct access of VISA shared components on the IVI web site.

IVI Foundation Meeting Minutes 44 September 10-14, 2001 14.4.3 VISA Locking VXI-11 holds a lock in the server. There is a question about how VISA based locking should work with this. The Agilent and NI implementations may differ here. Joe requested the wording should be clarified to handle this. The suggestion was to defer the exclusive lock to the VXI-11 server.

VXI-11 and VISA locking – first pass in the new spec will be that exclusive locks are passed through to VXI-11 and shared locks only applies to the VISA client.

The shared lock handling on each client machine may be inadequate. This potential conflict (with different clients obtaining different shared locks) is minimal due to the lack of use of shared locks and is something we all believe is acceptable. Adding it to the VISA 3.0 specification will be much easier than reopening the VXI-11 spec.

14.4.4 .NET Discussion Jon Bellin suggested looking at .NET in Wednesday’s technical meeting. Dan would like to start addressing this for VISA. He suggests we start defining the .NET API for VISA in the VISA TWG. The suggestion is that the .NET API be an assembly that looks very much like VISA COM, the .NET assembly may be different where there is compelling reasons to exploit .NET features. John Harvey suggests that any .NET discussions include both knowledgeable IVI members and expert COM developers. Dan Mondrik sees exposing the .NET development to a broader group as valuable, but we should set the technical direction prior to opening the discussion to a wider audience.

We agree that the .NET need exists for IVI drivers which means that the VISA TWG needs to address this issue in some way. The recommendation is to start with a telephone conference sometime in February or March 2002. It would be appropriate to include IVI driver developers in this conversation. We will invite interested parties by announcing the conference call on the IVI mail list. We will need at least ½ day at the next IVI meeting for this topic alone.

Action Items NI will call a phone conference before the next IVI meeting to suggest ways to exploit .NET features in the VISA API.

14.4.5 USB There is an effort to define a USB protocol to emulate IEEE 488. The question is how do we integrate this support into VISA C and VISA COM.

Each vendor of a USB device generally provides an .inf file. This leads to potential interoperability issues. The VISA spec (not the USBTMC spec) will address those issues.

There is no direct relationship between VISA or IVI and the USBTMC DWG; however, many of the companies are the same and there is a need for VISA to work with these devices.

IVI Foundation Meeting Minutes 45 September 10-14, 2001 Proposed VISA Changes

Reviewed USBTMC Interoperability Specification

What will the resource string look like? Some relevant info is possibly the USB board number and the device’s vendor ID, product ID, and serial number. VISA will need an optional integer to handle multiple interfaces on the same device. Example: USB::0xA37B::0x1234::SN_001::INSTR

Standard viFindRsrc regular expressions will work with these ID values.

INSTR indicates USBTMC compliance. Other protocols must use some string other than INSTR. Support for other protocols may not be addressed by the VISA specification; instead, this may be relegated to vendor extensions.

Andy – Should VISA alias the resource string? Dan – Spec already support this, but in a vendor specific way. Andy – Is the alias returned by viFindRsrc? Dan – The spec says the canonical name should be returned.

The proposed resource operations have a 1 to 1 mapping with the GPIB resource. What’s missing are the attributes. These are timeout, termination char, whether to send END, the model code, manufacturer ID, manufacturer name, and model name. We need to add serial number (a string). Possibly also needs a capabilities field and the device-specific interface number (different from the standard VISA interface number which in this case indicates the USB board number).

Andy - What is the procedure for changing the VISA spec? Dan – We will open the specs and start a new draft. Dan suggests calling this a V3.0 draft.

USB Interoperability Issues

Are all device vendors expected to write kernel drivers for USB devices? Will device vendors or VISA vendors supply this?

Andy – We need to be flexible. The architecture needs to be flexible. Application developers tend to want to use a single I/O library to communicate with their instruments.

Dan – Agrees with Andy, however it would be desirable to not require device vendors to write kernel drivers.

Dan – What happens if the .inf specifies a class driver and there is no OS supplied driver?

Andy – Specific cases are:

IVI Foundation Meeting Minutes 46 September 10-14, 2001  Only a vendor supplies vendor/product ID specific driver  I/O library supplies general driver (more specific vendor driver will be used if found)  OS vendors can supply only class level drivers (not specific drivers)

Andy believes an I/O vendor will likely supply a specific class driver. Dan – A VISA vendor will be able to provide a class driver and .inf for USBTMC? Andy – Yes that’s true. Dan – The user level code is agnostic about the driver used underneath? Andy – Yes.

Andy – A VISA library needs to get the device instance path name from the registry. This will allow the VISA library to deal with OS differences.

Andy – Proposes that the driver interoperability be dealt with as part of the VISA TWG. Dan – Agrees that is where this belongs.

Dan – When will the USB implementer forum spec be voted in? Andy – April is optimistic. Dan – We would like to roll support for the USBTMC spec into the VISA spec for vote at the July meeting. Drafts will appear before then. Andy – Can we have a web-ex conference to continue work on the VISA spec. This meeting would be separate from the USB implementers forum. Dan – Sounds like a good idea.

Andy – How many opens should be allowed on a device? Currently the spec allows only a single connection. The I/O library is expected to handle multiple connections to a single device. This restriction is a limitation of the Microsoft pass-through driver. It seems like a good idea to leverage this work.

Dan – Is it natural for a USB devices to have multiple connections? Andy – 99.9% of the time there is only one application communicating to a given USB device at a given time. Suggestion is leave this up to the VISA vendor. Dan – Cases to consider 1) One sessions anywhere 2) Multiple sessions in a process 3) Multiple sessions across processes

What followed was a discussion based on the USBTMC draft specification 0.7h. Since it covered mostly typographical errors and minor clarifications, and since the contents are not supposed to be public anyways, the details are omitted here.

Dan – The USBTMC spec references both a Message and a Transfer. Which of these corresponds to a viWrite? Andy – viWrite with END enabled would be a complete USBTMC Message.

IVI Foundation Meeting Minutes 47 September 10-14, 2001 Dan – In CreateFile it says we must support overlapped mode. Will calls to DeviceIOControl require the overlapped structure? Or should calls be forced to be synchronous? This is an action item for Dan.

Goal is to have a VISA 3.0 draft when the USBTMC spec reaches 0.9 so that both groups can review the VISA functionality. As long the USBTMC spec draft is less than 0.9, it is not available to the public.

Andy – There is a USB implementers forum meeting Jan 9th and 10th in Las Vegas. He will share the minutes of this meeting with them.

IVI Foundation Meeting Minutes 48 September 10-14, 2001 IVI Foundation Meeting Minutes 49 September 10-14, 2001 15. IVI Foundation, Inc. Members (12/01/2001)

Advantest Corporation BAE SYSTEMS (General) (General) Shinjuku-NS Building, 6 South Gyle Crescent, 2-4-1 Nishi-Shinjuku Edinburgh, EH12 9EA, UK Shinjuku-ku, Tokyo 163-0880, Japan Web Page: www.baesystems.com Web Page: www.advantest.co.jp Business Contact: I. H. Wilkinson Business Contact: Kazunori Uo Phone: +44 (0)131 3142332 Phone: +81-276-70-3300 Fax: +44 (0)131 3142678 Fax: +81-276-70-3429 4717 E-mail: [email protected] E-Mail: [email protected] Technical Contact: Yohei Hirakoso Technical Contact: Peter Richardson Phone: 503-627-2671 Phone: +440 131 314 2332 Fax: 503-627-3198 Fax: +440 131 314 2430 E-Mail: [email protected] E-Mail: [email protected]

Agilent Technologies BCO, Inc. (Sponsor) (General) 815 14 Street SW 799 Middlesex Turnpike Loveland, CO 80539 Billerica, MA 01821 Web Page: www.agilent.com Web Page: www.bco-inc.com Business Contact: Joe Mueller Business Contact: Terry Yetsko Phone: 970-679-3248 Phone: 978-663-7350 Fax: 970-679-5945 Fax: 978-670-2939 E-Mail: [email protected] E-Mail: [email protected] Technical Contact: John Harvey Technical Contact: Mel Petty Phone: 976-679-3535 Phone: 978-663-2156 Fax: 970-679-5945 Fax: 978-670-2939 E-Mail: [email protected] E-Mail: [email protected]

ASCOR Bode Enterprises (Associate) (General) 2515 Camino del Rio South, Suite 340 4384 Enterprise Place San Diego, CA 92108 Fremont, CA 94538 Web Page: www.vxinl.com Web Page: www.ascor-inc.com Business Contact: Fred Bode Business Contact: Terukuni Okuyama Phone: 619-297-1024 Phone: 510-490-2300 Fax: 619-297-5955 Fax: 510-490-8493 E-Mail: [email protected] E-Mail: [email protected] Technical Contact: Same as Above Technical Contact: Same as Above

IVI Foundation Meeting Minutes 50 September 10-14, 2001 The Boeing Company Flextronics International (General) (Associate) P.O.Box 3999 Box 532 Seattle, WA 98124 S-371 23 Karlskrona, Sweden Business Contact: John (Jay) Polivka Business Contact: Bo Millevik Phone: 425-342-4289 Phone: 46-455-54671 Fax: 425-294-4545 Fax: 46-455-54404 E-Mail: [email protected] E-Mail: [email protected] Technical Contact: Roger L. Williams Technical Contact: Asko Kauppi Phone: 425-717-2059 Phone: 358-40-518-6634 Fax: 425-717-2125 E-Mail: [email protected] E-Mail: [email protected] Keithley Instruments C&H Technologies, Inc. (Associate) (Sponsor) 445 Round Rock West Drive 28775 Aurora Road Round Rock, TX 78681-5012 Cleveland, OH 44139-1891 Web Page: www.chtech.com Web Page: www.keithley.com Business Contact: Gary Guilbeaux Business Contact: John Ryland Phone: 512-733-2621 Phone: 440-498-3134 Fax: 512-733-2629 Fax: 440-542-8017 E-Mail: [email protected] E-Mail: [email protected] Technical Contact: David Clark Technical Contact: Paul Franklin Phone: 512-733-2621 Phone: 440-498-8097 Fax: 512-733-2629 Fax: 440-542-8017 E-Mail: [email protected] E-Mail: [email protected]

Emergent Information Technologies LeCroy Corp. (Associate) (General) 2060 Briargate Parkway Ste 200 700 Chestnut Ridge Road Colorado Springs, CO 80920 Chestnut Ridge, NY 10977 Web Page: www.emergent-it.com Web Page: www.lecroy.com Business Contact: R. Scott Brunton Business Contact: Joseph M. Schacher Phone: 719-593-5974 Phone: 845-425-2000 x2282 Fax: 719-593-5978 Fax: 845-578-4496 E-Mail: [email protected] E-Mail: [email protected] Technical Contact: Bill Raskob Technical Contact: Same as Above Phone: 719-593-5974 Fax: 719-593-5978 Lucent Technologies E-Mail: [email protected] (Sponsor) 600 Mountain Avenue Ericsson Radio Systems AB Murray Hill, NJ 07974 (General) Web Page: www.lucent.com PO Box 6206 Business Contact: David Huddleston S-80006 Gevle Phone: 614-860-5587 Sweden Fax: 614-860-5883 Web Page: www.ericsson.com E-Mail: [email protected] Business Contact: Magnus Jansson Technical Contact: Neil Shah Phone: +46 26 156450 Phone: 614-860-5010 Fax: +46 26 157320 Fax: 614-860-5883 E-Mail: [email protected] E-Mail: [email protected] Technical Contact: Same as Above

IVI Foundation Meeting Minutes 51 September 10-14, 2001 The MathWorks, Inc. Pacific MindWorks (General) (General) 3 Apple Hill Drive 5665 Oberlin Dr., Suite 202 Natick, MA 01760 San Diego, CA 92121 Web Page: www.mathworks.com Web Page: www.pacificmindworks.com Business Contact: Loren Dean Business Contact: Kirk Fertitta Phone: 508-647-7495 Phone: 858-587-8876 x237 Fax: 508-647-7001 Fax: 858-587-8907 E-Mail: [email protected] E-Mail: [email protected] Technical Contact: Melissa Pike Technical Contact: Kirk Fertitta Phone: 508-647-7493 Phone: 858-587-8876 x237 Fax: 508-647-7001 Fax: 858-587-8907 E-Mail: [email protected] E-Mail: [email protected]

National Instruments PX Instrument Technology (Sponsor) (General) 11500 N. Mopac Expwy., Building B Unit 32 Beechwood Close Austin, TX 78759-3504 Boghall Road Web Page: www.ni.com Bray, County Wicklow Business Contact: Dany Cheij Ireland Phone: 512-683-5286 Web Page: www.pxi-tech.com Fax: 512-683-5569 Business Contact: Padraig O'Neill E-Mail: [email protected] Phone: +353-1-2864221 Technical Contact: Scott Rust Fax: +353-1-2864223 Phone: 512-683-5680 E-Mail: [email protected] Fax: 512-683-5569 Technical Contact: Patricia Dalton E-Mail: [email protected] Phone: +353-1-2864221 Fax: +353-1-2864223 Nokia Mobile Phones, Inc. (Associate) E-Mail: [email protected] 12278 Scripps Summit Dr. San Diego, CA 92131 Racal Instruments Inc. Web page: www.nokia.com (General) Business Contact: Joel Garcia 5730 Northwest Parkway, Suite 700 Phone: 858-831-5797 San Antonio, TX 78249 Fax: 858-831-6511 Web Page: www.racalinst.com E-mail: [email protected] Business Contact: John Rosenwald Technical Contact: Balan Tholandi Phone: 210-669-6799 x212 Phone: 858-831-4547 Fax: 210-699-8857 Fax: 858-831-6504 E-Mail: [email protected] E-mail: [email protected] Technical Contact: Patrick Johnson Phone: 210-699-6799x204 Northrop Grumman ESSS Fax: 210-699-8857 (General) E-Mail: [email protected] P.O. Box 746, MS 10 Baltimore, MD 21203 Web page: www.sensor.northgrum.com Business Contact: Gayle Matysek Phone: 410-765-9754 Fax: 410-765-0956 E-Mail: [email protected] Technical Contact: Same as Above

IVI Foundation Meeting Minutes 52 September 10-14, 2001 Rohde & Schwarz Teradyne (Sponsor) (General) Muehldorfstr. 15 600 Riverpark Drive, 81671 Munich, Germany North Reading, MA 01864 Web Page: www.rohde-schwarz.com Web Page: www.teradyne.com Business Contact: Jochen Wolle Business Contact: Andy Hutchinson Phone: +49 89 4129 13044 Phone: 978-370-1277 Fax: +49 89 4129 13055 Fax: 978-370-1440 E-Mail: [email protected] E-Mail: [email protected] Technical Contact: Johannes Ganzert Technical Contact: Teresa Lopes Phone: 49 89 4129 13405 Phone: 978-370-1377 Fax: 49 89 4129 13460 Fax: 978-370-1100 E-Mail: [email protected] E-Mail: [email protected]

Software AG, Inc. TYX Corporation (General) (General) 2613 Camino Ramon, 1910 Association Drive Suite 110 Second Floor San Ramon, CA 94583 Reston, VA 20191 Web Page: www.softwareagusa.com Web Page: www.tyx.com Business Contact: Roy Stark Business Contact: Narayanan Ramachandran Phone: 925-242-3774 Phone: 703-264-1080 Fax: 925-242-3000 Fax: 703-264-1090 E-Mail: [email protected] E-Mail: [email protected] Technical Contact: Danie Bierman Technical Contact: Ion Neag Phone: 925-242-3772 Phone: 703-264-1080 Fax: 925-242-3000 Fax: 703-264-1090 E-Mail: [email protected] E-Mail: [email protected]

Tektronix Vektrex Electronic Systems (Sponsor) (General) Attn: Bill Leineweber 10225 Barnes Canyon Road PO Box 500, M/S 39-732 Suite A-213 Beaverton, OR 97077 San Diego, CA 92121 Web Page: www.tek.com Web Page: www.vektrex.com Business Contact: Bill Leineweber Business Contact: Jeff Hulett Phone: 503-627-1153 Phone: 858-558-8282 x11 Fax: 503-627-5622 Fax: 858-558-2552 E-Mail: [email protected] E-Mail: [email protected] Technical Contact: Badri Malynur Technical Contact: Rengan Rajendran Phone: 503-627-5880 Phone: 858-558-8282 x20 Fax: 503-627-5622 Fax: 858-558-2552 E-Mail: [email protected] E-Mail: [email protected]

(General) and (Sponsor) Indicate Voting Members

IVI Foundation Meeting Minutes 53 September 10-14, 2001 16. IVI Foundation, Inc. Finances (9/30/2001)

Summary of financial account of the IVI Foundation, Inc. as of September 30, 2001

IVI Foundation Account Analysis 2001

IVI Revenue 1998 Dues Collected $ 9,000.00 1999 Dues Collected $ 17,800.00 2000 Dues Collected $ 19,100.00 2001 Dues Collected $ 42,000.00 Total Dues Collected thru 9/30/01 $ 87,900.00

IVI Dallas Nov. 2000 Meeting revenue $ 12,879.48 2001 IVI Dallas Nov. 2000 meeting receipts $ 172.50 2001 IVI San Diego meeting receipts $ 13,537.50 2001 IVI Paris meeting receipts $ 6,775.00 Total Revenues at 9/30/01 $ 121,264.48

IVI Expenses 1999 Expenses paid $ 3,391.69 2000 Expenses paid $ 24,801.15 2001 Lucash, Gesmer legal fees $ 935.45 2001 Lucash, Gesmer legal fees $ 1,212.64 2001 Website maintenance fees $ 74.99 2001 Website maintenance fees $ 74.99 2001 Website maintenance fees $ 74.99 2001 Website maintenance fees $ 74.99 2001 Lucash, Gesmer legal fees $ 486.54 2001 Lucash, Gesmer legal fees $ 1,873.02 2001 Lucash, Gesmer legal fees $ 3,133.89 2001 Lucash, Gesmer legal fees $ 607.60 2001 Clarion Hotel San Diego meeting $ 8,596.70 2001 Annual IVI Name Domain fee $ 50.00 2001 Website maintenance fees $ 74.99 2001 Bank wire transfer fee BAE dues $ 20.00 2001 Lucash, Gesmer legal fees $ 217.83 2001 CT Corporation Delaware Corp fees $ 265.00 2001 Advantest Europe, Paris meeting $ 6,700.00 2001 Lucash, Gesmer legal fees $ 345.03 2001 Lucash, Gesmer legal fees $ 260.76 2001 Website maintenance fees $ 74.99 2001 Bode Enterprises advance payment $ 1,000.00 2001 Website maintenance fees $ 74.99 2001 Website maintenance fees $ 74.99 2001 Website maintenance fees $ 74.99 2001 PR Newswire fee $ 212.50

IVI Foundation Meeting Minutes 54 September 10-14, 2001 Total Expenses paid through 9/30/01 $ 54,784.71

Total IVI Revenue at 9/30/01 $ 121,264.48 Less Expenses paid through 9/30/01 $ (54,784.71)

Total IVI Foundation Balance at 9/30/01 $ 66,479.77

IVI Foundation Meeting Minutes 55 September 10-14, 2001