Meeting Minutes - Feb 2001 - IVI Foundation€¦ · Web viewDefault interfaces are not important for this specification. The only 2 co-classes remaining in this spec are IResourceManager

IVI FoundationMeeting Summaries

February 26th – March 2nd, 2001San Diego, California

1. Table of Contents1. TABLE OF CONTENTS............................................................................................................................. 1

2. MEETING ATTENDEES............................................................................................................................ 3

3. GENERAL MEMBERSHIP MEETING.....................................................................................................5

4. WORKING GROUP SUMMARIES..........................................................................................................16

5. CONFIG STORE WORKING GROUP....................................................................................................23

6. SIGNAL INTERFACE WORKING GROUP...........................................................................................27

7. IVI-MSS WORKING GROUP.................................................................................................................. 30

8. COM WORKING GROUP........................................................................................................................ 33

9. IVI C WORKING GROUP........................................................................................................................ 37

10. SPECTRUM ANALYZER WORKING GROUP..................................................................................38

11. IVIDIGITAL WORKING GROUP.......................................................................................................40

12. USER WORKING GROUP................................................................................................................... 42

13. IVI 3.2: INHERENT CAPABILITIES WORKING GROUP...............................................................46

14. IVI 3.1: ARCHITECTURE WORKING GROUP.................................................................................47

15. GLOSSARY WORKING GROUP.........................................................................................................50

16. COMPLIANCE WORKING GROUP...................................................................................................53

17. IVIPWRMETER WORKING GROUP.................................................................................................56

18. VXIPLUG&PLAY VISA TECHNICAL WORKING GROUP..............................................................58

19. EVENT SERVER IVI-3.7 WORKING GROUP...................................................................................65

20. SUPPORT MODEL WORKING GROUP............................................................................................68

21. RF SIGGEN WORKING GROUP.........................................................................................................69

22. LEGAL WORKING GROUP................................................................................................................ 73

IVI Foundation Meeting Minutes 1 Feb 26 – Mar 2, 2001

23. API STYLE GUIDE WORKING GROUP............................................................................................77

24. Promotions Working Group...................................................................................................................... 79


2. Meeting Attendees

Name Company Phone EmailYohei Hirakoso Advantest 503-627-2671 [email protected] Kashi Agilent Technologies 707-577-4577 [email protected] Stern Agilent Technologies 707-577-2886 [email protected] Cribar Agilent Technologies 970-679-2061 [email protected] Gladfelter Agilent Technologies 970-679-5329 [email protected] Muir Agilent Technologies +44-131-335-7428 [email protected] Harvey Agilent Technologies 970-679-3535 [email protected] Borchert Agilent Technologies 970-679-3387 [email protected] Wheelwright Agilent Technologies 707-577-2568 [email protected] Krombholz Agilent Technologies 707-577-3188 [email protected] Gao Agilent Technologies 707-5772152 [email protected] Oblad Agilent Technologies 707-577-3466 [email protected] Greer Agilent Technologies 970 679 3474 [email protected] Schink Agilent Technologies 970-679-2196 [email protected] Okuyama ASCOR, Inc 510-490-2300 [email protected] Richardson BAE SYSTEMS +44-131-314-2332 [email protected]

mRon Taylor BAE SYSTEMS 858-675-1844 [email protected] Petty BCO, Inc. 978-663-2156 [email protected] Bode Bode Enterprises 619-297-1024 [email protected]

Don Davis Boeing 314-234-2722 [email protected] Wegener Boeing 314-234-3801 [email protected] Lawler Hamilton Software 707-542-2700 [email protected] Howarth Keithley Instruments 440-498-3044 [email protected] Shah Keithley Instruments 440-498-2934 [email protected] Prescott Ministry of Defense +44-1244-288331

[email protected]

