meeting minutes - may 2000 - ivi foundation · web viewglenn asked if there was a difference...

IVI FoundationMeeting Summaries

May 22nd – 25th, 2000Claysburg, Pennsylvania

Hosted by TYX Corp.

1. Table of Contents

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

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

3. GENERAL MEMBERSHIP MEETING.....................................................................................................4

4. WORKING GROUP SUMMARIES..........................................................................................................12

5. IVI COMMON COMPONENTS AND IVI MSS......................................................................................18

6. IVI-3.2: INHERENT CAPABILITIES.....................................................................................................20

7. IVI C WORKING GROUP........................................................................................................................ 22

8. RF SIGNAL GENERATOR WORKING GROUP..................................................................................23

9. USERS WORKING GROUP..................................................................................................................... 26

10. DIGITAL WORKING GROUP............................................................................................................. 29

11. IVI-3.1: ARCHITECTURE................................................................................................................... 37

12. COMPLIANCE...................................................................................................................................... 39

13. GUIDELINES FOR API STYLE........................................................................................................... 40

14. SPECTRUM ANALYZER..................................................................................................................... 42

15. SIGNAL INTERFACE WORKING GROUP........................................................................................47

16. COM WORKING GROUP.................................................................................................................... 52

17. POWER METER................................................................................................................................... 61

18. LEGAL SUBGROUP............................................................................................................................. 64

19. PROMOTIONS SUBGROUP................................................................................................................70

20. IVI-3.1 SC3 WORKING GROUP.......................................................................................................... 71

21. IDL Working Group................................................................................................................................. 73

IVI Foundation Meeting Minutes 1 May 22 – 25, 2000

2. Meeting AttendeesName Company Phone Email

Anne Faveur Advantest +33 1 69182592 [email protected] Hirakoso

Advantest 503-627-2671 [email protected]

Bob Stern Agilent 707-577-288 [email protected] Gladfelter

Agilent 970-679-5329 [email protected]

Joe Mueller Agilent 970-679-3248 [email protected] Harvey Agilent 970-679-3535 [email protected] Borchert


Lynn Wheelwright


Michal Krombholz


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


Terukuni Okuyama

ASCOR 510-490-2300 [email protected]

Paul Salopek BAE Systems 614-759-5399 [email protected] Richardson

BAE Systems +44 131 314-233x

[email protected]

Tom Timuho BAE Systems 614-759-5356 [email protected]

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

Boeing 425-266-4086 [email protected]

Greg Cala Data Science Automation

724-745-8400 [email protected]

John Prescott Defense Logistics Organization (UK)

+44-1244-288331 x7694

[email protected]

Magnus Jansson

Ericsson Radio Systems

+46-26-156450 [email protected]

Dean Lawler Hamilton Software 707-542-2700 [email protected] Sakmar Keithley Instruments 440-542-8016 [email protected] Ryland Keithley Instruments 440-498-3134 [email protected]


mailto:[email protected]




















Name Company Phone EmailNeil Shah Lucent Technologies 614-860-5010 [email protected] Cheij National Instruments 512-683-5286 [email protected] Burnside

National Instruments 512-683-5472 [email protected]

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

National Instruments 512-683-8374 [email protected]

Gayle Matysek

Northrop Grumman ESSD

410-765-9754 [email protected]

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

Jochen Wolle Rohde & Schwarz +49 89 4129 3044

[email protected]

Johannes Ganzert

Rohde & Schwarz +49 89 4129 3045

[email protected]

Toni Bunsen SEKAS +49-89-7481340

[email protected]

Eric Sacher Serendipity Systems 520-282-6831 [email protected] Rauniyar

Tektronix, Inc. 503-627-1191 [email protected]

Paul Nelson Tektronix, Inc. 503-627-3138 [email protected] Staub Teradyne 978-370-1515 [email protected] Lopes Teradyne 978-370-1377 [email protected] Dean The Mathworks, Inc. 508-647-7495 [email protected] Neag TYX 703-264-1080 [email protected] Ramachandran

TYX 703-264-1080 [email protected]

Daniel Eriksson

Vektrex 858-578-6787 [email protected]

Kirk Fertitta Vektrex 858-578-6787 [email protected]



















3. General Membership MeetingDate of Meeting: February 25th, 2000Location: Claysburg, PAChairperson: Scott RustMinutes Prepared By: Scott Rust/Craig Staub

3.1 Topics To Be Discussed:- Introductions- Review Agenda - Scott Rust- Membership - Scott Rust

- Review- Approve New Members

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

- Resolution from the User Working Group- COM Working Group Summary- Legal Working Group Summary- Promotions Working Group Summary- Power Meter Working Group Summary- Other working group summaries as needed

- Liaison Reports- SCPI – Jochen Wolle- ASAM-GDI – Jochen Wolle

- New Business Items- I/O library requirements in the IVI Foundation- Relationship of COM I/O discussions to the IVI Foundation

- Schedule for Next Meetings- Info on the August meeting in Fort Collins, Colorado

- Discussion of schedule and priorities- Propose date and location of following meetings

- Track 1 Meeting in San Diego- Next general meeting

- Adjourn

3.2 Voting Members In AttendanceCompany Representative

Advantest Yohei HirakosoAgilent Joe MuellerASCOR Terukuni OkuyamaBoieng Mark Stamper


Company Representative

BAE Systems Peter RichardsonData Science Automation Greg CalaDLO John PrescottHamilton Sotware Dean LawlorLucent Technologies Neil ShahNational Instruments Jon BellinNorthrop Grumman Gayle MatysekKeithley Instruments John RylandRockwell Collins Dave PtacekRohde & Schwarz Jochen WolleTektronix Paul NelsonTeradyne Teresa LopesTYX Narayan RamachandranVektrex Kirk Fertitta

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

3.3 Membership ReviewScott Rust passed out a membership roster for the members to edit and return. Scott Rust 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

Smiths Industries Aerospace Display & Control Systems Associate

C&H Technologies, Inc Associate

KMS Koch Microsystems Associate

Bode Enterprises Associate

Motion to approve the new members. The motion was unanimously approved.

3.5 Approve minutes from the previous General Membership MeetingMotion to approve the minutes as amended. The motion was unanimously approved.


3.6 IVI Account Summary - Scott Rust

IVI Account Summary

1999 Balance $20,308.32

2000 Revenues $13,300.002000 Expenses $364.85

Current Balance $33,243.46

3.7 IVI Working Groups

3.7.1 Resolution from the User Working Group

Users are concerned about the quality of the IVI components that vendors supply. They would like some type of certification process for IVI components. Therefore, they proposed the following resolution:

Resolution:

We the IVI Foundation resolve to create a working group to establish IVI Facilities for IVI component certification.

Discussion:

The users would like to see a group attempt to address their concerns. It is possible that the group might decide that this goal is not possible. If so, they need to report back to the User working group.

Lynn W. – As a minimum it would be nice to see a proposal from the group on how to handle the issue.

Dean L. – said that he would be interested in leading this group.

This would be part of the critical work required to complete the IVI specifications necessary for vendors to begin delivering IVI drivers.

Things that should be covered are: list of things to verify in the test what entities would perform these tests will there be different levels of certification what happens if you fail certification who pays for the certification access to instruments


what about certification of wrappers that are written without access to the instrument what are the legal ramifications how this relates to the use of IVI trademarks, logos, etc. Can you say that you are IVI compliant and not be certified? Economics of proposals – how many driver’s per year, time per driver, cost per

driver, etc. Who will create the compliance tests? Who validates the compliance tests? Who stands behind the certification?

The group would like a report at the August meeting.

The resolution was unanimously approved.

Dean L. will serve as the chairman of the working group. The working group is called the Certification Working Group. Interested parties include: Fred Bode, Gayle Matysek, Joe Mueller, Dave Ptacek, Craig Staub, Neil Shah, Zulfiqar Haider, Greg Cala, Jochen Wolle, Daniel Eriksson, Roger Oblad.

3.7.2 Motion Regarding Funds for use in Incorporating the IVI Foundation

The legal sub-group has selected an attorney to help incorporate the IVI Foundation. The group requested that the general membership authorize the legal sub-group to spend up to $15,000. The following motion was made.

Motion:

The legal group is authorized to spend up to $15,000 in the process of incorporating the IVI Foundation.

The motion was unanimously approved.

3.7.3 Working Group Summaries

The chairman for the following working groups gave summaries of the progress made during their meetings. The summary info is recorded in the Working Group Chairmen Summary Reports section in the Meeting Summary document.

COM Working Group Summary (John Harvey) Legal Working Group Summary (Kevin Borchert) Promotions Working Group Summary (Dany Cheij) Power Meter Working Group Summary (Zulfiqar Haider)


3.8 SCPI Liaison Report – Jochen WolleThere was no SCPI meeting between Q1 and Q2 meeting. There will be a meeting between now and August meeting

3.9 ASAM-GDI Liaison Report – Jochen WolleFred Bode and Jochen met with ASAM group

Info about ASAM Association for Standardization of Automation and Measuring Systems Consortium comparable to the AIGER group Since merger of Chrysler of Daimler They are working on standardization, including driver work There are 70 companies in consortium

o Automotive companieso Test companies

Financially well-equiped ($200K budget/yr)o Paying for certification

Started 6-7 years ago as German consortium They are a legal entity Jochen met with head of ASAM and discussed what IVI, VISA, and ASAM are

all about He feels that looking at what ASAM is doing is worthwhile so as to compare how

ASAM and IVI are functioning Head of ASAM is willing to give presentation at August meeting

o AIGER (American Industry/Gov’t Emissions Research) is looking to merge (or at least cooperate)

o They have a platform similar to VISAo They have done a lot of work on a lot of stuff we haven’t done (and vice-

versa)o They have a concept of class structures, but haven’t written any yeto They have worked on data representation (which we haven’t worked on)o They are working with XMLo Major difference results from the automotive industryo Conducted experiment to write driver on their platformo Paper study on how AIGER (American organization) and ASAM

(German organization) fit together Initial results show that they will fit well together ASAM has spent four years working on certification The paper will include comparisons, contrasts Will be sent out to IVI foundation prior to August meeting

General Conclusions:o There is a lot of benefit to working with themo Much to learno Now is a good time because why redo the work later


o If we agree to work together, then Joshen is volunteering to work on “translation of terms”

Discussion:o Q: Are there web pages to learn about the organization?o A: Web-site was mostly translated from German to Englisho Comment: Cross-pollination is a good ideao How will this paper be discussed/presented to IVI foundation?

Most of the General members felt they would attend such a presentation

Consensus: Presentation will be limited to 30 minutes, and present at the end of the general membership meeting

3.10 New Business Items I/O library requirements in the IVI Foundation

o For certain types of I/O, can we mandate which I/O library to use?o There has been no attempt to list what the real requirements are from a user

scenarioo We need to decide which direction to go, then outline technical requirementso Define IVI driver requirements surrounding the corresponding I/O libraries

Should this be considered in the User’s group? Some work has been done in the VISA working group

o There will be more data after the last day of May IVI meetingo COM I/O presents a part of the solution, but more discussions need to take

place Consensus for solution roadmap:

o Use 30 minutes of VISA and COM I/O workgroup meeting on Thursday of May’s IVI meeting to discuss I/O library requirements

o Goals: Clarify IVI Driver I/O Library requirements Define the needs for required I/O from different points of view

User’s point of view Supplier’s point of view

o Gayle will email users to gather input for next meetingo I/O library issues will be covered in VISA and COM I/O workgroup meeting

at future IVI meetings

3.11 Next general meeting Info on the August 21-25 meeting in Fort Collins, Colorado Hotel: University Park Holiday Inn

o Ask for Agilent Technology, IVI Foundation Meetingo Info packet will be sent out within next weeko Reservations must be made by June 21 for guaranteed roomo Discussion of schedule and priorities


What are the critical items so that we can find times to discuss (San Diego Config Store meeting, conference calls, August IVI meeting)

August Meeting Track 1o C architecture and C shared components working groups

Time needed: Half day (evening meeting proposed)o COM architecture working groups

Time needed: Half day (shared with IVI COM factory)o IVI 3.1 Driver architecture and Incorporating the compliance issues

Time needed: Full Dayo IVI 3.2 Inherent capabilities

Time needed: Half Day (to wrap it up)o IDL

Time needed: Half Dayo SC3

Time needed: One Hour?o Config Store

Time needed: Half Dayo IVI COM factory

Time needed: Share half day with COM architectureTOTAL TIME: 3 Days (and one evening)

San Diego Meeting (7/17-7/20)o Config Store

Time Needed: Two Dayso Repeated Capabilities

Time Needed prior to meeting: Time Needed in San Diego: One Day

o General Technical Issues (to be place on agenda before meeting) Hierarchy, reset/init, ?, etc. Time Needed: Half Day

o Event Server (at end or beginning of the meeting)TOTAL TIME: 3.5 Days ATTENDENCE: 10-12 people

