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
IVI Foundation Meeting Minutes 2 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
Agilent 970-679-3387 [email protected]
Lynn Wheelwright
Agilent 707-579-1678 [email protected]
Michal Krombholz
Agilent 707-577-3188 [email protected]
Roger Oblad Agilent 707-577-3466 [email protected] Greer
Agilent 970-679-3474 [email protected]
Terukuni Okuyama
ASCOR 510-490-2300 [email protected]
Paul Salopek BAE Systems 614-759-5399 [email protected] Richardson
BAE Systems +44 131 314-233x
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
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]
IVI Foundation Meeting Minutes 3 May 22 – 25, 2000
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
Johannes Ganzert
Rohde & Schwarz +49 89 4129 3045
Toni Bunsen SEKAS +49-89-7481340
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]
IVI Foundation Meeting Minutes 4 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 5 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 6 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 7 May 22 – 25, 2000
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)
IVI Foundation Meeting Minutes 8 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 9 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 10 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 11 May 22 – 25, 2000
3.12 Adjourn
IVI Foundation Meeting Minutes 12 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 13 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 14 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 15 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 16 May 22 – 25, 2000
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:
IVI Foundation Meeting Minutes 17 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 18 May 22 – 25, 2000
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?
IVI Foundation Meeting Minutes 19 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 20 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 21 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 22 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 23 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 24 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 25 May 22 – 25, 2000
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.)
IVI Foundation Meeting Minutes 26 May 22 – 25, 2000
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:
IVI Foundation Meeting Minutes 27 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 28 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 29 May 22 – 25, 2000
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:
IVI Foundation Meeting Minutes 30 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 31 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 32 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 33 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 34 May 22 – 25, 2000
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”
IVI Foundation Meeting Minutes 35 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 36 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 37 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 38 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 39 May 22 – 25, 2000
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]
IVI Foundation Meeting Minutes 40 May 22 – 25, 2000
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?
IVI Foundation Meeting Minutes 41 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 42 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 43 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 44 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 45 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 46 May 22 – 25, 2000
Functions.SPCAN44 Form the marker extension group to
a more final and formal state.Neil Shah, Lucent and Glenn Burnside, NI
IVI Foundation Meeting Minutes 47 May 22 – 25, 2000
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
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
IVI Foundation Meeting Minutes 48 May 22 – 25, 2000
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?
IVI Foundation Meeting Minutes 49 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 50 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 51 May 22 – 25, 2000
transmission of resource information identification (resource descriptor, channel/subsystem); examine what the Config Store is able to handle
IVI Foundation Meeting Minutes 52 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 53 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 54 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 55 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 56 May 22 – 25, 2000
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?
IVI Foundation Meeting Minutes 57 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 58 May 22 – 25, 2000
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)
IVI Foundation Meeting Minutes 59 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 60 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 61 May 22 – 25, 2000
17. Power Meter
17.1 General Meeting Info:Date of Meeting: May 24-25, 2000Location: Claysburg, PAChairperson: Zulfiqar HaiderMinutes Prepared By: Zulfiqar Haider
17.2 Record of Discussions
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.
IVI Foundation Meeting Minutes 62 May 22 – 25, 2000
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,
IVI Foundation Meeting Minutes 63 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 64 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 65 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 66 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 67 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 68 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 69 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 70 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 71 May 22 – 25, 2000
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
IVI Foundation Meeting Minutes 72 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 73 May 22 – 25, 2000
Steve will remove IsOverRange from the spec. We will consider whether to put it into Style.
IVI Foundation Meeting Minutes 74 May 22 – 25, 2000
21. IDL Working Group
21.1 General Meeting Info:Date of Meeting: May 25, 1999Location: Claysburg, PAChairperson:Minutes Prepared By:
21.2 Record of Discussions
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.
IVI Foundation Meeting Minutes 75 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 76 May 22 – 25, 2000
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.
IVI Foundation Meeting Minutes 77 May 22 – 25, 2000