Dan Mondrik National Instruments 512-683-8849 [email protected] Cheij National Instruments 512-683-5286 [email protected] Fuller National Instruments 512-683-5399 [email protected] Burnside National Instruments 512-683-5472 [email protected] Bellin National Instruments 512-683-5516 [email protected] Adorno National Instruments 512 683 5071 [email protected] Kovner National Instruments 512-683-0100 [email protected] Rust National Instruments 512-683-5680 [email protected] Zirojevic National Instruments 512 683 5374 [email protected] Haider` National Instruments 512-683-8374 [email protected]

Balan Tholandi Nokia Mobile Phones, Inc. 858-831-4547 [email protected] L Cole Northrop Grumman 410-993-5173 [email protected] Matysek Northrop Grumman 410-765-9754 [email protected]

.comBarry Shikoff Pacific Mindworks


Name Company Phone EmailBrad Honda Pacific Mindworks 858-554-0721Kirk Fertitta Pacific Mindworks 858-554-0721 [email protected] Rosenwald Racal Instruments 210-699-6799 x 212 [email protected] Johnson Racal Instruments 210-699-6799 x204 [email protected] Ptacek Rockwell Collins 319-295-0198 [email protected] Wolle Rohde & Schwarz +49-89-4129-13044 [email protected]

schwarz.comJohannes Ganzert Rohde & Schwarz +49-89-4129-13405 [email protected]

schwarz.comAlex Burggraf Software AG 925-242-3746 [email protected] Bierman Software AG 925-242-3772 [email protected] Lindstedt Software AG 925-242-3724 [email protected] Malynur Tektronix 503-627-5880 [email protected] Bill Leineweber Tektronix 503-627-1153 [email protected] Don Zocchi TektronixKeith Rule Tektronix 503-627-4338 [email protected] Teresa Lopes Teradyne 978-370-1377 [email protected] Hutchinson Teraydne 978-370-1277 [email protected] G McKay Thales Instruments (aka

Racal)+44-1202-872800 [email protected]

Richard Hazlewood Thales Instruments (aka Racal)

+44-1202-872800 [email protected]

Tom Gaudette The MathWorks, Inc 508-647-7759 [email protected] Geathers TYX Corporation 703-264-1080 [email protected] A. Neag TYX Corporation 703-264-1080 x132 [email protected] Nudelman Vektrex 858-458-5822 [email protected] Hulett Vektrex 858-458-5822 [email protected] Rajendran Vektrex 858-458-5822 [email protected] Eriksson Virtual Gadgets, Inc. 858-720-9866 [email protected] Spivak Winsoft 714-444-4844 x209 [email protected] Schwartzberg

Winsoft 714-444-4844 x204 [email protected]


3. General Membership MeetingDate of Meeting: March 1st, 2001Location: San Diego, CAChairperson: Scott RustMinutes Prepared By: Dany Cheij

3.1 Topics To Be Discussed:- Introductions- Review Voting Members In Attendance – Scott Rust (NI)- Review Agenda – Scott Rust (NI)- Membership – Dany Cheij (NI)

- Review- Approve New Members

- Approve minutes from the previous General Membership Meeting – Scott Rust (NI)- IVI Account Summary - Scott Rust (NI)- IVI Working Groups

- Reviews from the previous days working groups- VISA VXIplug&play Technical Working Group- IVI 3.2 Working Group- IVI 3.1 Working Group- IVI Glossary Working Group- Compliance Working Group- Power Meter- User’s Working Group

- Reviews from the morning working groups- Event Server, Support Model, Resource Locking Working Group- RF Signal Generator Working Group- Legal and Promotions Working Group

- Review the spec status document – Scott Rust (NI)- Process for reviewing and approving sets of specifications

- Core Architectural Specifications- Updated Class Specifications- New Class Specifications

- Old Business Items-

- New Business Items- Life Cycle of a Working Group- Source Code For Instrument Drivers

- Schedule for Next Meetings- Info on the June Meeting (6/5 – 6/8) – Anne Faveur (Advantest)- Info on the September Meeting ???

- Adjourn


3.2 Voting Members In Attendance

Company Representative

Advantest Corp Japan Yohei HirakosoAgilent Technologies John HarveyASCOR Terukuni OkuyamaBAE Systems Pete RichardsonBCO, Inc. Mel PettyDefense Logistics Organization John PrescottHamilton Software Dean LawlerKeithley Instruments Premal ShahNational Instruments Jon BellinNorthrop Grumman Gayle MatysekPacific Mindworks Barry ShikoffRacal Instruments John RosenwaldRockwell Collins Dave PtacekRohde & Schwarz Germany Jochen WolleTektronix Badri MalynurTeradyne Teresa LopesTYX Corporation George GeathersVektrex Electronic Jeff Hulett

There are 18 voting members present. Being more than four, this satisfies the requirements for a quorum.

3.3 Membership ReviewDany Cheij passed out a membership roster for the members to edit and return. Dany Cheij will update the membership information based on this information.

3.4 Approve New MembersThe following companies submitted the following membership applications to the IVI Foundation.

Company Name Voting or Associate

Nokia Mobile Phones Associate

Sandia National Laboratories Voting


Gayle Matysek made motion to approve the new members. The motion was seconded by John Prescott. The motion was unanimously approved (18-0).

3.5 Approve minutes from the previous General Membership MeetingJon Bellin made motion to approve the minutes as amended. The motion was seconded by John Harvey. The motion was unanimously approved (18-0).

3.6 IVI Account Summary - Scott Rust

IVI Account Summary

IVI Revenue

1998 Dues Collected $ 9,000.00 1999 Dues Collected $ 17,800.00 2000 Dues Collected $ 19,100.00

Total Dues Collected thru 1/31/01 $ 45,900.00

IVI Dallas Nov. 2000 Meeting revenue $ 12,879.48 2001 IVI Dallas Nov. 2000 meeting receipts $ 172.50

Total Revenues at 1/31/01 $ 58,951.98

IVI Expenses

1999 Expenses paid $ 3,391.692000 Expenses paid $ 24,801.152001 Lucash, Gesmer legal fees $ 935.452001 Lucash, Gesmer legal fees $ 1,212.642001 Website maintenance fees $ 74.99

Total Expenses paid through 1/31/01 $ 30,415.92

IVI Foundation Balance at 1/31/01 $ 28,536.06

Delinquent 1999 Membership Dues

Raytheon TI Systems $ 500.00 Shaanxi Hitech Elec China $ 200.00SIRTI SpA Italy $ 200.00

Total Delinquent 1999 Dues $ 900.00

Unpaid 2000 Membership Dues

IFR $ 500.00


Raytheon TI Systems $ 500.00 SIRTI SpA Italy $ 200.00

Total Unpaid 2000 Dues $ 1200.00

3.7 IVI Working Group Issues

3.7.1 Reviews from the Previous Days Working Groups

VISA VXI plug&play Technical Working Group

The main thing that the group was working on was to finish the VISA-COM spec. The group went through a lot of feedback from members. They dealt with six main issues:1 – Enumerations vs Longs: use enums where appropriate2 – Shared components: want to use the same model as IVI. Action item: NI and Agilent

make sure that they will donate the components they are writing3 – Versioning: allow for independent versioning of C and COM4 – Timeframe for COM: could be finished sometime in April.5 – Multi-vendor C interoperability impasse. The Passport model was discussed and

Agilent stated that they would not support the Passport model. Jon Bellin brought up the discussion that happened in the IVI-3.1 working group at the Dallas meeting (referenced in the Nov2000 meeting minutes) to the effect that for the requirements for VISA-C and VISA-COM agreed to at that meeting to work, the interoperability problem with VISA-C must be solved. Ni interpreted this as a commitment to actively pursue a solution. Agilent did not interpret the discussion as a firm commitment, but rather a statement of the facts and a strong desire to fix them. Agilent suggests offline discussions to resolve the issue. Badri Malynur asked what offline means. Will other members of the IVI Foundation and VXIplug&play have a chance to view the different solutions and make an informed decision? Dan Mondrik mentioned that NI has said that they would be willing to present the Passport model and asked whether Agilent would be willing to present the Tulip alternative. John Harvey said that they were not prepared to discuss this at this meeting and would have to think about and discuss the issues internally before they can state a position to the group. Badri Malynur stated that Tektronix also has the same interoperability issues with their version of VISA. John Harvey said that he assumes that whatever solution is decided upon will eventually have to approved through the appropriate standard bodies (VXIplug&play currently). Jon Bellin stated that since in the past we have included the COM I/O discussions in IVI, then we should also be prepared to discuss the progress of the efforts to solve the multi-vendor interoperability VISA-C problem. John Harvey said that the spokesman for Agilent on this issue (Steve is not currently present). Roger Oblad asked whether we can make the decision of whether VISA should be under VXIplug&play or IVI. Scott Rust took the action item to figure how we can organizationally handle VISA to bring it under IVI or not. Dan Mondrik will report back to both listservers about the plan to resolve this issue (within three weeks).


6 – Next meeting: that issue was not resolved and will be decided upon within three weeks.

IVI 3.2 Inherent Capabilities Specification

Reviewed changes made since last conference call. Added some COM interfaces that were left out in section 4.Added places to insert GUIDs for COM interfaces. We will put the real GUIDs into the spec just before the final review. Raised the question of the implications of class drivers using C and COM wrappers, with specific regard for packaging, installation, and the configuration store. Will work on this immediately after this meeting.Zulfiqar will accept the changes as soon as he has reviewed them.John Harvey proposes that in general we should track the changes to specs and accept the changes while attending the IVI meetings. We can use the “Word Compare Documents” feature to generate a succinct list of changes.After making the spec changes that are listed above, we consider this to be ready for final review.

IVI 3.1 IVI Driver Architectural Specification

Reviewed the changes to the document since the conference call, except we did not have time to get to Sections 4.1.11 through 4.1.18, and section 5.13. We will cover those in conference calls.

Section 6, Installation Requirements, has not yet been started.

Issue arose as to whether to require that drivers ship with source code. Currently, spec does not require this. Peter Richardson has concern about being able to debug and fix a system rapidly without source code. John Harvey expressed concern about being forced to reveal proprietary algorithms for some drivers or to reveal COM-in-the-box source code. It was agreed that this issue should be brought up in the general membership meeting. This topic was discussed at some length. It was agreed that drivers did not need to install source code automatically if they supplied it on the CD.

Spec assumes that C attribute hierarchy is defined for each class in the class specifications. This turns out not to be the case. Since the COM hierarchy in the class specs contains methods and properties, the consensus was that the C attribute hierarchies should be added to the class specs while they are open for the COM additions. Someone needs to notify the people currently working on the class specs. Action item: Serge to add to Serge’s document. Serge will add the attribute hierarchy to the Scope spec, sends to everyone and directs other chairs (both existing and current) of class specs to add this to their task list.


It was noted that we should add the word Specification to the title of every specification, except where not appropriate such in the case of glossaries and style guides. Noel A (and Scott R) to update the spec status document to include the word specifications.

It was agreed that there is a need for a user’s guide for how to use IVI drivers. E.g. Code snippets that show how to achieve interchangeability or mix class and specific calls.

There was a question as to whether we should prohibit circular references in the COM hierarchy. Section 4.1.6 currently prohibits it. John Harvey will take it as a topic for offline.

John Harvey will review the wording on 4.1.8.2 SafeArrays with specific regard to our discussion in the COM working group on [out] parameters in Visual Basic.

Section 4.1.8 needs to be reworded to correctly describe why multiple IDispatch interfaces on the same object should not be used. The problem as stated is technically incorrect. John Harvey will work on this.

Discussed the issue of whether to use “ _32” in DLL names ala VXIplug&play. John Harvey will follow up with the Agilent VEE folks. Jon Bellin will follow up with the CVI folks.

Also discussed whether the filename conventions for C DLLs and COM DLLs need to be the same. Since we allow for the C and COM interfaces to be in the same DLL, it would seem that the filename conventions should be the same. Did not come to a conclusion yet. Action item for IVI-3.1 working group chairman (Scott Rust): Make sure to include this in section 6 of the IVI-3.1 specification.

Srdan and John Harvey will look into having COM drivers implement IProvideClassInfo2 interface in addition to the ITypeLibrary2 interface.

IVI Glossary Working Group

This is the first time the working group met. This will not be a spec. It will be IVI document number 5 (IVI-5). Since this is not a spec and will be updated often, it was suggested to be able to update the document between meetings or at a meeting before the General Membership Meeting so that the changes can be approved at the GMM. Terms will be included in the document if they appear in more than one spec or if the working group chairs think they should. The glossary will not include general industry terms that are not specific to IVI. Members of the IVI Foundation should send a list of terms and definitions to Noel Adorno ([email protected]). Working group chairs MUST send this information to Noel.

Compliance Working Group


mailto:[email protected]

Reviewed Dallas minutes and group’s charter. The group has decided to take on the responsibility to investigate and offer a proposal to the GMM what someone would have to do in order to receive the Foundation’s compliance stamp. This group will provide methodologies and serve as a repository of tools that can assist in testing for compliance. Group reviewed NI’s conformance test in the form of a text file (the Z test). The group discussed other types of tests that could be done. The group feels like they made good progress especially in the area of categorization.

In addition, Dean Lawler and Jeff Hulett talked about co-chairing the Conformance working group. The members of the Foundation should continue to use Dean as the main point of contact for the Conformance working group.

Power Meter

Zulfiqar has already left. Glenn Burnside summarized. The group made very good progress. The main thing left to do is to work on the COM hierarchy. The group expects to have the spec ready for final review after the Paris meeting and ready for a vote soon after.

User’s Working Group

Gayle Matysek summarized the group work. Details will be provided in the Users’ Group Meeting minutes.

3.7.2 Reviews From the Morning Working Group

Event Server, Support Model, Resource Locking Working Groups

Review draft 0.3 of the IVI-3.7 spec. They will send out a request to have a line-by-line review of the document. This will be discussed at an April 5 conference call. They hope to have that done by the Paris meeting. The working group would like to release the event server spec with the 3.x series. Roger asked for volunteers for implementing the Resource Locking component.

The common code support model group had a great discussion. The group will present some proposals to the legal working group for their review and assistance. At the Paris meeting, the group hopes to have a document that describes a proposed process for supporting the common code.

RF Signal Generator Working Group

Reviewed the meeting minutes from Dallas and worked through the action items. Two open items that were presented to the users: 1) how to deal with Power units: to solve some issues, the group decided to only use dBm 2) IQData uploading issue: decided to have Voltage units in order to be interchangeable, and also decided to have separate arrays for the I & Q data. Also introduced an API that removes the concerns for huge


memory usage when uploading data. Then worked on the Arb marker extension. Tomorrow they will review the Burst control extension and the COM hierarchy. The group hopes to have the spec ready for final review at the Paris meeting.

Legal and Promotions Working Group

Kevin Borchert summarized the work of the group. Walked through the timeline, before-and-after, and Chairperson cheat-sheet documents. Concerns were brought up about the sub-committee rules being too strict. Group reminded the members to turn in the applications by the deadline of today. More details are provided in the legal and promotions working group minutes.

Scott Rust suggested that the group make sure to ask the legal firm whether our process for holding informal meetings such as phone conferences can be as flexible as we want it to be. A discussion ensued about the need for the subcommittees to have as few rules as possible.

The decision was made to include language to say that it is left up to the committee chair to decide the official rules of how meetings would operate and whether informal discussions between meetings are considered official.

An issue came up about the reason why only users can be part of the Users’ committee. Pat Johnson said that his company is both a vendor and a user. It was decided that vendors can also become members at the discretion of the Users’ committee chair.

3.7.3 Review the spec status document – Scott Rust (NI)Discussed changing the name of the Common Code Support WG to Shared Component Life Cycle WG. Glenn B. and Roger O. volunteered to help Pat J. to complete the specification document.

The group also reviewed the spec status master document, and updated the spec numbers and owners.

The group decided that we need an answer to the question “what do I need to have in order to ship an IVI driver?” without having to duplicate the information already contained in the specs.

3.7.4 Process for reviewing and approving sets of specifications

Core Architectural Specifications, Existing Class Specifications, and New Class Specifications

Some specifications go together, and those are on the Q3-01 timeline. We want to put the specs on the “final review” status as they get completed. Scott expressed a concern to


vote on the brand new class specifications at the same time without having them go through the same process as the old specs. Scott has 2 proposals:1) In order to effectively review specs, Scott proposes to have incremental/serial review

of the specifications.2) Proposal to delay the approval and review of new specifications until after the core set

is approved.Steve Greer suggests the following order: Core, Updated, New. Jeff comments that you can proceed with development even if the core is not ready, because there is enough info in the class specs themselves. Jon B. explained that you can have a driver, but you can’t call it an “IVI” driver before the core specs are approved. (Except for the “1st generation drivers”). John H. stated that at Agilent, there is not a lot of overlap in people involved with the spec reviews (except for Steve G.). The idea is to take the class specs to the “final review” state. People involved with multiple specification work need to inform the working groups of possible delays.John H. suggests that quarterly schedule should not limit the voting schedule.

3.8 New Business Items

3.8.1 Life Cycle of a Working GroupJon Bellin wanted to bring up the issue of the Life Cycle of a working group. Usually when TWGs get started, it is not very formal and there is no mechanism to ensure that we can revisit the decision and decide whether the Foundation wants to go ahead with the specification or the working group.

John Harvey asked whether there was anything in the by-laws that would allow the technical committee to cease work on specs. Jon Bellin would like to have a process in place in order to decide on whether to suspend a spec or working group. What is the procedure for someone to challenge the existence of a working group.

It seems that the technical committee is the perfect forum for this to happen. We need to describe the process that one would have to follow in order to make this happen. The answer seems that the request would have to be put on the agenda of the technical committee meeting.

3.8.2 Source Code For Instrument DriversCurrently, we say that you do not have to provide source code but you are able to if you want. If you provide source code, you do not have to install it, and if you do, you have to use specific filename.

Pete Richardson that system integrators have to be able to promptly respond to their customers. Vendors can either allow them to do that by providing source code, or they can be available to support the integrators.


John Harvey suggested that the vendors decide whether they want to give the source code or not rather than it being mandated by the Foundation. It should be a business decision of the instrument driver vendor to decide whether they want to provide their customers with the source code.

The point was brought up that there are two types of drivers: 1) simple drivers that just call SCPI commands, and these are probably going to be provided in source. 2) there are the register-based instruments where the driver might implement some proprietary algorithms that the driver provider does not want to share.

John Harvey made a motion that IVI driver vendors shall not be required nor prevented from shipping source code. Jon Bellin seconded the motion. Jon Bellin amended the motion to state that the compliance document shall state whether the source code is available or not, either with the driver distribution or conditionally from the vendor. Badri Malynur seconded the amendment to the motion. Discussion: Scott Rust mentioned that we should be careful about a wrapper driver claiming source code availability. Pete Richardson mentioned that this solution would be fine but that users can decide not to purchase an instrument if the driver is not provided with source code. The amendment was approved 14-4. The motion was approved 13-5.

3.9 Schedule for Next Meetings

3.9.1 Info on the June Meeting (6/5 – 6/8) – Anne Faveur (Advantest)

Yohei Hirakoso from Advantest presented on behalf of Anne Faveur. The meeting is at the Hotel Brebant (www.abpromhotels.com) located at 30-32 Blvd Poisonniere. The price of the hotel is 760FF for single rooms and 960FF for double rooms including tax and breakfast. Hotel reservations must be done through France By Heart S.A.R.L. The travel agent will prepare a web site as soon as possible for us to make reservations (www.france-by-heart.com) The travel agency will also collect the meeting fees on our behalf.

Proposed track 1 working group activities Annual Meeting 2 hours First BoD Meeting 4 hours (In evening or in parallel w/ T&V) Technical Committee 2 hours Testing & Validation On Monday (check w/ Anne on availability) Config Store & IVI Factory 8 hours IVI 3.1 4 hours COM 2 hours MSS & Event Server 1 hour Shared Components Life Cycle 4 hours Guidelines for API Style 3 hours Glossary 2 hours


http://www.france-by-heart.com/

http://www.abpromhotels.com/

3.9.2 Info on the September Meeting

John Harvey made a motion to hold a meeting the week of September 10th. Jeff Hulett seconded the motion. The motion passed 15-0-1. Teradyne volunteered to host the meeting in Boston. The following meeting would be in December and would be hosted by NI (tentatively).

3.10 Adjourn

John Rosenwald made a motion to Adjourn. Motion was seconded by Teresa Lopes. Motion was unanimously approved. (18-0)


4. Working Group SummariesThis section contains the summaries that the various working group chairman gave regarding the work that was conducted during the February 2001 IVI Foundation meeting.

4.1 Config Store Working Group SummaryReviewed changes to iteration #5. Asaf gave a presentation on the C++ implementation. The implementation iteration #6 will be available in March. Discussed new helper functions. David Fuller gave presentation on XML extensibility mechanism. Will look into client server extensions. A smaller group will meet after iteration #6. Meeting date TBD. The purpose is to review more of the details such as installation, issues regarding schema and parsing, and to decide what is in the next iteration. The group will create an installation script and all code will be posted on the web site.

A major issue is that no one has been identified to write the specification for the Config Store. Agilent will write the specification for the IVI Factory.

The group feels that they will have two more iterations and plan to complete the work on or before the Paris meeting. At that point the remaining work will be to write/complete the IVI Configuration Store specification.

4.2 Signals Working Group SummaryHad planned to discuss digital and bus testing. However, several new individuals attended the meeting and the group spent the majority of the time reviewing the purpose and direction of the Signals working group. There were a lot of questions and misunderstandings. The group plans to update their presentation and white papers on the web site so that people can understand what the signal interface is.

Will have an interim conference call to discuss issues brought up. Will meet prior to the next general membership meeting to define answers to the following questions and then present them to the General Membership meeting.

1. What are the pieces and who implements them? 2. What is the business case.3. Who are the parties involved?4. What are the benefits?5. How does it give higher levels of interchangeability?6. How does the group plan to define or reference the definition of signals.

The group plans to update it’s charter.

Scott Rust asked that the group also give a status on the IEEE SCC20 efforts to standardize a signal model.


4.3 MSS Working Group SummarySpent the hour reviewing the draft of the MSS specification (IVI 3-10, Draft 0.4). Got a lot of feedback. One item regarding terminology has been fed forward to the Config Store working group. Would like to collect more feedback over the next two weeks and then update the draft. Will have a clean and stable draft by the Paris meeting.

4.4 IVI COM Working Group SummaryStarted by reviewing the location of COM info in the specs. Talked about a memory leak with output parms in VB 6.0. Will go with in/out parameters. Presented an approach regarding properties. The approach would require changes to the architecture. The group agreed to take no immediate action but will keep it in mind as they move forward.

Srdan presented the modified Scope specification that has been modified to contain COM information. Reviewed Srdan’s comments and the scope specification. Discussed how to represent the COM information in the specification. Srdan has also created macros that are useful in modifying the class specifications. The group identified owners for modifying the individual class specifications. The group needs to discuss the anticipated completion dates for the spec updates during the General Membership meeting.

The group also talked about demos and betas with the intent of supplying the user’s group with something that they can get their hands on regarding COM implementations. The group identified the use cases that they would like to demonstrate.

Talked about the needs of people who will write drivers. There is a need to support those people with tutorials and examples. Also, discussed discussion groups and mailing lists. Discussed the need to stabilize the components used to create the demos. Talked about and characterized the client testing needs. The I/O usage will be developers choice. Should have 8 to 13 COM drivers for people to play with by the next meeting (hoping for 5 to 10). Want to do some basic validation and post the drivers by May 10th so that people can develop applications prior to the meeting.

The group feels that the spec work is winding down for COM. The group feels that they should use the working group for testing and validation of COM implementations. The group wants to put a testing/validation session earlier in the week and not to conflict with the user group meeting.

4.5 IVI C Working Group SummaryReviewed IVI 3.9 and 3.12. Made some minor wording changes. We declared them ready for a final review.

In the General Membership meeting we should discuss the final review and voting phases for all of the specifications. We would like to move all of the core architectural specs through this process in unison.

The group does not think any additional work needs to be done by the C Working Group prior to the final review for all of the core architectural specs.


4.6 Spectrum Analyzer Working Group SummaryGroup agreed on the COM hierarchy for the spectrum analyzer. The group would like to have a similar C hierarchy. Will discuss this during the API Style Working Group.

Other questions raised by the working group:

Do we need a table that shows which functions affect which attributes?

Do we need something similar for the function parameters that show which attributes they affect?

Need to reformat the spec and add the COM spec. Will do so by the Paris meeting and attempt to vote on the specification after the Paris meeting. The group does not think they need much time at the Paris meeting. Will know for sure 1 month prior to the meeting.

4.7 Digital Working Group SummaryThe group reviewed the class specification focusing on the parts that had changes since the last meeting. Reviewed the COM hierarchy. It is not finalized.

There was suggestions for making the static and dynamic extensions more similar. Anyone with comments on the specs need to get them to Teresa in 3 weeks.

The group will demonstrate demo digital drivers at the next meeting.

Assuming that there are no major issues raised at the Paris meeting, the spec should be ready for a vote.

4.8 Users Working Group SummaryReviewed the SW demo package supplied by Noel Adorno (NI). The package shows how class drivers work in CVI, LV, and more traditional C/C++ development environments. The demos run in simulation.

Discussed questions regarding David McKay’s presentation during thfe COM working group. The group did not give much feedback.

Reviewed a document that attempts to capture user requirements. They will continue to review the document today.

4.9 IVI 3.2 Working Group SummaryReviewed changes made since last conference call. Added some COM interfaces that were left out in section 4.Added places to insert GUIDs for COM interfaces. We will put the real GUIDs into the spec just before the final review. Raised the question of the implications of class drivers using C and COM wrappers, with specific regard for packaging, installation, and the configuration store. Will work on this immediately after this meeting.


Zulfiqar will accept the changes as soon as he has reviewed them.John Harvey proposes that in general we should track the changes to specs and accept the changes while attending the IVI meetings. We can use the “Word Compare Documents” feature to generate a succinct list of changes.After making the spec changes that are listed above, we consider this to be ready for final review.

4.10 IVI 3.1 Working Group SummaryReviewed the changes to the document since the conference call, except we did not have time to get to Sections 4.1.11 through 4.1.18, and section 5.13. We will cover those in conference calls.

Section 6, Installation Requirements, has not yet been started.

Issue arose as to whether to require that drivers ship with source code. Currently, spec does not require this. Peter Richardson has concern about being able to debug and fix a system rapidly without source code. John Harvey expressed concern about being forced to reveal proprietary algorithms for some drivers or to reveal COM-in-the-box source code. It was agreed that this issue should be brought up in the general membership meeting. This topic was discussed at some length. It was agreed that drivers did not need to install source code automatically if they supplied it on the CD.

Spec assumes that C attribute hierarchy is defined for each class in the class specifications. This turns out not to be the case. Since the COM hierarchy in the class specs contains methods and properties, the consensus was that the C attribute hierarchies should be added to the class specs while they are open for the COM additions. Someone needs to notify the people currently working on the class specs. Action item: Serge to add to Serge’s document. Serge will add the attribute hierarchy to the Scope spec, sends to everyone and directs other chairs (both existing and current) of class specs to add this to their task list.


It was agreed that there is a need for a user’s guide for how to use IVI drivers. E.g. Code snippets that show how to achieve interchangeability or mix class and specific calls.



Section 4.1.8 needs to be reworded to correctly describe why multiple IDispatch interfaces on the same object should not be used. The problem as stated is technically incorrect. John Harvey will work on this.


Discussed the issue of whether to use “ _32” in DLL names ala VXIplug&play. John Harvey will follow up with the Agilent VEE folks. Jon Bellin will follow up with the CVI folks.

Also discussed whether the filename conventions for C DLLs and COM DLLs need to be the same. Since we allow for the C and COM interfaces to be in the same DLL, it would seem that the filename conventions should be the same. Did not come to a conclusion yet. Action item for IVI-3.1 working group chairman (Scott Rust): Make sure to include this in section 6 of the IVI-3.1 specification.

Srdan and John Harvey will look into having COM drivers implement IProvideClassInfo2 interface in addition to the ITypeLibrary2 interface.

4.11 Glossary Working Group SummaryThis is the first time the working group met. This will not be a spec. It will be IVI document number 5 (IVI-5). Since this is not a spec and will be updated often, it was suggested to be able to update the document between meetings or at a meeting before the General Membership Meeting so that the changes can be approved at the GMM. Terms will be included in the document if they appear in more than one spec or if the working group chairs think they should. The glossary will not include general industry terms that are not specific to IVI. Members of the IVI Foundation should send a list of terms and definitions to Noel Adorno ([email protected]). Working group chairs MUST send this information to Noel.

4.12 Compliance Working Group SummaryReviewed Dallas minutes and group’s charter. The group has decided to take on the responsibility to investigate and offer a proposal to the GMM what someone would have to do in order to receive the Foundation’s compliance stamp. This group will provide methodologies and serve as a repository of tools that can assist in testing for compliance. Group reviewed NI’s conformance test in the form of a text file (the Z test). The group discussed other types of tests that could be done. The group feels like they made good progress especially in the area of categorization.

In addition, Dean Lawler and Jeff Hulett talked about co-chairing the Conformance working group. The members of the Foundation should continue to use Dean as the main point of contact for the Conformance working group.

4.13 Power Meter Working Group SummaryZulfiqar has already left. Glenn Burnside summarized. The group made very good progress. The main thing left to do is to work on the COM hierarchy. The group expects to have the spec ready for final review after the Paris meeting and ready for a vote soon after.

4.14 VISA VXIplug&play Technical Working Group Meeting SummaryThe main thing that the group was working on was to finish the VISA-COM spec. The group went through a lot of feedback from members. They dealt with six main issues:

1. Enumerations vs Longs: use enums where appropriate



2. Shared components: want to use the same model as IVI. Action item: NI and Agilent make sure that they will donate the components they are writing

3. Versioning: allow for independent versioning of C and COM4. Timeframe for COM: could be finished sometime in April.5. Multi-vendor C interoperability impasse. The Passport model was discussed and

Agilent stated that they would not support the Passport model. Jon Bellin brought up the discussion that happened in the IVI-3.1 working group at the Dallas meeting (referenced in the Nov2000 meeting minutes) to the effect that for the requirements for VISA-C and VISA-COM agreed to at that meeting to work, the interoperability problem with VISA-C must be solved. Ni interpreted this as a commitment to actively pursue a solution. Agilent did not interpret the discussion as a firm commitment, but rather a statement of the facts and a strong desire to fix them. Agilent suggests offline discussions to resolve the issue. Badri Malynur asked what offline means. Will other members of the IVI Foundation and VXIplug&play have a chance to view the different solutions and make an informed decision? Dan Mondrik mentioned that NI has said that they would be willing to present the Passport model and asked whether Agilent would be willing to present the Tulip alternative. John Harvey said that they were not prepared to discuss this at this meeting and would have to think about and discuss the issues internally before they can state a position to the group. Badri Malynur stated that Tektronix also has the same interoperability issues with their version of VISA. John Harvey said that he assumes that whatever solution is decided upon will eventually have to approved through the appropriate standard bodies (VXIplug&play currently). Jon Bellin stated that since in the past we have included the COM I/O discussions in IVI, then we should also be prepared to discuss the progress of the efforts to solve the multi-vendor interoperability VISA-C problem. John Harvey said that the spokesman for Agilent on this issue (Steve is not currently present). Roger Oblad asked whether we can make the decision of whether VISA should be under VXIplug&play or IVI. Scott Rust took the action item to figure how we can organizationally handle VISA to bring it under IVI or not. Dan Mondrik will report back to both listservers about the plan to resolve this issue (within three weeks).

6. Next meeting: that issue was not resolved and will be decided upon within three weeks.

4.15 Event Server and Resource Locking Working Group SummaryReview draft 0.3 of the IVI-3.7 spec. They will send out a request to have a line-by-line review of the document. This will be discussed at an April 5 conference call. They hope to have that done by the Paris meeting. The working group would like to release the event server spec with the 3.x series. Roger asked for volunteers for implementing the Resource Locking component.

4.16 Common Code Support Model Working Group SummaryThe common code support model group had a great discussion. The group will present some proposals to the legal working group for their review and assistance. At the Paris meeting, the group hopes to have a document that describes a proposed process for supporting the common code.


4.17 RF Sig Gen Working Group SummaryReviewed the meeting minutes from Dallas and worked through the action items. Two open items that were presented to the users: 1) how to deal with Power units: to solve some issues, the group decided to only use dBm 2) IQData uploading issue: decided to have Voltage units in order to be interchangeable, and also decided to have separate arrays for the I & Q data. Also introduced an API that removes the concerns for huge memory usage when uploading data. Then worked on the Arb marker extension. Tomorrow they will review the Burst control extension and the COM hierarchy. The group hopes to have the spec ready for final review at the Paris meeting.

4.18 Legal Working Group SummaryKevin Borchert summarized the work of the group. Walked through the timeline, before-and-after, and Chairperson cheat-sheet documents. Concerns were brought up about the sub-committee rules being too strict. Group reminded the members to turn in the applications by the deadline of today. More details are provided in the legal and promotions working group minutes.

Scott Rust suggested that the group make sure to ask the legal firm whether our process for holding informal meetings such as phone conferences can be as flexible as we want it to be. A discussion ensued about the need for the subcommittees to have as few rules as possible.

The decision was made to include language to say that it is left up to the committee chair to decide the official rules of how meetings would operate and whether informal discussions between meetings are considered official.

An issue came up about the reason why only users can be part of the Users’ committee. Pat Johnson said that his company is both a vendor and a user. It was decided that vendors can also become members at the discretion of the Users’ committee chair.


5. Config Store Working Group

5.1 General Meeting Info:Date of Meeting: February 26, 2001Location: San Diego, CAChairperson: Bud CribarMinutes Prepared By: Stephen Greer

5.2 Meeting Attendees:

Name Company Phone EmailAnthony Nudelman VektexKirk Fertitta Pacific MindworksDon Zoachi TektronixBud Cribar Agilent Technologies 970-679-2061 [email protected] Kashi Agilent Technologies 707-577-4577 [email protected] Harvey Agilent Technologies 970-679-3535 [email protected] Greer Agilent Technologies 970 679 3474 [email protected] Okuyama ASCOR, Inc 510-490-2300 [email protected] Fuller National Instruments 512-683-5399 [email protected] Burnside National Instruments 512-683-5472 [email protected] Bellin National Instruments 512-683-5516 [email protected] Adorno National Instruments 512 683 5071 [email protected] Zirojevic National Instruments 512 683 5374 [email protected] Tholandi Nokia Mobile Phones, Inc. 858.831.4547 [email protected] L Cole Northrop Grumman 410-993-5173 [email protected] Ptacek Rockwell Collins 319-295-0198 [email protected] Ganzert Rohde & Schwarz +49 89 4129 13405 [email protected]

schwarz.comBadri Malynur Tektronix 503-627-5880 [email protected] Keith Rule Tektronix 503-627-4338 [email protected] Teresa Lopes Teradyne 978-370-1377 [email protected] G McKay Thales Instruments (aka Racal) +44-1202-872800 [email protected] Hazlewood Thales Instruments (aka Racal) +44-1202-872800 [email protected] Geathers TYX Corporation 703-264-1080 [email protected] A. Neag TYX Corporation 703-264-1080 x132 [email protected] Eriksson Vektrex 858-458-5822 [email protected] Schwartzberg

Winsoft 714-444-4844 x204 [email protected]



5.3 Topics To Be Discussed:Review of UMLChanges made for Iteration 5Walkthrough of Repeated CapabilitiesUpdate of C++ ImplementationHelper APIsProposal for componitized XML schema definitionSchedule and features for Iteration 6

5.4 Record of Discussions:UML Diagram in handout:

Virtual names – changed from alias names and logical namesWhy is it part of base class? Used serialize and deserialize terms.Change DriverComponent to DriverSessionSupported Instruments

Implementation notes from handout:Trouble finding a parser for the UML. Expect another parser coming out from MicroSoftThe server could create new items in collections at the request of the client. Or the client could create an object and ask the server to add it to a collection. Would be nice if all collections worked the same way. DOM uses server creation. Will make a decision based on how difficult the implementation is.Java parsers are slower than other parsers. J++ is going away as a language.Where is config store located? Current parser does not validate.Who is writing the Config Store specification? No one has the assignment right now. Should be brought up at the general membership meeting. Can’t just assume NI will do it.Installation and un-installation is a concern. David Fuller will touch on it in his presentation.Do we need a version number in the SoftwareModule? .NET has a version associated with a DLL so they can be differentiated and multiple versions can reside on a system. Should Config Store mimic this policy? It isn’t necessary. Is it useful enough to include? Version number of the desired driver version better belongs in the DriverSession. The config store file contains which versions of the driver are acceptable. Whatever loads the driver must check a driver’s version against what is allowed by the config store. Is this use case common enough to justify adding the information and required code? If during installation discussion we think adding version would be useful, only then will any change be made.Do we need defaults for some of the methods? Typically we have Name as the default. In general, no defaults, but perhaps for Item in collections and Value for some others such as String. Looks like a natural type in the language. Also hides operations which the user can’t see.Meta data is important. Defer until David Fuller’s discussion.

Asaf’s presentations on C++ implementation.Full C++ implementation with iteration 6. MS parser is not validating. When we release, we will have a validating schema.


Helper APIs:1. GetIviConfigComponent – follow the virtual name chain until it finds the component at

the end of the chain. A user could give the same name to components of different types. How is the ambiguity resolved? Virtual names must be unique. The collection of virtual names off the root cannot contain conflicting names. Each component can have its own collection of logical names.Separate logical names from virtual namesThis API works at the ConigStore level and maybe for roles, but nowhere else.

2. GetIviComponentList – returns list of names that supports a certain role. Change name to GetIviComponentListByRole. Need a example of how role components behave. Lots of confusion about how roles work and how this method would work.

3. GetIviConfigComponentListByAttribute – the name string could be very sophisticated expression of what to find. It could be a generalized xpath expression.

4. GetInstalled???List – could return a list of components with a specific type, such as all the DriverComponents.

David Fuller’s presentation on XML Extensibility MechanismsExtensibility mechanisms have implications on implementation.When a vendor installs a driver, it might add a XSD file to describe vendor extensions and add a line to the IVI Config Store XSD. This XSD is just a list of includes.What is potential of vendor extension colliding with each other? Suggestion is to use traditional vender prefix on extensions.A user might want to extensions beyond the vendor extensions. The user must extend from each vendor extension. We are tending to expose XML rather than hide it. If you do an extension are you required to supply a schema? Yes.A user won’t have to use several configuration management tools to configure drivers from different vendors even if those vendors have different extensions.Dave or Asaf: verify that key and keyref support Asaf’s use case - role component verification. Is the IVI config store just for IVI and MSS stuff or is it a generalized configuration tool? It probably doesn’t support general configuration very well.There are tools which make creating new schema which inherit from IVI defined schemas relatively easy. WG needs to decide how far to extend the API to cover some XML specific things.There are deployment and installation issues that need to be resolved. Should be separate installable components from configurable components? More discussion on meta data such as requiring min/max for numeric values.

Iteration 61. C++ implementation2. Helper functions – need more than those Asaf mentioned. Jon Bellin has some ideas on

ones needed.3. Client or server collection needs a resolution4. Compare XML produced by implementation vs. that generated by tools David Fuller

found.


5. Logical name vs. virtual name change6. Compare XML generated against that generated by new Microsoft tools7. Available on March 30. 8. Installation script9. Will be posted on the web site.

Need to have an interim working group meeting in person. Actual date and place to be determined. About five seem interested in attending such a meeting.

Part of the Config Store component is an installation which silently installs the component. A driver installation would use this installation.

IviFactory – need a specification written. Implementation is estimated to be 100 lines of code. Who owns writing the document? John Harvey volunteered to write. Implementation will wait until after iteration 6 is done.

Bud will post latest available UML, etc. to the web site.

Is the config store a good place to store cal data?


6. Signal Interface Working Group

6.1 General Meeting Info:Date of Meeting: February 26, 2001Location: San Diego, CAChairperson: George Geathers on behalf of Narayan RamachandranMinutes Prepared By: George Geathers


Name Company Phone EmailAlex Spivak Winsoft 714-444 4844 [email protected] Richardson BAE UK +44 131 314 2332 [email protected]

mJohn Rosenwald Racal Instruments 210 699-6799 [email protected] Johnson Racal Instruments 210 699-6799 [email protected] Hutchinson Teradyne 978 370 1377 [email protected] Matysek Northrop Grumman 410 765-9754 [email protected]

omRoger Oblad Agilent 707 577-3466 [email protected] Stern Agilent 707 577-2886 [email protected] Petty BCO [email protected] Wegener Boeing 314 234-3801 [email protected] Davis Boeing 210 699-6799 [email protected] Wolle Rohde & Schwarz +49 894 129 3049 [email protected]

schwarz.comIon Neag TYX 703 264-1080 [email protected] Geathers TYX 703 264-1080 [email protected]

6.3 Record of Discussions:George Geathers opened the meeting, acting on behalf of Narayanan Ramachandran who was unable to attend. George asked the attendees to introductions themselves. Additionally, he requested first time attendees to state their rationale for participation. Scott Rust of National Instruments joined the meeting to gain an understanding of the Signal Interface. Peter Richardson of BAE Systems (UK) attended the meeting as a user to assess the functionality and use of the Signal Interface within the IVI Architecture.

6.3.1 Reviewed points/issues from meeting in November

Ion began to recap the progress achieved in the November SIWG meeting. Changes discussed during the last meeting were added to the revised Signal Interface Functional Specification (draft 0.4) available on the SIWG section of the IVI web site. Ion presented the following agenda;

Review Digital Testing section of the Functional Spec.









Review Bus Testing section of the Functional Spec. Review RF and Microwave Testing section of Functional Spec.Discuss semantics of self-test for Signal Components Discuss Resource information Discuss use cases for composite signals Discuss sources of interchangeability problems in ATE Discuss survey questions to be submitted to the Users Group.

The SIWG was informed that Eric Sacher, author of the proposed semantic for digital test section, had dropped out of the IVI Foundation. Eric will no longer support the IVI initiative. A suggestion was made to have Teresa Lopes of Teradyne get involved. Unfortunately, Teresa was not available for the meeting. A proposal to use standard digital constructs utilized within the ATLAS language was introduced. In lieu of lack of support for specialized Digital support, the use of standard ATLAS digital semantic would suffice.

Ion continued to the Bus Testing section. He asked the available users in the meeting if a requirement for specialized Bus Testing existed. Should the signal interface support Bus Testing and what capabilities would users prefer?

At this point - Scott Rust requested clarification of the use of the Signal Interface and what exactly is its purpose and merits. Are we defining the semantics of the Signal Interface?

-Ion Neag gave slide presentation of basic SI reference architecture. He explained the purpose of the SI and highlighted the signal based test paradigm. - Ion discussed and pinpointed the specific information required for higher levels of instrument interchangeability based on the signal paradigm. -Ion responded with goal of IVI in general - the standard to be developed must fit the main IVI targets, which are interfaces for instrument control. This position is consistent with the charter of the Signal Interface working group. The Signal Interface only addresses instrument interchangeability from the perspective of an IVI-MSS role component interface, not through system wide functionality. However, the overall ATS architecture is analyzed for its impact on signal interface. - Roger Oblad and Bob Stern responded with their assessment of the degrees of interchangeability. Roger also mentioned the work load required to define/implement architecture vs. the interchangeability benefits. - Scott Rust asked if the SIWG would define the semantics of Signals. - Ion responded that the semantics of Signals may be provided by standards created by external organizations. - George mentioned the IEEE SCC20 and ATLAS 2000 initiative as a recommendation from the DoD and UK MoD users. - Ion explained the generic transmission of parametric data via the SI, allowing external definitions of signal parametrics. - Ion continued with response - Resource capabilities unique to the specific instrument are identified in the reference architecture. The SI separates the resource description from signal control.

-Resource Allocation is not required for the SI to operate. Architecture should support no resource allocation, manual allocation and automatic allocation ( both static and dynamic ). This arrangement facilitates support for legacy, current and future implementations. We should not be concerned about the internals of client application.The case was made that the IVI Foundation is not the proper place to standardize functionality such as resource allocation services.


- The SI may borrow framework attributes and concepts (signal types, synchronization mechanisms, etc.) from the ATLAS language, but it should avoids its potential problems. (e.g. extensibility). - Scott Rust requested an edit of the charter statement; such that signals will be defined by external organization or state the subset of signal to be defined by the SIWG. Furthermore, How do we resolve Signal Standards and define parametrics? Are there any other signal standards groups other than the IEEE SCC20.- George Geathers responded that ATLAS was created to address test problems within the commercial airline industry. ARINC was the original organization, but now the IEEE SCC20 controls and publishes the ATLAS standards. Furthermore, the IEEE and the IEC are the proper standardization organizations.- Andy Hutchinson suggested the inclusion in the SI specification of definitions for a set of basic signal types.- Ion continued presentation of use cases and possible architecture example for the participants. The Signal Interface is (1) Application Independent and (2) Instrument Independent.- Ion stated two advantages of Automatic Resource Allocation -

Automatic selection of signal capabilities from available instruments - Verification that resource meets test capabilities requirement –

Roger made a comment concerning ground rules for items to be standardized in the SIWG – He suggests critical elements that effect vendor interchangeability.

General comments were made concerning the lack of understanding of Principles, Architectures and Benefits of the Signal Interface. A request was made to create informational presentations, white papers and reference documents that better describe the essential features of the Signal Interface. Likewise the following additional questions should be addressed;

What are the elements (pieces) of SI architecture and who supplies (creates) the elements? What are the benefits of Signal Interface? What does SI provide beyond IVI-MSS and IVI Class

Drivers? Abstract & Business Case should address user, instrument vendor, solution provider and systems integrator.

How to delegate the specification of signal type information to others standards

Participants with an understanding of Signal Interface concept provided the following answers. Signal Abstraction – creation of generic test sequences Provides ability to query resource capabilities Relationship to other IVI components Use cases

These concepts will be presented to the General membership Meeting at the next IVI meeting. A charter amendment will be proposed, to better reflect the principle of the approach and the outcome of the SI Working Group activities. It was suggested to discuss the above issues in a webcast.


7. IVI-MSS Working Group

7.1 General Meeting Info:Date of Meeting: February 27, 2001Location: San Diego, CAChairperson: Roger ObladMinutes Prepared By: Asaf Kashi


Name Company Phone Email

Dean Lawler Hamilton Software

Don Zocchi

Fred Bode Bode Enterprises (619) 297-1024 [email protected]

Kirk Fertita Pacific MindWorks [email protected]

Rengan Rajendran

Asaf Kashi Agilent Technologies 707-577-4577 [email protected]

Bob Stern Agilent Technologies 707-577-2886 [email protected]

John Harvey Agilent Technologies 970-679-3535 [email protected]

Roger Oblad Agilent Technologies 707-577-3466 [email protected]

Terukuni Okuyama ASCOR, Inc 510-490-2300 [email protected]

David Fuller National Instruments 512-683-5399 [email protected]

Jon Bellin National Instruments 512-683-5516 [email protected]

Noel Adorno National Instruments 512 683 5071 [email protected]

Srdan Zirojevic National Instruments 512 683 5374 [email protected]

Balan Tholandi Nokia Mobile Phones, Inc. 858.831.4547 [email protected]

Gayle Matysek Northrop Grumman 410-765-9754 [email protected]

John Rosenwald Racal Instruments 210-699-6799 x 212 [email protected]

Dave Placek Rockwell Collins 319-295-0198 [email protected]

Johannes Ganzert Rohde & Schwarz +49 89 4129 13405 [email protected]

Alex Burggraf Software AG 925-242-3746 [email protected]

Mike Lindstedt Software AG 925-242-3724 [email protected]

Badri Malynur Tektronix 503-627-5880 [email protected]

Keith Rule Tektronix 503-627-4338 [email protected]

Dave McKay Thales Instruments (aka +44-1202-872800 [email protected]


Racal)

Richard Hazlewood Thales Instruments (aka Racal) +44-1202-872800 [email protected]

Tom Gaudette The MathWorks, Inc 508-647-7759 [email protected]

George Geathers TYX Corporation 703-264-1080 [email protected]

Ion Neag TYX Corporation 703-264-1080 x132 [email protected]

Alex Spivak Winsoft 714-444-4844 x209 [email protected]

Gariela Schwartzberg Winsoft 714-444-4844 x204 [email protected]

7.3 Topics To Be Discussed:Review of the IVI-3.10 Spec version 0.4Collect more feedback on the spec

7.4 Record of Discussions:RO = Roger ObladRO: Quick overview of MSS using presentation slide graphically depicting MSS componentsRO: Asked for feedback about agenda for the hour. <No comments>By show of hands, only half a dozen or so people received the spec via email and read it prior to the meeting.RO: Discussed the 3.10 spec section by section.RO: Section 2.4 definitions should be looked at as candidates for the top level IVI Glossary

Jon Bellin: Point 4 of Section 3 of the spec is vague. {Change placed in to Version 0.5}John Harvey: Isn’t it more of a packaging issue?Jon Bellin: Feels that it says that IVI Drivers are not interchangeable, suggest to talk about it in a higher level abstraction level.

Resolution: {Change placed in IVI-3.10 Version 0.5}

Jon Bellin: Point 5 of Section 3: Need a place to guarantee it that inst drivers can’t provide. Need a place for a solution provider to guarantee. Too out of the blue of why it ties into MSS.Ion Neag: Change Must to enables… with additional defined layers

Resolution: {Change placed in IVI-3.10 Version 0.5}

Kirk Fertita: Section 4.2.3.1 Maybe we should change the IviRoleComponent to IviMSSComponent in config store.

Resolution: Will be discussed with the Config Store Working Group…

Srdan Zinjev: Section 4.3 Change the passive voice to standards language.(shall be provided)

Jon Bellin: Section 4.3.2 Be more specific about which specs are not followed.David Fuller: Section 4.3.2 Be more specific about which specs are followed.John Harvey: Section 4.3.2 Work with Stephen Greer on which specs are followed.


Resolution: Will ask Steve Green to review and identify requirements from the config store. A reminder Note has been placed in IVI-3.10 draft Version 0.5.

Jon Bellin: Section 5: Definition of Conceptual Asset is needed. Also show that a role control module can call other role control modules.

Resolution: A reminder note placed in IVI-3.10 draft Version 0.5. to address this.

Ion Neag: What type of code goes into servers? what goes into role control modules? Maybe figure 3 shouldn’t show the server and rcm as separate pieces? He wants more design principles describing his initial comment in this section.

Resolution: Ion will send a proposed diagram and other inputs via e-mail.

Jon Bellin: Doesn’t want to make the distinction between IVI-MSS Server and Role Control Module.

Resolution: Will be resolved in conjunction with Configuration Store work. The true distinction between a server and a Role Control module is that the former has a published interface.

Gabriela Schwartzberg: wants to understand how to configure this system, what does the user see?

Resolution: A reminder note placed in IVI-3.10 draft Version 0.5. to address this.

David Fuller: Configuration, Design, UseIon Neag: Disagrees with David Fuller, understands that we have need to have multiple layers to support aggregation. Config Store needs to have single object and allow multiple aggregation levels. Fig 3 in section 5 is independent of differences in server versus role module.


8. COM Working Group

8.1 General Meeting Info:Date of Meeting: February 27, 2001Location: San Diego, CAChairperson: John HarveyMinutes Prepared By: John Harvey

8.2 Topics To Be Discussed:- COM & The Specs- IVI-COM IDL Issues- The IVI-Scope Spec- Updating Class Specs- “Beta” Projects

8.3 Record of Discussions:

John Harvey reviewed where to find COM information in the specs. See the COM WG presentation on the web site.

Kirk discovered that [out] parameters leak memory in VB 6.

Discussion of [out] parameter leak in VB- Investigate Visual Studio 7 to see if this problem is fixed. (John Harvey)- Make sure we perpetuate this decision to the VISA I/O group. The I/O group is

ready to vote, and needs an answer. The I/O group is not willing to allow the leak.

Straw PollOption 1: Make all [out] parameters [in,out] - 15Option 2: Keep all [out] parameters [out] - 9Option 3: Make scalars [out] and arrays [in,out]

Decision – go with option 1 for the initial set of IVI-COM specs.For 3.4 – Class specs should specify when an [in,out] parameter is only used as an [out] parameter.

If we ever do SAFEARRAY properties, MIDL will try to choke. Steve will document in 3.4.

David McKay presented Thales Instrument’s approach to representing properties. His presentation will be posted on the web site. Addressing these issues would require changes to the architecture, and Ion Neag and Roger Oblad noted that MSS could potentially be used to


address some of David’s concerns. No immediate action items, but issues to keep in mind as we move forward.

Serge Zirojevic presented the Scope spec as updated to include IVI-COM information. He passed out two documents. One was the updated Scope document and the other was a follow-on document with feedback from reviewers and examples of the types of changes made. Both documents will be posted under the scope working group.

Serge has also created macros for automating part of the updating process. He will make the macros available to those who are updating specs, and instructions for running the macros in the correct order. Some of the macros may require document edits prior to running the macro, so that the macro works correctly.

Serge reviewed the list of comments sent to him by reviewers, and the additional changes that he made as a result. Some decisions were made regarding details that Serge noted. Serge also added information to describe the IVI-COM collection information.

We decided to change the value of max time out constants. We decided to change compliance notes to refer to IVI-C custom class drivers.

Some scope IDL changes need to be made, found in the process of reviewing the spec. AcquisitionStatus should be a method. Change names: Envelopes->NumberOfEnvelopes, Averages->NumberOfAverages.

Discussion on how to reflect IDL in the document. Do we put it in the spec, or do we refer people to standard files in a well known IVI location? We need to include at least the GUID’s in the specs, since they would otherwise only be found in the .idl files. Appendix C will contain .h text. Appendix D will contain .idl text.

The following people have responsibility for updating class specs with COM information. Scope Srdan Zirojevic DCPwr Steve Greer DMM Zulfiqar Haider Fgen Agilent Swtch Srdan Zirojevic SpecAn Neil Shah (??) RFSigGen Johannes Ganzert PowerMeter Zulfiqar Haider Digital Teresa Lopes

Demo Goals (potential) Being able to talk to an instrument specific interface w/o going through the class

interface. Use class-complaint interface with a logical name. Multiple class compliant interfaces in one component.


Demonstrating issues related to leveraging class-compliant interfaces to specific interfaces.

Intermixing calls to class-compliant interfaces and instrument specific interfaces Are there any inherent interfaces we want to make a point of showing? DCOM Repeated capabilities Interchangeability

Write a tutorial for driver writers.What about the idea of a model IVI driver?

Focus on COM technology exposing C and COM wrappers internals of dealing with the config store.

Developers Discussion

Standard IDL John Harvey will make known changes to the class and inherent IDL within a week. John Harvey will add Johannes’ SpecAn IDL into the standard IDL project. At that point, John will post it. When the RFSigGen IDL is available, it will be added.

Config Store We will use iteration 5 of the config store to begin. We can switch to iteration 6 when it is available if the impact is not too great. We can get the feedback to the config store team.

IVI Factory Post the existing source for the factory on the web site. Racal will provide the IVI shared component. Driver developers can write their own if needed.

Questions on Driver Technology John is willing to answer COM technology questions and attempt to handle general

questions. Glenn Burnside is available to handle general IVI technology questions and will attempt

to answer COM questions. Serge is willing to share ideas on creating both C and COM interfaces with minimal

incremental effort.

Issues for client testing ADE & platform testing. DCOM testing. Interchangeability – would be nice to pin down issues that surfaced in Munich and

address them.


o NI & Agilent will cooperate on some interchangeability testing on DMMs. Performance characterization.

o In process vs. out of process vs. remote.o Impact of [in] vs [in/out] – how bad do we hurt C++ developers?o QI vs. interface reference pointers (& collections).

I/O usage – For this round of drivers, developers are free to use the I/O of choice.

John Harvey will create and maintain a schedule for beta/proto work, and try to do the coordination to keep the momentum going.

DMM (IDL) - Agilent(Src,1-2), NI(Src,1-2) DCPwr (IDL) Fgen (IDL) - Agilent(Src,1) Scope (IDL) - NI(Src,1-2) Swtch (IDL) - Racal (?,1-2), TYX (?,1) SpecAn (IDL) - R&S (?,1) RFSigGen (IDL soon) - R&S (?,1) PowerMeter - Agilent(Obj,1) Digital - Teresa possible

If we can validate drivers prior to the meeting, post drivers by May 10. That will allow others to write client programs to test the drivers.

Planning for next meeting As the spec work winds down, should we spend more time on testing/validating. Be careful to schedule so that people can attend sessions they are interested in. Testing/validation session should probably be earlier in the week.


9. IVI C Working Group

9.1 General Meeting Info:Date of Meeting: February 27, 2001Location: San Diego, CaliforniaChairperson: Jon Bellin / Glenn BurnsideMinutes Prepared By: Glenn Burnside

9.2 Topics To Be Discussed:

For both the IVI 3.9: C Shared Components and the IVI 3.12: Floating Point Shared Component:Review changes since last conference call.Discuss any remaining open issues.

9.3 Record of Discussions:All changes were reviewed and accepted. Some small wording issues were resolved.There were no remaining open issues.


10. Spectrum Analyzer Working Group

10.1 General Meeting Info:Date of Meeting: February 27, 2001Location: San Diego, CAChairperson: Lynn Wheelwright substituting for Neil ShahMinutes Prepared By: Lynn Wheelwright


Name Email Address Company

Craig Cole [email protected] Northrup Grumman

Jochen Wolle [email protected]

R & S

Glenn Burnside [email protected] NI

Lynn Wheelwright [email protected] Agilent

Yohei Hirakoso [email protected] Advantest

Bob Stern [email protected] Agilent

10.3 Topics To Be Discussed: Discuss General Issues Discuss Marker Extension Group’s Open Issues Discuss/Review COM AND C Function Hierarchy Final Inspection of the Specification

10.4 Record of Discussions: Approve November 2000 Meeting Minutes

Approved Unanimously

General Issues: Improved Linkage between the attributes and the functions that call these

attributes Talk to Steve Greer about updating the Style Guide to enable this! Mention in

morning report out. The question is: do we want to add an explicit listing in all of the specs to cover this? Question: Do we need a table by function of what attributes are affected? Question: Do we need a table of function parameters telling what attribute is

affected?









Action item: update style guide relating to explicit mention of parameters that set attributes.

Action item: update specification to conform to style guide. No action item necessary relative to floating point comparisons.

Marker extension group open issues Approved Peak Excursion Diagram for inclusion in the specification. DONE – inserted

in attribute section. Agreed to change markerToPosition parameter to valueToSet. DONE Spcan31 and 32 are closed.

COM and C Function hierarchy Approved the COM hierarchy drawing. Discussion of C hierarchy drawing: having entries with only one child seems

unnecessary. Maybe these can be consolidated at the next higher level. Question for wider group: Should we consider having the C hierarchy drawing as

part of style guide? Other issues and concerns

Action Item: 4.3.3 move descriptive information to attribute section. DONE Check rest of specification for other cases of this. NOT DONE.

Action Item: add more explanation to Vertical Scale to distinguish it from amplitude units. DONE

Action Item: remove triggering and calculations from behavior model of base instrument. Place current behavior model in trigger extension groups that affect it (with highlighting to emphasize what the current extension group is adding). Extension groups affected: triggering, markers. DONE

COM Formatting Action Item: IDL and .h files become an appendix to specification. We need to create

these! (R&S will do IDL) (Glenn or Zulfiqar will do .h file) Meeting Adjourned.

New “Open” Action Items from February 2001 Meeting

SPCAN49 Update Style Guide to have explicit mention of parameters that set attributes

Steve Greer, Agilent

SPCAN50 Check specification (similar to 4.3.3) for more descriptive information in the attribute sections.

Neil Shah, Lucent

SPCAN51 Add IDL files to the appendix of the specification. Johannes Ganzert, R&S

SPCAN52 Add .h file to the appendix of the specification. Glenn Burnside or Zulfiqar Haider, NI


11. IviDigital Working Group

11.1 General Meeting Info:Date of Meeting: February 27, 2001Location: San Diego, CAChairperson: Teresa LopesMinutes Prepared By: Teresa Lopes



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

Bud Cribar Agilent (970) 679-2061 [email protected]

Steve Wegener Boeing (314) 234-3801 [email protected]

Peter Richardson BAE Systems +44 (1383) 822-131 [email protected]

Patrick Johnson RACAL Instruments (210) 699-6799 x204 [email protected]

Scott Rust National Instruments (512) 683-5680 [email protected]

Ron Taylor BAE Systems (858) 675-1440 [email protected]

Craig Cole Northrop Grumman (410) 993-5173 [email protected]

11.3 Topics To Be Discussed:Review class specification


11.4.1 Working Group SummaryReviewed the class specification. Focused on the parts of the specification that changed since the last meeting – mostly the description and overview sections.We also reviewed the COM hierarchy for the digital class…it’s still a work in process. There were suggestions for modeling the static and dynamic extensions in a similar way.A new rev of the spec will be released in 3-4 weeks. We’ll work on getting one or more prototype drivers together and have those available by the Paris meeting. Assuming there are no major issues raised at the Paris meeting, we should be ready for a vote after that meeting.










11.4.2 Specification Review Comments Explain how to read the diagrams in the specification, at least once. Need to explain what an opcode is. Does it make sense to tie some of the more complex opcodes to extensions? Need use cases for the class interface. Start with use cases developed during early class

interface discussions. Investigate modeling a pattern in the same way we modeled the dynamic pattern set. Do we need a static pattern set…a collection of static patterns? When collecting DATA only, should the pattern result be “NOT SUPPORT” or “NOT

AVAILABLE” instead of PASS? Should we add a callback interface for pattern set complete…perhaps with the event

server? What have other class specifications done for synchronous versus asynchronous

executions?o Look at what the Scope class did for blocking and non-blocking callso Make sure that the digital class specifications follows the same paradigm

Add a function for retrieving exception information Look at modeling a pattern as the common thing between the static and dynamic

interfaces


12. User Working Group

12.1 General Meeting Info:Date of Meeting: February 27 and 28, 2001Location: San Diego, CAChairperson: Gayle MatysekMinutes Prepared By: Gayle Matysek



Bud Cribar Agilent Technologies 970-679-2061 [email protected] Greer Agilent Technologies 970 679 3474 [email protected] Richardson

BAE SYSTEMS +44-131-314-2332 [email protected]

Ron Taylor BAE Systems 619-675-1844 [email protected] Petty BCO, Inc. 978-663-2156 [email protected] Wegener Boeing 314-234-3801 [email protected]

mDon Davis Boeing 314-234-2722 [email protected] Lawler Hamilton Software 707-542-2700 [email protected] Adorno National Instruments 512 683 5071 [email protected] Tholandi Nokia Mobile Phones,

Inc.858.831.4547 [email protected]

Craig L Cole Northrop Grumman 410-993-5173 [email protected]

Gayle Matysek Northrop Grumman 410-765-9754 [email protected]

Patrick Johnson Racal Instruments 210-699-6799 x204 [email protected] Rosenwald Racal Instruments 210-699-6799 x

[email protected]

Dave Ptacek Rockwell Collins 319-295-0198 [email protected] G McKay Thales Instruments

(aka Racal)+44-1202-872800 [email protected]

Tom Gaudette The MathWorks, Inc 508-647-7759 [email protected] Geathers TYX Corporation 703-264-1080 [email protected] Spivak Winsoft 714-444-4844 x209 [email protected]

























12.3 Topics To Be Discussed

Tuesday Febuary 27th

- IVI driver “starter set” from Noel Adorno National Instruments- User feedback to Racal regarding COM development- Review of User Requirements Document- Access to user mailing list on IVI list server

Wednesday February 28th

- Provide feedback on ideas for COM demo- Continue review of User Requirements Document


Tuesday February 27th

1. At the user’s request, National Instruments provided a “starter set” of software files to allow users to run some IVI C drivers in a simulation mode. The installation package contains: class and specific drivers, a VISA library, IVI engine, Measurement & Automation explorer (used to select the specific driver to be used with the class driver), sample programs for LabWindows/CVI and LabView use and a set of basic C files that can be run in a standard tool environment. The configuration store information is contained in a CVI.INI file

Noel Adorno demonstrated how to map a specific driver to a class driver, how to run the examples, how to set various selections for the class & specific driver.

An unanswered question that arose during discussion is the mapping of channel names. At the moment, the channels must be identified from the specific driver and entered into the configuration information by the user. Noel believed that this should not be required and said she would check on this issue. This manual operation is error prone and an undesirable burden on the user.

2. John Rosenwald requested time to ask the users their thoughts on a presentation given by Dave McKay to the COM working group. Since most of the users are C developers, we were able to provide little guidance.

3. A brief reminder on the use of the users mail list was presented. Users were informed that they would be added to the user distribution list on the list server following the meeting.

The information is available from the IVI web page and is also recorded here for reference:

To send a message to the rest of the users, address it to [email protected].

In order to subscribe to the list (if you want to tell anyone else to do so): - Send a message to: [email protected] - Include the following in the BODY (not the subject line) of the message:



subscribe users Yourfirstname Yourlastname

In order to unsubscribe to the list: - Send a message to: [email protected] - Include the following in the BODY (not the subject line) of the message:

unsubscribe users

4. The remainder of the meeting was spent discussing items in the list of user requirements.

Wednesday February 28th

1. John Harvey requested the users to review a list of ideas that the COM Working group formed as guidelines for their demo for the next meeting.

Demo Goals (potential)

Being able to talk to an instrument specific interface w/o going through the class interface.

Use class-complaint interface with a logical name. Multiple class compliant interfaces in one component. Demonstrating issues related to leveraging class-compliant interfaces to specific

interfaces. Intermixing calls to class-compliant interfaces and instrument specific interfaces Are there any inherent interfaces we want to make a point of showing? DCOM Repeated capabilities Interchangeability

The users added the following items:User ideas:

Source code we can step through the full execution of the driver from how it gets data from the config store through all instrument calls

interface block diagram system installation process how to configure the installed driver (something like the NI MAX tool)? some means to determine performance differences between C and COM Visual C++ implementation preferred over VB simulation version available for users to load on their PCs if possible, access to the software ahead of time to allow users to develop

questions prior to the meeting

Additional issues mentioned during the discussion:Demo equipment available for user access

located in the room where we will meet the block of time prior to the user meeting is typically open and would allow

users access prior to our formal meeting


The dual short sessions are preferred on Tuesday/Thursday, if possible. The early week/late week meeting allow users to get an introduction and then regroup with questions, issues and concerns that arise during the meeting. The short meeting creates ”free” time prior to the start of the user meetings which enables the users to run examples and experiments.

2. The remainder of this session was spent addressing the User requirements document and a list of items that Peter Richardson brought to the meeting. Some of the items on the list had already been identified and others were added as required.

Action items:1. Gayle Matysek will eliminate duplicate requirement entries and recirculate the draft to obtain

user feedback.


13. IVI 3.2: Inherent Capabilities Working Group

13.1 General Meeting Info:Date of Meeting: February 28, 2001Location: San Diego, CAChairperson: Scott RustMinutes Prepared By: Noel Adorno

13.2 Meeting Attendees:List not available.

13.3 Topics To Be Discussed:Review changes since last conference call.Discuss any remaining open issues.


Reviewed changes made since last conference call. Added some COM interfaces that were left out in section 4.Added places to insert GUIDs for COM interfaces. After making the spec changes noted in the action items, the IVI 3.2 specification will be ready for final review.

Action Items:

1 - Document the GUIDs for the COM interfaces. We will put the real GUIDs into the spec just before the final review. 2 – Make all instances of courier and courier new consistent. Especially look at the tables in section 8 and 9. (Apparently there is a conflict between the 3.2 spec and the class spec.)3 – We have to add a GUID to section seven. Need to put real GUIDs into spec just before final review.4 – What is the implication of class drivers using C and COM wrappers? With specific regard for packaging, installation, and the configuration store. This will be worked on immediately after the IVI Foundation meeting.5 – Tell Zulfiqar to accept the changes as soon as he has reviewed them.6 – John Harvey proposes that in general we should track the changes to specs and accept the changes while attending the IVI meetings. We can use the “Word Compare Documents” features to generate a succinct list of changes.7 – After making the spec changes that are listed above, we consider this to be ready for final review.


14. IVI 3.1: Architecture Working Group

14.1 General Meeting Info:Date of Meeting: February 28, 2001Location: San Diego, CAChairperson: Scott RustMinutes Prepared By: Noël Adorno

14.2 Meeting Attendees:List not available.

14.3 Topics To Be Discussed:Review changes since last conference call (February 1, 2001). Changes included:

1) Integrated IVI-COM architecture content into Section 4.2) Added IVI-COM driver requirements to Section 5.3) Moved IVI-C status base values to Section 5.10, IVI Error Handling, because actually

applies to both COM/C.4) Updated IVI-C include file requirements to allow inclusion of ivic.h declarations without

explicitly requiring ivic.h to be included in driver header file.5) Updated IVI-C packaging to allow some filename flexibility.6) Created table of contents and fixed some Microsoft Word style inconsistencies.

Review changes modified before last conference call but not discussed during conference calls. Major changes included:

1) Integrated C architecture into IVI 3.1. Overview material included in Section 4, IVI Driver Architecture. Requirements added to Section 5.14, IVI-C Requirements. Most of IVI-C architecture material was reviewed by working group before integration into main document. However, sections that still need to be review include: IVI-C architecture sections, 4.2.7, Interactive Development Interface, and 4.2.8, Events.

2) Accepted tracked changes. With significant modifications, it was becoming difficult to work within MS Word.

Other changes to be reviewed:

1) Sections 5.5.1 and 5.5.2 on attribute and fxn compliance rules. Last bullet point split into two bullets to clarify when class driver acts as a pass-through layer and when it implements functionality.

2) Removed Section 5.8.1.3, Separate Sessions for IVI Class Drivers, as material covered in C content added to sections 4 and 5.14.

3) Updated the behavior described in section 4.2.4.2, Dynamic Loading. The IviDriverLoader_New function now takes a module path instead of a logical name.


4) Inserted section 4.2.5, Accessing Attributes.

5) Significantly updated Section 4.2.6, Include Files, as previously it was hard to comprehend.

Discuss user issues brought up when requesting feedback for compliance document.

Review IVI-COM architecture material in sections 4 and 5.


Reviewed specification as itemized in topics to be discussed. Several action items noted in the IVI 3.1 spec directly and highlighted in blue. Made some changes to IVI 3.1 during meeting.

Brought up user issues. Addressed them in IVI 3.1 (such as making tables for supported capability groups in compliance document) or clarified situation with users. Issue arose as to whether to require that drivers ship with source code. Currently, spec does not require this. It was recommended that this be discussed at the General Membership meeting.

Discussed Custom class drivers. Custom class driver are allowed, but you have to have a published the class interface.

Spec assumes that C attribute hierarchy is defined for each class in the class specifications. This turns out not to be the case. Since the COM hierarchy in the class specs contains methods and properties, the consensus was that the C attribute hierarchies should be added to the class specs while they are open for the COM additions.

Started reviewing COM architecture material. Completed review most of of section 4, but did not finish reviewing sections 4.1.11 through 4.1.18, and section 5.13. We will cover those in conference calls. John Harvey will review Style Guide to see if some material needs to be pulled out of it and added to IVI 3.1.

Section 6, Installation Requirements, has not yet been started. Installation will be discussed in conference calls before the Paris meeting.


It was agreed that there is a need for a user’s guide for how to use IVI drivers. E.g. Code snippets that show how to achieve interchangeability or mix class and specific calls. Jon Bellin suggested that this might be a good User Working Group project.




Action Items: 1) Noel: revisit paragraph types in 3.3.6 – indentation issues2) Noel: revisit 2.4 – same indent issue.3) Noel: make use of courier fonts consistent.4) Noel: look at all instances of “vendor-???” and decide on whether to change to vendor-defined or vendor-specific. Make sure it is defined before it is used.’5) Noel: Section 4.2.8 and the equivalent COM section needs to be pulled in section 3.6) Noel: In 5.13, put section names in italics.7) Noel: Table 5-6 format is screwed up. Fix it.9) Noel: Double-check on 107 for length of IVI-C attribute identifiers.10) We must allow the possibility to have the C and COM driver interfaces in the same DLL module. This needs to be researched further before specifying requirements. This will be included in IVI 3.1 section 6.11) John Harvey to check with Agilent folks about proposed filename flexibility – allowing for dll file names with/without “_32”. Also do filenames need to match prefix exactly? Proposed is to have filename begin with prefix.. John Bellin to check with NI folks.12) John Harvey to review Style Guide for material in section 5.13) Serge to add to Serge’s document. Serge will add the attribute hierarchy to the Scope spec, sends to everyone and directs other chairs (both existing and current) of class specs to add this to their task list.14) Srdan and John Harvey will look into having COM drivers implement IProvideClassInfo2 interface in addition to the ITypeLibrary2 interface.15) Section 4.1.8 needs to be reworded to correctly describe why multiple IDispatch interfaces on the same object should not be used. The problem as stated is technically incorrect. John Harvey will work on this.


15. Glossary Working Group

15.1 General Meeting Info:Date of Meeting: February 28, 2001Location: San Diego, CAChairperson: Noël AdornoMinutes Prepared By: Noël Adorno



Roger Oblad Agilent Technologies

John Harvey Agilent Technologies

Jon Bellin National Instruments

David Fuller National Instruments

Srdan Zirojevic National Instruments

Steve Greer National Instruments

Jochen Wolle Rohde & Schwarz

Johannes Ganzert Rohde & Schwarz


Spec Number Voting procedure Terms to be included/excluded Contributors of terms/acronyms Schedule for first release


Since the Glossary is not a specification, Jon Bellin suggested the document be numbered 5.0.

Furthermore, since glossary isn’t intended to be a specification, the working group discussed a more lenient voting procedure so that it could be updated in a timely manner. It was decided that the group would meet to review modifications to the document before a scheduled general membership meeting. This could be a session at the IVI Foundation, a conference call, or some other organized meeting. Once the working group agrees on the changes, the new terms are voted on at the quarterly general membership meetings.


It was decided that since class specifications and other specifications have a terms and acronyms section, terms unique to a specification should be defined in the individual specifications. Terms and acronyms that are common to two or more specifications are candidates for inclusion in the Glossary document. If a term is unique to a specification, it still can be a candidate for inclusion in the Glossary if it is a key term to understanding the general purpose of the specification. For example, terms used in charter documents could be good candidates for the Glossary.

It was general consensus of the group that the Legal and Promotions Group should define controversial terms, such as “interchangeability”. The Glossary will then include these terms in the document.

Action Item: Legal and Promotions Group: Define “Interchangeability”.

It was decided that some terms should be included in the document both preceded with “IVI” and without it. For example, “IVI Config Store”and “Config Store”. One should refer to the other.

Action Item: Noel Adorno: Look through glossary and make first pass at separating these out. One should reference the other.

The group decided that all IVI Foundation members be able to submit terms and definitions for inclusion in the Glossary. However, it is the responsibility of working group chairpersons to review their specifications and submit terms and definitions to Noel Adorno.

Action Item: Chairmen: Review individual specifications and find terms/definitions for inclusion in Glossary.

Roger Oblad suggested that a good resource for terms is a document posted to the MSS working group site. It has about 40 terms that are possible candidates for the Glossary.

Action Item: Noel: Review terms in MSS terms document for possible candidates.

The group took a cursory look at the existing rough draft document and made some suggestions for terms, including state caching, repeated capabilities, IVI COM collections, and shared component.

The existing rough draft has several terms that are specific to the switch specification. These terms should be removed and added to the IviSwtch specification.

Action Item: Srdan Zirojevic: Take IviSwtch terms and add them to Terms and Acronyms section of IviSwtch specification.


There was consensus that generally understood industry terms would NOT be included in the specification. Examples of such terms include method, function, and interface. If potential for confusion exists, there can be exceptions to this rule.


16. Compliance Working Group

16.1 General Meeting Info:Date of Meeting: February 28, 2001Location: San Diego, CaliforniaChairperson: Dean Lawler and Jeff HulettMinutes Prepared By: Dave Ptacek


Name Company

Gayle Matysek Northrup Grumman

Pat Johnson Racal ATE

Don Davis Boeing

Steve Wegener Boeing

Glenn Burnside National Instruments

Noel Adorno National Instruments

Jeff Hulett Vektrex

Dave Ptacek Rockwell Collins

Dean Lawler Hamilton Software

Steve Greer Agilent Technolgies

16.3 Topics To Be Discussed: Open Issues and Questions NI IVI C driver acceptance test suite Test matrix presentation

16.4 Record of Discussions: Reviewed Dallas Meeting minutes Pat Johnson, Dean Lawler, Glen Burnside, Jeff Hulett, Steve Greer, Noel Adorno, Gayle

Matysek, Dave Ptacek, Steve Wegener (Boeing), Don Davis (Boeing) Review the Group Charter… Are the users comfortable with the notion of “voluntary testing” as a means of Compliance?

One idea is the vendors either needs to supply source code, or use a common test suite to give a certain level of integrity to the driver. The vendors noted that it is virtually impossible for device drivers to keep up with the versioning of device firmware. Noel asked that we attempt to document the varying levels of test levels and the expected costs /


implications to the foundation. Dean had an excel spreadsheet which was used as a starting point to list various tests, ADEs, and OS.

The example of the OPC and how they went through the certification process, MS wanted certification, but the rest of the organization voted against, why will IVI be any different?

A suggestion was made the 80/20 rule may apply here and a reasonable list of areas of tests can be defined that simple errors will be found.

The point was made that two devices may have the same functionality, but for some reason, the driver was never updated for some of the functions. The driver is still IVI compliant, but hardly useful when the capability wasn’t exposed.

If the vendor tests were written to the class driver API, couldn’t the tests be shared across the vendors for a given class? NI has offered to share some of these types of test with IVI, but it may not be exactly what IVI wants, however it is a good starting point.

It appears that if tools to generate test were to be owned & controlled by IVI, market share and competition between vendors could be a legal problem for the foundation.

One approach could be a checklist and a test report detailing the tests run, the results, and maybe all of the supporting software libraries and versions, as well as equipment descriptions and firmware versions.

Can “Initialize” (IVI 3.2 Inherent Capabilities) be modified to add a check to insure the driver is dealing with a version of firmware that the driver has been tested against? If so, it needs to happen very soon as 3.2 is nearing completion. If the firmware version is not the expected version, a warning or error will be propagated up to the user.

The General membership and more specifically, the legal team, needs to define how the IVI logo is to be used – how does the vendor attain the usage of the logo, how is it enforced? If IVI does control the logo, the vendors need to be given a target – setting the bar – that must be complied with to attain the logo.

This committee should define compliance guidelines, have legal authorize them and then recommend these to the general membership for vote.

All of this resulted in a re-worded charter for the Conformance working group the group approved.

IVI Conformance Working Group Charter

The IVI Conformance Working Group is chartered to investigate issues and propose standards related to the conformance of IVI drivers as defined by the IVI consortium. The conformance group is chartered to work in partnership with the other working groups – some of which already have defined, or are in the process of defining, IVI driver conformance criteria.

The IVI Conformance Working Group shall take direction from the general membership of the IVI consortium. (1)The IVI Conformance Working Group will investigate and propose what is required of a driver to obtain the IVI trademark/brand/logo/indication of performance. (2)In addition this group will provide methodologies/documentation/tools that facilitate compliance. All recommendations will be passed to the legal committee for consideration.


The ultimate measure of effectiveness of the IVI Conformance Working Group is the positive reception and acceptance of IVI compliant drivers amongst IVI driver users.

Pat Johnson will speak to the working group on the common code components (IVI factory, etc) and this topic will ride along with it to the legal group in terms of what IVI will legally back.

Breakdown Zufiqar Haider’s paper of Compliance tests, into sections of tests that apply to all ADEs and OS, then sections that apply to specific ADEs and OS. A possible breakdown may be

This is a proposed structure for review and comment (two weeks prior – end of march style tests code structure tests expected class compliant behavior tests conformance to static class rules – ie zulfiqar’s z-test Application level testing – state caching, simulation, range checking …is the driver correctly

implemented? Works w/state caching, simulation, range checking, attribute conflict) ADE Tests – do IVI drivers work with LabView? VEE? C++? VB? Operating system tests – Win98? WinME? WinNT? Win2000? I/O libraries? (VISA) would be useful to identify which library was used for development/test What instrument models were tested “This product was tested with this ADE, OS, Inst Model, Firmware, on this day Performance/speed? We don’t want to go there!

Information describing testing environment including ADEs, OS, device models, firmware version, I/O libraries versions….specification of the testing environment such that it could be reproduced by someone else and the same results obtained.

Should performance or speed be considered? Probably not. COM vs. C testing is a blackhole, Dean will send the new Charter to Pat Johnson by end of the day. (done)

Of interest to the general membership: Emphasize that this wouldn’t be decided here


17. IviPwrMeter Working Group

17.1 General Meeting Info:Date of Meeting: February 28, 2001Location: San Diego, CAChairperson: Zulfiqar HaiderMinutes Prepared By: Craig Cole



Zulfiqar Haider NI 512-683-8374 [email protected]

Craig Cole Northrop Grumman 410-993-5173 [email protected]

Gordon Muir Agilent 44-131-335-7428 [email protected]

Glenn Burnside NI 512-683-5472 [email protected]

17.3 Topics To Be Discussed: Review each attribute and function starting with base capability group.

17.4 Record of Discussions: “Relative measurement” is misleading. Need to use correct and unambiguous terminology. Need to clarify single measurement wording. What does measurement units mean? Change “measurement offset” to “channel offset”. Changed “Auto Averaging Enabled” to “Averaging Auto Enabled”. Agilent contended about what settings are measurement based and what settings are channel

based in terms of what the attribute applies to. Decided not to revisit the measurement vs. channel-based discussion and consider the measurement to be the RF power measurement taken at the output terminals.

Need to be explicit about what type of averaging is performed: sliding window or buffer full. This affects the performance of the averaging. Is this important from an interchangeability point of view? Need to say that measurement is complete when n samples have been taken for Averaging attribute and function descriptions.

Question raised about Offset Enabled. Offset off = offset 0 Discussed need for Channel Enabled attribute. Enable is a usage concept separate from setup. Changed Measurement Units attribute name to just Units. For Over Range and Under Range conditions the returned value (reading) should be –Inf and

+Inf respectively. Suggestion was made to change the way (relative) measurements are specified. Configure

measurement than do single read. Configure a measurement with channels and math functions. Two configure functions: ConfigureMeasurement (single channel (vi, channel))






and ConfigureMath (vi, feed1, feed2). Get rid of Channel Enabled (or make it read-only). Read is simplified (there is no Read Relative function anymore).

Prefer full behavior model diagrams in extension capability group behavior model sections. Query users and vendors to resolve table in Read Relative function description. Need to specify internal trigger level units. Concern about supportability of Resolution extension group. Units table includes %, which

is not supportable interchangeably. In fact, all rows are not supportable interchangeably. Go to user community for read on this.

Change Calibrate function to include channel. Change ReferenceOscillatorPower to ReferenceOscillatorLevel. Initial review of COM hierarchy. To be redrawn and sent out. Future goals: Send out meeting minutes, action items and spec changes by March 15 Send user’s group questions by March 15 Conference goal by April 15 on reved C spec Post C spec by May 1 COM hierarchy sent out by May 15 Generation of IDL and *.H file COM incorporated by Paris meeting for review. Submit for vote shortly after Paris meeting.


18. VXIplug&play VISA Technical Working Group

18.1 General Meeting Info:Date of Meeting: February 28, 2001Location: San Diego, CAChairperson: Dan MondrikMinutes Prepared By: Dan Mondrik



Yohei Hirakoso Advantest [email protected]

Dave Gladfelter Agilent (970) 679-5329 [email protected]

Roger Oblad Agilent [email protected]

Steve Schink Agilent (970) 679-2196 [email protected]

Premal Shah Keithley Instruments [email protected]

Dan Mondrik National Instruments (512) 683-8849 [email protected]

Scott Kovner National Instruments (512) 683-8567 [email protected]

Scott Rust National Instruments (512) 683-5680 [email protected]

Kirk Fertitta Pacific Mindworks [email protected]

Jochen Wolle Rohde&Schwarz +44-89-4129-13044 [email protected]

Badri Malynur Tektronix (503) 627-5880 [email protected]

Don Zocchi Tektronix [email protected]

Keith Rule Tektronix (503) 627-4338 [email protected]

Rengan Rajendran Vektrex [email protected]

Alex Spivak Winsoft [email protected]

18.3 Topics To Be Discussed:After discussing handouts/overheads by NI and Agilent, we came to the following agenda:

1) Review changes since the November meeting2) Pros and cons of enum versus long – where to use each?3) Shared components – who will implement these, and when?4) VISA version – do updates to C and COM API’s track each other?5) How do we get the VISA COM spec finished?6) Discuss VISA C interoperability and the possibility of standardizing on Passport7) Decide the timeframe for the next VISA TWG meeting


















18.4.1 Review changes since the November meeting

The NI handout covered the changes made since the last meeting and is copied below:

Changes made as a result of discussions at the last meeting: Unsigned types other than BYTE (VT_U1) should not be in the spec. BYTE is necessary for things

like termination character and a few others. But all other previously unsigned types (such as ViUInt16) will now be signed (ViInt16).

We dropped BigEndian as a parameter to the formatted I/O IEEE-block methods since it is a property on the interface.

There is now a better description of DisableEvent()/UninstallHandler()/Close() to describe how these should synchronize with a vendor-created callback thread, also when the user is and is not allowed to call these methods.

Optional output parameters do not work well in VB and do not work at all in Delphi. Output only parameters apparently leak in VB. These were fixed by making as many [out, retval] as possible and making the others [in, out].

Added IVisaConflictTableManager. This is ‘hidden’ so as to not show up and confuse VB users. Renamed I488FormattedIO to IFormattedIO488 so the co-class name FormattedIO488 is valid. Default interfaces are not important for this specification. The only 2 co-classes remaining in this

spec are IResourceManager and IFormattedIO488, and they are shared/common components. Made sure all optional parameters come after all required parameters. The ‘VisaStatus’ output parameter has been removed. A new ‘LastStatus’ read-only property was

added to IVisaSession. All methods can return success codes and warnings greater than 0, just as in the original VISA spec and in IVI too. Any user (such as from VB) that does not get the return value directly, can query it using the property.

At that meeting we thought default BSTR values did not work, but in fact they do. There are now default values for BSTR parameters in Init(), Open(), LockResource(), ReadList(), and WriteList().

Changes made for other reasons and from other discussions since the meeting: Renamed IMessageIntfc to IGpibIntfcMessage and IMemacc to IVxiMemacc so as to keep all

hardware-interface-specific classes beginning with the hardware interface type itself. Renamed Lock()/Unlock() to LockResource()/UnlockResource() to avoid name conflicts with ATL.

Otherwise, a VISA COM ATL implementation gets ugly conflicts that are difficult to workaround. VB programmers prefer to use properties directly rather than using GetAttribute() and SetAttribute().

However, these methods are necessary for several reasons as per several previous discussions. They will remain in the IDL but will be marked with the ‘hidden’ directive so as not to show up in VB. Power programmers can still use them.

Universal marshalling is good and is still recommended but cannot be required for various reasons. We added some text and rules as to how to use, register, and unregister other marshalling methods.

The VISA data types are important for the specification but do not need to be in the IDL since they will not show up in the end (in the TLB) anyway. We now use all native automation types in the IDL and have a table in the specification showing the correlation between VISA and COM data types.

We added a public typedef to each enumeration, just as is being done in IVI. We removed IEnumVisaResource and FindResourceEnum() because while it ‘looks’ compatible with

the IEnumXXX classes, it is not. It turns out to be more work (to make it compatible) than it is worth. Returning the array of resource names works just fine. We also renamed FindResourceAddresses() to FindResources() since this name is simpler.


ReadList() does not need the FlushToEnd input parameter since it always reads to the end. For a user implementing IEventHandler in VB, he must use the form itself as the callback interface

implementer because VB does not expose the interface properly in class modules and user controls when building a standard EXE. This is actually not a change in this specification, just a clarification for this meeting. This is the type of information we need to put in the user documentation.

The discussion of these changes centered around the following topics: Making GetAttribute() and SetAttribute() hidden is good. Using a long for the attribute ID is OK

because it allows for vendor extensibility. Most users won’t use these methods anyway, so while not having an enum impairs IntelliSense, that is acceptable in this case.

Kirk Fertitta gave an explanation of what kinds of use cases might need a marshaller other than the Universal Marshaller. Dan Mondrik read aloud Dave Gladfelter’s proposed text for rules and recommendations using custom marshallers. Everyone agreed to it. Dan Mondrik will add this text to the specification for both common/shared components as well as the vendor-specific ones.

Using a typedef for each enum is good, but we must make sure to use the same name for the enum and its corresponding typedef, which we already do. Otherwise, as Kirk Fertitta and Dave Gladfelter pointed out, the IntelliSense in VB does not always work correctly.

Once the typedef is declared in the IDL, the enum should not be used later. Dan will fix this. Enum/typedef names should be singular (XConst) not plural (XConsts). Dan will fix this. Removing the IEnumVisaResource means that a user cannot query attributes on the resource list.

This was possible in VISA C using viGetAttribute() on the ViFindList. Not having this feature in VISA COM was deemed acceptable.

18.4.2 Pros and cons of enum versus long – where to use each?

Agilent’s slides discussed the pros and cons of using an enum: The pros are that this will be consistent with IVI drivers, that IntelliSense will make it easier for VB

users, and that we will avoid compatibility problems with the upcoming .NET platform, where an enum and a long are orthogonal types that require a typecast.

The cons are that some methods currently allow a bit-OR of 2 or more values, and this is not possible with an enum. Also, if we extend the values in an enum later, a developer must be able to handle out-of-range values gracefully, or we might possibly need to consider revving the interface GUID to avoid this problem for developers.

Both NI and Agilent were for using an enum wherever feasible, and everyone agreed.

Dan Mondrik will search the spec for places where we currently allow a bit-OR and either 1) split this into multiple parameters, 2) add combined values into the enum, or 3) disallow the bit-OR. One example of where #1 was already done was in Flush(), which now takes the bufferMask enum, which can be in, out, or in/out. The ability to discard the buffer was moved to a separate Boolean parameter.

Dave Gladfelter summarized cases where an enum doesn’t make sense, such as in timeouts, where we have defined immediate (0) and infinite (-1) timeouts. An enum is impossible and would be horrible because it would include 2^32 values.

The 3 types that NI questioned were InterfaceTypes, AddressSpaces, and EventTypes. For the first 2, it was decided that they should remain as integers because 1) few people use these types programmatically, and 2) these are areas that vendors will likely add other values.


We briefly discussed enum extensions. Dave Fuller recalled a recent IVI conference call, where they agreed to allow adding new values to an enum without revving the GUID. Some present at this meeting were unsure that it was completely safe, so Dave Gladfelter will verify that extending an enum without revving the GUID is OK in VB.

For EventTypes, Dave Gladfelter suggested several ways to solve this while allowing extensibility. One way was to duplicate each method, making one type take an enum and one type take a long EventType. This would encompass the entire IEventManager and make it unwieldy. Another way is to add a “Custom” value to the enum EventType, with an extra optional long parameter in each method that uses the custom value only if needed. This second way seemed to be acceptable. The IEvent interface will now have 2 “eventType” properties, 1 that is an enum and 1 (custom) that is a long. Neither will be hidden. Dan Mondrik will add all of this to the spec.

For the WaitOnEvent() method and the IEventHandler() interface, we agreed to remove the “long eventType” parameter since 1) most users know which type they are expecting, and 2) users who need to know this can query it via the IEvent interface that is available from both of these. Dan Mondrik will remove the extra parameter from those 2 methods.

Roger Oblad asked about the differences between the VISA and IVI event models, and how event handling should work overall in IVI. Dan Mondrik was to talk to Qi Gao about the event server specification, and he did. NOTE: See the final segment of this document (section 5) for updates.

One of the big questions about using an enum is how it affects or limits vendor extensions. Given that the 3 types in question all allow for non-enum extensions, this is not an issue. Any vendor can create his own .tlb and provide his own interfaces. No vendor may modify or extend the documented visacom.tlb or its classes.

Kirk Fertitta had questions about the derived classes such as IMessage: is the relationship with regard to IVisaSession “is-a” or “has-a”. The answer is “is-a”. It was suggested that an inheritance diagram in the specification would be useful. Dan Mondrik will add such a diagram.

18.4.3 Shared components – who will implement these, and when?

Roger Oblad presented on the IVI shared components and the Support Model Working Group. This was a precursor to Pat’s presentation the next day. The main points are that IVI owns the source and the only compliant binaries are delivered by IVI. Any other build of a common component, even using the same source code, is not compliant.

One question dealt with intellectual property. Roger surmised that there might be a small NDA group that reviews source code before accepting it for a general release. This would protect the owner if the code were rejected (fewer outside sources would have seen the source code).

Scott Rust asked about compliance and other platforms. On Win32 only the binaries are compliant. It seemed that IVI had not given sufficient thought as to compliant versions on other OS platforms.

The VISA COM shared/common components include 1) the Global Resource Manager, 2) the Conflict Table Manager, and 3) the Formatted I/O. Although there was no commitment at this meeting, it appears that NI will implement and donate #1 and #2, and Agilent will implement and donate #3. NI and Agilent need to get approval for doing these shared components.


Another question dealt with whether VISA should specify the only compliant version as being owned by IVI. Scott Kovner suggested that this would be difficult. However, it is possible and even a good idea for IVI to stipulate that the only compliant version of VISA COM for IVI developers is the one IVI owns.

Dave Gladfelter asked about testing. Roger replied that there are code reviews, but IVI must be able to know that the product is stable. Dave asked whether the provider is responsible for providing source code to the test suite. Roger said that IVI received certain privileges when acquiring source code, but was not sure what they were.

VXIplug&play members should need access to the binaries, for redistribution, and this would be allowed under the IVI model. But only IVI members will have access to the common components’ source code.

The final question on this topic dealt with “when”. Scott Rust said that he anticipates that the new IVI specs will be voted in during Q3. The IVI foundation will have a demo at the June meeting, but he does not anticipate shipping products until Q4. Dave Gladfelter suggested that as long as we meet the IVI timeline, that should suffice; Dan Mondrik suggested optimistically that releasing before IVI has benefits as well. Jochen Wolle asked whether there would be a VISA COM prototype available for the June IVI meeting, but it was too early to tell at this meeting. By the time the VISA COM spec is voted on, NI and Agilent need to determine the timeframe they can commit to for an implementation.

18.4.4 VISA version – do updates to C and COM API’s track each other?

Dave Gladfelter showed a slide asking whether the VISA COM ratification will cause the VISA C version to be updated. The answer at this time is no, it will stay at 2.2 (0x00200200).

Dave asked whether future changes to VISA C will be tracked in VISA COM and vice versa. Dan Mondrik replied that additional functionality would bump both versions, but that header file changes or new interfaces for ease of use might affect only 1 version. The SpecVersion property refers to both versions and changes to that property value are currently arbitrary. It should be revisited with each modification to see if it needs to change.

Steve Schink asked about VISA subsets. Must all implementations support all hardware interface types? Dan Mondrik replied that the VISA specifications stipulate that if you support one feature of a given hardware interface type, you must support all the features for that type.

Steve asked whether all VISA implementations must have both C and COM support. Does C support imply COM support, or vice versa? This was not clear, but it is best to not make such assumptions – it would probably be left to vendor distinction. Also, a vendor’s support of C and/or COM is not equivalent to which types are installed on a given machine. For example, a vendor could support both with separate installers, and it is possible for only 1 to be on a given target machine.


18.4.5 How do we get the VISA COM spec finished?

There was a short discussion about finishing the specification. Dan Mondrik will first put the current draft specification onto the IVI web site. Dan has asked Dany Cheij to post the document at this location: http://www.ivifoundation.org/groups/IO/default.htm

Once all the feedback from this meeting is incorporated into the specification, Dan Mondrik will post the new (hopefully final) draft version onto the IVI web site by the end of March. All IVI and VXIplug&play members should have 2 weeks to review it, and we should be able to begin the vote in April. The VXIplug&play voting process takes 2 weeks, so this should in theory be completed by the end of April. NOTE: See the final segment of this document (section 5) for updates.

Keith Rule asked whether VPP-6, the VXIplug&play specification dealing with installers and installation locations, needs to be updated to include the VISA COM specification. Dan replied that at this time, it would probably not need to be updated since all the other VPP components rely on a standard installation location whereas VISA COM uses a GUID rather than a directory for this purpose. However, should the VISA C specification be updated to stipulate a multi vendor capable implementation, then VPP-6 should definitely be updated at that time.

18.4.6 Discuss VISA C interoperability and the possibility of standardizing on Passport

This discussion was driven by the fact that in the November IVI meeting, the IVI 3.1 group said that both VISA C and VISA COM were valid I/O API’s for IVI driver writers. To accommodate this, VISA needed to solve the multiple vendor C problem so that IVI drivers could ship VISA C if they wanted to.

NI proposed a discussion of using Passport to solve the problem, at which time Steve Schink said that Agilent uses TULIP plug-ins and would find it hard to support Passport – they might propose TULIP as the plug-in model instead of Passport. Steve said that standardizing on Passport was not for discussion in this forum. Steve asked whether Passport was used solely by NI, and Keith Rule replied that Tektronix is using a Passport as well. Anyone who is interested in TULIP should contact Steve Schink; anyone interested in Passport should contact Dan Mondrik.

Steve said that discussing TULIP and Passport is but one way to solve the problem, via the driver interface. There is another path of discussion that might be more fruitful, which is discussing installation and configuration issues. In other words, we could possibly standardize on registry entries on how to recognize other vendors’ cards, or we could standardize the device discovery mechanism. Should we have interchangeable VISA implementations that recognize each other’s underlying drivers? This is not scalable, since other implementations do exist (eg, Tektronix has a VISA C).

Dave Gladfelter suggested that each vendor’s VISA COM implementation be able to talk to their own VISA C implementation even if it is installed in a location other than <SYSTEM>\visa32.dll, since there can be only one of those. Each vendor would then install an extra copy of their visa32.dll into their own location, and the VISA COM would use that one instead. This would provide the best interoperability. The ensuing discussion pointed out that it would not help the VISA C problem at all.

At this point, the VISA C interoperability discussion came to an impasse.

18.4.7 Decide the timeframe for the next VISA TWG meeting


http://www.ivifoundation.org/groups/IO/default.htm

With nothing else left to discuss, we did not think we would need to meet in Paris with IVI in June. We felt that the work that would be done in that timeframe would be implementation of the common/shared components and vendor-specific resources. This work might require exchanging emails but should not require a meeting.

We suggested meeting again with IVI in September at whatever date was chosen at Thursday’s general membership meeting. NOTE: See the final segment of this document (section 5) for updates.

The meeting was adjourned.

18.5 Follow-up:

Dan Mondrik spoke with Qi Gao on Thursday after the IVI event server meeting. She had not yet looked at the VISA COM specification, and indicated that she would. Her initial thoughts were that I/O events were at a different level than driver events, and therefore did not need to be handled or serviced identically. As long as there was no inherent conflict in the models, the VISA COM event model should be fine. Unless Dan hears otherwise from Qi, we will proceed with the currently proposed VISA COM event model.

At the IVI general membership meeting, it was declared that not solving the VISA C interoperability issue was not acceptable. Pushing forward with VISA COM at the expense of VISA C was not in IVI’s best interest. Solving this problem could possibly involve needing to meet with IVI in Paris in June. Dan Mondrik must get back with VXIplug&play vendors within 3 weeks to come up with a plan for further discussions on how to solve multi vendor VISA C interoperability. The plan may include phone conference calls, exchanging emails, and/or a VISA TWG meeting with or without IVI.


19. Event Server IVI-3.7 Working Group

19.1 General Meeting Info:Date of Meeting: March 1, 2001Location: San Diego, CAChairperson: Roger ObladMinutes Prepared By: Roger Oblad



Roger Oblad Agilent Technologies (707) 577-3466 [email protected]

Qi Gao Agilent Technologies (707) 577-2152 [email protected]

Patrick Johnson Racal Instruments

Johannes Ganzert Rode & Schwarz

Stephen Greer Agilent Technologies

John Harvey Agilent Technologies

Jon Bellin NI

Keith Rule Tektronix

Don Zocchi Tektronix

Premal Shah Keithley Instruments

Badri Mauynr Tektronix

Jeff Hulett Vektrex

Richard Hazzewood

Thales Inst.

John Piescott M.O.D

Teresa Lopes Teradyne

Gayle Matysek Northrop Grumman

Peter Richardson BAE Systems

Dave Ptacek Rockwell Collins

Dan Mondrick NI

Scott Kovner NI



Issues from previous San Diego Meeting of concern to Jon Bellin1) The Event Server was using bits that are private to Microsoft definitions.

Resolution: The event server was modified to eliminate this problem prior to this meeting.

2) Jon asked about a concern raised by David Fuller over possibly wanting to have an additional abstraction layer so that the Event Server can interoperate with other event mechanisms that are being used.Resolution: Roger had e-mail and voice mail exchanges with Dave where Dave said that he believes that this can be achieved by using the Source and Sink components. Jon will check back to Dave and verify that this issue can be closed.

Have we verified that the Event Server specification follows the IVI API style guide? No.ACTION: Steve Greer will perform a review of the document for style.

John Harvey… Asked for a simple example of how the Event Server could be used by an IVI Driver.

How difficult would it be to provide a C interface for the sink client?Answer: It could be built on top of the DLL.

Changes that were made since the last meeting:1. Automation data types are now being used2. The “MSS” prefix has been removed from the APIs3. Function specifications were reformatted to be more descriptive.4. Several use cases were added.5. The problem statement was updated.

NEXT STEPS: Event Server

We will release the Event Server specification at the same time as 3.1,2,3,4,5,6,7, 9,10 and 12.

Interested parties in IVI-3.10 should perform a line-by-line review over the next month.

On April 5th there will be a phone meeting where all of the line-by-line inputs will be taken.

Within two weeks of this meeting a final draft will be prepared and send out for final review prior to the Paris Meeting. It is expected that little time will be needed on the Event Server at the Paris meeting and that the specification can wait for the other sections in IVI-3.x to be completed so they can all be released together.

Attendees required having a quorum: John Harvey, Jon Bellin, Qi Gao, Roger Oblad.


ACTION Steve Greer: Agilent will reserve hone conference number for 6-8 weeks in a row, starting Mar 15th through mid May. Agilent will also host Web-X document sharing for these meetings. Only the April 5th date will be used for the Event Server.

Jon expressed concern over VISA naming conflicts:Resolution: Component methods will be modified to have a prefix of I-IVI as other components like the configuration.

ACTION Qi Gao: Make this modification in the code.


20. Support Model Working Group

20.1 General Meeting Info:Date of Meeting: March 1, 2001Location: San Diego, CAChairperson: Patrick JohnsonMinutes Prepared By: John Harvey

20.2 Topics To Be Discussed:Proposal for the common code support model


Patrick provided a presentation on the issues related to common code. The slide set will be posted on the web site, and will also be presented to the legal group.

Roger noted that there is an act of giving by the donator and an act of receiving by the IVI Foundation. As a principle of receiving a piece of code, the IVI Foundation must have enough IP rights to support the code if the original donator should be unable or unwilling to do so.

Additions to the architecture and support of additions are the responsibility of the solution provider.

Steve Greer – Are we supplying source? Roger – thought the decision was to supply source to the foundation members and binaries to the world. Steve – thought the decision was to have a select group review the source, and then hide it away and distribute only the binaries.

Roger brought up the idea of open source. Patrick thought that guarantees of support were required for IVI acceptance, and that open source did not address that issue.

Availability of software on the web site is problematic – the web site is not secure enough to protect the integrity of the common code.

If the IVI Foundation does not supply telephone support, where do application program developers go for general support – use questions, bug reports, etc.?

Compliance testing for common code. We need to publish tests, procedures, and results so that people know what compliance was tested, and what the results were.


21. RF SigGen Working Group

21.1 General Meeting Info:Date of Meeting: March 1, 2001Location: San Diego, CAChairperson: Jochen WolleMinutes Prepared By: Craig Cole



Jochen Wolle Rohde-Schwarz

Michal Krombholz Agilent 717-577-3188 Michal_krombholz@agilent

Srdan Zirojevic NI 512-683-5374 [email protected] Burnside NI 512-683-5472 [email protected] Lawler Hamilton Software 707-542-2700 [email protected] Ganzert Rohde&Schwarz 089 41 29-13405 [email protected]

schwarz.comCraig Cole Northrop Grumman 410-993-5173 [email protected]

om

21.3 Topics To Be Discussed: Approve Nov 2000 Dallas Meeting Minutes Action Items Answer from User Group / Phone Conference

Power Level IQ Format

Review Changes to Base class Repeated Capabilities (LF Gen/Mod Sources) Review Digital Modulation

Instrument Model Burst control ARB Generator

Review COM Hierarchy

21.4 Record of Discussions:March 01 2001

Meeting minutes from previous session reviewed and approved.









Action Items review Name of NOMINAL_MODULATION_VOLTAGE. Should function name be “query”,

“get” or dropped. Constant for instrument. Scope has dropped query function (use get attribute). Decided to drop the query function (IviRFSig_GetNominalVoltage and getIQNominalVoltage). RFSIGGEN 01 is closed.

Discussion about PulseGenerator triggering. Should we provide gated triggering and external triggering of continuous pulses? Need to clarify capability in diagram. Discussed possibility of adding additional attribute GATING_ENABLED Added parameter to IviX_ConfigurePulse. RFSIGGEN02 still open. User community will be queried.

Decided to leave synchronization (blocking and non-blocking) in specification. RFSIGGEN08 closed.

ARB filter frequencies. Instruments may have different frequency sets for reconstruction bandpass filter centers. Try to coerce, otherwise return error. RFSIGGEN 11 closed.

Discussed RFSIGGEN10 Michal presented proposal on how to deal with arb markers. Rename ARB marker functions to be compliant with standard naming conventions in

Michal’s proposal. Had discussion and decided to have so as to move one step ahead in the

standardization of markers. Proposal to be E-mailed to Jochen by Michal for inclusion in spec.

User’s group feed back. Users responded that base units of dBm across the board are fine. Removed base

capability attribute and various references throughout spec. IQ data format. For interchangeability, decided to use voltage expressed as doubles

scaled to +/- 1 volt. Interleaved vs separate arrays. Decided to use two arrays I, Q and numberOfSamples.

Worried about time to convert to native DAC values (4 Gigabyte typical). Should we include function that supports conversion ahead of time. Discussed arb List conversion functionality. Desire to append list of converted values.

Need a method to start, append and finish. Decided to have a single function called IviX_WriteARBList with value that indicates writeMode (END_OF_LIST, APPEND). Replaces IviX_CreateArbList.

Leaves concept of large file storage to user.

March 02 2001

Reviewed overview document with respect to all capability groups Within spec, attribute names are generally not enough. Description of physical meanings

must be explicitly spelled out SWEEP_MODE attribute VAL_NONE vs CW. Decided to keep as VAL_NONE Need clear behavior diagram which addresses trigger in the sweep realm. CreateFreqPowerList was modified to only specify a single length parameter. Undefined

behavior if lists were different lengths. Continued ARB discussion. Reviewed Michal’s updates to overview Discussed ARB Sequences Extension group


Developed new prototype for CreateArbSequence Compared with FGEN ARB sequence capabilities. Much more capability in FGEN for same

sort of capability. Decided to model this capability after FGEN sequence capability. Michal accepted action which is recorded in RFSIGGEN15.

Plan to have phone conference at end of March to review entire document. Discussed Digital Modulation diagram and basic concepts. Difficult to model. Capabilities are varied and tightly coupled. Mapping, Coding, Filter and

Symbols. Seems like model is simplified if lump coding and mapping together so as to represent

standard forms of modulation.. Come up with enums that describe the combined functionality Need to precisely define meaning of each

Discussed DM_IQ_DATA_SOURCE enumerations. Decided to have single EXTERNAL enum rather than additional ones which are much more instrument specific

DM_DATA_PRBS Enumerated numbers (PRBS9, PRBS15, etc) seem odd. But really specifies standard not just number of bits. Change name to DM_DATA_PRBS_STANDARD.

DataList, PRBS, IQSource capabilities all agreed onh Need definition of how PRBS patterns work with triggering. Research the trigger source and

triggering in general. RFSIGGEN16 was generated. Investigate different type of clock frequencies as they relate to symbols and bits in symbols.

Action item RFSIGGEN17 generated DM_FILTER enums agreed on. Need to explicitly define what each one means.

Relationship to DM_FILTER_PARAMETER was discussed. Some times parameter doesn’t apply.

Not all filter types are supported by all instruments Discovered that FILTER_TYPES had standards mixed in with them. Standards

removed. Added helper function, ApplyDMStandard and ApplyFilterStandard Deleted Still not sure what to do with filter parameter Need to document in spec that high level functions (green button) is to be

implemented by instrument, not within driver emulating functionality. The specific drive documentation must clarify how the functionality is implemented

(single setup command or implementation of specific standard and rev). Possibility of dropping DM capability for initial spec release. Will continue working on content while reformatting remainder of spec which is solid DM can not be dropped due to user request Issue must be worked in parallel via tele-conference At Paris meeting want to put up core for final review. Submit DM for comment. Concept is

we’re done with the exception of one or two extensions. Reviewed COM Hierarchy Johannes provided presentation Discussed repeated capability for sources. Agreement that structure OK for modulation

source Is LFGEN a repeated capability?

Yes


Create an active LFGEN property and select active generator method Two proposals for stepped/sweep capabilities

First proposal preferred if “mode” changed to “sweep mode”. At root, “sweep mode, Step, List.

Agreed to add power sweep capability to spec. Goal to implement demo driver for Paris What’s next

Rework spec per hierarchy changes Add LFGEN active concept DM and Burst control are missing. Will be worked over phone near term


22. Legal Working Group

22.1 General Meeting Info:Date of Meeting: March 1 and 2, 2001Location: San Diego, CAChairperson: Kevin BorchertMinutes Prepared By: Dany Cheij

22.2 Meeting Attendees (March 1):


Fred Bode Bode Enterprises 619 297-1024 [email protected]

Kevin Borchert Agilent Technologies 970 679-3387 [email protected]

Dany Cheij National Instruments 512 683-5286 [email protected]

Barry Shikoff Pacific Mindworks 800 337-5940 [email protected]

Kirk Fertitta Pacific Mindworks 800 337-5940 [email protected]

George Geathers TYX 703 264-1080 [email protected]

David Howarth Keithley Instruments 440 498-3044 [email protected]

John Rosenwald Racal Instruments 210 699-6799 x212 [email protected]

Andy Hutchenson Teradyne 978 370-1277 [email protected]

Badri Malynur Tektronix 503 627-5880 [email protected]

Bill Leineweber Tektronix 503 627-1153 [email protected]

Scott Rust National Instruments 512 683-5680 [email protected]


1. Discuss the incorporation timeline.2. Discuss the differences between current operation and future operations (after

incorporation).3. General discussion around any remaining concerns.4. Prepare for General Meeting.


Discussion began on how we are going to transition from the current IVI Foundation to the new IVI Foundation, Inc. The group then walked through the before and after document that Dany Cheij created.














The committee chair of the Marketing Committee and the Users Committee should maintain a list of who the members of the committee are in order to figure out what the quorum. This is the recommendation for all subcommittees.

Those present requested that we create a set of scripts that would tell us how things would operate for each meeting type or task that we operate (e.g., General Membership Meeting, TWG meetings, voting on specs, etc.)

A large discussion about quorums at the subcommittee meetings. Does the 25% quorum requirement stated in the by-laws affect our operating procedures. We want the voting on specs at the technical committee meeting to include a two-week waiting period before voting on a spec. The decision was made during the general session to have the subcommittee chairs determine how they will conduct their meetings on an on-going basis.

The group went through a timeline of what will happen between now and the Paris meeting in June. The discussions focused around forming the BoD and all the other things that will have to happen between now and then.

The group created a document that will serve as a guide of operation for subcommittee chairs and also describes the operating procedures at the different levels of the Foundation. The first portion of that document describes the operation of subcommittee meetings.

The group decided to present the timeline and before and after documents at the general membership meeting in the afternoon.

Summary of Chairperson’s Responsibilities (Prior to General Meeting)

1. The chair notifies the members of an upcoming meeting ten working days prior to the meeting. The e-mail must contain an agenda and any other required documents.

2. The chair needs to maintain a list of committee members.3. The chair needs to determine if there is a quorum. A quorum consists of at least 25% of

the committee members and not less than two committee members.4. The chair needs to follow Robert’s Rules of Order.5. The chair will post the meeting minutes within 30 days following the meeting.6. The chair will report meeting progress and any issues to the sponsor organization.7. Subject to further change without notice!

Election Process (Prior to General Meeting)

1. Members send in application for level of membership.2. IVI Foundation Incorporated.3. Scott Rust in the sole director until the Board is seated.4. Sponsor-level members have a seat on the Board.5. General-level members apply for a seat on the Board.6. General-level Board seats are voted on by the general membership through a fax vote.


7. Nominations for President, Secretary and Treasurer are sent to the Board.8. The Board votes on three officers.9. The Board determines how the committee chairs will be selected (i.e., appointed by the

Board or by the general membership.).10. The committee chairs are selected.11. The sub-committee chairs are identified (new ones found or current one re-seated).

22.5 Record of Discussion – Friday, March 2, 2001On Friday, March 2, Pat Johnson gave a presentation to the Legal working group regarding the Shared Component Lifecycle working group.

The need for an IVI Foundation policy around shared components was first identified at the Columbus meeting as part of the MSS Subcommittee. Pat feels that this work is now in a critical path. He believes it will be difficult, if not impossible, to release IVI drivers without completing this work. Pat Johnson has a white paper (to be posted to the IVI Server)

Pat presented and discussed the charter of the IVI Conformance Working Group Charter.

Recommendation - The IVI Foundation will retain ownership of and all rights associated with common code components developed by Foundation members. The submitter of the code will have unlimited right of use or adaptation of the submitted code.

General Questions or Issues: How do users and members download shared components? What is the submittal process for shared components? What is the protection of the submitter after the component has been submitted for

review and prior to it being approved. What is a shared component?

Support Questions or Issues:

The IVI Foundation will need to provide on-line assistance in the form of examples or guidelines for the shared components.

The IVI Foundation will not provide telephone or “real time” assistance. Who fixes code that is donated if it's broken. Looking at having a phone number w/answering machine.

Miscellaneous Questions or Issues:

IVI “Compliance” will require a defined, enforceable level of testing. This really applies to the web site.

Action Plan:

Pat will post his white paper to the IVI list server by March 9th.


Pat will post a draft proposal regarding the Shared Component Lifecycle specification to the IVI list server by April 15th.

Will have a conference call 1 week after the draft proposal is posted.


23. API Style Guide Working Group

23.1 General Meeting Info:Date of Meeting: March 2, 2001Location: San Diego, CAChairperson: Steve GreerMinutes Prepared By: Steve Greer

23.2 Topics To Be Discussed:Steve collected a list of topics to discuss.


safe array parameters – where to put the suggestion in the spec? Serge – where do you have things like when to use [out,retval] vs. [out]. We decided to create section 5, COM IDL Style. John Harvey will help Steve fill in the content for this section.

Where to document disable function – 3.1 section of class spec. Table will be renumbered starting at each major section. Class Spec Appendix C will contain the class header file. Class Spec Appendix D will contain the class IDL file. Table showing relationship between functions and attributes. If there is a one-one

correspondence between parameters and attributes, the parameter description should specify that the parameter changes that attribute. If it is not one-one, the relationship should be described in the function description.

What about including the Visio document? Don’t include in the class spec, but do make it available with the spec on the web site. Put a note in the style guide to the effect that class spec authors must keep the visio document up to date.

Discussion of how to document interfaces. Fix the grammar/tone of the interface hierarchy section – perhaps more in the imperative, but

not as rules (shalls). Remove vernacular. Definitions of Terms and Acronyms needs an explanation of what should be put in it vs. in

the IVI Glossary. Controlling Automatic Parameter Setting Repeated Capabilities – Text that goes after the COM hierarchy table – if the text has

repeated capabilities implemented as collections, document Item there. Role of the API Style Guide. With regard to instrument specific features, we want to make

sure that it is clear to a driver developer that is just becoming familiar with the specification what is required to comply with the spirit of the specification. In the sections that use class names, specific driver developers should replace the class prefix with the specific driver prefix. John Harvey will review to see if any additions to the 3.1 spec are appropriate.


Review process:1. Chair will publish a version by May 1. No change marks.2. Conference call around May 15.3. Publish revisions based on comment from conference call one week before June meeting.

With change marks.


24. Promotions Working Group

24.1 General Meeting Info:Date of Meeting: March 2, 2001Location: San Diego, CAChairperson: Dany CheijMinutes Prepared By: Dany Cheij



Dany Cheij National Instruments 512-683-5286 [email protected]

Fred Bode Bode Enterprises 619-297-1024 [email protected]

Kevin Borchert Agilent Technologies 970-679-3387 [email protected]

Dave Ptacek Rockwell Collins 319-295-0198 [email protected]

Pat Johnson Racal 210-699-6799 [email protected]

John Rosenwald Racal 210-699-6799 x212 [email protected]

Bill Leinweber Tektronix 503-627-1153 [email protected]

Gayle Matysek Northrup Grumman 410-765-9754 [email protected]

Scott Rust National Instruments 512-683-5680 [email protected]


The group talked about what things could be done from a promotions point of view. Ideas included:

1) Revamping the web site2) Holding a press event at either AutoTestCon or Productronica3) Brochure should be a top priority:

a. We should explain key terms such as interchangeability. We should describe what will be interchangeable.

b. A top level graphic and top level description of what the IVI Foundation is all about. The main point is to drive people to the web site and to provide a method for people to find out about what IVI is all about.

c. This can be used as a way to introduce IVI to new users.d. We need an overview of IVI, what are the pieces that I need, what are the

differences between the different architectures.












e. We could hire a writer, hand them some information and have them create a piece.

f. We could follow the technical groups’ lead and have regular phone conferences.g. We could work on a presentation that we could then convert into the brochure.

The presentation could also serve as the basis of an IVI-101 piece.h. AutoTestCon can be a good forum to “test-drive” the presentation. If we could

come up with the presentation in time, we could actually give people a chance to preview the information.

i. Pete Richardson said that we need to make sure to be truthful and not mislead people into thinking that IVI is the silver bullet.

j. Gayle suggested that we need to describe the process (with diagrams) of how you go about using a specific driver with a class driver, etc.

k. Scott Rust said that our goal should be to start in a simple fashion and move on to more complex situations

l. Where can we get information to actually start putting this together? We could use the presentations, and we can also leverage the spec documents, especially 3.1.

m. It seems like we need to have the IVI-101 document first, and then work on the brochure.

n. John Rosenwald will put together an outline of what should go in the brochure and the IVI 101 .pdf file.

4) We decided that we need four things:a. A brochureb. A IVI 101 pdfc. A IVI 101 presentationd. Update the web site (lower priority)

5) Action items:a. John to come up with a outlineb. Dany to solicit input from Membersc. Dany to e-mail documents and links to Johnd. Dany to e-mail conference call numberse. Kevin and Dany to coordinate the creation of the brochure

6) Pat Johnson presented on the IVI Common Code Component Support Model.