Q4 Meetingo TIME: November 13-17, 2000o LOCATION: Las Vegas, NVo HOST: IVI Foundation, Kurt as site coordinator, Scott as funds collectoro New Precedent: Each Attendee will pay for his/her own luncheso For now, attendees will pay NI with check/cash, and NI will pay conference

center. If anyone is negligent, then the company will be billed.

Action Item: Scott to send out email to all working group chairs instructions on how to upload documents to IVI web-site


3.12 Adjourn


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

4.1 IVI-Common Components and IVI-MSS (Roger Oblad)The group spent the majority of the time on the IVI Configuration store. Did not talk about Locking, IVI Factory, or IVI COM base classes. Roger gave an overview of the proposed MSS architecture and how IVI drivers relate to the MSS architecture.

IVI-MSS: Next Steps

There is confusion over the terms used to describe components. The group specifically wants to resolve conflict over the use of the word “Role” between MSS and the IVI Configuration store.

The group wants to revise IVI specification 12 to remove the event server, remove the asset server, adopt new terminology, and add requirements for MSS compliance.

Action Item – Scott Rust to generate a document number for the IVI Locking Component specification

Event Server: Next Steps

Move the specification from Section 12 to a new IVI Document Deal with misc issues that the group has identified.

The group is proposing an interim meeting in San Diego to discuss the IVI Configuation Store and the Event Server. Interested attendees are John Harvey, Jon Bellin, David Fuller, Teresa Lopes. Kirk Fertitta will setup the meeting and broadcast an email to the IVI email list server.

Joe Mueller suggested that we go back and look at the MSS charter now that we have taken several components that were originally proposed by MSS and created distinct working groups for them.

4.2 IVI 3.2 Working Group (Scott Rust)The group reviewed issues found by the general membership with regard to the draft specification that was posted to the IVI list server prior to the meeting. The group also discussed the two proposal documents that were posted prior to the meeting: Ivi32Proposal 8May2000.doc, and AdditionalIvi32Proposals 15May2000.doc. The group agreed to all of the proposals in the Ivi32Proposal 8May2000.doc. Scott Rust will incorporate them into the specification.


The group agreed to all of the proposals in the AdditionalIvi32Proposals 15May2000.doc with one exception, the proposal for discovering channel names. This proposal is dependant upon the repeated capabilities proposal that is currently up for discussion in the IVI 3.1 IVI Driver Architecture. Scott Rust will incorporate the other proposals in the specification.

There was a lot of discussion regarding the purpose of the Reset and Disable function and whether it is necessary to have and additional function that does something like “resets the instrument to an interchangeable state”. The group agreed that we need a Disable function and that we need a Reset function that just sends the *RST. The group agreed that we need a third function. However we need to still define the functionality. The group will attempt to resolve this issue via conference calls prior to the next meeting.

4.3 IVI C Working Group (Jon Bellin)Reviewed Jon’s C API for C Shared Components document. The goal is to clean up the document and turn this into a specification, implement the shared components, and implement prototype drivers based on the shared components prior to the next meeting.

Action Item – Jon Bellin volunteered to draft a C version of the Config Store API prior to the next meeting.

4.4 RF Sig Gen Working Group (Jochen Wolle)The group reviewed draft 3 of the spec. It represents a reformatting to the same format as the recently approved version 2.0 class specifications. Discussed an “is settled” functionality in the base capabilities. The group felt like this capability should also be in other source classes such as function generator or DC power supply. The “is settled” capability is used to determine if the output of the source has settled to the configuration that user specified. The group wants to have blocking and non-blocking versions of the capability.

The group was able to cover more than 80% of the specification, but was unable to cover some of the digital modulation extensions. The group wants to work between meetings to cover these specifications.

The goal for the group is to have a document ready for vote by the meeting that follows the August meeting.

Action Item: Scott Rust to generate a document number for the RF Sig Gen specification.

4.5 Users Working Group (Gayle Matysek)The group defined its mission and working process. The group defined a resolution for the General Membership regarding the formation of a working group to propose how the IVI Foundation certifies IVI components. The group discussed issues with regard to the IVI 3.2 specification – Default values for some of the inherent attributes and the role of the reset and disable type functions.

Gayle encouraged other working group chairmen to work with her to define issues that the users working group should discuss.


Would like to minimize the schedule conflict between the users working group and other technical sessions.

4.6 Digital Working Group (Teresa Lopes)Had the 1st half of their meeting on Monday. They covered the outline of the specification, which has a base capability group and two extensions. Some of the group felt that some of the new functions really belong on the SC3 specification.

The group discussed the name of the specification. Would like to use IviDigital. Some in the group felt that this violated an 8 character rule on class names. The limit on class names is now 31 characters.

Action Item: Scott Rust to notify the classes currently under consideration that the 8 character prefix is no longer a hard requirement and give them the chance to use different names.

The group had a brief discussion of whether the class should have an instrument focus or signal focus. The group decided to continue with the instrument focus and work with the Signals working group to see if that group wants to define a signal interface for digital instruments.

Made it through the first rough draft of the specification. Want to look at the other class specifications to see how they handle issues similar to those in Digital spec.

Created a schedule for the work between meetings. Will have a conference call in the June timeframe so that they can have two reviews prior to the next meeting.

Put together a rough outline of features to be added in future versions of the specification.

4.7 IVI 3.1 Driver Architecture Working Group (Scott Rust)The group discussed the Repeated Capabilities proposal from Srdan Zirojevic. The group compared and contrasted the proposal against several other alternatives. The group did not come to an agreement and will attempt to resolve the issue via telephone conferences prior to the next meeting.

The group reviewed a proposed outline for the first draft of the IVI 3.1 specification. Some of the introductory material was removed and it was decided to document the compliance requirements of specific drivers in a single section rather than spreading this material across the sections that describe the overall architecture and requirements of IVI drivers.

The group was unable to review the proposal regarding error handling. John Harvey volunteered to review the proposal during the COM Working Group.

It was discussed that there are several naming issues in the IVI 3.2 specification where function, attribute, value, or error names do not match the current naming recommendations


in the current draft of the API Style Guidelines specification. Scott Rust will enumerate these potential problems and review them with the IVI 3.1 working group via a conference call.

4.8 Compliance (Joe Mueller)Reviewed the compliance document from the November meeting. Two main areas of conformance – Architecture conformance, and class conformance. There were several people in the room that were surprised that it was possible to have an IVI driver that only complied with the architecture. The documentation of compliance will be moved to the IVI 3.1 specification. Trademark issues have been moved to the Legal/Promotions group. The Legal/Promotions group will decide how IVI drivers express their compliance with IVI standards. Therefore, the Compliance sub-group has completed its work and will disband.

The group has the desire to resolve IVI architectural issues rapidly. Therefore, we want to carefully prioritize the topics of the next few meetings so that vendors can begin delivering IVI drivers as soon as possible. We will talk about this at the General Membership meeting.

4.9 Guidelines for API Style (Steve Greer)The group spent the first part of the meeting talking about naming conventions for things like function names, class names, capability group names, COM interfaces, etc. Spent a lot of time talking about “fuzzy comparisons” of real numbers. Another major topic was the discussion of hierarchies. Two hierarchies exist – Function hierarchies and COM hierarchies. We will hold conference calls to try to develop recommendations for hierarchies prior to the next meeting.

In two meetings, Steve feels that we will have enough of a spec that we can consider voting on it.

4.10 Spectrum Analyzer (Neil Shah)The group feels that they have finalized the base capabilities. Moved the trigger functionality to multiple extension capability groups. The group had a conference call to deal with issues regarding markers. The group wants feedback from the users regarding markers. Neal will send the issues to Gayle Matysek. The group feels that multi-trace capability is a critical feature of the Version 1.0 specification. The final solution for multi-trace is dependent upon the repeated capabilities issue.

The group feels that they can have a specification that is ready for vote after the November meeting.

4.11 Signal Working Group (Narayanan Ramachandran)Reviewed the requirements and design issues for the specification. Had a discussion of the use of XML for the description of resources. Want to come the next meeting with a rough draft of the specification.

The group wants to use the web site to post their documents.


Need more time to review the documents that were presented for the group’s consideration.

4.12 COM Working Group Summary (John Harvey)Talked about where the COM specs live. Most of them will live in 3.1 or 3.4. Will keep the COM Reference Technology document alive until it is no longer needed. Focused on interface issues and packaging.

Looked at scheme for error codes between COM and C drivers. Got about half way through the proposal and will follow up with conference calls.

4.13 Power Meter Working Group Summary (Zulfiqar Haider)The spec consists on one base capability group. The group was able to review the entire capability group. They subdivided the single group into an additional 4 extension groups.

The group identified that many of the attributes are input-based or measurement-based. Want help from vendors and users to identify the same for some of the attributes.

The group proposed a way to specify the units for many of the attribute settings of a power meter and control the auto-range capability. Therefore the group needs resolution on the repeated capabilities issue.

The group identified the remaining open issues that need to be addressed prior to a 1.0 version of the specification.

4.14 Legal Working Group Summary (Kevin Borchert)Reviewed what has been going on with the selection process for the legal firm since the last meeting. The group agreed to select Andy Updegrove at the law firm Luchash, Gessner, and Updegrove to represent the IVI Foundation.

Goal is to distribute by July 31st the first pass of the Articles of Incorporation and By-Laws to the general membership. Plan to have a working group and the August meeting to address issues raised by the general membership.

Scott Rust read a letter stating that National Instruments intends to make the trademark for IVI available to the IVI Foundation once the group incorporates.

Reviewed legal issues that the group wants Andy U. to address as part of the incorporation process.

The legal team to work with Andy is Kevin Borchert, Dany Cheij, and Fred Bode. The group will attempt to move ahead quickly while keeping the group informed and allowing for anyone to participate in the process that wants to

Fred Bode recommends that we authorize the group to spend up to $15,000

Motion:


The legal group is authorized to spend up to $15,000 in the process of incorporating the IVI Foundation.

The motion was unanimously approved.

4.15 Promotions Working Group Summary (Dany Cheij)Did not have a lot of time to discuss promotions activities at this meeting. One idea is to have some time of media alert on the IVI Foundation web site to alert the media on what happened at this meeting. Some newsworthy items are:

First Users Working Group Meeting Created a Certification Working Group to investigate possibilities of certifying IVI

SW components 4 new members and high numbers of attendees at this meeting

The group agreed the promotions group should create the media alert.

The promotions group also needs to address general confusion in the general community regarding the types of IVI drivers that will exist. In particular we need to address IVI drivers that are compliant with the Inherent Capabilities and not compliant with a class specification. In the 3.1 discussions there was a proposal to use a term such as IVI Custom to identify these drivers.

Dany Cheij will make a first stab at the marketing information necessary to communicate the intentions and goals of the IVI Foundation as well as the way to identify with what a driver is compliant. He will do so by the August meeting.


5. IVI Common Components and IVI MSS

5.1 General Meeting Info:Date of Meeting: May 22, 2000Location: Claysburg, PAChairperson: Roger ObladMinutes Prepared By:

5.2 Record of DiscussionsAgenda (Roger Oblad)

Roger had one slide set that includes the agenda and the MSS presentation. [Roger slide – Replace “Asset Server” bubble with “IVI Factory” and “Configuration

Store” bubbles.] The presentation noted that the issues of IVI ownership and support of common

components must still be addressed.MSS slides (Roger Oblad)

MSS specification overview Terminology discussion [Roger has IVI-COM throughout the slide set, and at least some should read IVI. Roger

will review all occurrences of COM in the slides.] John – Meaning of “IVI Driver” – it implies class compliance in some contexts and not

in others. This should be discussed in the 3.2 and/or compliance discussions.Discussion of Configuration Store (Kirk Fertitta)

What does “required” really mean in config store IDL? For example, is H/W Asset really required for all configurable components?

David Fuller’s XML has Default Setup that does not show up on the Config Store Class Diagram – Default Setup is reflected in the diagram as an IVI Attribute set.

John Harvey showed a class diagram [XML Class Diagram.ppt] based on David Fuller’s .dtd file.

John Harvey raised the question, “Can you add stuff to the XML file that is totally custom?” Answers from Ion Neag and Teresa Lopes: You can if you don’t use the .dtd file. If you use the .dtd file, you will get errors in certain applications such as XML notepad unless you modify the .dtd file to accommodate the syntax of the added XML.

Discussion of Configuration API (Kirk Fertitta) Kirk presented an overview of his config API. Do you need an Attribute Template in order to implement an Attribute Set? What form does the C API take? How is it related to the COM API? In general, this seems too complex, at least for users – what about simpler solutions?

What about interfaces geared to different mental models, for instance the driver writer. How do we partition these into classes? How is the referential integrity of the config store enforced? What about multiple readers and writers?


Discussion of Event Services (Roger Oblad) Roger gave a presentation regarding the Event Server Agilent Technologies will be using the Event Server internally, and believes there is

value in making it available generally, to avoid having to make translations between various ways of propagating asynchronous events through systems.

IVI Factory component (Kirk Fertitta) Waiting on the config store.

Action Items:MSS – Roger will make noted changes to slides and resend.MSS – Need more discussion on terminology & documentation. Scope went well beyond MSS.Config Store – Schedule working group meeting in San Diego. Kirk. (maybe telephone conferences also?)Config Store – John will send out config store class diagram.Event Server – Pin down the requirements for the event server.Event Server – Ask the user group to generate a list of use cases for event server.


6. IVI-3.2: Inherent Capabilities

6.1 General Meeting Info:Date of Meeting: May 22, 2000Location: Claysburg, PAChairperson: Scott RustMinutes Prepared By:

6.2 Record of DiscussionsAgenda (Scott Rust)

Scott reviewed the agenda and added, “Reset, Disable and Re-initializing”. Scott handed out Srdan’s proposal for repeated capabilities and added to the list. Additional items from Joe Mueller – choice of error code names, function names (a

little). There are some differences with the style document.Review of IVI 3.2 proposal dated May 8, 2000

The group agrees with this proposal and Scott Rust will incorporate them into the 3.2 document.

Review of IVI 3.2 proposal dated May 15, 2000 GetNthChannelString

Channel strings need to be defined somewhere, along with restrictions. We need to specify what occurs if the user passes less than 0 as the index for

channel strings. Approval of the channel string proposal is subject to approval of the repeated

capabilities proposal. Change name to GetChannelString and make the indexes 0 based.

Wrapper functions COM wrapper functions need to be in a different interface than Utility. Will have problems using ViAddr for IUnknown pointers in

GetSpecificDriverIUnknownPtr and GetNativeIUnknownPtr. It won’t work in VB. Need to investigate the correct data type for these functions. ViInt32 is definitely not the right one to use.

Attribute ID Definitions Are there ways to word the 3.3 intro verbiage more simply?

With the reservations listed above, the proposal is accepted.Conference Call Status Report

The user working group agreed with the new proposed defaults for the Boolean inherent attributes.

IVI 3.2 document review Review everything having to do with errors after completing the error proposal

(known problems – 3.1.2 …). NumChannels should be in the Utility interface.


May want to look at naming for Lock and LockSession in the COM API – naming, operation at the object level.

Change interface name Operation to DriverOperation & make the document consistent.

Change Component Prefix to Component Identifier & make the document consistent. State what the format requirements of strings are – c.f. Component Identifier section

5.13 notes. How do we specify BSTR length restrictions? What is the behaviour of Init if you init once against a LogicalName or

ResourceDescriptor and then Init again against the same LogicalName or ResourceDescriptor. It is not guaranteed to work well, but should not be inherently illegal. For COM, it is illegal to try multiple Inits on a driver object, but not to instantiate multiple drivers against the same LogicalName or ResourceDescriptor.

Reset, disable, & Re-initializing The group came up with 5 options for potential functions. People agreed on the need

for a “Disable”, a “VPP Reset” and some form of re-initialize. The reinitialize should put the instrument in the same state as a Close()/Init(). This could include applying some class-defined settings. Steve Greer will experiment with class-defined settings for the existing classes. If we don’t apply class-defined settings, we’ll look at reinitialize w/o the class-defined settings.


7. IVI C Working Group

7.1 General Meeting Info:Date of Meeting: May 22, 2000Location: Claysburg, PAChairperson: Jon BellinMinutes Prepared By:

7.2 Record of DiscussionsThe meeting time was spent reviewing the IVI-C spec document.


8. RF Signal Generator Working Group

8.1 General Meeting Info:Date of Meeting: May 22, 2000Location: C;aysburg, PAChairperson: Jochen WolleMinutes Prepared By: Glenn Burnside

8.2 Meeting Attendees1) Steve Greer Agilent2) Jochen Wolle R&S3) Glenn Burnside NI4) Zulfiqar Haider NI5) Neil Shah Lucent6) Michal Krombholz Agilent

8.3 Record of Discussions1) Reviewed notes from February meeting.2) Started looking at draft 0.2. Looked at base capability attributes and functions.

DisableAllModulation disabes ALL modulation at once – it seems better to not have a reverse functionality to disable a particular modulation as there are interchangeability problems associated with it.

3) Steve proposed that we should avoid abbreviations when naming constants and identifiers.4) Reviewed the concept paper and went through some naming.5) Glenn questioned if the SWEEP_MODE attribute belongs in the Base Extension.6) Mickal proposed renaming the CW SWEEP_MODE value to VAL_NONE.7) Agreed to move the SWEEP_MODE attribute and ConfigureSweepMode function to a

Sweep extension group. All other sweep/step/list groups would be derived from this extension group.

8) Glenn will aid Jochen in setting up the extension heirarchy.9) Discussed the possibility of adding an IsSettled function.10) Mickal proposed that we also need a WaitForSettled function.11) Added a WaitUntilSettled function. Zulfiqar proposed calling it WaitForSettled to be

consistent with WaitForDebounce in switch. Settled on WaitUntilSettled.12) Mickal asked about the ALC capabilities in the Base group. He identified the possibility for

an ALC_BANDWIDTH and ALC_SOURCE.13) Decided to investigate the ALC capabilities of instruments, and possibly add an ALC

extension group. This would move the ALC_ENABLED attribute to this extension.14) Steve asked if ALC should be completely in the base group.15) Agreed that ALC_ENABLED will remain in the base class, but additional ALC attributes

will be placed in an ALC extensions group. The motivation for this is that ALC is typically enabled by default. This causes other ALC attributes to affect the behavior of the


instrument. It is not desirable for an extensions to affect behavior by default. Also, we have identified that virtually all instruments support some kind of ALC circuitry.

16) Question was raised about the interaction between internal source for modulation and the configuration of internal sources.

17) Glenn proposed that DEPTH should assume an input of 1.0 V in the spec. Specific drivers should be responsible for doing the appropriate conversion.

18) Glenn proposed a method to allow the user to specify the combination of internal and external source to which DEPTH and SENSITIVITY apply e.g. “INT1, EXT2”. repeated capabilities?

19) (Resuming after lunch) Jochen summarized the situation from before lunch20) After much debate, we have come to the following agreement:

Sensitivity is renamed to nominal voltage. It is a constant, and will be a read-only attribute.

Depth is the depth which is applied at the nominal voltage.21) It might make sense to move the nominal voltage attribute to a common modulation

extension group.22) Coupling will be moved to an external source extension group23) A similar pattern could be applied to the other modulation sources – FM, PM, PULM.24) Examined the pulse generator extension.25) Michal pointed out that not all pulm generators have double delay settings.26) Agreed to split pulse generator extension into some smaller sub-extensions. (Pulse Double,

Pulse Trigger, and Pulse Output).27) ACTION ITEM: How does TRIGGER_DELAY interact with IMMEDIATE_TRIGGER

source?28) ACTION ITEM: Double pulse delay is given as time relative to what event? (falling edge,

end of period, etc?)29) Changed VAL_RECTANGLE to VAL_SQUARE.30) Agreed to move the LF_OUTPUT_ENABLED and LF_AMPLITUDE attributes to this

extension group.31) Jochen Reviewed the current state of the sweep groups.32) Agreed to remove CENTER and SPAN attributes from the proposed list.33) Agreed that for an analog sweep, we would want a start, stop, and sweep time.34) For a step sweep, we would want a start, stop, dwell time, and step size, and a scale.35) ACTION ITEM: Need to understand what the step size units are when in Logarithmic scale.36) Do we need to add a ConfigureCenterSpan for steps as well as for sweeps?37) How is dwell time defined? Does dwell time block triggers?38) Identified a need for a resetStep function, also a resetList function.39) ACTION ITEM – lists might be able to borrow some syntactics from the IviFgen

ArbWaveform extension group. This needs to be investigated.40) LOTS of possible approaches to the List extension. It is not clear at this time what we really

want to do.41) Mickal notes that some instruments denote power in a list as an offset (in dB) from the Base

Power level.


8.4 Action Items1) Glenn and Jochen will work to revise the specification based on changes made at this

meeting2) Glenn will work with Jochen to fill in the compliance note sections and the notes regarding

extension heirarchies.3) Michal and Jochen will research the ALC capabilities of their instruments and propose what

attributes and functions need to be in the ALC extension group, if any.4) Glenn will research how trigger delay works for an immediate trigger when generating a

pulse waveform.5) Michal and Jochen will research how double pulse delay is specified for their instruments.6) Glenn and Jochen will research how the architecture of the IviFgenArbWaveform extension

can be leveraged to help form the List extension.7) All will research how step size is affected when using a logarithmic step scale.

Entire group needs to work on proposals for the Sweep and Step extension groups. (Specifically, the list extension.)


9. Users Working Group

9.1 General Meeting Info:Date of Meeting: May 22, 2000Location: Claysburg, PAChairperson: Gayle MatysekMinutes Prepared By: Gayle Matysek

9.2 Meeting Attendees:

Name Company Email

Anne Faveur Advantest [email protected]

Joe Mueller Agilent Technologies [email protected]

Peter Richardson BAE Systems [email protected]

Fred Bode Bode Enterprises [email protected]

Mark Stamper Boeing [email protected]

Greg Cala Data Science Automation [email protected]

John Prescott DLO (UK) [email protected]

Dean Lawler Hamilton Software [email protected]

Scott Rust National Instruments [email protected]

Gayle Matysek Northrop Grumman [email protected]

Dave Ptacek Rockwell Collins [email protected]

Eric Sacher Serendipity Systems [email protected]

Narayanan Ramachandran TYX [email protected]

Yogul Shikarpuri TYX [email protected]

Rami Hanbali TYX [email protected]

Daniel Eriksson Vektrex [email protected]

9.3 Record of Discussions:1. Review of comments provided by users of working group goals, products, and

relationship to other working groups. The user inputs and discussion notes (shown in italics) are contained in attachment 1 of this document.

2. Based on the concurrence of the users that a proposal for a level of compliance checking / certification is desirable, the following resolution was formed:


















We the IVI Foundation resolve to create a working group to establish IVI facilities for IVI component certification.

The resolution will be taken to the General Membership meeting for discussion and vote.3. A proposal submitted by Patrick Johnson to realign the Common Code Component

Support Model Committee to be a committee within the User Working Group was placed on-hold due to Patrick’s absence from this meeting. The proposal will be discussed at a future meeting when he can attend.

4. Scott Rust had requested time to present an open item from the 3.2 architecture draft in order to obtain user response. Scott presented several attributes and default value state. The users unanimously accepted the information as presented by Scott.

5. The remaining time was spent discussing another issue related to IVI 3.2 regarding instrument reset and several variations of the theme. No conclusions or general agreements were reached during this discussion. The topic is scheduled to be addressed during the IVI 3.2 meeting.

9.4 Action Items1. Gayle Matysek will prepare a draft of the operating procedures and working group

charter.2. The resolution will be raised to the General Membership at the Thursday meeting.

9.5 IVI User Working Group Mission: Attachement1

Agree Disagree On holdGeneral Keep IVI foundation focus on developing instrument

classes on non-technology related issuesDisagreement based on the concern that we need both technology and class development.

X

Prototypes, demos, etc with pros & cons feedback XProvide actual use models to the instrument class developers (at their request)

X

Provide a place where the other working groups can go to get "end user" input

X

Collection point for visibility to the value of IVI to the end user

X

Internal guides

Detailed overview of the overall IVI approach- required elements- supplied elements- validation/verification/certification required (see CM)-overall post-adoption support required/suppliedUsers do not believe that we should produce a document to meet these needs. The users need to define the need for user guides or application notes & format.

X


Define what is expected from IVI and the drivers XDevelop documents describing users requests in terms of functionalities and usabilityQualification during discussion - not class spec specific, not to overlap cross class capability work.

X

External guides

List of drivers available from others even if they are not complete and available on the market. List of other driver developers and users.

X

How to get IVI drivers (instrument and class) XDescribe the capabilities class drivers provide (State Caching, etc.)Not a separate task - provided through general user feedback during specification reviews.

X

How much will the drivers cost and where do you get them? Provide general feedback to IVI.

X

Define benefits to users to promote their involvement.Feedback to promotion group/user forum (chat area)

X

How to use IVI drivers in end-user's applicationsDefine need for any additional documentation required with Class drivers, help files, app notes

X

CM Tasks Master work in progress list - timeline & progress report of all working groupsDesired by users, not user generated.

X

Configuration managementDesired by users, not user generated.

X

Create a proposal to IVI for a level of compliance checking/certificationGenerate a resolution to form a committee to address this issue -

Resolution: We the IVI Foundation resolve to create a working group to establish IVI facilities for IVI component certification.

X

Reviews Review the class specs and provide feedbackPerformed as part of normal user involvement.

X

Joint Efforts

Common Code Component Support Model Committee proposal

X


10. Digital Working Group

10.1 General Meeting Info:Date of Meeting: May 22-23, 2000Location: Claysburg, PAChairperson: Teresa LopesMinutes Prepared By: Craig Staub/Teresa Lopes

10.2 Meeting Attendees:Name E-Mail Phone

Teresa Lopes [email protected] 978.370.1377Craig Staub [email protected] 978.370.1515Stephen Greer [email protected] 970.679.3474John Prescott [email protected] Haider [email protected] 512.683.8374Eric Sacher [email protected] 520.282.6831Peter Richardson [email protected] (+44) (0) 131.314.2332Narayanan Ramachandran

[email protected] 703.264.1080

Rami Hanbali [email protected] 703.264.1080Dan Zimmermann [email protected] 210.925.4401 ext. 3092Andy Hutchinson [email protected] 978.370.1277

10.3 Working Group Summary: Rename class name to IviDigital Suggest adding support for symbolic names for channels to cross-class capabilities

specification Suggest adding support for defining channel groups to cross-class capabilities

specification Reviewed outline of class and first 2 extension groups Reviewed details of functions and attributes in base class and first 2 extension groups

10.4 Topics To Be Discussed: Review minutes from last meeting Review action items Review IviDigital class outline Serendipity SR192 presentation and discussion Review rev 0.1 of the IviDigital class specificatin

Record of Discussions:













10.5 Item #1: Review minutes from last meetingUsing programming examples of how different instruments get programmed to get a start on defining the API.

Start with how static patterns get programmed Look at how dynamic patterns are programmed so we don’t shoot ourselves in the

foot (don’t something in specifying static patterns that makes it difficult to specify dynamic patterns). The class API must support both static and dynamic.

Starting with the interface is more useful than starting with the attribute model in defining the class

10.6 Item #2: Review Action ItemsWho What By Status

Teresa Look at prior art on the subject of definitions. Check Teradyne glossary.

3/22/00 In process

Teresa Document usage scenarios listed above for Teradyne M9-Series DTI

3/22/00 Done

Kosta Document usage scenarios listed above for NI PCI-6527

3/22/00

Kosta Document usage scenarios listed above for NI PCI-DIO-32HS

3/22/00

Pat / Eric Sacher Document usage scenarios listed above for Talon SR-192

3/22/00 Done

Pat/Dale Johnson Document usage scenarios listed above for IT DWG

3/22/00

John Document usage scenarios listed above for RACAL digital I/O

3/22/00

John Document usage scenarios listed above for BAE Systems Digital I/O

3/22/00

Teresa Arrange for conference call the week of March 27.

3/22/00 Done

Discussion of Action Items Eric has provided examples for using the Talon SR192 Teresa has made an outline for the class specification using Eric’s examples and the

M9 examples. Everyone needs to provide “interface to instrument” examples so that we have more

than two data points

10.7 Item #3: Review IviDigital class outlineWhat do we need to cover?

How to program patterns statically and dynamically Base class and extension groups Base class has some functionality, but to be compliant must either or both the Static

or Dynamic extensions.


Do other digital instrument specify the execution mode at both the instrument and channel level?

o The M9 allows the specifying of the execution mode at the instrument, channel and group of channel level.

o The Talon SR192 specifies it only at the instrument level.

IviDigitalBase Capability Group Group Functions

o How are channels and groups identified? - Numeric, alphanumeric, both? Discussion of Virtual Channel Names

o Virtual channel names are not specific per applicationo Should the IVI driver take care of the mechanics of mapping “symbolic”

channel names to virtual channel names or physical channels? Should the class provide an API or should it be left to the programmer? Could go from symbolic names (for application readability) to virtual

channel names (for interchangeability) to instrument channel names (via the IVI.ini files) – three levels of inderiction

Programming example: IviDigital_LoadOpcode(vi, “U_10”, IVIDIGITAL_IH); IviDigital_LoadOpcode(vi, “U_11”, IVIDIGITAL_IL); If we just provide the IVI virtual channel capability, then “U_10” (which

is meaningful to the application) would be replaced with “P0” (not meaningful to the application). So, the application would need code that maps “U_10” to “P0”. If this is something that most users of the class are going to want to do, why not build this capability into the class.

One more example: IviDigital_DefineChannel(vi, “U_10”, “P0”); IviDigital_DefineGroup(vi, “databus”, “U_10, U_11”); Is there a nicer way to do this? We all agreed that the virtual channel names are important since each

instrument has a different mechanism for identifying channels (e.g. zero versus one based channel numbering)

If we think that allowing for application specific channel names is a good thing, should it be specified by the IviDigital class or in the cross-class capability specification?

Same question applies to defining groups of channels.

IviDigitalStatic Capability Group IviDigitalQueryPatternResult

o Should the result be a Boolean or an enumeration? The consensus was that an enumeration was better. The result could be than just a simple pass/fail.

IviDigitalDynamic Capability Group Instrument attributes are configurable for the instrument, but some instruments don’t

allow these to be configured. So, maybe make it read/write, but some instruments


only support a single value. If you tried to write to an instrument that supported one value, an error would be returned.

Don’t allow the pattern rate to be specified as either period or frequency. Only support one method for specifying the pattern rate. The consensus was to use period.

How should we identify multiple pattern sets in instrument memory? Proposed solution is to use named pattern sets.

We should support synchronous and asynchronous execution of pattern sets. A pattern set timeout should be returned as a status instead of a result. Functions to query pattern and result information for channels are different for static

and dynamic. The dynamic functions need to include the pattern number.

General Discussion What are we missing from the base class? What data types are allowed for specifying the value for group functions?

o Only allow 32 bit groupso Use an array to pass the value and then allow arbitrarily large groupso Are groups of groups allowed? How do groups defined as a group of groups

interpret the data?o The M9 uses arrays to pass the group value. Customers think this is

cumbersome when you have a small group. The basis for the IviDigital class will be the base class, and the static and dynamic

pattern loading extension groups. More advanced capabilities will be specified later in extension groups:

o Levelso Timing

10.8 Item #4: Serendipity SR192 presentation and discussionEric: We should look at things from a signal orientation instead of from instrument.Eric proposed defining a set of attributes for everything. He doesn’t like extensions. If the instrument can’t do it, then it can’t do it.Show everything, but make it easy for the types of instruments that don’t support it, i.e., allow instrument to not support attributes or functions.Teresa: Extension groups give you the ability to determine if an instrument supports a certain capability without having to try and call the function to find out whether or not the instrument can do it.Description of Serendipity SR192 programming environment:

Patterns specified in tables – can type it in or draw it graphically1) Signal names, I/O, steps2) Associated with each step is a timing set

Graphical editing of patterns and timing sets Showed code example in VB. Can code in a programming language and then view

the results in the SR development environment.Signal vs. Instrument interfaces

Eric proposes starting with the signal descriptions From the beginning we started from the instrument up


There is a place for both – they are complementary, not mutually exclusive Since we started from the instrument up strategy, we should continue along that path

unless we make a conscious decision to change the focus Teresa’s argument is that approaching it from this high a level (signals) will exclude

the simple digital I/O boards Attacking both at the same time might be too much to handle at once. It was decided

earlier to draw a line in the sand so that the first version of the IVI class specification has some capabilities, and can be reached in a reasonable amount of time.

Do you want to thing about the signals that they want to create, or the instrument that they will use to create them?

There are 3 alternatives:1) Create an instrument interface and build a signal interface on top of it2) Create an instrument interface and stop there3) Create a signal interface

From the instrument vendor’s perspective, if we did alternative 3, we would have to code all the functions – greater investment. Whereas alternatives 1 and 2 allow vendors simply to include or exclude extension groups (only implement the functionality available in their instrument).

Which alternative should we proceed with? Consensus was to continue moving forward using the instrument interface approach.

Where do we draw the line in the sand?o Revision 1.0 of the class specification includes:

Base Class Static extension group Dynamic extension group

o When do we add Voltage Levels (3 levels of functionality)

1) Pre-defined2) Select from pre-defined list3) Programmable

Timing Sophisticated pattern control

Agreed to the following content for first 3 version of class specification:o Version 1.0: Base class, Dynamic and Static extension groupso Version 2.0: Voltage and Timing extension groupso Version 3.0: Pattern control extension group

10.9 Item #5: Review rev 0.1 of the IviDigital class specification

General Discussion Issue: Should we include attribute names in the value names?

o Consensus: We will try to include the attribute names in the value names, but when we come across a value that is used across multiple attributes, we will determine on a case-by-case basis. We will also abbreviate the attribute name in the value name when it is appropriate.


Use “Get” instead of “Query” when reading back an attribute value

4.2.1 IVIDIGITAL_ATTR_EXECUTION_MODEDescription: Specifies how the instrument executes patternsValue descriptions:

Static: when in static mode, the digital instrument executes patterns at a rate defined by the CPU

Dynamic: when in dynamic mode, the digital instrument executes patterns from instrument or CPU memory at a rate defined by the instruments timing controller.

Discussion: Keep EXECUTE in the value names

o e.g. IVIDIGITAL_VAL_EXECUTE_STATIC Will users understand meaning of “CPU” used in static value description?

Suggestions:o Host systemo Host computero Instrument controllero At an unspecified rate

“At an unspecified rate” was chosen. Consensus is to keep attribute definitions small, and give more extensive definitions

of things like static and dynamic in the class or extension group description sections. In the static/dynamic example, the value description for static would read: “…executes patterns at an unspecified rate” instead of “…executes patterns at an unspecified rate that is dictated by a number of factors including the speed of the instrument controller, the cable, etc…”

4.2.2 IVIDIGITAL_ATTR_OPCODE Agreed to continue using the abbreviations for the opcodes (IH, IL, etc) Naming of the attribute: Change OPCODE to something that is more widely

understood. Suggestions:o Actiono Stateo Instruction

Action Item: Plow through documentation to see if Opcode is used anywhere else. Find a name (probably Opcode) that is not used anywhere and keep it unique to digital

Since we are not setting the state of the channel, maybe this doesn’t belong as an attribute in the first place.

o Consensus: Since you can read back what you set, it is in fact an attribute. Concern: Names in general should be self-documenting. There is some worry about

Opcode and IL, IH, etc.

4.3 IviDigitalBase FunctionChange “Query” to “Get”


4.3.3 IviDigital_ConfigureGroupOpcode This function limits the size of the group and the value to 32 bits. Name of “opcode” parameter is ambiguous with previous definition of opcode.

Rename “opcode” to “groupOpcode” and “value” to “groupValue”

4.3.4 IviDigital_ConfigureGroupOpcodeEx This function supports arbitrarily large groups. The value is specified using an array

of 32 bit values. Do you need to send the array size for the value array?

o Argument for not specifying the array size: You implicitly know the size of the array because you know the size of the group. Including the size of the array would be redundant.

o Argument for specifying the array size: It would be in keeping with typical style of how arrays are used in other IVI drivers.

o Consensus: YES, we should include a “valueSize” parameter. What should the function be called?

o “Ex” is ugly. Some suggestions: HighGroupOpcode LargeGroupOpcode BigGroupOpcode WideGroupOpcode

o People seemed to like “Big” and “Large”

4.3.5 IviDigital_QueryChannelOpcode Change function name from “IviDigital_QueryChannelOpcode” to

“IviDigital_GetChannelOpcode”

4.3.6 IviDigital_QueryGroupOpcode Rename to “IviDigital_GetGroupOpcode” Add parameters: “valueSize” and “valueActualSize”

5 IviDigitalStatic Extension Group Add timeout status to IviDigital_runStaticPattern

6.2 IviDigitalDynamic Attributes User can only set the PERIOD, not FREQUENCY. If a function needs the

frequency, then the driver will make the calculation. If the user has the frequency value, then the user must perform the calculation.

Add an attribute for specifying the response delay, the amount of time into the period where the response from the UUT is captured.

6.3.3 IviDigital_BeginPatternSetLoading Add new functions to be consistent with model

o IviDigital_CreatePatternSeto IviDigital_BeginPatternSetLoading


o IviDigital_EndPatternSetLoadingo IviDigital_ExecutePatternSeto IviDigital_ClearPatternSet

Compare this set of functions with how the IVI Arb and FGen class handle waveform generation. Action for Teresa

Should a PatternSet be called a DigitalSequence?o There was a terminology discussion at the last meeting where it was decided

that an ordered collection of digital patterns would be called a pattern set.

6.3.6 IviDigital_ExecutePatternSet Add a max time parameter to the execute function

6.3.8 IviDigital_FetchPatternSetResult Change result values “NOT_RUN” to “NOT_EXECUTED” and “RUNNING” to

“EXECUTING” Add an IviDigital_WaitForPatternSet function. Action for Teresa Look at scope acquisition status. Action for Teresa

General Action Items Add the following functions:

o Fetch functions for results collection: getting rows and elements of tableso Functions for sampling data in dynamic mode – strobes, windows, etc. Be

consistent with static mode delay function

What’s Next Need to clean up current specification of base class and static and dynamic extension

groups. Action for T by the end of June. Conference call end of July-ish to discuss work on specification.


11. IVI-3.1: Architecture

11.1 General Meeting Info:Date of Meeting: May 23rd, 2000Location: Claysburg, PAChairperson: Scott RustMinutes Prepared By:

11.2 Records of Discussion:Agenda

Repeated Capabilities Review spec outline Error code proposal Architectural Issues Review

Discussion of Srdan’s Repeated Capabilities Proposal

John Harvey – wants time to think about the C”OM issues. Wants to deal with the overall channels issues such has what to do when a class spec defines channels and an instrument is single channel. Is there a way to not make the user have to understand channdels

Joe Mueller –

Alternatives1. Use a single parameter to represent the entire repeated capability hierarchy. It could

be a string-based approach such as Srdan’s proposal or other. Daniel E. has proposed a channel structure approach that allows you to operate on multiple channels in one call.

2. Use the IVI session. That is get another session that represents the repeated object.3. Collections.4. Set active repeated capability.

Pros and Cons of the Alternatives

Single ParameterPros

Cons What is the user implication of having users navigate multiple layers?

SessionsPros


Similar to COM collections Get a handle that represents the group/object that is modified by the string that

represents the particular member of the group. Gets rid of channel string parameter

SetArttr( vi, “intrsrc1:markr1”,….)GetSubsession(vi, “intrsrc1:markr1”, &vi2)SetAttr (vi2, …)

Cons Multiple layers of retrieving sessions to navigate a multi-layer hierarchy can be

cumbersome. Multiple layers are required in C if you want to check for errors.

CollectionsPros

Natural way of grouping things that you have X of. Can express the name of group of things in the program as well as the name of

the particular thing in the group

Cons - We have tended to avoid Collections because: Performance issues with DCOM Mapping to C The attribute hierarchy needs to match the repeated capability hierarchy. This

becomes uglier when you have attributes from different locations in the hierarchy in one method.

How to write interchangeable programs between instruments have do and do not repeat their capabilities?

Issues to be discussed Discovery of the repeated things and the id’s of the things. That is, how do we expand

the proposed GetChannelName function?

The group wants to give this feedback back to Srdan and then have Srdan schedule conference calls between now and the next meeting to get the issue resolved.


12. Compliance

12.1 General Meeting Info:Date of Meeting: May 23, 2000Location: Claysburg, PAChairperson: Joe MuellerMinutes Prepared By:

12.2 Record of Discussions

We want a designation that distinguishes IVI-C and IVI-COM and a separate designation for the class-compliance, if any.

Discussion: Is there such a thing as an IVI driver without a class – what does interchangeability mean

for a driver like that? Also, there may be “levels” of interchangeability with signal interfaces or MSS

components. What about using the “Custom” to distinguish drivers that don’t conform to a class? What about conformance to other specs – event server, etc… Should we do some promotions work to set expectations appropriately? Describe the

pieces and the respective value of each piece.

Action Items: Discuss a meeting schedule for solving architecture issues at the general membership.

[Scott] Assign someone to write-up the compliance portion of the discussion and include it in

IVI 3.1. [Joe] Forward trademark issues to legal and promotions group. [Joe]


13. Guidelines for API Style

13.1 General Meeting Info:Date of Meeting: May 23, 2000Location: Claysburg, PAChairperson: Steve GreerMinutes Prepared By:

13.2 Meeting AttendeesSteve GreerJohannes GanzertJohn HarveyJoe MuellerDave PtacekFred BodeMagnus JanssonDaniel EricssenKirk FertittaScott RustJon Bellin

13.3 Record of DiscussionsSteve review changes to the Style Guidelines made after the Austin meeting.Steve reviewed progress on action items:

Steve did remind WG chairs to review their specs. Steve still does not know how to get stuff onto the web. John & Srdan did not get enumeration style work done. Noel didn’t do “front-end” research. On the discussion list from the Feb meeting, 1 is not done, 6 was done but needs to be

revisited, 9 is half done – automatic parameter setting section is not done, 10 is not done, 12 is not done, but is on the agenda, 13 needs to be revisited, 14 is not done.

Steve then started the review of the document

Class Naming. We asked Fred Bode to be on the watch for someone wanting to reserve “Iv” for VPP 9. We considered reserving “Iv” for IVI, but decided to hold off pending figuring out what it would be used for.

Outstanding question – Should we include IDL snippets in this guide?


Outstanding Issue – Should we try to keep naming and capitalization consistent between COM and C enumerated values? Between C enumerated values and defined constants? Between COM enumerated values and corresponding C defined constants?

Outstanding Issue – Should we specify defined constants for enumerations in C.

Hierarchy Discussion – It was generally agreed that the C and COM hierarchies should be allowed to diverge, according the needs/expectations of each environment.

Controlling Automatic Instrument Setup – Generally agreed that we don’t need this section.

13.4 DecisionsSee edited document. Steve created a redlined version of the Style Guidelines that show changes made during the meeting.

We will move the discussion of hierarchy (LowLevel or not) to the Style working group.

We all agree that we should not apply retroactive use of shall, should, and may until the standards are revisited.

13.5 Action Items Steve will fix references to VPP documents (incl. 3.5.1 & 3.5.2). John will take responsibility for getting the three hierarchies that Agilent currently has.

Johannes Ganzert will do a SigGen hierarchy. These should be done in time to review prior to the telephone conference that Steve will organize to discuss the issue. We expect to have this conference in about a month.

Scott will add standards related to fuzzy comparisons of reals and Infinity and non a number to IVI 3.1.

Jon Bellin will write up a straw-man for “4.2.2 Specifying Real Parameter Validation and Coercion” and send it out for review. Jon will do that by a week after Jon gets the text from Steve.

Steve – let people know that the issue of locating attributes in the hierarchy has been moved to the Style Guidelines group.

Zulfiqar (NI) – Will investigate NaN vs. ±(infinity) Boolean parameter naming – need to see if we have any naming guidelines.


14. Spectrum Analyzer

14.1 General Meeting Info:Date of Meeting: May 23, 1999Location: Claysburg, PAChairperson: Neil ShahMinutes Prepared By: Neil Shah (from the notes taken by Glenn Burnside)

14.2 Meeting Attendees:

Name Email Address Company

Neil Shah (Chair) [email protected] Lucent

Chris Bartz [email protected] NI

Jochen Wolle [email protected] R & S

Anne Faveur [email protected] Advantest

Lynn Wheelwright [email protected]

Agilent

Yohei Hirakoso [email protected]

Advantest

Glenn Burnside [email protected] NI

Bob Stern [email protected] Agilent

Dean Lawler [email protected] Hamilton Software

Michal Krumbholz [email protected]

Agilent Technologies

14.3 Topics To Be Discussed:1. Approve February 2000 Meeting Minutes2. Version 1.0 of the Specification3. Review Base Capability Group4. Review Marker Extension Group5. Discuss Multi-Trace Extension Group6. Miscellaneous Issues















14.4 Record of Discussions:

14.4.1 Approve February 2000 Meeting Minutes Neil modified the date of the minutes to be the correct year. Anne pointed out that not ALL instruments have a read-only race size. Anne pointed out that there was a dependency between the reference level and the

units/div. Minutes were approved.

14.4.2 Version 1.0 of the Specification Neil outlined the roadmap for today’s meeting and in completing the specification. Identified that the Multi-Trace extension may not be a requirement for 1.0 release. Identified that the Delta marker extension may not be a requirement for 1.0 release.

14.4.3 Review Base Capability Group SPCAN10: Update Figure 1-1 (Open, 1.3)

o Neil still needs to update the figure in section 1.3 Some changes are contingent on decisions in the multitrace

capabilities. Feedback on Sections 1 through 3

o Agreed to change the name of the specification to IviSpecAn. (NEIL) Discussed the semantics and intent of the Units per Division attribute.

(Exhaustively!)o Agreed to move the Units/Div attribute to the display category and

potentially add a number of divisions queryable attribute to the display extension.

Review Compliance Notes for all attributes (4.2)o Glenn explained how and in what form compliance note sections are

needed.o Identified that most attributes did not need a special compliance note, or a

defined value section. Lynn discussed trace capabilities:

o Lynn proposed that the base specification consider required a minimum of 2 traces.

Glenn proposed tweaking the names for specifying “non-acquisition” types of traces.

SPCAN27: External Trigger Extension Group (4.2.20)o Jochen explained the capabilities of external triggering.o Agreed to move the trigger attribute to a new TRIGGER extensions group.

There would be extension groups under this group like ExternalTrigger and VideoTrigger. ConfigureTriggerSource and ConfigureVideoTriggerLevel would be moved to the appropriate extension groups.

o Anne asked what the units of Video level would be.


For the programmatic user, the level should be in units as reference level.

For some instruments, the driver could convert that value to appropriate units for the instrument.

SPCAN28: Move Discussion of Sweep Coupling to Overview section (Open, 4.3.4)

o Neil still needs to do this. SPCAN29: Warning Codes for UNCAL State (4.3.12-4.3.14)

o Glenn still needs to do this.o Bob proposed that the name UNCAL is an inappropriate name, and that

another name(s) should be proposed.o Jochen proposed that the return points for these codes should be in

Initiate and Read. SPCAN30: Reword Abort Issues (4.3.15)

o Still Open SPCAN16: Verbiage for properly using existing functions and avoiding synch

issueso Still Open

14.4.4 Review Marker Extension Group SPCAN34/35: Single vs. Multiple

o Active Marker Approacho This has been approved and resolved.

SPCAN31/32/33: Behavior of Markerso Glenn and Lynn still need to fill in the overview section.

Delta Marker:o The group agreed that the user’s group needs to be polled to determine

the need for the delta marker functionality. All of the issues related to delta marker will be resolved based on the feedback from the User’s Working group.

Add attribute MarkerThresholdOn/Off? (Anne)o This may be an instrument specific feature or an extension group in the

future. SPCAN17: Extend marker search domain to more than just threshold.

o A extension group could address this in the future. SPCAN24: Reword description to handle both types of signal track

implementation (5.5.7)o Lynn still needs to complete this.

14.4.5 Discuss Multi-Trace Extension Group Lynn’s proposal for adding two additional trace types and a trace parameter for the Read

and Fetch functions was generally approved. Lynn identified things you would do on a trace:

o Trace matho Reference Traces


o Data reduction Agreed that in the present multitrace group, the trace label is no longer needed. Glenn asked if there was a difference between the length of a trace and the length of a

directly acquired trace. Identified that the primary focus of this extension would be inter-trace math. We need to

discover from the users whether these operations are important to their programmatic use.

Proposed that inter-trace operations (add, subtract, multiply, divide) would be most useful.

14.4.6 Miscellaneous Issues SPCAN20: Update Spec per new IVI Template

o Continuing work SPCAN23: Identify SPCAN Specific Failure Codes

o Assigned to Glenn Burnside, NI. SPCAN07: Review Entire Specification

o Lynn had some feedback here: Fetch functions should not have timeouts. Had a question about the behavior of the Acquisition Status

function (resolved) SPCAN21: Other Prototype Drivers

o NI will be developing some prototype drivers this summer. Feedback on Sections 11 through 17

o Agreed that some work will need to be done in the future after the spec has stabilized some.

14.5 Action Items:The following table summarizes all of the NEW action items.

Issue # Title Owner

SPCAN39 Change the prefix from IviSpcAn to IviSpecAn in the entire specification.

Neil Shah, Lucent

SPCAN40 Revise attribute and functions throughout the specification to avoid using abbreviations.

Neil Shah, Lucent

SPCAN41 Re-organize the base group to separate the external trigger, trigger source, and video trigger into appropriate extension groups

Neil Shah, Lucent and Glenn Burnside, NI

SPCAN42 Identify warning codes for UNCAL conditions that are more explicit as to the cause of the warning.

Jochen Wolle, R&S; Lynn Wheelwright, Agilent; Anne Faveur, Advantest

SPCAN43 Remove Warning codes from Fetch Neil Shah, Lucent


Functions.SPCAN44 Form the marker extension group to

a more final and formal state.Neil Shah, Lucent and Glenn Burnside, NI


15. Signal Interface Working Group

15.1 General Meeting Info:Date of Meeting: May 23, 2000Location: Claysburg, PAChairperson: Narayanan RamachandranMinutes Prepared By: Narayanan Ramachandran

15.2 Meeting AttendeesThe following people attended the session:

Bob Stern Agilent [email protected] Krombholz Agilent [email protected]

mRoger Oblad Agilent [email protected] Salopek BAE Systems [email protected] Richardson BAE Systems [email protected] Timcho BAE Systems [email protected]

mMark Stamper Boeing [email protected] Prescott M.O.D. UK john.Prescott@a-t-

e.demon.co.ukGayle Matysek Northrop Grumman [email protected] Zimmermann SA-ALC/LDAE Kelly

[email protected]

Toni Bunsen SEKAS [email protected] Sacher Serendipity Systems [email protected] Hutchinson Teradyne [email protected]

omCraig Staub Teradyne [email protected] Lopes Teradyne [email protected] Neag TYX Corp. [email protected] Ramachandran TYX Corp. [email protected] Hanbali TYX Corp. [email protected] Shikapuri TYX Corp. [email protected]

15.3 Presentations:These presentations are available on the web site, and are not included here. The web site address is:

http://www.ivifoundation.org/groups/Signal-Interfaces/signal_interfaces.htm


http://216.33.148.250:80/cgi-bin/linkrd?_lang=&lah=dec97e121292874399e80cce60d0803e&lat=961793612&hm___action=http%3A%2F%2Fwww.ivifoundation.org%2Fgroups%2FSignal-Interfaces%2Fsignal_interfaces.htm






mailto:Bunsen@SEKAS











The Role of the IVI Signal Interface Standard in Supporting Instrument Interchangeability - review

Requirements for the IVI Signal Interface Standard – preliminary set of requirements Terminology for the IVI Signal Interface Standard – preliminary proposal Design Issues for the IVI Signal Interface Standard - overview A2K Status update demonstration of a Java signal-based ATS with Signal Components

15.4 Comments/Questions:Q: Does a Signal Component have to be an IVI-MSS Role Component?A: yes; moreover, signal roles may be IVI-MSS roles

Q: Is the signal interface standard tied to ATLAS? A: A distinction made between interface and implementation

Q: Resource allocation an implementation issue and should be left outside the standardization scope? A:

resource allocation itself it not an implementation issue; the functionality is essential for the signal-based paradigm, being required in all signal-based ATSs;

resource allocation may either be static or dynamic; this is an implementation issue ATLAS-based ATSs are not the only possible implementation featuring resource

allocation; a Java signal-based ATS will be demonstrated current proposal: Signal Components should support resource allocation, but not require

it to be present on the ATS

Q: Why is the Signal Interface placed on top of IVI-MSS Role Components? Why not directly over IVI Drivers?A:

to provide instrument interchangeability, the signal interface must define an instrument-independent interface and an architecture where this interface is implemented by instrument-specific components; these components are required to compensates for differences in instrument behavior

the Role Component may be also a Measurement Server, which aggregates Role Components for multiple instruments; such a solution is also supported by the Config Store

Q: Does a SC have to use an IVI Driver? A: No; it may use any instrument control approach, such as IVI Drivers, VXI plug&play drivers, SCPI, etc.

Q: Will we have to create a specification for each Role Component? A: Probably not; there may be one specification that defines multiple interfaces; the interface contents is specific to each signal role

Q: Who will be interested in writing Signal Components?


A: Several members expressed such interest. They actually develop such components, but the interfaces are proprietary. Standardizing the interface would allow them to sell such components to more customers.

Q: Is the Signal Interface an implementation of MSS? A: It is an addition to MSS, providing semantic contents. It is one of the possible standardized semantics.

Q: Why would the driver care about control/capability information? A: Capability information belongs with the driver, because it allows it to operate the driver in signal-based test environment; this is where it provides the extended interchangeability we are targeting

Q: How would you validate Signal ComponentsA:

specialized test programs are needed such programs may be requested by customers along with the Signal Components;

verification concerns (1) proper operation of functions that implement signal operations and (2) the actual fulfillment of the capabilities described in the device information

the validation of TPSs using Signal components is much simpler compared to instrument-based TPSs, because: they are more concise; no instrument-specific knowledge is required

C: The IVI approach for the switch model provides connectivity information in a restrictive manner (when a path is requested, the driver answers if it is able to provide it or not); this may be done better

Q: Are we suggesting standardizing the format of device information? How much information do you want to standardize?A: Yes, if “format” means the XML tags for device, function, capability; etc; we should not standardize specific signal names, parameter names, etc.

Q: XML is an implementation issue and should not be specified in the standard; for instance, some implementation may want to use a databaseA:

The approach consistent with the COM interface definition would be to standardize a COM object model; two potential problems are foreseen: the model may be complicated and not tree-like (e.g. to support complex mapping of instrument subsystems to device functions); once defined, COM interfaces may not be changed, while the XML model may be enhanced independently;

We may attempt to develop an object model (after possible usage scenarios are defined) and decide then if this is feasible or not.

Using XML may simplify the integration of device information with the Config Store (if we decide to take this approach); an extension mechanism similar to the one requested by driver developers may be used; in the Config Store, XML was chosen as one of the possible implementation mechanisms; on the other hand, the XML technology is capable and easy to use

Specifying the XML DTD is rather an interface definition than an implementation definition


Q: regarding the approach shown in the demo: why do we need 4 files for ATE and ITA description? A:

They should not be 4; however, ITA information must be distinct; the use of 4 separate files is an implementation-specific approach; it is also consistent with TEDL models.

What we need to standardize is how the device information is provided by the Signal Component vendor; each ATS is free to use and convert it in any format it wants

15.5 Recommendations: examine IEEE-1226 and ARI work, to see what was already done change last bullet (business model) in Requirements presentation to: “define an

environment that allows reusability” put the Signal Interface terminology in a broader context; include it in the IVI glossary

(maybe in a separate section); check compatibility with other Foundation terminology

15.6 Action Items: put presentations on web site WG members will examine terminology proposal and provide feedback WG members will submit requirements in 1 month; they will be included in functional

specification start a draft document; include design issues that can be easily derived form the signal-

based paradigm; put placeholders for issues to be resolved later such as digital testing, bus testing, timing and synchronization

provide definitions for Signal Component, Signal Interface, Device Information; other signal-specific terms if required

examine IEEE-1226 and ARI work Eric Sacher will put together a paper on digital signals for the Digital WG

15.7 Decisions: terminology:

o use “Signal Component” in development specso define other terms later, as required; since signal roles (sensor, source) may be

also roles in the sense of IVI-MSS, we may have a Signal Source Component or Signal Source Role Component, etc.

o use “Device Information” term if definition is provided

15.8 Open issues: use XML or an object model for device information integrate device information in the Config Store transmission of signal information (ex. parameter names) in a generic (signal-type

independent) format basic approach for signal timing and synchronization


transmission of resource information identification (resource descriptor, channel/subsystem); examine what the Config Store is able to handle


16. COM Working Group

16.1 General Meeting Info:Date of Meeting: May 24, 2000Location: Claysburg, PAChairperson: John HarveyMinutes Prepared By:

16.2 Agenda Where do COM Specs Live? Review COM Technology Reference Changes Error Handling What’s Next? IDL

16.2.1 Where do COM Specs Live? Lots of questions about where the COM technology reference material should live.

o A lot of what is the COM technology reference that is specification material belongs in the 3.1 document

o Repeated capabilities (collections and channels) material also goes in 3.1o Some stuff also goes in the 3.4 specification.

Collections Hierarchy Issues

There may be information that goes into other specifications, but a majority of the information goes into 3.1 and 3.4

Will continue to maintain the COM Technology Reference. Useful to have a one-stop shopping for IVI-COM technology

John has taken the action item to work with Scott and Steve to get this information integrated into the 3.1 and 3.4 specifications

16.2.2 Review COM Technology Reference Changes

16.2.2.1 Versioning COM Interfaces All IDL should be versioned according to the rules. Published when the specification is approved by the foundation Any changes require a new interface May inherit the new interface if not changes to methods or properties IVI components may support multiple versions of an interface

o Must have a new class IDo May cause other interfaces to be changed if they include interface pointers to the

modified interface


o Append number to interface name identify new interface (add 2 for the 2nd revision of the interface, 3 for the 3rd, etc.)

Enumerations should also be versioned when new values are addedo Can compromise this at the expense of having inaccurate values be displayed and

returning an error status if one of these values is used. IVI-COM drivers can implement multiple versions of the same interface so that old

clients do not need to be modified. What are the implications of adding the number to create a new interface? Old clients

continue to use the interface name without the number. New clients would use the interface name with the number if they wanted to take advantage of the new interface.

If you have multiple versions of the same functions that differ only in the enumeration type for one of the parameters does C++ have a problem with that? Need to be looked at.

16.2.2.2 Required Interfaces for Class Drivers Extracted one interface for all components (useful for identifying a component as an IVI

component): IIviComponentId. Provides information that identifies the component. Contains 3 items

o Vendoro Versiono Description

Information is not specific to any type of interface. Have the names been voted on? Names have not been validated or evaluated against the

style guidelines. Need to change IviSetupBase to IviDriverOperationBase IIviInstrBase (init, close, property called initialized that indicates whether or not you

have run a successful init) IIviIdBase (variety of information used to identify the driver) IIviSetupBase (methods and properties having to do with the operation of the driver, not

the instrument) IIviUtilityBase (utility functions, things like reset, self-test, error-query, basic to most if

not all drivers) These interfaces are defined in the inherent capabilities document. IDL will be in the 3.2

specification.

16.2.2.3 Required Interfaces for Custom Drivers A custom driver is a driver for which no class exists. IIviInstr – root interface for custom interface hierarchy Needs to include reference pointers to IIviIdBase, IIviDriverOperationBase,

IIviUtilityBase IIviInstr inherits from IIviInstrBase

o Init, Close, etc. are the same as for class compliant drivers What is the difference between IIviInstrBase and IIviInstr? IIviInstrBase is the interface

that other drivers inherit. Class compliant drivers do not implement IIviInstr


16.2.2.4 Class Compliant Interfaces Implement IIvi<class name> Implement IIvi<class name><utility class name> Contains interface pointers to class specific utility classes or generic utility classes if the

class specific utility classes don’t exist Interface reference pointers to other class specific interfaces

16.2.2.5 WhiteBoardIIviInstrBase

InitCloseInitialized

IIviInstr::IIviInstrBaseUtility (IIviUtilityBase *)IdDriverOperation

IIviScope::IIviInstrBaseUtility (is IIviUtilityBase * or IIviScopeUtilityBase *)IdDriverOperationConfigureTriggerWaveform

New IIviInstrBaseInitCloseInitializedUtility – IIviUtilityBase *Id – IIviIdBase *DriverOperation – IIviDriverOperation *

If there are not class specific utility interfaces, then can move the utility interface pointers back to IIviInstrBase

Can always get to an IIviUtilityBase because the interface uses the default interface or implements their own interface that inherits from the base interface

We should just have one way to do it.o Empty inheritance: always have a IIvi<class name>Utilityo Don’t allow people to add stuff to these inherent interfaces – would always use

IIviUtilityo Have a separate interface for class specific utility functions

We should look at the current classes and see if we are adding to utility Need to make sure that we don’t do something that is too restrictive Delay the decision until we look the existing class drivers


John wants to go through the IviScope class and apply the macros and hierarchy. Since the IDL that defines this is defined by the foundation, it’s not a big deal. It becomes more confusing if we allow either. We don’t want to allow the class specifications to have a choice as to which utility

interface to inherit: either IIviUtilityBase or IIvi<class name>UtilityBase. If we did this then we can have one base class for class and non-class drivers.

If we restrict it to one thing, then the client always knows what interface to QI for. Simplifies the interface naming – can remove “Base” from all the names Problem: User wants to some of these operations on all of the drivers without knowing

what kind of driver it is. Action: Jon Belin volunteered to look at the C function hierarchies and see what class

specific methods and properties where added to these interfaces.

16.2.2.6 Driver Specific Interfaces Root interface is names I<prefix> Hierarchy should reflect the hierarchy of the class-compliant or non-class interfaces

(where there is overlap)o Syntactical leveragabilityo As much as possible, the interfaces should be kept the sameo Examples where you would deviate

Leave out channel if specific instrument is not channel based Leave out methods if they don’t apply

o “Just be really smart about what you do”o Inheritance or no inheritance is up to the driver writer

Vektrex: replicate all the class-compliant interfaces in the instrument specific interface so that you don’t need to bounce back and forth between the two interfaces.

Downside is that it does not isolate the interchangeable code from the non-interchangeable code.

Replicate all support class-compliant interfaces in the specific driver. Does not preclude the user from using only class-compliant interfaces.

16.2.2.7 Default Interfaces Default interface should be I<prefix> Not a problem for interchangeability because you only get 100% interchangeability when

you use the IVIFactory and that always returns IUnknown. User that doesn’t want interchangeability will get the specific interface right off the bat.

16.2.2.8 Driver Classes Introduce the term “standard” when talking about interfaces that all drivers custom or

class must support. Decide on term after the decision is made about the required interfaces.

16.2.2.9 Driver Type LibrariesType libraries are good. We should create them.There are issues about how to register the type libraries. Want to make sure that


David Gladfelter raised several issues with type libraries: Issue with multiple drivers installing type libraries – first one to uninstall, then you lose

the type library. Wrap TLB in a DLL so that you get version information Use “importlib” in the IDL in the library block

16.2.3 Packaging & Installation

16.2.3.1 Driver Packaging IVI-COM drivers shall be packaged in a DLL Can include multiple classes in a DLL

o Computational classo IDispatch wrapper classes for driver interfaces

Type libraries for these classes may be separated from the type libraries A driver talks to one thing. If you are using multiple instruments to implement a class –

then you are probably in the world of MSS. Unless, you talk to multiple things as one and there is one way to specify the I/O address.

A driver may include support for multiple IVI classes. Jon Belin: DLL should also include the C interface for the driver. The assumption is that the driver is a custom interface and you can QI for any of the

interfaces. You have one object that you can QI for everything.

16.2.3.2 Required Driver Files DLL – with class TLB – type library HLP or better (appropriate help file technology – hlp, html help)

o People don’t like the idea of using a PDF file for help Free to add custom marshalling – not required What about installation?

o Don’t want one installation program.o Need to look at MSIo Want to look complex operations (config store and registry) and package thato Do we assume that the DLL is self-registering? YES

16.2.3.3 Optional Driver Files Source files Other files – custom proxy/stubs, for example – as needed

16.2.3.4 Registry Entries Self-registering. Do all the COM entries. Create a category “IVI Instrument Driver” and

have all drivers register in the category. We should limit ourselves to the standard COM entries and a limited number of category

IDs, if any. Issue: What should we do for category IDs other than drivers? Issue: Do we want category IDs for classes?


Issue: If we have this information in the config store, do we need category IDs in the registry?

o People seem to like the idea of at least one category ID for IVI stuff

16.2.3.5 Configuration Store EntriesLets skip this until we know what the config store is going to do.

16.2.3.6 Issues Solution providers may want to re-distribute IVI drivers as part of their installations.

Should we make it easier than executing the installation executable directly?o MSI merge module is a way to do thiso Could do the Microsoft MDAC (sp?) and package the install as a separate

executable? – not a lot of resolution if something goes wrongo Could make the DLL responsible for doing all the registry and config store

entries so only the DLL would need to be included in the installation.o Installation issues is not COM specific

Installation needs to be dealt with in 3.1

16.2.4 COM Stuff

16.2.4.1 Target ADEs VC, VB, VBA, LabWindows/CVI (it is possible) ADEs that only support IDispatch (but may in the future support custom interfaces)

LabView, Agilent VEE, Mathworks MATLAB ADEs that require drivers to support wrappers – J++, JS, VBS

16.2.4.2 Threading IVI-COM drivers need to be thread-safe (global and member data needs to be thread

safe) Live in multi-threaded apartment Free or both: issue with worker threads

o Issues if you are using other COM components in your applicationo Do we want to require the free-thread marshaller? Don’t want to require it. Do

we want to prohibit it? Does it make sense to do MTA when it is not the preferred way in Win2K - TNA is the

Microsoft preferred way? Requires you to use Configured Components which are not easy to manage in non Win2K environments (COM+ is available for other environments).

16.2.4.3 Events Callback Interface – conceptually equivalent to connection points, similar to callbacks in

ANSI-C. Advantage is that it does not require automation.o Would the callback interface work in VBA?o Only work in process.


Event Messaging – Microsoft Message Queue is an alternative (requires SQL server in not Win2K environments). MSS Event Server is also a possibility. Useful for more than just instrument drivers.

o Works out-of-process.o Works in more ADEs

These can co-exist. Callback interface as a short them solution until the Event Server is available and migrate to Event Server as it becomes available.

Current class specifications are not defining callbacks.o No implementation.o No standard mechanism for doing it across languages.

Event server is the better long-term solution. If it were available today, there would probably be some event message being built into class drivers.

Roger and Agilent have volunteered to provide their implementation. If we put this stuff in the class drivers, we need to provide a way to implement/use the

class driver without events.o Provide both blocking and non-blocking mechanisms.o Support the event based interfaces as an extension group.o Event server should not be a requirement for using the class driver

Actions for the San Diego Group or Style (I think I heard both)o Event interfaces should be in an extension group – look at common use patterns

(Jon Bellin waffled on this one)o Section in Style Document that describes the patterns and recommended

approacheso Recommend that there be a non-event way to perform the same functionalityo Recommendation on how to deal with asynchronous errors

Not ready to pick one implementation Need to provide interfaces that use events and polling. Shouldn’t force users to have to

use learn events. Events imply that the driver has at least 2 threads.

16.2.5 What’s NextACTION: (John Harvey) Summary table of open action items and open technology items by (6/9/2000)ACTION: (All) Feedback on document to John Harvey

16.2.6 Error Handling

16.2.6.1 Description of Syntax used by IVI-C, VPP and VISA MSB – 0, success, positive warning, negative error Produce code – VISA and VPP All error codes start at some base All IVI-C drivers will have error codes that start at some base specific to the class

16.2.6.2 Description of COM Error Structure Similar syntax (COM allows other positive numbers to mean other types of success)


VB will not throw an error if it gets a positive number Don’t know if COM error structure updates if the status is negative

o Might be OK – just tell users that if they are using VB they are not going to get warnings

MSB – success/failure Facility Code – ITF facility code is for use by any non-Microsoft facility Error Code – errors returned by an interface must be unique

o If there are 5 interfaces in a driver, the errors just need to be unique to the interface (COM constraint)

o For IVI-COM, it makes sense to make the error codes unique across all the interfaces.

We will probably try and duplicate the existing error numbers. It is possible when using COM drivers that the driver will get errors that it knows

nothing about, for example when RPC is involved.

16.2.6.3 Possibilities VISA generated errors still 3FFA VPP generated errors still 3FFC IVI_BASE < IVI errors < IVI_CLASS_BASE IVI_CLASS_BASE < Class errors < IVI_SPECIFIC_BASE IVI_SPECIFIC_BASE < Driver errors < whatever Reserve upper 4 bits of the error number to distinguish amongst the different types of

errors. Reserve an additional 4 bits for identifying classes Class errors don’t overlap. Only get 256 error for each of 64 classes – could change the number of bits we’ve

allocated to identify the class so that you could allow for more classes with fewer errors in each

16.2.6.4 Other Possibilities Allow error numbers to overlap across common components One of the things that you could do was have the driver return a generic I/O error and

have the description contain the VISA/VPP error string (allows for I/O layers that return unpredictable error codes)

Would be difficult to keep them unique across other I/O layers Keeping them unique might get difficult if you get lots of common components.

o Coordination issue across all common componentso Coordination with proprietary components

Every component should have its own error space Drivers should map component errors to errors in its error space COM I/O gets its own space Combining IVI and VPP errors (inherent errors)

o Probably not a big danger in new VPP errors getting added Within the COM driver space, define spaces for inherent errors, class errors and specific

errors


Why do we need to keep errors unique across classes?o Allows for more growtho Make it easier to have centralized error handling when you are using multiple

classes If users are defining their own classes, they should use errors from the IVI_SPECIFIC

error space. Class identifier is reserved for IVI defined classes Why are errors structured differently in C and COM?

o Need to look at what the BASE is for CLASS and SPECIFIC in the IVI-C world GOAL: Need to investigate keeping the bottom 16 bits the same across IVI-C and IVI-

COM. Want at a minimum to be able to translate from one to type of error to the other. Feel that there is some flexibility in diverging from VPP errors.

16.2.6.5 What are the optional constraints Separate errors for different classes Can we abandon VPP errors Can we abandon I/O errors (map them to IVI errors) Can we keep the bottom 16 bits the same across IVI-C and IVI-COM


17. Power Meter

17.1 General Meeting Info:Date of Meeting: May 24-25, 2000Location: Claysburg, PAChairperson: Zulfiqar HaiderMinutes Prepared By: Zulfiqar Haider


Attendees

Glenn Burnside NI Zulfiqar Haider NI Neil Shah Lucent Peter Richardson BAE Systems Steve Greer Agilent

Minutes

1. The class prefix was changed to IviPwrMeter.2. Proposed a solution on how to specify the units. Added an INPUT_UNITS attribute to

specify the units in which measurements are taken at the input terminals.3. Defined a mechanism for the auto-ranging capability. Identified

RANGE_AUTO_ENABLED, RANGE_UPPER, and RANGE_LOWER as channel (input) based attributes. It would be specified in the same units as the current value of INPUT_UNITS.

4. Some instruments cannot return the range value when auto-ranging. RANGE_LOWER and RANGE_UPPER will return class defined error when queried while auto range is enabled.

5. Divided the attributes in the base capability group into the following extension groups:- TriggerSource- DutyCycleCorrection- Averaging

6. Identified for most of the attributes which were input channel-based vs. measurement based, need to ask users, e.g. Trigger source and resolution – will ask it to the users working group.

7. Went over Crest factor capability proposed by R&S at February meeting. It was agreed to not consider this for the current version of the spec.

8. IviPwrMeter_Reset function was removed.


9. Removed VAL_OFF and VAL_EXTERNAL as possible values for TRIGGER_SOURCE attributes.

10. The attributes and functions were divided in the following manner:

Attribute Name ChangesRANGE_AUTO_ENABLED

RANGE_UPPER May return error when queried in autorange mode.RANGE_LOWER

INPUT_UNITS DBM, WATT, DBUV, DBMVRESOLUTION Need to investigate if this is input or measurement based.EXPECTED_FREQUENCY Need to determine if this belongs in the base or the

calibration extension group.DUTY_CYCLE_CORRECTION_ENABLED

Go to DutyCycleCorrection Extension group.

EXPECTED_DUTY_CYCLE Go to DutyCycleCorrection Extension group.OFFSET Is this name descriptive enough? Is the correction logic

correct?

OFFSET_CORRECTION? OFFSET_COMPENSATION?

Does it need to be in an extension group?

No, it goes in the base group because it is always set.TRIGGER_SOURCE Action item: Does the measurement window trigger? Or

trigger a terminal? Move to TriggerSourceExtensionGroupAVERAGING_ENABLED Goes into AveragingExtensionGroup. Boolean, not channel

basedAVERAGING_MODE Goes into AveragingExtensionGroup. Enumerated, notAVERAGING_COUNT Goes into AveragingExtensionGroup.

MEASUREMENT_ENABLED

MEASUREMENT_FUNCTION

MEASUREMENT_PARAMETER_1

MEASUREMENT_PARAMETER_2

MEASUREMENT_UNITS

CALIBRATION_ENABLED

Function Name ChangesConfigureAcquisition Vi, units, resolution,


Function Name ChangesConfigureExpectedFrequency Vi, channel, freqConfigureRange Vi, channel, autorange, high, lowConfigureTriggerSource Vi, <channel> source, in trigger extension groupConfigureAveraging Vi, enabled, modeConfigureAveragingCount Vi, countConfigureDutyCycle Vi, channel, enabled, dutycycleConfigureOffset Vi, channel, offsetRead

Abort

Initiate

IsOperationComplete

Fetch

IsOverRange

Calibrate

Zero

Reset REMOVE


18. Legal Subgroup

18.1 General Meeting Info:Date of Meeting: May 24, 2000Location: Claysburg, PAChairperson: Kevin Borchert (elected during meeting)Minutes Prepared By: Craig Staub

18.2 Meeting Attendees:Name Company Email

Dany Cheij National Instruments [email protected] Rust National Instruments [email protected] Rauniyar Tektronix, INC. [email protected] Lawler Hamilton Software [email protected] Bode Bode Enterprises [email protected] Borchert Agilent [email protected] Staub Teradyne [email protected] Salopek BAE Systems [email protected] Sacher Serendipity Systems [email protected] Stern Agilent [email protected] Ramachandran TYX [email protected]

18.3 Agenda Select Lawyer Review minutes and scrub to give to lawyer

o Components and ownership Rules surrounding Compliance How do we express to the outside world what IVI is

o Press Release?o Media Alert on web-site?o Generate Slides to describe IVIo Generate PPT template

“Think Outside the Box”o How do we run the consortiumo Even out the costso Think about changes that comes with being a big organization

18.4 Review of Austin, Texas Meeting Discussed process of becoming incorporated Board of directors

o How many people










Need to get recommendations for lawyers to speak too Called three lawyers alreadyo Choose a lawyero What kind of documents should we supply to them

18.5 Choosing a Lawyer

18.5.1 Interview Three Firms

o Ken Johnson and Pat Ziarniko Dorsey and Whitney o Andy Updegrove

Questions:o What do you charge (fees)?o Who will perform the work?o Are there references that we can contact?o Size of the firm?o Do you have experience with consortiums?o What are our priorities (time line)?o Intellectual properties?o Do you have expertise with the mechanics of starting up a consortium?o Bank accountso Dueso Etc

18.5.2 Results of Interviewso Johnson – Rejected!

o Negatives Worked with many groups with blanket by laws, but not with an entity

that had special, or unique needs Other two firms had more experience working with organizations,

analyzing needs, and generating by-laws and charter Had a difficult time supplying references Had more experience working with consortium after the organization had

been formed Johnson is working with the TDC – how come they didn’t mention it in

the interview? Johnson expressed interest in working with consortiums after formations,

but couldn’t back up his “pitch” with references or solid answers to questions

Would use counsel outside the firm to do most of the worko Positives

Bob Stern saw Johnson speak and was impressedo Dorsey and Whitney


o Responses: Charges and Fees “I challenge you to find anyone who specializes in this type of law!”

o A large firm – 600+ Positives and negatives

o Negatives: Big Firm Fees

o Positives Experience

o Updegroveo Small Firm – 32 attorneys with speciality in high tech – a “High Tech Boutique” o Responses:

Fees:o Will not execute mechanics such as the signing of NDAs – they provide the tools

(note: this is true with Whitney too)o “Specializes” in consortium lawo Worked on VXI Consortiumo Worked with NI on PXI

After initial work was complete, there was little follow up needed Regarding intellectual property – more communication would be needed

18.5.3 Conclusions/Consensuso All three firms could probably perform the tasks needed by IVI, however, Dorsey &

Whitney and Updegrove outshine Johnsono Winner: Updegrove

More experienceo Scott, as Foundation Chair, will inform Andy of the resultso Kevin will supply the initial documents

18.6 General Commentso Config Store, Event Server, Session Generator, Driver Factory

o Shared components owned by the foundationo Licensed out to be used in Vendors drivers

o How do you get the components into the Foundation and distribute to vendorso Need to discuss and recommend a model from the Legal Workgroupo Critical for successful deployment of IVI Drivers

o Lawyer should generate NDA formso Have a coherent strategy and vision BEFORE meeting with Updegrove to minimize

redrafts of by-lawso This includes, but is not limited to,

What are the software tools What intellectual properties will be shared/not shared


18.7 What’s Next?o Hire Updegrove

o Set up a formal face to face meeting with Updegrove (for first meeting)o Lobby IVI Foundation to authorize up to $15K to get the consortium incorporatedo Identify 2-3 person contacts to communicate with Updegrove

o Information will be funneled through the contactso Contacts selected:

Kevin Borchert (Sub-Committee Chair for Legal) Dany Cheij Fred Bode

o Plan to present By-Laws at the next General Meeting (August 21st)o Work that will be completed before August

o Hold conference calls to ready for meetings with Andyo 1-2 immediate initial meetings with Andy to get him up to speedo Generate rough by-lawso Discuss and Scrub documentso Have semi-rough document with questions for distribution to general

membership ready three weeks prior to Q3 meeting (July 31)o

18.8 Review/Scrub Minutes & Generate Package to Give to Updegrove

18.8.1 Austin Meeting Minutes Summary Delaware will be jurisdiction of incorporation

o Many companies are located in Delaware -- familiarityo A favorable location for incorporation

Cost (Cali is very expensive) Membership

o Levels Officers

President and Secretary as a minimum Treasurer will be needed

o More money will be changing hands (dues, etc)o Provided lunch and snacks costs

How to seed the officer seats has not been defined Voting members

Vote on specs Elects the Board of Directors “One member, one vote” Simple majority for general voting Voting on special items will potentially use a different

percentage Will voting on specs be handled differently


o Today, specs go out for a two week review, and all voting members must participate

o Currently 54 members 38 voting members 20 associate member

o No intention to limit the membership Must be open to all qualified participants

Board of Directorso Number of directors has not been definedo Eligibility was not definedo Election of Officers has not been defined

By-lawso Statement of the Scope of Businesso Need to write into the by-laws what the dues will be for each class of

membership Need to take into account the cost of running the group

Intellectual Propertyo Rights

Protect the entity License at little or no cost to member companies

o What, if any, assignments of intellectual property rights will go to the consortium?

o Will the standard set by IVI include patentable, trademarkable, or copyrightable material?

Approving SW Componentso Source Code review committee evaluates potential software components

(including source) Should committee sign an NDA?

o Once approved by the source code review committee, the membership reviews and votes on the component

Feature reviewo Once approved by the entire membership, the SW component developer either

Assigns ownership to the IVI Foundation with a perpetual license bak to the member company, or

Licenses the component to the IVI Foundationo The world has access to thebinary versions

Need to have standard licenses, disclaimer, and copyrights.o IVI Foundation Members

Have access to source code Can compile for debugging on any OS Can compile for distribution on OS’s that the IVI Foundation does not

support Can not enhance the capabilities Must notify the IVI Foundation if they intend to re-distribute


18.8.2 Discussion of Austin Meeting Minutes One of the strengths of this organization is the presence of users

o Proposal is to make users a large percentage (40%) of the Board of the Directors Request for Treasurer officer

o Treasurer will be needed More money will be changing hands (dues, etc) Provided lunch and snacks costs

What will be the role of the Board of Directorso If the board is an advisory role – then there should be many userso If the board is more action item oriented, then there should be fewer users

Suggestion: Before we incorporate we should set up a checking accounto Will be needed to pay the lawyero Negative: Difficult to open an accounto Recommendation was made to open a non-interest bearing savings accounto Consensus: we will continue the way we have been operating to date – will

not open account We need to conscious about reviewing decisions with users (especially regarding

licensing and the like) What will be the process for Revision Control?

o This may be a potential support issueo Discuss with Pat Johnson (Racal)

Common support model

18.8.3 To Discuss with Andy Percentage of Users on the Board of Directors What will be the role of the Board of Directors What, if any, assignments of intellectual property rights will go to the consortium? Will the standard set by IVI include patentable, trademarkable, or copyrightable

material? We would like an understanding of compliance symbols and trademarks and the

ownership associated with them Present initial guidelines and request feedback

18.9 Compliance How do we use the IVI trademark How do we distinguish the different levels of compliance?

o Lawyer will be of little help Notion of NI owning the IVI trademark until the Foundation can own it in the future

o There is a legal document supporting NI’s commitment to hand over the trademarks to the IVI Foundation

Create a group to decide what it means to be complianto How do we grant the right to use the IVI mark

There should be two IVI marks


o One for certification (this mark should only appear on products that are IVI certified)

o One for promotional materialso Promotions sub-committee needs to generate markso Legal sub-committee needs to generate paperwork to legalize the marks


19. Promotions Subgroup

19.1 General Meeting Info:Date of Meeting: May 24, 2000Location: Claysburg, PAChairperson: Dany CheijMinutes Prepared By: Craig Staub

19.2 Meeting Attendees:Name Company Email

Dany Cheij National Instruments [email protected] Rust National Instruments [email protected] Rauniyar Tektronix, INC. [email protected] Lawler Hamilton Software [email protected] Bode Bode Enterprises [email protected] Borchert Agilent [email protected] Staub Teradyne [email protected] Salopek BAE Systems [email protected] Sacher Serendipity Systems [email protected] Stern Agilent [email protected] Ramachandran TYX [email protected]

19.3 Record of Discussions Web-site needs to market information about what IVI is delivering

o Time Frame – not “next week” urgent Media Alert Press Alert on the Web-site

o Need to generate list of interesting events – email list to general members Users Group Participation Level Dates for completion on a number of issues Certification Stuff

Review of Austin Meetingo Need more user participationo A first draft of charter was created since last meeting

Will discuss over email among promotions committee Will recruit members of promotional committee via email










20. IVI-3.1 SC3 Working Group

20.1 General Meeting Info:Date of Meeting: May 25, 2000Location: Claysburg, PAChairperson:Minutes Prepared By:

20.2 Record of DiscussionsWhat is the notation for designating a class prefix in a specification. The options are “<prefix>_” and “ClassPrefix_”.

What can be completed quickly for the first version of this document? (Scott, Glenn) The software triggering should be completed quickly since all of the

existing specs refer to it. The multi-point capabilities should be delayed to see what is needed for the power meter. Right now the only data point is the DMM spec with the power meter spec in process.

(John, Glenn) Could we allow the current work to live on either in an appendix or a version 1.1 draft? That way we wouldn’t lose the work that Steve has already done. We don’t want people totally re-inventing this each time just because it isn’t part of an approved spec.

(Steve) There is a lot of interest in common capabilities. People want guidance for things that look like SC3.

(Scott) Are there any other elements of a definition of software triggering that should be documented in addition to the software trigger function – for example, the behavior model, etc.

(Glenn) What about error messages? Steve brought up the DMM spec to see what was documented there. Glenn said that he assumed that most of the 13.x s/w trigger section would be part of SC3. Then the only thing we needed is the error.

What to do with IsOverRange? There is too much variation to pin it down to one function. We want functions where we know what to expect, but we do need them to meet the needs of the class. Does it belong in Style? Style seems too loose.

Action Items Steve will allow an additional two weeks to refine the formatting in the document. Steve will create a version 1 for voting with software trigger. He will create a draft

version 1.1 with software trigger and multi-point and some variation of IsOverRange. Steve will change software trigger section to reflect the following: The trigger source

attribute must accept <CLASS>_VAL_SOFTWARE_TRIG as a valid setting for this function to work. If the trigger source is not set to SOFTWARE_TRIG, this function does nothing and returns the error NOT_SOFTWARE_TRIG.


Steve will remove IsOverRange from the spec. We will consider whether to put it into Style.


21. IDL Working Group

21.1 General Meeting Info:Date of Meeting: May 25, 1999Location: Claysburg, PAChairperson:Minutes Prepared By:


21.2.1 ”IVI Language Mappings” document

Question: Do we need unsigned values?Answer: John has gone through the specifications. It looks like unsigned data types are not used.

Question: Do we have a need for long long (64 bit)?Answer: We don’t know.

21.3 Macro magic

We need some way of handling the class specific prefix. This could be done using search-and-replace or some other way.

The fact that the function specification must end with an open parenthesis forces the person specifying the macro to add a close parenthesis and a semi-colon at the end of the macro specification. This is a potential problem.

The output does not look pretty at all. You need to touch up the output to delete blank lines and to insert new-line characters to make the code readable. Touching up an automatically generated file means you have to it each time the file is re-generated.

There might be a free IDL parser available from OMG (http://www.omg.org). This is probably a CORBA specific IDL parser, but it might be possible to modify it to accept Com IDL.

Question (Gary): What is the purpose of this whole exercise?

Jon Bellin: There should be both an IDL and a C prototype in the class specification. It is not reasonable to expect everyone to learn IDL. The class spec should be easy to read.


http://www.omg.org/

Do we really need this. Wouldn’t it be counter-productive to force a third language upon the persons doing class specifications.

Jon Bellin: It is not up to this group to decide if it is needed or not. The group was formed by the foundation in January last year. This topic should be discussed at the next general membership meeting at the Fort Collins meeting in August 2000.

Johannes Ganzert: What about the time line of this solution. Do we want to wait until the next meeting to specify a possible third language? Is that too late?

Ion Naeg: If we will consider other languages in the future, then a common language will allow us to quickly create all the IDL/header for the new language without having to update all the specifications.

21.4 Pros and cons of a third independent language:

Proso A common language will enforce the rules of the IVI Foundation upon the

class specifications. Ensuring follow API guides.o Consistency between the (current) two languages. With one “golden”

source there will be full consistency between the two languages.o Easy to add an extra language.o Satisfy the General Membership Meeting in January 1999 to have a

language independent representation.o Reduce language bias in class spec.o Makes the revisioning process more fault-proof.o Useful tool for driver writers if they want to use it.o It really decouples the interface from the technology.

Conso A third language means more to learn.o Minimal payoff in productivity because it’s a small audience.o Very centered on C or COM. Might not work well for other languages.

Might require rework when adding an extra language. We might not see all the problems involved in adding a new language

o The target audience is small. The proposal has too many negative side effects.

o It doesn’t leverage IDL enough.o It’s more trouble than it worth. Most people care about COM, so designing

for the minority of the users (C users) is wasteful.o It’s not native to either the C or COM users.o IDL is ugly and hard to understand. The MACRO approach is easier to

understand.


21.5 Pros and cons of specific solutions as described in John’s powerpoint slides:

21.5.1 Limited IDL approach:Con:Still a lot of work to be done to get the C result out of it.Pro: It’s consistent with the GMM expectations.

21.5.2 Stick with IDL and parsing:Con: Makes adding new languages difficult.Pro: Prettier output and makes it possible to do more complex parsing.Con: It requires an actual tool that needs to be distributed.

John does not want to wait until the next meeting to have some kind of IDL to insert into the Inherent Attributes document.

The argument is between #2 and #5. (PERL or separate C and COM definitions)

John H. suggests that we do a COM IDL file that we append as an addendum/appendix to the (inherent capability) specifications.

Kirk suggests that we look at the specific cases where the bindings are not clear. Where we can’t use the IDL.

21.6 Action Items Action Item: Come up with inherent COM IDL that can be worked into inherent

capabilities so that it can be worked into the 3.2 specification. Action Item: Work on the existing COM IDL to get it ready for use. Action Item: Figure out what we want to do with this item for the next general

membership meeting.


meeting minutes - may 2000 - ivi foundation · web viewglenn asked if there was a difference...

Documents