Meeting Minutes - Nov 2000 - IVI Foundationivifoundation.org/meetings/2000Nov/2000NovMeetingSummary.doc · Web viewUpdate the Word documents with hyperlinks based on the index produced

IVI FoundationMeeting Summaries

November 13th – 17th, 2000Dallas, Texas

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

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

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

4. WORKING GROUP SUMMARIES..........................................................................................................11

5. IVI C WORKING GROUP........................................................................................................................ 15

6. IVI-3.2: INHERENT CAPABILITIES WORKING GROUP...................................................................16

7. IVI CONFIG STORE WORKING GROUP.............................................................................................18

8. IVI COM WORKING GROUP................................................................................................................. 21

9. GUIDELINES FOR API STYLE WORKING GROUP...........................................................................24

10. IVI-3.1: ARCHITECTURE WORKING GROUP.................................................................................27

11. IVI MSS WORKING GROUP............................................................................................................... 34

12. RF SIGNAL GENERATOR WORKING GROUP...............................................................................37

13. SPECTRUM ANALYZER WORKING GROUP..................................................................................40

14. POWER METER WORKING GROUP................................................................................................44

15. COMPLIANCE WORKING GROUP...................................................................................................50

16. SIGNAL INTERFACE WORKING GROUP........................................................................................54

17. LEGAL WORKING GROUP................................................................................................................ 58

18. PROMOTIONS WORKING GROUP...................................................................................................61

19. USERS WORKING GROUP................................................................................................................. 63

20. VXIPNP SYSTEMS ALLIANCE VISA WORKING GROUP..............................................................66

21. Digital Working Group............................................................................................................................. 73

IVI Foundation Meeting Minutes 1 Nov 13 – 17, 2000

2. Meeting Attendees

Name Company Phone EmailAnne Faveur Advantest +33-1-60114454 [email protected] Hirakoso Advantest 503-627-2671 [email protected] Stern Agilent 707-577-2886 [email protected] Gladfelter Agilent 970-679-5329 [email protected] Mueller Agilent 970-679-3248 [email protected] Harvey Agilent 970-679-3535 [email protected] Borchert Agilent 970-679-3387 [email protected] Wheelwright Agilent 707-577-2568 [email protected] Krombholz Agilent 707-577-3188 [email protected] Oblad Agilent 707-577-3466 [email protected] Greer Agilent 970-679-3474 [email protected] Schink Agilent 970-679-2196 [email protected] Bigelow Anritsu 408-778-2000 [email protected] Petty BCO, Inc. 978-663-2156 [email protected] Yetsko BCO, Inc. 978-663-7350 [email protected] Bode Bode Enterprises 619-297-1024 [email protected] Davis Boeing 314-234-2722 [email protected] Wegener Boeing 314-234-3801 [email protected] Prescott Defense Logistics Org

(UK)+44-1244-288331 x7694

[email protected]

John Ryland Keithley Instruments 440-498-3134 [email protected] Franklin Keithley Instruments 440-542-8097 [email protected] Shah Keithley Instruments 440-498-2934 [email protected] Mondrik National Instruments 512-683-8849 [email protected] Cheij National Instruments 512-683-5286 [email protected] Fuller National Instruments 512-683-5399 [email protected] Cox National Instruments 512-683-0893 [email protected] Bellin National Instruments 512-683-5516 [email protected] Winkeler National Instruments 512-683-5779 [email protected] Adorno National Instruments 512-683-5071 [email protected] Wolfe National Instruments 512-683-5466 [email protected] Kovner National Instruments 512-683-8567 [email protected] Rust National Instruments 512-683-5680 [email protected] Zirojevic National Instruments 512-683-5374 [email protected] Haider National Instruments 512-683-8374 [email protected] Matysek Northrop Grumman ESSD 410-765-9754 [email protected].

comDave McKay Racal Instruments +44-1202-872800 [email protected] Rosenwald Racal Instruments 210-699-6799 [email protected] Johnson Racal Instruments 210-699-6799 x204 [email protected] Diestelhorst Rohde & Schwarz +49 89 4129 13331 arnd.diestelhorst@rohde-

schwarz.comJochen Wolle Rohde & Schwarz +49 89 4129 13044 [email protected] Ganzert Rohde & Schwarz +49 89 4129 13405 [email protected] Pryor Sandia National Labs 505-845-3557 [email protected]


Name Company Phone EmailMike Lindstedt Software AG 925-242-3724 [email protected] Malynur Tektronix, Inc. 503-627-5880 [email protected] Rule Tektronix, Inc. 503-627-4338 [email protected] Lopes Teradyne 978-370-1377 [email protected] Pike The Mathworks, Inc. 508-647-7493 [email protected] Geathers TYX 703-264-1080 [email protected] Neag TYX 703-264-1080 [email protected] Zimmermann USAF 210-925-4401 x3092 [email protected] Eriksson Vektrex 858-458-5822 [email protected] Hulett Vektrex 858-578-6787 x11 [email protected]


3. General Membership MeetingDate of Meeting: November 15th, 2000Location: Dallas, TexasChairperson: Scott RustMinutes Prepared By: Dany Cheij

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

- Review- Approve New Members

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

- Reviews from the morning working groups- Guidelines for API Working Group- Spectrum Analyzer Working Group- VXIplug&play VISA Working Group report

- Legal Working Group Status- Review the spec status document – Scott Rust (NI)- Review working group charters- Spec renumbering proposals – John Harvey (Agilent)- Chairman for the IVI Config Store Working Group

- Old Business Items- A public position from IVI Foundation on MSS

- New Business Items- Meeting Costs

- Schedule for Next Meetings- Info on the February Meeting (2/26 – 3/2) – Daniel Erikson (Vektrex) - Info on the May meeting – Anne Faveur (Advantest)

- Proposed Dates: 5/28 – 6/1- Adjourn

3.2 Voting Members In Attendance

Company Representative

Advantest Corp Japan Yohei HirakosoAgilent Technologies Joe MuellerAnritsu Company Jimmy Bigelow


Boeing Don DavisDefense Logistics Organization John PrescottKeithely Instruments John RylandNational Instruments Jon BellinNorthrop Grumman Gayle MatysekRacal Instruments John RosenwaldRohde & Schwarz Germany Jochen WolleTYX Corp Ion NeagTektronix Keith Rule Teradyne Teresa LopesVektrex Electronic Daniel Eriksson

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

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

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

Company Name Voting or Associate

BCO, Inc. Upgrade to Voting

Software AG Inc. Voting

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 approved unanimously (16-0).

3.6 IVI Account Summary - Scott Rust

IVI Account Summary

1999 Balance $23,408.31

2000 Revenues $17,600.002000 Expenses ($7,969.19)


Current Balance $33,039.12

IVI Expenses

2000 Kevin Rea reimbursement $ 224.85 2000 Lucash, Gesmer & Updegrove legal fees $ 3,877.48 2000 Lucash, Gesmer & Updegrove legal fees $ 3,566.90 2000 Kevin Rea reimbursement $ 299.96 Total 2000 Expenses through 11-7-00 $ 7,969.19

Delinquent 1999 Membership Dues

Raytheon TI Systems $ 500.00 Shaanxi Hitech Elec China $ 200.00SIRTI SpA Italy $ 200.00 Total 2000 Expenses through 11-7-00 $ 900.00

Unpaid 2000 Membership Dues

IFR $ 500.00 Lucent $ 500.00Pacific Software Group $ 500.00 Raytheon TI Systems $ 500.00 SIRTI SpA Italy $ 200.00 Total 2000 Expenses through 11-7-00 $ 2200.00

3.7 IVI Working Group Issues

3.7.1 Reviews From the Morning Working Group

Guidelines for API Working Group

Naming COM enumerations discussed. Yesterday did a lot of work on COM hierarchies and these will be encapsulated in the style document. As there are multiple documents, they are noticing that there is coverage of the same issues in multiple documents and they are trying to decide where those should reside. A new topic was brought up about synchronization techniques and these will be incorporated.

Spectrum Analyzer Working Group

No meeting on Wednesday morning.


VXI plug&play VISA Working Group

Discussed VISA COM API that is in work. Talked about several issues including discussion on Formatted I/O. Came to resolution on some issues and there are still some issues outstanding. They hope to have the spec ready for vote in the January timeframe. Some open issues where discussed about where to move from here and these will be discussed at the 3.1 meeting tomorrow.

Ron Wolfe described a discussion that happened at the VISA TWG about possibly bringing the VISA TWG into the IVI Foundation fold. Ron W. will investigate how to go about doing this. However, the VISA COM I/O spec will be voted on in VXIplug&play.

Another issue is the Shared Component Support Model. We should have a plan on how to be able to own the software.

Action Items:1) Ask the Shared Component Support Model work group to try to get to a resolution of this issue between now and February (at least make progress)2) Dany Cheij will act as the legal committee liaison with this working group to ensure that their views are taken into account in the legal documents3) The legal team will check with Andy Updegrove whether we can put in anything into the bylaws that defines some of these issues.

3.7.2 Legal Working Group Status

- Kevin Borchert summarized the status of the legal working group and walked through a presentation that summarizes the legal framework document.

- We are at a stage where we are ready to move to the next level and actually draft the legal documents (articles of incorporation and bylaws)

- We want approval and buy-in from the general membership to move forward.- Additions and changes from the last meeting:

- The User Committee is now at the same level as the technical committee and marketing committee

- Question about who is part of the technical committee- Dany Cheij said he thinks it is similar to the general membership meeting

we currently have. Action item: Verify this with the legal team.- The number of seats allotted to Sponsor members can now be up to ten. This

number is set at initial formation and then it is at the discretion of the BoD to increase that.

- Question came up about who’s eligible for committee chairmanship. Is it an AND/OR or just OR. We need to clarify this with the legal team.

- Can Associate members be committee chairs. No, but we should clarify that.- Issue came up about the Meeting Cost Overrun being in the official budget.

The pros and cons were discussed and this issue will be evaluated further.


- Question about who would like to join at the different levels- Sponsor: NI, Teradyne, Keithley, R&S, Tektronix, Agilent, Anritsu- General: 9 companies- Associate: None

- Question about what people should expect for the legal incorporation schedule from now on.- Kevin B. reviewed the formation schedule as we have it set.

3.7.3 Review the spec status document – Scott Rust (NI)

Scott Rust reviewed the spec status summary document. The dates for some of the specs were modified. In addition, a new date column was added differentiating between the completion date and the approval date. This is necessary because many of the architecture specs are closely tied and should be voted on together. The class specs were also pushed back from Q4-00 to Q3-01.

3.7.4 Review working group charters

Scott Rust reviewed the charters he received from the members. From the class specs, only the digital and chemical analyzer working groups were

sent in. The charter for the 3.1 spec should be improved by adding stuff that was put in

the intro of the spec document In the charter of the C Working Group (3.9) update the description to use the 3.1

terminology (IVI-C instead of C-based, etc.) Need to add IVI Factory to the charter of IVI 3.5 Scott Rust summarized the list of groups that did not send charters Action Item: Scott Rust send current document and Nepcon summary document

(obtained from Dany Cheij) to the membership and request that chairs update their specs.

3.7.5 Spec renumbering proposals – John Harvey (Agilent)

John Harvey presented spec renumbering schemes suggested by NI and Agilent. Both schemes suggest grouping specs into areas that logically fit together.

o Both of these were discussed as well as other more complex taxonomies. A scheme was chosen that groups Administrative specs into a 1.x series, Common

technology specs into a 3.x series, and class specs into a 4.x series. Motion to approve this scheme. Approved 15-0.

3.7.6 Chairman for the IVI Config Store Working Group

Kirk Fertitta resigned as working group chair. Joe Mueller volunteered Bud Cribar from Agilent to be the chair of this working group.


3.8 Old Business Items

3.8.1 A public position from IVI Foundation on MSSScott Rust discussed an action item from the last meeting. Dany Cheij solicited feedback from the members that volunteered to help out at the August meeting. Only Jon Bellin from NI responded. This response was not forwarded to the rest of the group.The group would like to take this further.

Action Item: Dany Cheij will forward NI position to listserver and solicit input for members.

3.9 New Business Items

3.9.1 Meeting CostsScott Rust explained that he planned the headcount according to past projections. The estimate was about 10 people short. From a budget point of view we are $5200 short for this meeting.

For future meetings, one suggestion was to overestimate costs by 20% to try to cover costs. Gayle Matysek that from her experience that if you go over the $200-300 level, attendance drops.

Outcome is that we are going to try to do this again and ask people to pre-register. The cost will be $400 with a $100 early registration credit. We will also lower the headcount estimate while still leaving a slight buffer over the preregistration numbers. Also consider having simpler lunch which might be cheaper (no dessert).

3.9.2 Suggestion of Interoperability SessionJoe Mueller suggested that we hold an interoperability session at the next meeting to try to start demonstrating different vendors’ systems working together. Joe wondered whether the February meeting might be pre-mature but he would still like to see something, even if it is only a set of vendor demos.

Dan Mondrik described how this has worked well in the past for the VXIplug&play group.

At the next meeting have a session that starts at noon and runs until whenever. Food could be ordered to keep people in. The Action Item for Scott Rust is to find a half day in track 1 (on an afternoon) where we could hold this session.

Dany Cheij suggested that we hold a 4 ½ day meeting in February so we could have more time for all the business that will need to be conducted.


3.10 Schedule for Next Meetings

3.10.1 Info on the February Meeting (2/26 – 3/2) – Daniel Erikson (Vektrex)Daniel Eriksson went over plans for the February meeting. Several hotels are being looked at. Options include hotels that don’t charge for meeting rooms and some that do but have a lower per room cost. The Bristol Court downtown ($129), Clarion Bayview ($109). Daniel will look into these options and figure out which hotel would work best.

Action Item – Try to come up with a pre-registration procedure for this meeting to try to better estimate a headcount.

3.10.2 Info on the May meeting – Anne Faveur (Advantest)- Anne Faveur went over her proposal for a meeting in Paris. The hotel is the Brebant

and it is very nice. - The proposed dates for the meeting is:

1. 6/5 – 6/8 (Full Days – Tuesday through Friday)2. 5/29 – 6/1 (Full Days – Tuesday through Friday)

3.11 Adjourn

Motion to Adjourn. Seconded. Motion was unanimously approved.


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

4.1 IVI C Working Group SummaryThe group completed the implementation of a prototype of the C shared components. The group was unable to create a draft specification. The group reviewed the changes made and created several action items. Main goal is to get a specification draft for the next meeting.

4.2 IVI 3.2 Working Group SummaryThe group reviewed the IVI 3.2 Status document. The only open items in the status document are items to be reviewed during the final review of the specification. The group reviewed major issues raised by Steve Greer. There was not enough time to review all of the issues. Steve Greer and Scott Rust will review the remaining issues during one evening this week. The group feels that the spec is nearing completion. Scott Rust and Zulfiqar Haider will modify and the document based on feedback during the meeting and repost as soon as possible. They will make an announcement that the general membership needs to review the specs and that we will be conducting a conference call in January or February to address issues found during the review.

4.3 Config Store Working Group SummaryThe chairman of the group has resigned. The group needs to find a new chairman. Working through most of the issues the prevented the group from implementing the Config store component. Major open issues are repeated capabilities and finding a Chairman. The group also needs to find someone to create the specification for the Config store. Will discuss at the General Membership meeting.

4.4 IVI COM Working Group SummarySpent a lot of time discussing hierarchies for the class specs. Were resolve all hierarchy issues with the exception of one naming issue. Should have IDL to approve at the next meeting. Have an action item to take one class specification and bring it up to full COM documentation by the next meeting. Discussed repeated capabilities issues. Decided that they need to settle on one way to identify hierarchical repeated capabilities. Resolved many issues with regard to repeated capabilities. Had some demos of COM demos and had some question and answer.

4.5 Guidelines for API Style Working Group SummaryNaming COM enumerations discussed. Yesterday did a lot of work on COM hierarchies and these will be encapsulated in the style document. As there are multiple documents, they are noticing that there is coverage of the same issues in multiple documents and they are trying to decide where those should reside. A new topic was brought up about synchronization techniques and these will be incorporated.


4.6 IVI 3.1 Working Group SummaryFirst half of the day discussed the I/O requirements that IVI might make. Quite a bit of discussion. Four quite complex options, and ended up taking an informal straw poll with a vote in favor of what was called option 2 which requires that drivers communicating with GPIB, VXI, Serial and maybe VXI-11 would have to use VISA-C or VISA-COM. We didn’t touch on any other buses. Also said that VISA-C and VISA-COM would have to coexist and that we would solve the multiple VISA-C problem.

In the afternoon, we went through the 3.1 document. We finished section 3 and got partway through 5. We didn’t touch on section 4 which is the C and COM architecture. Section 6 is on installation issues. These will be continued in conference calls. Hopefully ttrying to have more than two which is the number we had between the last two meetings. Also Jochen brought up an issue about interchangeability checking in the RF Sig Gen and it would be helpful to have users solve this problem but that users have not been showing up. Sometimes it seemed that the rules in 3.1 were either in conflict or not applicable to what was in the RF Sig Gen spec.

4.7 RF Sig Gen Working Group SummaryReviewed the base capabilities and most of the extension groups except for some of the modulation extension groups. Today they will discuss the digital modulation extension groups. There were only 3 attendees (Agilent, R&S, and NI, No users). Jochen requested that more people attend these meetings.

In the second half of the meeting, they walked through digital modulation. Walked through the instrument model for digital modulation. For the first release, they decided have more basic modulation extenstion groups that can be extended later with the control of more complex communication signals such as CDMA 2000.

The meetings were not well attended. The group requests more attendance from the users and system integrators.

The group feels that they could release this specification soon if they could exclude digital modulation.

4.8 Spectrum Analyzer Working Group SummaryHad 10 people attend the meeting. Reviewed the work and edits completed since the last meeting. Worked through the agenda items for the meeting. Reviewed the COM hierarchy for the spectrum analyzer class. Would like to integrate COM in the specification either before or at the next meeting and then send it out for ballot after the next meeting. The group is not meeting for the second half of the meeting.

4.9 Power Meter Working Group SummaryDiscussed remaining issues regarding the spec. They discussed almost all of them and got to some sort of resolution. Added Calibration, reference oscillator, internal trigger, zero channel


extension groups. Also changed the Trigger source to a channel based attribute where previously it was not. Added a new high-level function to allow user to perform synchronized dual-channel relative measurements. Decided to make averaging a base capability. The spec is almost complete, and they are confident that they will complete the spec by the February meeting.

4.10 Signal Working Group SummaryCompleted review of their specification except for the digital and bus testing subsystems. Would like to post a draft design specification for broader review by the foundation. Are asking for help from users and system integrators on issues regarding calibration, timing, synchronization, and composite signals.

4.11 Legal Working Group SummaryHad a good session. Reviewed and updated the presentation from the last meeting based on the current proposal for the by-laws. The group then reviewed the proposal. The group will discuss this more at the General Membership meeting.

4.12 Promotions Working Group SummaryDiscussed the idea from the last meeting regarding a brochure/handout that describes what IVI is. Not much work was completed between meetings due to the legal activity. Reviewed the press conference presentation and update or left place holders where information needs to be updated. Dany will contact the member companies to get more feedback on the contents.

4.13 Users Working Group SummaryUpdated the description of the user working group and gave it to Dany.

Discussed what is going on ASAM. The users that requested this information at the last meeting did not attend this meeting. Would like to learn more about the certification process that ASAM uses and would like to learn more about the prototype that Dan Matthews is developing.

Discussed ways of making driver availability information to users. No clear actions were identified.

Discussed holding the user group on a single day and inviting non-member users to attend. We are a little premature at this time. Would be a way for users to share experiences and help mature the group.

In the second half of the meeting an informal discussion was held among the users. Users very interested in having access to the equipment from the demos at the next meeting. The users are also very interested in the IVI 101 publication that the promotions working group is working on that they would use to educate other users. They also discussed that the $300 fee for attending the meetings should be a cap or the attendance would drop. Also discussed the layout of the web, and that there is a lot of confusion as to where everything was on the web and the difference between the public area and private.


Action Item – Dany Cheij will contact Kevin Rea to find out whether he is still in charge of web site and volunteer to take it over if he is not.

4.14 VXIplug&play Systems Alliance VISA Technical Working GroupDiscussed VISA COM API that is in work. A complete summary is given in section 3.7 of this document.

4.15 Digital Working Group SummaryTeresa was concerned that it was only herself and John Prescott who were veterans of the spec. She decided to work through it on the list server and instead gave a tutorial to all the new people in the audience of the digital spec.


5. IVI C Working Group

5.1 General Meeting Info:Date of Meeting: November 13, 2000Location: Dallas, TexasChairperson: Jon BellinMinutes Prepared By: David Fuller

5.2 Record of Discussions1. What components of interest may be required across both COM and C drivers?

Steve: The only thing that he could see is the float supportSteve: Could we have a C and COM componentConsensus: Separate shared component. C and COM API sharing common implementation. Thus we need a separate spec number for the “IVIFloat Stuff”IVIFloatNaming Conventions: IVIFloat.hWhat about file naming conventions in generally?IVIC.h for CIVICOM.h for COMJohn: We need a central list to ensure that name conflicts do not occur.Place naming of shared components in IVI 3.1Each shared component spec should also include its own name and file conventions.

2. AI Update this to reflect these changes (Steve’s) and this open discussion.

3. Goal: We would like to have a spec for review by Christmas.4. Are there any open packaging issues?

A. John: We want modularity with the shared components. We do not want to have to carry around all of the shared components.

B. John: In the short term we can do something individually. Long term we can have more integration.

C. Bellin: Should we release the shared components with their own installer or just rules for installation?

D. John: We can delay this discussion until more shared components become available and people identify the specific issues and form more opinions on distribution.

5. Questions about who owns and manages code arise. Went into legal work underway. (Bug reports, source availability, …)

6. Scott Rust: Discusses legal management of shared component


6. IVI-3.2: Inherent Capabilities Working Group

6.1 General Meeting Info:Date of Meeting: November 13, 2000Location: Dallas, TXChairperson: Scott RustMinutes Prepared By: Scott Rust

6.2 Record of Discussions

6.2.1 IVI 3.2 SummaryReviewed the IVI 3.2 Status document. Only 3 open itemsJohn Harvey and Scott Rust to work on the COM API for Lock and Unlock functions on Thursday night during the IVI Foundation meeting

John Harvey – someone needs to verify that the IDL and the IVI 3.2 specification match.Srdan – will verify that the IDL and IVI 3.2 specifications match.

There was discussion whether a header that corresponds to IVI 3.2 would exist on its own.Srdan – will create a header that corresponds to IVI 3.2

Steve Greer – will validate the header file.

Steve Greer pointed out that there is a boilerplate in sections 2 and 3 that is almost identical for all of the class specification. If the text is for the spec reader, then it should stay in IVI 3.2 and the class specs reference it from the corresponding boilerplate sections.

We will leave section 2 alone. IVI 3.4 and the class specifications will reference it.Steve Greer – to coordinate with Class spec authors to reference the section 2 and 3 boilerplate issues.

Zulfiqar – Section 3 duplicates much of what is in IVI 3.1. Section 3 should be modified to reference IVI 3.1.

Noel and Zulfiqar – To define a neutral name for the concept of a Prefix in IVI 3.1 and then refer to it from the various attributes in IVI 3.2 that are intended to return it.

Zulfiqar – Put an example such as “TDS3012,TDS3014” in the Supported Instrument Models attributes. Also put in a note that it is not necessary to include the abbreviation for the instrument vendor if it is the same for all of the instruments.


Zulfiqar – Look for all cases of E_NOTIMPL and replace with the IVI version of the error code.

The functions that document completion codes use the C version of the error code.Zulfiqar – Document completion codes that particular functions document as shown in Table A below.

6.2.2 IVI 3.4 Summary

In the IVI 3.4 working group meeting, we decided on a new error table format for the error tables that are at the end of the specification. We decided that there would be two tables

Table A

Name COM Identifier C IdentifierMaximum Time Exceeded E_IVIDMM_MAX_TIME_EXCEEDE

DIVIDMM_ERROR_MAX_TIME_EXCEEDED

Table B

Name Value Message StringMaximum Time Exceeded 0x00232323 “Maximum time for the

operation was exceeded”

Keep the message string the same font style that it currently is in IVI 3.2.

The tables are alphabetical by Name.

For each function, the completion codes will be listed like Table A.

6.2.3 Future Plans

The group requests that we post IVI 3.2 with changes as soon after the meeting as possible (approximately 2 weeks). Need to announce to the general membership that the spec is almost done and everyone needs to review it. Then announce a conference call in late January or early Februrary to respond to comments from their review.


7. IVI Config Store Working Group

7.1 General Meeting Info:Date of Meeting: November 13, 2000Location: Dallas, TXChairperson: VacantMinutes Prepared By: Steve Greer


7.2.1 General DiscussionReviewed VB program that illustrates use cases

Reviewed UML figure.

Association logical names to DriverComponent is to name repeated capabilities. We think that referencing repeated capabilities needs to be improved.

Issue 1. What was the design decision to use a reference through a name rather through an idref? Late binding and computers are really fast. Should we use this model consistently throughout?

Issue 2. Naming. DriverComponent and RoleComponent.

Issue 3. What about default setup, initial settings? Most complicated thing we have. UML has combined concepts of driver setup with initial settings. Initial settings need to include the concept of repeated capabilities.

Issue 4. IsSimulationDriver association from SoftwareModule and SimulationDriver association from DriverComponent should be handled as an extended attribute so remove them from the UML and subsequent code.

7.2.2 Implementation notes:1. Namespace – Take out for now to avoid complexity. GUI could add it by providing

prefixes.2. NC3. Classes structure should exist only on SoftwareModule.4. Implementation will support Strings someday.5. Need to do.6. Someday.


7. Should drivers install the config store not the config store shared component? Distribution and packaging issue which remains on many shared components. Installation of config store won’t be ready in Feb.

8. To be done.9. Choice of parser is more important than implementation language. Is a validating parser

needed? The config store shared component should use a validating parser. We not use one because we can’t find one which meets our needs. The user adds elements and attributes types. They should be able to create an xml

schema which integrates unambiguously with the IVI schema. Driver developer extends IVI elements with custom attributes using the ivi attribute

extension mechanism, i.e. extended attributes.

To determine acceptability of Java need to determine impact to install and runtime support.Is there expertise in the foundation to review Java code?Performance – not that important. We’ll know if it’s too slow.Watch for localization problems. David Fuller will do some investigation. Bud will arrange a phone conference for the week of Dec. 4.

7.2.3 Current Issues:1. Need to establish intelligent defaults for file paths. The driver never tells the config store

what xml to use. The app can tell the config store what xml to use. Perhaps an environment variable or global in the config store. The driver reads the xml file using the config store during initialization and only then.Item for Dec phone conf is how do we create factory class ( may not really be a class) for config store. Includes issue 12.

2. Covered in implementation note 3.3. OK4. NC5. Investigate multiple interfaces for different users, driver or GUI. A simple interface for

driver writers.6. Covered in implementation note 9.7. Alternate name for DriverComponent: DriverSession

Alternate name for RoleComponent: IviMssSession8. Bud and Noel will determine good names for the things we talk about with Config Store.9. The driver session contains virtual channel names for the capabilities. The software

module has a template, DataComponent, for its repeated capabilities. The driver session duplicates the structure of the DataComponent with specific values for that DriverSession. A SoftwareModule needs its own DataComponent to extend itself. Change label on arrow from DriverSession to LogicalNames from LogicalNames to RepeatedCapabilities or something else.

10. No. Keep schema separate from data.


11. It’s already in the driver. Sure, why not. The string should be the same as what’s returned by the driver’s supported instrument models attribute.

12. Done with 1.13. Why are some things attributes and other elements? The auto-generated xml are all

elements. Some sort of holy war among xml experts. Attributes can’t have sub-elements, but it can have a default. Elements are probably better for someone editing by hand. Using attributes makes the file smaller. Stick with elements. We still have a requirement for default values. Component installer could store default values.

14. Who creates the documents? 15. Need a way for a SoftwareModule to describe the extensible attributes of the

DriverSession that refers to the SoftwareModule. An attribute in the SoftwareModule which is a DataComponent, perhaps named Template. We don’t need anything additional in DriverSession because the existing extensible attributes will contain the values specified by the template.


8. IVI COM Working Group

8.1 General Meeting Info:Date of Meeting: November 14, 2000Location: Dallas, TXChairperson: John HarveyMinutes Prepared By: John Harvey


8.2.1 Hierarchy Issues.Principle 1: If you have multiple mutually exclusive options, separate the elements in them into separate sub-interfaces (for example, scope triggers or dmm temperature interfaces.

Principle 2: If you have repeated capabilities, minimize redundancy (e.g. only put things that are truly repeated in the RC interface).

Principle 3: If you have an interface with some optional elements, you may separate them or not, depending on other factors (number of methods & properties, depth of hierarchy, etc). Examples are multi-point trigger on DMM (which we separated) & AMInternal in the fgen (which we did not separate out).

Principle 4: If there is a clear cross-class capability, they should be represented in the same way.

Principle 5: Keep in mind potential for future evolution of the design and potential ways that specific instruments might extend the class capabilities when designing the hierarchy.

Principle 6: If you have elements that are logical siblings, don’t put them at different depths in the hierarchy. (switch example – don’t make trigger a child of scan). Either put the elements in one interface or in sibling interfaces.

Principle 7: It’s OK to bury seldom used, read-only stuff lower in the hierarchy, particularly if it serves to highlight more commonly used stuff. (Swtch)

Principle 8: The root should have a no (or minimal) of properties and methods. (DCPwr keeps this one, Fgen breaks it)

Principle 9: Keep parallelism between like elements rwt level in the hierarchy and interface names. (Abort() and Initiate() – note that DCPwr/Fgen broke this one)

Principle 10: Keep other methods and properties out of the collections interfaces. (DCPwr)


8.2.2 Hierarchy Decisions

8.2.2.1 DMMKeep the multiple sub-interfaces under the temperature interface.Where to put multi-point trigger methods and properties. Put multipoint off of trigger.Kill the Query function in the aperture time interfaceKeep the AC and Frequency interfacesMove powerline frequency, aperture time, auto zero, actual range to an interface named something to be decided. Names not eliminated: characterisitics, advanced, system, globalsetting, setting.

8.2.2.2 FgenKeep the AM and FM interfaces flat – no internal sub-interfaces.Eliminate generate interface – move Abort() to root AbortGeneration(), move Initiate to root InitiateGeneration(), move SendSWTrigger to the Trigger interface.Leave ArbitraryWaveform and ArbitrarySequence interfaces flat and eliminate the QueryCapabilities methods in both interfaces.SetActiveChannel(). Remove SetActiveChannel() and use channel strings for specifying channels in each channel dependent item. This is not the precedent for future specs – spec groups are free to use set active channel in the future if they wish.How do we give people access to channel names and count. Put properties under output.

8.2.2.3 SwtchLocation of Trigger interface needs to be changed. Add the Trigger stuff back into the scan interfaces.

8.2.2.4 DCPwrLocation of Abort(), Initiate(), and SendSoftwareTrigger() – move to Trigger interface, eliminate the Generate interface.How to organize the DCPwrOutput interface – eliminate the OVP interface and move the methods and properties into the Output interface.

8.2.3 Repeated Capabilities

Settle on one way of identifying hierarchical capabilities at the second level or lower as strings for every occurrence in an API, whether C or COM. For RC Strings, option #3 is more flexible for instruments that present a more complex hierarchy than is reflected in the class specs.

Don’t use the SetActiveToXXX syntax for hierarchical capabilities. COM should not allow composite aliases. It appears to me that we should avoid composite aliases. If C wrappers can translate composite aliases to underlying COM single RC aliases or RC names, then composite aliases for IVI-C could work.


8.2.4 Multiple Instances of Repeated CapabilitiesDon’t use multiple instances of RC’s indiscriminately. Use them where it is anticipated that it makes a high value add to the driver. For example, don’t use for scope channels, do use for digital or data acq.

8.2.5 Prototype DemosSteve, Ion, and Serge gave demos of prototype IVI-COM drivers based on the Standard IDL, including Q&A to each.

8.2.6 Misc. IssuesWe discussed tweaking the packaging of the standard IDL. When packaged in a type library as we are currently doing, the interface proxy/stubs are not registered. Also, Ion found ways to make the oleautomation attribute work for custom interfaces. We will investigate using oleautomation and packaging the type library as a DLL with proxy stub info.

We decided not to review the current COM specs, partly due to time constraints and partly to wait until we can get more alignment in terms of presentation and organization with the rest of the IVI 3.1 spec.


9. Guidelines for API Style Working Group

9.1 General Meeting Info:Date of Meeting: November 15, 2000Location: Dallas, TXChairperson: Steve GreerMinutes Prepared By: Steve Greer


9.2.1 NamesCOM enumerationsPotential conflict between enum names in the IDL and functions names in C. We could

1. remove underscore in IDL enum name2. avoid conflicts by changing IDL enum name3. add a suffix, e.g. Enum, to IDL enum names

We will add Enum after every enum name. No underscore before the Enum.Add section 3.7.4 to describe.

The HS_ and HC_ macros have conflicts between instrument classes. Johannes and John will work on a solution.

9.2.2 Repeated CapabilitiesThere will be a check list to cover all the changes to the existing instrument class specs when going to the new versions with COM and other stuff added. This check list will be created by modifying IviScope class by Serge and Steve. This checklist will include handling repeated capabilities such as channel count.

9.2.3 HierarchiesPrinciples

What is the underlying principle: is it based on how instruments are constructed or how instruments are used? Action or structure? We seemed to use structure in general, but there are cases where action functions are grouped together.

The principles we use may be hierarchical themselves. Some principles apply in certain cases and not in other contexts.

The principles may lead to conflicting results. Class writers should use them, but with caution and judgement. No particular order or priority to the principles.


9.2.4 Section Layout:AttributesFirst column in table needs to be data type.

FunctionsLeave them in 3.4 and make sure we all the details for writers. Other specs may include additional information for readers. 3.2 and instrument classes refer to 3.4 and also include info on how to read.

Return value table needs to follow style used in 3.2:

Name COM Identifier C IdentifierMaximum Time Exceeded

E_IVIDMM_MAX_TIME_EXCEEDED

IVIDMM_ERROR_MAX_TIME_EXCEEDED

Entries in the table are alphabetized by name.

Completion Code tableUse the same style as used in 3.2.

Change title to “API Style Guide”

9.2.5 Synchronization techniquesRF source – IsSettled, WaitUntilSettled functionsSpecAn – AcquisitionComplete,

1. non-Blocking call – IsOperationComplete2. blocking call – WaitUntilOperationComplete3. callback – RequestOperationCompleteCallback 4. configure what operation complete means(optional)

Is this an SC3 topic which provides specific names for the methods? Is it a style topic which says the instrument classes provide certain functions.

Consult with existing instrument class chairs, RF Sig Gen, SpecAn, Power Meter, to see what belongs in SC3. The instrument class is responsible for exactly defining the meaning Should we omit the callback? Defer until event server is better defined.

Put in style – - Is<thing done>(ViBoolean*) and - WaitUntil<thing done>(timeout).

9.2.6 Data typesLarge arrays (millions of elements) might be better served using a float rather than a double or int16 vs. int32. Need a style rule on when the smaller data type is acceptable. Double and


long are preferred over float and int in general. Instrument classes should use the smaller data types only in unusual cases. Be careful about user needs.

3.1 had table on data types and so does 3.4. Leave the table in 3.1. 3.4 can refer to that table.

Reconcile with 3.1, 3.2, etc.

Read through 3.4 from the view a driver writer trying to include instrument specific things. For example, <CLASS_NAME> vs. <PREFIX>. Class vs. something more generic.

In 4.2.1, stuff about guard bands moved to 3.1.


10. IVI-3.1: Architecture Working Group

10.1 General Meeting Info:Date of Meeting: November 16, 2000Location: Dallas, TXChairperson: Scott RustMinutes Prepared By: Scott Rust

10.2 Records of Discussion:

10.2.1 Topics To Be Discussed:- IVI I/O Requirements- Review action items from last meeting

- Indexing IVI 3.1 and IVI 3.2- Legal teeth

- Review the specification- Review edits to Section 3 made after the last conference call- Continue walking through the spec starting in Section 5

- Action Items

10.2.2 IVI I/O Requirements DiscussionRon Wolfe (NI) gave a historical perspective on I/O standardization and where we are today.

Joe Mueller needs to be able to deliver with their instruments whatever the customer needs to be successful. They want the instrument driver to come with the instrument. They expect to begin building more instruments with more computer interface buses such as USB and 1394. Certain customers don’t want to open the computer to install a T&M interface card. Want to be able to bind their drivers to the serial interface drivers that came with the computer.

Agilent plans to supply drivers that bind to OS components from the computer interface bussed and VISA or NI-488 for GPIB.

Agilent has created a piece of SW that binds to either VISA or NI-488.

Badri M. from Tektronix gave their perspective. Wants to hit the I/O problem head on. Wants to solve the problem in a way that does not require proprietary SW.

Jon Bellin stated that he feels that there are two issues:1. Should the foundation specify an I/O layer API that can talk to different I/O

products?


2. Should the foundation provide an I/O layer that drivers can use to talk to different I/O products? And should it be 1 or 2 layers?

3. Should the foundation require the use of this layer?4. Should the foundation require that drivers ship with I/O SW?

Joe Mueller suggested that we hear from more companies.

Jochen Wolle – R&S is an instrument vendor and does not supply I/O products. They rely on the output of standards bodies such as VISA and what is installed on the computer. They have to deal with NI-488 and VISA implementations. In the ideal, there would be 1 API for them to deal with. However, this may not be reality. Feels that we collected requirements at the Blue Knob meeting. We should look at those minutes. We structured the requirements from the Instrument user, instrument vender, driver developer, and I/O supplier perspectives.

Paul Franklin – Wants to achieve a balance between the user’s requirements and the instrument vendor’s requirements. The larger the number of possible APIs the more difficult it becomes for the instrument driver supplier. Wants the number of APIs to be small. 1 is ideal. A small number is acceptable. VISA-C and VISA-COM would be acceptable. Sees the Agilent proposal as viable. Seems that if there was a single implementation that was easy to obtain and widely available, this would be in the user’s best interest and the instrument vendor’s best interest. It is probably unreasonable to expect that there be 1 implementation because of the technical difficulties in implementing that layer and the business models associated with that layer. Would like to find a way to still have the benefits of 1 API but allow for support for multiple implementations of I/O products. COM takes care of much of this. Would like to find a solution for VISA as well. Would like to find a way to minimize the number of components that make up a system.

Daniel Eriksson – As a driver developer, Vektrex would like a solution for reducing the amount of testing required (NI-VISA, HP-VISA, NI-488). Would like to be able to write drivers for computer buses without requiring a specific I/O library. Would like some way of plugging in your own I/O libraries such as Passport. Would like some way to plug into the backside of VISA or COM I/O to support proprietary I/O buses.

Gayle Matysek – From a user perspective, the fewer number of things that she has to deal with the easier it is for her to build a system. It is difficult when various vendors are all overwriting each other I/O. It is best if their can be one or very few I/O libraries. Maintaining compatibility between versions is a major concern.

Keith Rule – would like to echo what Gayle says. There are COM and C camps. The reality is that we have to make the multi-vendor situation work. A multi-vendor world is not going to go away. C and COM have to coexist. We have to solve the multi-vendor VISA compatibility problem.

Paul Franklin – Need to have I/O standards that can survive and adapt to new I/O technology. The passport provides a way to deal with different I/O busses. Passport is a


way to deal with these types of problems. There are also other ways. The same goes for the TULIP architecture.

Bandri – Thinks that the Passport architecture is good, but that you should not require its use. Anyone should be able to implement the thing that loads Passports.

Jon Bellin – From an instrument vendor and driver point of view. We agree with many of the concerns. We also have issues such as cross-platform compatibility, easy to use from C with no significant performance degradation (compared to our existing VISA), full-featured (existing VISA features such as register-based support), and decoupled from Microsoft decisions.

Believes it is possible to create an I/O layer that vendors can write to and do not have to worry about the underlying I/O. However, we should not require its use. It is possible to have VISA-C and VISA-COM to be compatible such that someone that uses VISA-COM that their driver would work on a system where the only I/O implementation is VISA-C. The reverse might also be possible.

Roger Oblad – Passport does a nice job of providing interoperability. However, we cannot require that customers purchase NI’s VISA. We need to make sure that it is open and anyone can implement the VISA. A combination of IVI drivers and I/O products from a variety of vendors (including computer standard I/O), If Passport if the interoperability mechanism, then it is inappropriate for a require an implementation from a single vendor.

Jon Bellin would like to register a protest. Need to have a process to make progress and move forward. We need to make sure that we have time to work on IVI 3.1.

We are going to attempt to list the positions that IVI 3.1 specification might take.

1) IVI makes no requirements whatsoever with regard to I/O.2) IVI requires using either VISA-C or VISA-COM.

a. For all buses b. For selected buses

i. currently known busesii. GPIB, VXI

iii. Message-basediv. ii and iii

c. Foundation provides VISAi. VISA costs something, but is available to everyone at a reasonable

priceii. Like 2.c.i but VISA is shipped with the driver.

3) Requiring the use of VISA-COM onlya. Foundation provides the implementation framework

4) Requiring the use of VISA-C only


Joe Mueller suggested that we take the above list and form complete more thought out proposals.

Clarification of the 2)

Open issues is yellow:

IVI requires that IVI drivers use VISA-C and/or VISA-COM for selected buses. The selected buses include GPIB, VXI, RS-232, VXI-11, and possibly others. For new buses we are not certain what we do. For proprietary connections (eg. PCI) the driver would ship with whatever it is necessary and must coexist with VISA-C and VISA-COM. VISA-C and VISA-COM must be able to coexist.

The standard guarantees that if the customer has installed VISA-C and VISA-COM then any IVI driver will work. The driver developer may distribute a VISA-C or VISA-COM implementation with the driver but is not required to do so. The driver provider may choose to deliver a driver that binds to other I/O APIs in addition to VISA (eg. NI-488).

For this to work, we must solve the multiple-VISA-C problem. It was suggested that there should be a standard way to discover what I/O library is currently installed on the system.

Proposal is to leave IVI 3.1 requirement open as to whether or not the driver uses VISA for other buses.

Clarification of 3)

IVI requires that IVI drivers must bind to VISA-COM. IVI Foundation owns and makes available to driver developers versions of VISA-COM that will bind the driver either to VISA-C or NI-488. The drivers are required to distribute the IVI shared VISA-COM component.

The standard guarantees that if the customer has installed VISA-COM then any IVI driver will work. The driver developer may distribute the VISA-C or VISA-COM implementation with the driver but is not required to do so. The driver provider may choose to deliver a driver that binds to other I/O APIs in addition to VISA (eg. NI-488).

Observation: The issue is whether the IVI brand means that an IVI driver ships with everything necessary to work on the I/O that is preinstalled in the system, or does the IVI Foundation make it possible for the driver supplier to do so.

The group took a straw poll. It was 7 to 1 in favor of the clarification of option 2).


10.2.3 Review Action Items from Last Meeting

10.2.3.1 Indexing IVI 3.1 and IVI 3.2Here is what was proposed with regard to Indexing IVI 3.1 and IVI 3.2 by NI’s technical publications group

1) Wait until the 3.1 and 3.2 specs are in fairly good shape.2) Ship them off to our indexer to come up with the original index. I believe that this

also includes providing a list of key words you want to show up in the index. This will cost approximately $500 (please verify). The indexer said that $500 should be a safe, padded estimate of what the cost of a normal document for that pagecount would be. She was unsure of whether a spec would require more work, so Ryan sent her the current version of one of the specs a couple of days ago. We are still waiting for a reply from her, but I think it is safe to assume that about $500 would cover it, and hopefully it would be less.]

3) Update the Word documents with hyperlinks based on the index produced by the indexer. This is so that future indices will automatically be generated.

4) Every update to the documents must consider the impact on the index. This basically means adding hyperlinks for the new stuff.

10.2.3.2 Legal TeethEmail from Dany Cheij regarding this issue,

--------------------------

I was tasked with finding out what legal teeth we could sink into the compliance with the 3.1 spec issue. I asked Andy Updegrove our lawyer the question and here is the answer he gave me:

The quick answer is, through your ownership of the trademark "IVI" (whether or not its registered), you can forbid people from saying "IVI Compliant" unless it meets whatever uniformly applied rules you set. Hence, you can say that "IVI Compliant" has to be used only in a statement that specifically excludes the offending drivers.

Another approach is one common to the Open Source movement, under the"LPGL", which, in this case, might require the developer of any such driver to give source code back to IVI, so that IVI could (if it wished)incorporate the driver into the spec.

Finally, its worth noting that there's another issue here: what does"compliant" mean? These are the mainstream choices:

- self asserted compliance to the *spec*. This may or may not mean that interoperability will result (it depends on how good the spec is, let alone whether the assertion is accurate)

- self asserted passage of a compliance test


- verified (on paper) passage of a compliance test

- IVI (or authorized third party) test of compliance

The way I interpret his answer is that we could define whatever rules we can agree on within the foundation and state that you have to abide by those rules in order to claim IVI compliance. However, I still don't think we can police this rule, so really, there are no teeth behind it. His four options at the bottom will somehow clarify the issue a little bit more depending on which route we go.

Steve Greer - You would hope that there would be enough market pressure for vendors fit within classes. The danger is that vendors might try to comply with classes for which they don’t really fit.

John Harvey – There were two cases that he thought of. 1) The class specs attempt to support 95% of the instruments of a given class. This automatically excludes at least 5% of the instruments. 2) There are specialty instruments that do tasks that might be considered as part of the class spec but still not be able to implement the class specification. So you would still want to write a Custom driver for these instruments.

Jon Bellin – Isn’t it a good idea to recommend that vendors develop driver interfaces for the classes with which the instrument is compliant.

10.2.4 Review the Specification

10.2.4.1 Review edits to Section 3 made after the last conference callInterchangeability Checking – Need to talk about the effects of Reset and ResetWithDefaults on Minimal Interchangeability Checking for whether an attribute is in a user-specified state. Should leave open that class specification can have additional requirements on minimal interchange checking for other functions such as AutoSetup.

Note that things set as a result of the User-Specified Initial Settings are not considered to be in a user-specified state.

The group identified that there are challenges with interchangeability checking in the RF Sig Gen with regard to generating special signals such as CDMA 2000 and then tweaking the signal. The group agreed to continue the discussion in a different forum such as a conference call or the next RF Sig Gen working group. Jochen will host the discussion at the next RF Sig Gen working group.

Remove IVI from the specification titles for IVI 3.1 and IVI 3.2.

The group wants to change the name of the IVI Factory to be IVI-COM Driver Factory.

The group finished reviewing section 3.


10.2.4.2 Continue walking through the spec starting in Section 5The group reviewed section 5 up to (but not including) section 5.6.1.6.

The group plans to continue reviewing section 5 in conference calls. The first conference call will be in the second week in December.

There was a discussion of making sure that the read/write functions for message-based devices do not get overlooked get overlooked by driver developers. We decided that we cannot mandate a particular function prototype. So we have decided to recommend function prototypes in IVI 3.4 API Style Guidelines.

Steve Greer to document the read/write function prototypes in IVI 3.4.


11. IVI MSS Working Group

11.1 General Meeting Info:Date of Meeting: November 17, 2000Location: Dallas, TXChairperson: Roger ObladMinutes Prepared By: John Harvey


11.2.1 Common Code Support ModelPatrick Johnson showed a presentation that will be posted on the web site.

We revised the list of common code components Configuration Store COM Driver Factory IVI Float C Shared Component Event Server Locking and Sharing Component

Discussion related to foundation legal liability for software behavior and support. We want to structure things so that we are only liable for what we create – not for how it works in non-IVI software. We are ready to back up the software at the level of the testing and certification that we do, but not beyond that. This includes clearly defining what interchangeability means so that we are not liable when people using IVI drivers or other IVI software complain that their interchangeability expectations have not been met.

Joe Mueller mentioned that one alternative is for the foundation not to distribute the common code – users would only get the software through IVI foundation members.

Dany Cheij indicated that there might be some legal issues related to not giving access to common code to non-members.

Joe Mueller noted that we will not have the ability to provide support out of the foundation – it will have to be through vendors.

Ion is concerned about the perception of “free” software is just put on the web and available to all, but not quality, supported code.

John Harvey mentioned that this increases the need to distinguish between “compliance” and “quality”.


Patrick will post the presentation on the web site and also solicited the group for input and help working on the problem. Dany Cheij volunteered to help.

11.2.2 MSSRoger presented a charter for the Event Server working group. The charter has been integrated into the charters document.

Roger walked through the Event Server specification document, IVI 3.7, at a high level. He will mail the document out for review prior to the next meeting.

Jon Bellin suggested that we refer to the Event Server as the IVI Event Server rather than the IVI-MSS Event Server, since it is generally applicable to drivers and perhaps other components as well as MSS components. The suggestion was accepted.

Roger reviewed a memo he wrote that described how to position MSS within the IVI Foundation. He also showed a presentation that attempted to summarize how the IVI interchangeability message related to several IVI concepts – specific drivers, instrument classes and class compliant drivers, IVI-MSS, and IVI Signal Interfaces.

Jon Bellin showed a presentation that presented NI’s perspective on these issues. Some points noted were

Interchangeability with IVI drivers also requires re-acquaintance with the test program design.

Ion noted that Signal Interfaces provide some tight semantics for either drivers or role components.

There was quite a bit of discussion on the different understandings people have concerning MSS and drivers. The key point is that IVI drivers can be used without using MSS; MSS does not replace IVI drivers but rather compliments use of IVI drivers for users with the specific set of needs that requires MSS.

John Harvey made a proposal to distill the two presentations into a technical description and a promotional message.

The list of people interested in working on the presentations are Roger Oblad, Dany Cheij, Jon Bellin, Ion Neag, and Joe Mueller.

Comment – modifying driver source is not the best way to achieve interchangeability.

11.2.3 MSS SpecificationRoger introduced the MSS Specification first draft.

A suggestion was made to make sure that people know the basic terminology and OO concepts – perhaps to provide references. Also, it would be nice to have examples. There is a glossary on the IVI-MSS web site and in the IVI 3.12 spec, but it may need to be expanded.

There was additional discussion about what it means for the IVI Foundation to specify MSS. This includes common component specs (Event Server, Config Store, and Resource


Locking). The IVI-MSS spec will discuss what MSS role components are like and how they relate to each other and other IVI components.


12. RF Signal Generator Working Group

12.1 General Meeting Info:Date of Meeting: November 13-14, 2000Location: Dallas, TexasChairperson: Jochen WolleMinutes Prepared By: Zulfiqar Haider

12.2 Meeting Attendees1. Jochen Wolle – R&S2. Michal Krombholz – Agilent3. Zulfiqar Haider - National Instruments4. Roger Oblad – Agilent5. Lynn Wheelwright – Agilent


Monday, November 13, 2000

1. Went through agenda.2. Reviewed and approved August meeting minutes.3. How should we define digital modulation? New standards keep up coming and

standards changing. Should the class define a subset of the standards and the rest become specific capability? It’s a moving target. Users like to have most of the standards.

4. We digressed into a discussion of what digital standards are, how do we define the parameters for these standards, what benefit does it give users to specify standards interchangeably. What can instruments do? What do users want to do?

5. It was discussed if LFGenrator attributes should be channel based or not because some (10%) instruments have more than one generator. The argument against is that the user will not have to specify the channel parameter for the majority of the use cases.

6. Correction made to no. 10 in meeting minutes for Tuesday. Creat -> Crest. CBA -> CDMA.

7. No.19 concluded to use the unit in the base group and dropped power unit for POWER_STEP.

8. Minutes approved as amended.9. Jochen proposed to review all the changes made to the spec. and identify the status of

the action items.10. Reviewed base capability group. No changes or comments.11. Changed QueryAMNominalVoltage to GetAMNominalVoltage. Need to pass this by

Steve Greer.


12. Michal raised the question what is meant by ‘summing’ sources for AM_DEPTH. 13. How do you specify AM_SOURCE which is the sum of more than one external

voltage sources .Agreed that AM_SOURCE will specify a comma seperated list of virtual channels (which coprrespond ot the LF generator channels) and sum those voltage sources together. This does not require that LFGenerator be defined as a channel based capability.

14. Staying with the decision that LFGenerator should be not channel based. Debated this for some time. Agreed to make this channel based. Reason: ease of extensibility, there mght be a stimulus system, and a high probability that future instruments might integrate multiple sources. Be more forward looking. Much easier to implement for single-sourced instruments. Same for LFGeneratorOutput.

15. Michal asked if it was necessary todefine the PulseDoubleGeneratgor group since only a small group of instruments support this. Need to ask users if they use this interchangeably. Decided to leave it in.

16. Need additional compliance rule for SWEEP_MODE that you are required to support at least one defined value other than VAL_NONE.

17. Michal questioned that incase of step or list sweeps, the trigger can trigger the entire sweep or just a transition. How do we specify this?

18. For FrequencyStep extension, one remaining question is how dwell time interacts with trigger?

19. Dwell time is ignored in single step mode. Added tin the description that it relates to triggering.

20. Drop LIST_POWER_UNIT also similar to STEP_POWER_UNIT? Should we remove the notion of units from the specification or remove the global unit attribute or have a unit attribute in each extension group? Resolve this issue by asking the users and style working group.

21. Typical usage is not to have separate power and frequency lists and combine them together. How do we model frequency and power lists? Went back to older specification. Create power, frequency, and frequency-power list, and select A list.

Tuesday, November 14, 2000

1. Changed ‘channel’ parameter in LFGenerator functions to ‘LFGenerator’ to be more descriptive of the repeated capability that it applied to.

2. Summarized the decisions made yesterday.3. Discussed Settled extension group. Roger mentioned that this is either an SC3

capability or a capability belong in the base capability group. Decided to make an action item and discuss.

4. Decided to move IsSettled and WaitUntilSettled to the base capability because all users need this. If the driver is unable to implement this in hardware then the driver should implement this functionality.

5. Discussed digital modulation. No objections to the IQ Impairment extension. Michal asked if we had put in something for the sensitivity of the source similar to NOMINAL_VOLTAGE which would make sense only for external input.

6. Decided to have a read-only attribute for IQ_NOMINAL_VOLTAGE to allow the user to query the fixed sensitivity that the instrument uses.


7. Went over the diagram for the Digital modulation. Lyn pointed out that third position of switch for Coding for the burst control corresponding to the Internal PBS. We need to provide some signaling for the burst shaper as well.

8. Lyn said that we need to specify that we need to provide other synchronization switches for Arb. There should be at least one triggered output in the base box. This can be driven from somewhere from inside the DM or the Arb Waveform section.

9. Discussed Arb Generator extension group. There was a question on what is the best way to pass the data array for I & Q to create the CreateARBList function. Should we have two separate lists for I and Q and the driver can combine them and send it to the instrument, Jochen pointed out this could cost in performance since these lists are very large. Zufiqar pointed out that the application would have to do it in the other case. Need to research if we can use ViInt16. Base decision on what some other applications deal with IQ arrays. Should we have alternate I/Q in one array or two arrays for I and Q? What are the underlying values - voltage (float32) or daq bits? Do some user research. Do we create one big block of RAM when creating IQ data or do we provide a way of streaming the data or some other alternative.Delay this till the next meeting.

10. If we define IQ values in terms of volts, what is the range of voltage values? Proposal: To assume that the sensitivity to be 1 Volt peak to peak (+- .5). Still need to look at the precedence. Ask users.

11. How do we deal with arb sequences. Do we need sequences of lists? Action item for Michal.

12. Investigate filtering capabilties for ARB_FILTER_FREQUENCY.13. Restated goal that for the 1.0 version of the spec to have IQ modulator, arb, DM , and

Burst control.14. Achieved agrrement on IQ Modulator, made progress on diagram and arb section.

DM and burst to be discussed.15. Jochen Volle to rework the specification and send it out by first week of December

latest.16. Question asked if the coupling between FILTER_TYPE and FILTER_PARAMETER

is modeled correctly? Decided that it was and to leave the attributes as is.17. Michal proposed that each digital extension group should provide convenience

functions to configure IQ for different standards. Zulfiqar and Jochen pointed out that the standards extension groups should deal with these from a higher level. Decided not to include these functions.

18. How do we handle FSK mapping? Maybe need another interface for FSK. Action item for Jochen.

19. Michal had some issues with DM_CODING. How do we want to generalize the mapping? Michal to send Jochen more detailed questions about differential modulation.


13. Spectrum Analyzer Working Group

13.1 General Meeting Info:Date of Meeting: November 14-15, 2000Location: Dallas, TXChairperson: Lynn Wheelwright substituting for Neil ShahMinutes Prepared By: Lynn Wheelwright

13.2 Meeting Attendees:

Name Email Address Company

Bob Stern [email protected] Agilent

Jochen Wolle [email protected] R & S

Anne Faveur [email protected] Advantest

Lynn Wheelwright [email protected] Agilent

Ian Dees [email protected] Anritzu

Bob Watzlavick [email protected] NI

Chris Bartz [email protected] NI

Jeremiah Cox [email protected] NI

Yohei Hirakoso [email protected] Advantest

Zulfigar Haider [email protected] NI

13.3 Topics To Be Discussed:1. Approve August 2000 Meeting Minutes2. Version 1.0 of the Specification3. Review Base Capability Group4. Review Extension Groups5. Review Sections 15 through 21

13.4 Record of Discussions:

13.4.1 Approve August 2000 Meeting Minutes Approved Unanimously

13.4.2 Version 1.0 of the Specification Must have base, multi-trace, marker, trigger, external trigger, video trigger, display,

and delta marker Delta marker, and display will only be basic stuff, not complete capabilities.


mailto:[email protected]










We would like to have a working IDL file before we do the final vote on the spec.

13.4.3 Review Base Capability Group Reviewed changes to base group since last meeting.

ACTION ITEM (DONE): Why is statement: “If the spectrum analyzer cannot sample a value for a point in the trace, the driver sets the corresponding element in the amplitudeArray to an IEEE-defined NaN (Not a Number) value and the function returns IVISPECAN_WARN_INVALID_TRACE_ELEMENT. Use the IviSpecAn_IsInvalidTraceElement function to test each element in the amplitude array parameters for an invalid waveform element.” This appears in ReadXYTrace, ReadYTrace, FetchXYTrace, and FetchYTrace functions. The working group does not believe that this is possible for any of the existing instruments and voted to remove this from the document. Neil, could you enlighten the working group on how this was put in the document in case we missed something.

ACTION ITEM (DONE): the function IviSpecAn_IsInvalidTraceElement is not defined. If the only use is as referenced in the previous Action Item, it can be eliminated.

ACTION ITEM (DONE): The word ‘waveform’ is used in ReadXYTrace, ReadYTrace, FetchXYTrace, and FetchYTrace. The working group found this to be confusing and voted to change this to ‘trace’ or ‘trace data’ as appropriate because the names of the functions contain ‘trace’ not ‘waveform’. Also, the term waveform implies a time domain signal (which is generally not the case for these functions).

ACTION ITEM (DONE): ReadYTrace function has duplicate information in 1st and 2nd paragraphs. It appears that the first paragraph should be eliminated (check that non duplicate information is not lost).

ACTION ITEM (DONE): In ReadXYTrace, ReadYTrace, FetchXYTrace, and FetchYTrace: add after ‘stop frequency’ (in frequency domain, in time domain the amplitude array is ordered from beginning of sweep to end). This should help clarify the time domain case where start frequency and stop frequency are the same.

ACTION ITEM (DONE): Add to IviSpecAn_Initiate function a reference to IviSpecAn_AcquisitionStatus so that users will have a pointer to how to determine when the acquisition is complete.

SPCAN12 (DONE): Draw Detector Type Diagram Working group liked drawing and approved it.

SPCAN23: Identify SPCAN Specific Failure Codes Not Done, needs to be done. Still needs to be done.

New ACTION ITEM: EQUALITY working group agreed that we need to add reference to IVI 3.1 (?) about comparing two floating point numbers for equality.

13.4.4 Review Extension Groups SPCAN31/32/33: Behavior of Markers (November meeting – still needs to be

done)


Glenn, Lynn and Srdan to review, edit, and produce this. Agreed that we don’t need a block diagram.

SPCAN24: Reword description to handle both types of signal track implementation (5.5.7)

Some concern was expressed about the availability of this feature, and the amount of interchangeability that could be defined. Agreed that the feature that should be standardized on would be the peak tracking.

ACTION ITEM (DONE): in 6.2.11 strike last two sentences for IVI_SPECAN_ATTR_SIGNAL_TRACK_ENABLED also same sentences in ConfigureSignalTrack function. The working group is not convinced that these two sentences are valid. Neil maybe you can shed some light on the thoughts behind these two sentences.

ACTION ITEM (DONE): In section 6.3.2 the function prototype name does not match the section name. We need to fix this.

ACTION ITEM (DONE): Need to add to SignalTrack description that only one marker may have this enabled at any given time. The driver shall check all other markers to see if this function is already enabled on any marker other than the active and turn this off on the other marker before enabling this on the active marker.

ACTION ITEM (DONE): in 6.3.4 (ConfigureSignalTrackEnabled) the paragraph numbering in the description starts at 3 instead of 1.

ACTION ITEM (DONE): In 6.3.10 (Ivi_SelectMarker) remove the last sentence of description (it is not true).

Marker Frequency Counter Resolution (DONE): Decided that this attribute may only contain values that are a power of ten. All other values should be rejected with an error.

Peak Excursion Diagram: Jochen has a diagram that illustrates this. He will mail it to group. We agreed to put it in the document. Also we need to state in description of attribute / function parameter that the units on peak excursion are dB.

6.3.11 working group agrees with changes made. MarkerSearch (DONE): We need to add to the function description that this DOES

the search (not just configures it). Sections 15 – 21 Anne Faveur graciously offered to review these sections

between now and the next meeting and query the working group about unclear or missing items.

13.4.5 First Review of COM structure The working group was favorably impressed with the progress on the COM interface.

The group believes that although there may be a few minor issues with it regarding the marker interface (the marker type and marker delta extension groups were integrated in with the marker extension group), the current work should be distributed to the working group and to the COM working group for further comment.

13.5 Action Items

The following table summarizes all of the NEW action items.


Issue # Title Owner

SPCAN46 EQUALITY working group agreed that we need to add reference to IVI 3.1 (?) about comparing two floating point numbers for equality.

Neil Shah, Lucent

SPCAN47 Add a Peak Excursion Diagram in the specification.

Jochen Wolle, RS

SPCAN48 Review Sections 15 through 21 and query the working group about unclear or missing items.

Anne Faveur, Advantest


14. Power Meter Working Group

14.1 General Meeting Info:Date of Meeting: November 16, 2000Location: Dallas, TXChairperson: Zulfiqar HaiderMinutes Prepared By: Zulfiqar Haider

14.2 Meeting Attendees1. Arnd Diestelhorst - RS2. Zulfiqar Haider – NI3. Clay Pryor – Sandia National Labs

14.3 Meeting Agenda1. Review and approve minutes from August meeting and summarize the decisions made.2. Review action items.3. Discuss summary proposal document.4. Review all base attributes and functions.5. Review all extension groups.6. Start work on the specification document.

14.4 Record of Discussions1. Action Item: Check with Steve Greer on naming scheme for IsMeasurementComplete.2. It was suggested to add an extension group for the capability to zero on a channel-basis.

Arnd suggested that averaging could be turned off explicitly. Need to rework the averaging extension group.

3. Discussed the summary proposal document issue by issue. Agreed to add Calibration extension group.

4. Added IVIPWRMETER_ATTR_REF_OSCILLATOR_FREQUENCY and IVIPWRMETER_ATTR_REF_OSCILLATOR_POWER to the ReferenceOscillator extension group.

5. Agreed to add extension group for zeroing on a channel.6. How is resolution specified? In the powermeter the auto averaging adjusts to affect the

measurement. Arnd pointed out that for low power measurements instruments might not be able to achieve the desired resolution. It is not possible to ask instruments exactly what resolution it is set to and it is sensor dependent. On older sensors it is not possible to query the sensor type. The spec tries to define the resolution in an interchangeable way. Zulfiqar proposed that this might be a Write-Only attribute, or a COERCEABLE_ONLY_BY_INSTRUMENT attribute.

7. Arnd pointed out that resolution is really an additional parameter for when autoaveraging is enabled, and averaging count is an additional parameter for when averaging is manual. It was proposed to create two move averaging enabled to the base capability group and


add an autoaveraging and a manualaveraging extension group that sets these two attributes.

8. Proposal: Move AUTO_AVERAGING_ENABLED to base capability group. Have two extensions : One for ATTR_RESOLUTION, and One for ATTR_AVERAGING_COUNT.

9. Action Item: Arnd to make diagrams for Overview section that describe a power meter as defined by the specification.

10. Arnd made the point that RANGE_UPPER and RANGE_LOWER should be in an extension group much like autoaveraging enabled. Zulfiqar said that this is probably a base capability and the user would not be required to set it unless he switches AUTO_RANGE_ENABLED to FALSE. Also, the users should be encouraged to specify the range if they want a higher degree of interchangeability.

11. Arnd pointed out that DB millivolts are not supported by most instruments. Action Item: Need to ask users if they take measurements in dB millivolts.

12. Arnd suggested that the units for REF_OSCILLATOR_POWER should be based on the MEASUREMENT_UNITS as well. Zulfiqar suggested this should always be specified in dBm, because it is not a ‘measurement’ unit. Not sure if this is a good use. Do vendors and users always think in terms of dBm?

13. Triggering Model: It was suggested that there are two typical use cases:a. The user wishes to take independent (unrelated) measurements on one or

more channels. The user should be able to specify trigger sources on a per-channel basis and be able to take measurements for a particular channel.

b. The user needs to take a relative measurement in which case he needs to synchronize triggering on multiple channels. Need an initiate and read function that triggers channels at the same time and takes measurement.

A model that assumes a system-wide trigger on all enabled channels, together with a high level function that synchronizes measurements between two channels caters to both use cases. Decided to provide a high level function IviPwrMeter_ReadRelative

to provide this synchronization and allow relative measurements.14. Discussed internal trigger source for the TRIGGER_SOURCE attribute. Additional

attributes that need to be configured are trigger level and trigger slope. Discussed Anritsu’s proposal to allow for more than one internal trigger source and specify the channel that generates the internal trigger signal. Decided that the class specification should support only one internal trigger source and additional sources could be instrument specific capability. Discussed if rigger attributes should be channel based. Arnd said that there is just one trigger system (comparator) that triggers on the external signal. Decided that for the user to be able to use channels independently, the trigger level and slope would have to be specified individually.

15. Added a ZeroChannel extension group that zeroes a particular channel (as opposed to all channels) as there are some instruments that do not support this. Therefore took this out of the base capability group.


14.5 Capability Groups Discussed

Base Capability Group Attributes

Name Data Type Channel-Based Access Coercion

IVIPWRMETER_ATTR_CHANNEL_ENABLED ViBoolean

Yes R/W None

IVIPWRMETER_ATTR_RANGE_AUTO_ENABLED ViBoolean

Yes R/W None

IVIPWRMETER_ATTR_RANGE_UPPER ViReal64 Yes R/W UpIVIPWRMETER_ATTR_RANGE_LOWER ViReal64 Yes R/W DownIVIPWRMETER_ATTR_MEASUREMENT_UNITS ViInt32 No R/W NoneIVIPWRMETER_ATTR_RESOLUTION ViReal64 Yes R/W UpIVIPWRMETER_ATTR_CORRECTION_FREQUENCY ViReal64 Yes R/W NoneIVIPWRMETER_ATTR_OFFSET ViReal64 Yes R/W NoneIVIPWRMETER_ATTR_AUTO_AVERAGING_ENABLED

ViBoolean

Yes R/W None

ViStatus IviPwrMeter_ConfigureChannelEnabled (ViSession vi,ViString channel,ViBoolean channelEnabled);

ViStatus IviPwrMeter_ConfigureMeasurementUnits(ViSession vi,ViInt32 measurementUnits);

ViStatus IviPwrMeter_ConfigureAutoAveragingEnabled (ViSession vi,ViString channel,ViInt32 autoAveragingEnabled);

ViStatus IviPwrMeter_ConfigureCorrectionFrequency(ViSession vi,ViString channel,ViReal64 correctionFreq);

ViStatus IviPwrMeter_ConfigureRange (ViSession vi,ViString channel,ViBoolean rangeAutoEnabled,ViReal64 rangeLower,ViReal64 rangeUpper);

Ignore rangeLower and rangeUpper if autorange is TRUE.


ViStatus IviPwrMeter_ConfigureOffset (ViSession vi,ViString channel,ViReal64 offset);

ViStatus IviPwrMeter_Read (ViSession vi,ViString channel,ViReal64 timeout,ViReal64 *reading);

Return error if channel is not enabled.

ViStatus IviPwrMeter_Abort (ViSession vi);

ViStatus IviPwrMeter_Initiate (ViSession vi);

ViStatus IviPwrMeter_IsMeasurementComplete (ViSession vi,ViBoolean *isComplete);

ViStatus IviPwrMeter_Fetch (ViSession vi,ViString channel,ViReal64 *reading);

ViStatus IviPwrMeter_ReadRelative (ViSession vi,ViString channelA,ViString channelB,ViInt32 function,ViReal64 *result);

Returns error if triggersorce for channel A and B are not the same.Returns error if either channel A or channel B are not enabled.Enables both A and B, takes measurement, and does math.

ViStatus IviPwrMeter_QueryResultRangeType (ViSession vi,ViString measurement,ViReal64 *type);

ViStatus IviPwrMeter_ZeroAll (ViSession vi);

IviPwrMeterAutoAveraging Extension Group


IVIPWRMETER_ATTR_RESOLUTION ViReal64 Yes R/W Down


ViStatus IviPwrMeter_ConfigureResolution (ViSession vi,ViReal64 resolution);


IviPwrMeterManualAveraging Extension Group


IVIPWRMETER_ATTR_AVERAGING_COUNT ViInt32 Yes R/W Up

ViStatus IviPwrMeter_ConfigureAveragingCount (ViSession vi,ViInt32 averagingCount);

IviPwrMeterTriggerSource Extension Group


IVIPWRMETER_ATTR_TRIGGER_SOURCE ViInt32 Yes R/W None

ViStatus IviPwrMeter_ConfigureTriggerSource (ViSession vi,ViInt32 triggerSource);

IviPwrMeterInternalTrigger Extension Group

Name Data Type Channel-Based

Access Coercion

IVIPWRMETER_ATTR_INTERNAL_TRIGGER_LEVEL ViReal64 No R/W None

IVIPWRMETER_ATTR_INTERNAL_TRIGGER_SLOPE ViInt32 No R/W None

IVIPWRMETER_ATTR_INTERNAL_TRIGGER_EVENT_SOURCE

ViString No R/W None

ViStatus IviPwrMeter_ConfigureInternalTrigger (ViSession vi,ViString eventSource,ViInt32 triggerSlope );

ViStatus IviPwrMeter_ConfigureInternalTriggerLevel (ViSession vi,ViReal64 triggerLevel );

IviPwrMeterDutyCycleCorrection Extension Group


IVIPWRMETER_ATTR_DUTY_CYCLE_CORRECTION_ENABLED

ViBoolean

Yes R/W None

IVIPWRMETER_ATTR_DUTY_CYCLE_CORRECTION

ViReal64 Yes R/W Up


ViStatus IviPwrMeter_ConfigureDutyCycleCorrection(ViSession vi,ViString channel,ViBoolean correctionEnabledViReal64 correction);

IviPwrMeterCalibration Extension Group


ViStatus IviPwrMeter_Calibrate (ViSession vi);

IviPwrMeterReferenceOscillator Extension Group

Name Data Type Channel-Based

Access Coercion

IVIPWRMETER_ATTR_REF_OSCILLATOR_ENABLED ViBoolean

Yes R/W None

IVIPWRMETER_ATTR_REF_OSCILLATOR_FREQUENCY ViReal64 Yes R/W None

IVIPWRMETER_ATTR_REF_OSCILLATOR_POWER ViReal64 Yes R/W None

(Freq in 50 MHZ, power = 1 dBm so always specify power in dBm)

ViStatus IviPwrMeter_ConfigureRefOscillatorEnabled (ViSession vi,ViBoolean refOscillatorEnabled);

ViStatus IviPwrMeter_ConfigureRefOscillator (ViSession vi,ViReal64 refOscillatorFrequency,ViReal64 refOscillatorPower);

IviPwrMeterZeroChannel Extension Group


ViStatus IviPwrMeter_ZeroChannel (ViSession vi,ViConstString channel);



15. Compliance Working Group

15.1 General Meeting Info:Date of Meeting: November 17, 2000Location: Dallas, TXChairperson: Jeff Hulett substituting for Dean LawlerMinutes Prepared By: Jeff Hulett from minutes taken by Steve Greer

15.2 Meeting Attendees

Name E-Mail Phone

Gayle Matysek [email protected] 410.765.9754

Jeff Hulett [email protected] 858.578.6787Jochen Wolle [email protected] +49 89 41 29-13044

Noel Adorno [email protected] 512.683-5071Zulfigar Haider [email protected] 512.683.8374

Steve Greer [email protected] 970.679.3474Pat Johnson [email protected] (210) 828-5743

15.3 Working Group Summary Reviewed actions of last meeting Discussed charter for group Created a prototype charter Decided upon new chairperson if Dean is unable to serve


Item #1: Discussion of prior meetingThe prior meeting was discussed. Little could be remembered from the meeting and no meeting minutes were taken. It was decided to press forward at this meeting to generate a charter for the group. Steve Greer volunteered to take minutes on his laptop.

Item #2: Discussion of charter for groupWe spent some time discussing the charter and the reason for the group:Users requested a certification group. Somewhere it was changed to compliance. Users have been frustrated with the quality of drivers.

Question about whether conformance covers quality.

What guarantees does the foundation make about a driver?


Compliance is not always a major issue, but quality is.

Two levels of compliance1. complies with the spec.2. how the driver fits in the IVI technology.

What system tests?

Installation? Many combinations. Including the un-installationprocess.

Does the charter include driver quality or just compliance?

Compliance testing was discussed:

ASAM does compliance testing. There is a university in Germany which does the testing. Vendors are required to deliver complete source. Testing is done black box and white box manner. Testers also look at the source code for problems. 5-10K$ for product testing. Unclear whether vendors sell drivers or not.

We discussed the perceived value of drivers:

Users don't mind paying for drivers which have been certified. 100-200 depending on the complexity of instrument. Perhaps a percentage of the cost of the instrument. Vector Network Analyzer driver might cost $1000.

How does a standards body impose quality requirements on a product? Can assess documentation. There are many complex combinations which may be difficult to test all the combinations.

What does the logo mean? Who puts the stamp on a product? Several legal and procedural problems which the foundation has not covered.

One customer expected to pay for IVI driver, but not for a plug&play driver.

We then categorized compliance:

What is the scope of a compliance?

1. Syntactic and some semantic compliance with claimed capability. Interface correctness.a. All the required functions, attributes, values exist. It adheres to the compliance

rules specified in the inherent and class specs plus any exceptions. b. Proper data types are accepted and returned. Class defined attributes have the

same data types as specified by class.c. Appropriate error numbers and messages are returned.


d. Required extension groups based on attribute values supported and vice versa.e. Function parameters are ignored when another parameter in the same function has

a value that requires the other parameter to be ignored. For example, in the RF sig gen LF output amplitude is ignored when enable is false.

f. Attributes have proper R/W and channel based as specified.g. Driver should try not to set instrument to a bad state. (Maybe another character)

2. System related a. Installation process complete. Are all the components installed? Out of the box

experience.b. Installs all dependent components based on foundation rules.c. Supply to installer information about other required components or other

expectations about the system such as OS. d. Doesn't prevent another driver from working. Or other application. e. Interoperability sessions provide a good opportunity to test system related

problems.f. It operates well the shared components. It does not corrupt the config store

during installation or other times.

3. Qualitya. correctness - the instrument is programmed properly. b. performance - execution without error. May not be a compliance issue. c. robustnessd. The driver actually follows the behavior rules in the specs.

4. Interpretation of the standard

5. how much of the instrument specific capability is covered

Some other issues came up:

Is it necessary for a driver writer to expose source code to meet compliance criteria? There are some rules which require certain implementations.

Don't put more requirements in compliance criteria which are not in the other specs.

We are uncomfortable with the term compliance. A better name for the working group might be conformance. It might include certification.

We listed three fundamental questions related to conformance:

1. What is conformance?2. How do we measure conformance?3. How do we enforce conformance? Might be certification.


Decisions were made:

We need to ensure that conformance rules are legally enforceable. We need a mission (charter) statement. We need to create some guidelines on our

scope. We will generate a document which answers the above three questions.

Item #3: Discussion of draft charterWe came up with the following proposed draft charter:

Background:Users want drivers which work. They want to know what to expect from an IVI driver. Because of experiences with plug&play drivers, we wanted to learn from those experiences and do a better job communicating expectations. Users wanted better products and feltthat conformance testing could improve the quality.

Purpose:Define the limits the IVI foundation will support the quality of its products: architecture, shared components.

Scope:TBD

Item #4: Appointment of new chairperson

Jeff Hulett was appointed as a new chairperson, assuming Dean Lawler would not be able to serve.

Action items with due dates were assigned to accomplish the above tasks.

Who What By Status

Steve Send meeting minutes to Jeff Complete

Jeff Publish meeting minutes to group Next meeting

Complete

Group Work on revising charter Next meeting


16. Signal Interface Working Group

16.1 General Meeting Info:Date of Meeting: November 13, 2000Location: Dallas, TXChairperson: George Geathers substituting for Narayan RamachandranMinutes Prepared By: George Geathers

16.2 Meeting Attendees

Name Organization Voice Email AddressDave McKay Racal UK +44

1202872800 [email protected]

Dan Zimmerman USAF Kelly AFB 210 925 4401 X 3092

[email protected]

John Rosenwald Racal Instruments 210 699-6799 [email protected] Davis Boeing 314 234 2722 [email protected] Wegener Boeing 314 234 3801 [email protected] Oblad Agilent 707 577-3466 [email protected] Stern Agilent 707 577-1400 [email protected] Prescott DLO, England +44 1244288331

X [email protected]

Mel Petty BCO Inc. 978-663-2156 [email protected] Ion Neag TYX 703 264 1080 [email protected] Geathers TYX 703 264 1080 [email protected]


16.3.1 Report to IVI General Meeting Work Completed during IVI SIWG meeting:Completed review of Functional Specification: except for Digital testing and Bus Testing sections; Require Digital Working Group inputs: Request Bus Testing domain expertise and support:

Open Issues:Digital Testing; Support for specialized Digital Signal InterfaceCommunications Bus Testing; Support for specialized Bus Testing InterfaceInitiate dialog with domain experts prior to February IVI Foundation meeting

Request for Support and Assistance:Request use cases and functionality requirements from users, instrument vendors and system integrators on the following topics; Instrument Calibration, Timing and Synchronization, Software Signals, Path loss Compensation, and Composite or Complex Signals.









Action Items:Add Instrument calibration generic capabilities (handles scalars, gains & offsets)Add Self-test based on IVI Instrument self test definition.Rename Device Information – Resource Information/Capabilities on reference architecture diagram. Post Draft design document on IVI Foundation web site.

Plan for Next Meeting:Begin discussion of Draft Design Specification: Draft Design Specification on the web site for evaluation/review/comments.

16.4 Meeting Notes:George Geathers began the meeting, acting on behalf of Narayanan Ramachandran who was unable to attend. George asked the participants to introduction themselves. Additionally, he requested that first time attendees state their rationale for participation. Mel Petty from BCO Inc. responded. BCO was recently awarded a US Navy SBIR contract. The SBIR will focus on the requirements definition of a software interface and architecture similar to the Signal Interface (SI) and the IVI MSS.

16.4.1.1 Reviewed points/issues from SIWG meeting in August. Ion Neag gave slide presentation of basic SI reference architecture. He explained the

purpose of the SI and highlighted the signal based test paradigm. Dan Zimmerman asked about ID/ITA specific information for interchangeability.

Dan requested that components from the ABBET Architecture become a requirement within the SIWG. He would like to address all interchangeability issues.

Ion responded with goal of IVI in general - the standard to be developed must fit the main IVI targets, which are interfaces for instrument control. This position is consistent with the charter of the Signal Interface working group. The Signal Interface only addresses instrument interchangeability from the perspective of an IVI-MSS role component interface, not through system wide functionality. However, the overall ATS architecture is analyzed for its impact on signal interface.

Roger Oblad responded with his assessment of the degrees of interchangeability. Roger also mentioned the work load required to define/implement architecture vs. the interchangeability benefits.

Bob Stern responded. – (Using Maslow’s Hierarchy of Needs as an analogy) – Bob attempted to compare and contrast user needs for the different levels of interchangeability

John Prescott requested that all possible sources of interchangeability problems should be identified but not solved within the SI.

Mel Petty responded - Fixture information is part of the application/Test Routine – Including this component would be an attempt to capture too much information within the signal interface. Fixture information should not be part of this discussion.

Ion responded - The SI standard is not the proper place to identify ATS-level interchangeability problems. Within the resource description: we need to be concerned only with the information relevant for the operation of the Signal Interface; this information may be


retrieved at run-time from the driver or transferred during installation in a system-wide database; a translation may occur at this time.

16.4.1.2 Update reference architecture diagram: For clarification purposes;

Action Item - RENAME Device Information – Resource Information/Capabilities to add clarity and reduce any terminology confusion.

Ion continued with response - Resource capabilities unique to the specific instrument are identified in the reference architecture. This information is a subset of the total information in the Resource Information database. We are concerned with only the data required for the use of the signal interface by client applications.

The burden of translation from a Signal Interface-specific format to ATE-specific formats (proprietary or standardized) is low.

The SI separates the implementation of resource models & signal models from signal level control interface. It logically decouples signal interface definition from definition of Signal types (Models). This allows external standardization groups to work and define the reference signal model.

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

The SI borrows framework attributes and concepts from the ATLAS language, but it avoids the potential problems. (e.g. extensibility). Components, concepts of ATLAS 1995/2000, IEEE-1226 may be referenced in design specifications as a possible implementation standard.

16.4.1.3 Functional Specification Review Delay Digital Test Architecture discussion until next meeting! Establish dialog with

Eric Sacher & Teresa Lopes before the next meeting. Initiate communication and resolve via email.

Began discussions on Timing and Synchronization Functionality. Time Measurements, Event-based Events, Signal-based Events, and Time-based Events. Time and Sync system components will be based on corresponding ATLAS models. Hardware based Timing and Sync as well as software based Timing and Sync was addressed.

Reviewed support for Hierarchical Signal Components: Examples: Digital Parent/Child Components, Complex Signals, Aggregate and Composite Signals

Discussed support for simulation capability: Discussed functionality for instrument calibration: Instrument Calibration Data,

Internal Path Compensation, ATE System Calibration, and TPS Calibration/normalization.

Bob Stern identified the high accuracies and uncertainty associated with high fidelity RF (high frequency AC). He suggested that the Power Meter Class specification may be a good place to look for calibration functionality.


Ion made the point :The SC should provide calibration services specific to the instrument (e.g. obtain and store calibration data that changes with the instrument used in your system), required for interchangeability.

Roger Oblad suggested to first address signal path compensation, which should cover about 80% of use cases.

Several calibration approaches were identified, providing different levels of accuracy. Calibration Discussion:

Scenarios identified during meetings:o Calibration performed by instruments, which generate/sense calibrated datao Instrument calibration is not supported or insufficient; signal paths are

calibrated Path loss compensation: losses are computed by adding the

attenuations of all segments in the signal path; Calibrating complete signal paths;

Calibration is performed each time a path is created Calibration is performed once, for all possible paths

(corresponding to all possible switch connections); calibration data are stored separately, for each path

Ion’s proposal:o Provide a function that instructs the SC to perform instrument calibration; the

implementation, including data storage (is required) is SC-specific; some manual operator intervention may be required (this is also instrument-specific)

o Support the retrieval of instrument-specific calibration data from the SC (instrument-specific calibration data probably describe the signal paths including the instrument and the cables that connect it to the switching matrix)

Agilent suggested adding “RF & Microwave” section in Functional Spec or Design Spec.

Self test Discussion: Not clear what the functionality should be; alternatives:

o Only check connectivity and basic instrument operation (call self test on the instrument, if available)

o Complete verification of relevant instrument functionality; may require manual intervention

Implement self test as defined for IVI Drivers Alternative: Define semantics of self test


17. Legal Working Group

17.1 General Meeting Info:Date of Meeting: November 14, 2000Location: Dallas, TXChairperson: Kevin Borchert Minutes Prepared By: Dany Cheij

17.2 Meeting AttendeesName Company Phone

Bob Stern Agilent (707) 577-2886Dan Zimmerman DoD (210) 925-4401 x3092Dany Cheij NI (512) 683-5286Fred Bode Bode Enterprises (619) 297-1024Gayle Matysek Northrup Grumman (410) 765-9754George Geathers TYX (703) 264-1080John Rosenwald Racal (210) 699-6799Kevin Borchert Agilent (970) 679-3387Scott Rust NI (512) 683-5680

17.3 Record of DiscussionsThe group went through the restructuring proposal presentation:

Gayle Matysek brought up the point that there were a few things that did not make it into the final proposal. e.g., marketing costs paid by sponsors, etc.

Management overview: Should we have the user committee at the same level as the technical and marketing committee, or should it be at the technical subcommittee level

o Gayle’s feeling is that if it is at the higher level, it seems to have more oversight. It is not really a technical committee

o Fred summarized his feelings about the issue. Having at the higher level is a better depiction of what we are trying to have happen.

o Gayle is concerned that there is not that much user participation at this meeting

o Seems like everyone is leaning to having a user committee at the same level as the technical committee

o What will happen if user participation drops and we have a chair of the user committee and no committee?

Sponsor members in the BoD: explain the way the up to 10 members work Why does the president get a board seat automatically if they are external? Discussed

that if they are facilitators they do not get a seat but if we hire them as a full time president then they would.


Kevin went over the budget with the group. At this meeting, we will be about $3k short, so we need to adjust the budget accordingly.

We need to clarify exactly what we mean by marketing & PR? Are we talking about publicity or traditional product marketing:

o Communications and public relations, which are intended to add community awareness and increase user member participation as well additional vendor membership which will increase available products.

What happened to the idea of charging the host company a $5k meeting fee? We decided that it was not practical to work in. The host company will pay on a per person basis as well.

The meeting fees will be used to cover the cost of meeting rooms, lunches, and breaks.

Marketing costs will be split as follows:o Communications and Public Awareness are paid from the main budget. These

include the quarterly press releases, and any collateral that is available to all members.

o Additional marketing events will be paid by the members that are participating in the event.

o This issue will be brought up at the general membership meeting for a decision

The group then went through the restructuring proposal document page by page to identify issues.

Cover e-mail:o Reverse the order of priorities of the first sentence. Flip-flop form a

membership corporation, and establish liability protection. Main document:

o Page 3: flip-flop the order of “avoiding the danger” and “lowering the cost”o Page 3: Change instrument programming models; add test system developers

and users.o Find out if we can place a definition of some of the terms that are used:

Interoperability Interchangeability Consortium Shrinkwrap & clickwrap

o Page 5: Why is the necessity of using the term SIGs? It has a negative connotation to some people. For our purposes TWGs are probably enough.

o Page 5: Add the designation of the Users Committee in the 4th paragraph in D. Management Structure.

o Page 5: All committees can create sub committees.o Page 8: Add entry for Users Committee, with description to follow from

Gayleo Page 8: Can one person hold more than one office? We need to clarify what

the policy is.


o Page 8: 3 of the 5 BoD seats from the General membership are reserved for users but will roll over to other members from that category. Same applies for the other two seats. This rule applies for each year from there on out.

o Page9-10: Membership categories. Replace “targeted at companies” with “targeted at organizations”.

o Page 9-10: Replace SIG with TWG.o Page 11: Technical Participation (a) A vote per member organization basis.o Page 12: Scratch interoperability from the very first sentenceo Page 12: Craft a letter that can be used as a template for people to show their

commitment to being a chair of a committee.o Page 12: Add “while giving due regard to all viewpoints” to the Chairperson

of the Marketing Committee paragraph.o Page 13: Add a strict deadline about when the final review of this document

should be brought in. When are we going to incorporate? Force people to think about

12/6/00: Final comments in 12/15/00: Final legal documents are circulated 1/15/01: All comments should be received by the legal committee 1/22/01: Final legal documents are circulated 2/19/01: Deadline for receiving applications and fees 2/26/01: Identify and announce the board and incorporation at the

meeting in San Diego. ?/?/01: Public announcement

o Page 13, why should we finalize the names of the initial work groups? TWGs come and go so we shouldn’t put them in there.

o Should we consider a pro-rated membership from now on.


18. Promotions Working Group

18.1 General Meeting Info:Date of Meeting: November 14, 2000Location: Dallas, TXChairperson: Dany CheijMinutes Prepared By: Dany Cheij

18.2 Meeting Attendees:Name Company Phone

John Rosenwald Racal (210) 699-6799Jimmy Bigelow Anritsu (408) 778-2000Gayle Matysek Northrup Grumman (410) 765-9754Fred Bode Bode Enterprises (619) 297-1024Dany Cheij NI (512) 683-5286Kevin Borchert Agilent (970) 679-3387Scott Rust NI (512) 683-5680Jon Bellin NI (512) 683-5516


Dany went over a roadmap presentation for promotions events for the next year. We discussed possible dates for press releases and press events and possible collateral.

Jon Bellin brought up the general membership action item brought up in August that required that we define and IVI Foundation position on IVI MSS.

o Dany requested feedback from Promotions Committee meetings but only received response from NI

o Position was not forwarded to the rest of the groupo The issue is how to force the MSS subgroup to define what they areo Jon can sit through the MSS meeting on Friday and try to get the committee

to agree to what the charter. Should we come up with a schedule of when we will come up with positions on MSS

as well as the overall IVI architectureo Set a date around the February meeting where we would do a web cast or

presentation on what IVI is? Work backwards from there to come up with a schedule of

implementation Work on a presentation that can be used as part of the tutorial and then

come up with a brochure that is based on thato Schedule of completion of this task:

3/27/01: Web cast of IVI Foundation Position (What is IVI?)


3/2/01: Finalize presentation at IVI Foundation Meeting and get agreement from everyone about the content and messages in the presentation.

2/13/01: Third Draft of Presentation completed in order to be presented at IVI Meeting

1/30/01: Second Draft of Presentation 1/9/01: First Draft of Presentation completed 12/8/00 – 1/9/01: Consolidate information into the form of one

presentation 12/8/00: Deadline to receive content from Committee chairs 11/22/00: Dany to solicit (individually) from appropriate Committee

chairs positions and descriptions of the content of their specs.o What are some of the issues that need to be brought up and clarified in this

document What is IVI (IVI 101)? What is IVI MSS? What is IVI COM? What is Interchangeability and what are the different levels? What should the user expect in terms of useability of IVI? How do

you use IVI? What do the drivers look like? It almost seems that we need to break up a portion of the presentation

into three different views of IVI: IVI for system end user IVI for driver user (system integrator) IVI for driver programmer IVI for management

Discuss what different members’ (mostly webcast participants) views on all the topics discussed in the presentation

Everyone is on the same page as to what positions and views are

Better to disagree in private and figure out how to relay information to the outside world.

Group went through Productronica/Nepcon presentation and updated with new info and place holders for the purpose of serving as the basis of a web cast.


19. Users Working Group

19.1 General Meeting Info:Date of Meeting: November 14 & 16, 2000Location: Dallas, TXChairperson: Gayle MatysekMinutes Prepared By: Gayle Matysek

19.2 Meeting Attendees:

Name Company Phone Email

Jimmy Bigelow Anritsu 408-778-2000 [email protected]

Mel Petty BCO 978-663-2156 [email protected]

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

Don Davis Boeing 314-234-2722 [email protected]

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

John Prescott DLO, Ministry of Defence 44-1244-288331x7694 [email protected]

Jeremiah Cox National Instruments 512-683-0893 [email protected]

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

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

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

Clay Prior Sandia National Labs 505-845-3557 [email protected]

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


Tuesday November 14

1. The User Committee has been elevated from beneath the technical working group to report directly to the Board of Directors in the latest legal proposal. As a result, some new text is required defining the role of this group. Several newly paragraphs were reviewed.

2. Interest in ASAM was expressed by several users at the last meeting. Thus a briefing on the activity was provided by Fred Bode. Since the users for whom this was provided were not in attendance, we spent some time attempting to determine how we could best benefit from this activity.

Two areas were identified that may provide useful knowledge:















a. Dan Matthews is planning to implement a SCPI architecture driver into ASAM

This experience will provide some indication as to how well an IVI driver may fit into this architecture.

b. The certification process has been defined and implemented.

Identification of costs and the associated efforts will provide some data points or cost tradeoff information for the Compliance Working Group.

Fred was assigned an action to report back to the user working group on each of these issues at the next meeting.

3. Discussion on adding driver information to the web site led to no conclusion. It is difficult to post drivers for vendor specific devices on a standardization area without showing favoritism. Creating newsgroups was also considered. For the moment, the group was reminded that there are at least two list servers that aid in sending requests or questions to the IVI population, the IVI list server and the IVI User group list server.

4. A suggestion to hold the User group on a single day and open it to all interested parties (members and non-members of IVI) seemed to have appeal. Implementing such an idea at this moment is a bit premature. It may serve as the best method to acquire information on user experiences in the future.

5. A first cut at a definition of user requirements was introduced as a topic of discussion for Thursday.

Thursday November 16

1. Since we could not locate the video cable for the projector in the room, the review of the requirements chart was postponed. Email between meetings will be used to refine the document prior to the next meeting.

To fill the meeting time we held an informal discussion which ranged in topics.

2. I had several discussions during the week with Scott Rust, Jon Bellin and Noel Adorno from NI and John Harvey from Agilent. The Tuesday evening session was a bit of product demo and a bit of C interface demo, but triggered some thoughts on activities for the next meeting. Jon and Noel have promised to aid in configuring an installation package that we can load and run on the PCs of all interested Users. Both NI and Agilent are interested in bringing some instruments for a portability demo. I have requested to have it set up in the Track 3 room so that it will be available to users throughout the week to come a test drive/play with. All of the users in attendance at this session were very interested in this upcoming activity.

3. The promotions working group is taking strides to form an ‘IVI 101’ presentation. In general, the users agree that this tutorial would be of value.

4. There is confusion on web access. The password to access the private areas is not widely known. There appear to be no guidelines as to when an item is placed in the public area and when it is private. A procedure defining web layout needs to be generated and followed.

Users would like to have an area where questions can be posted with the resultant


answers. Something like the NI Knowledge base or a similar structure. It is anticipated that many IVI members (other than users) may need to assist in responding to the questions.

5. It was speculated that the attendance fee may be somewhat responsible for the low attendance at this meeting. Many users reinforced an effective $300 cap on their attendance. Fees in excess of this target may result in less participants at a given meeting.


20. VXIpnp Systems Alliance VISA Working Group

20.1 General Meeting Info:Date of Meeting: November 15, 2000Location: Dallas, TXChairperson: Dan MondrikMinutes Prepared By: Dany Cheij & Dan Mondrik

20.2 Meeting AttendeesName Company Phone Email

Dave Gladfelter Agilent (970) 679-5329 [email protected] Mueller Agilent (970) 679-3248 [email protected] Schink Agilent (970) 679-2196 [email protected] Bode Bode Enterprises (619) 297-1024 [email protected] Ryland Keithley (440) 498-3134 [email protected] Franklin Keithley (440) 542-8097 [email protected] Pike Mathworks (508) 647-7493 [email protected] Mondrik NI (512) 683-8849 [email protected] Cheij NI (512) 683-5286 [email protected] Winkeler NI (512) 683-5779 [email protected] Wolfe NI (512) 683-5466 [email protected] Kovner NI (512) 683-8567 [email protected] Zirojevic NI (512) 683-5374 [email protected] Wolle Rohde & Schwarz +44-89-4129-13044 [email protected]

schwarz.comClay Pryor Sandia Labs (505) 845-3557 [email protected] Malynur Tektronix (503) 627-5880 [email protected] Rule Tektronix (503) 627-4338 [email protected] Eriksson Vektrex (858) 458-5822 [email protected]


Dan M passed out copies of the latest draft version of the VPP-4.3.4 (VISA COM) specification.

Dan M walked through his agenda for the meeting. Not necessarily in this order.o COM Specification technical issueso Logistics – how to get the spec votedo Consistency issues between C and COM API’so Multi-vendor C interoperabilityo IVI I/O requirementso Demo of formatted I/O by Dave G





















Joe M mentioned that the discussion on IVI requirements for I/O might be related and asked where the appropriate forum for holding that meeting is. That discussion will occur in the IVI 3.1 working group on Thursday, November 16.

Dan M, Scott K, and Dave G went through all action items from the last meeting by phone conference and they think that they have resolved most of the issues already. At this meeting we will discuss any remaining issues.

Dan M mentioned the one issue that is still open regarding resource conflict resolution. NI will define this and add it to the specification.

Dave G went through a presentation that summarized the state of affairs. What are the goals, of the group, what has been completed so far and who has been involved in updating the specs.

o What are the next steps in the process: How do we vote on the completed spec? What are the IVI I/O requirements?

Dave G walked through a VB demo that he has written to show off a proof of concept of the VISA COM I/O.

o Showed how to communicate to an instrument connected via the serial port using the IMessage and I488FormattedIO interfaces

o Showed how to use the ReadString and WriteString methods and the OptionString property.

o The OptionString property needs a better description in the spec to make it clear that it contains all settable properties. Dan M and Dave G need to verify whether it excludes possibly conflicting properties.

o Joe M mentioned that it was weird that we are asking the user to concatenate a Chr(10) at the end of a WriteString

Dan M. mentioned that this is in line with the way users are used to sending the command when using either VISA or other I/O API’s.

One way to solve this is to define the default behavior based on what interface the instrument uses. e.g., for GPIB don’t automatically concatenate a Chr(10) and for Serial automatically concatenate a Chr (10).

It is possible to add a property to the IMessage interface that tells whether the interface natively supports an out-of-band EOI behavior (such as GPIB) or whether it explicitly requires a \n (such as Serial). The formatted I/O implementation could use this information to add the \n if needed. This topic needs more discussion.

There was a discussion about whether we should specify default interfaces. We will remove most co-classes from the IDL, so this will not be an issue. If a user co-creates a resource manager (global or vendor-specific), the default interface should be IResourceManager. For other interfaces, since this will not be in the spec, COM specifies that it will be IUnknown. IVI COM does not address this, so it probably does not need to be in the VISA COM spec either.

Daniel E brought up the point that in some of the commands, the optional parameters were actually interspersed in between required parameters. This might not be a problem for VB but it might cause problems in other environments such as C++ or JAVA.


o Keith W mentioned that according to the COM spec, you have to have the optional parameters at the end of the list.

o Dan M and the group will look into changing the spec to move all the optional parameters to the end. An issue was brought up about having the same interface for two types of resource managers (Specific Resource Manager and General Resource Manager)

o It is beneficial to have this because a vendor can give an SRM to a customer and when the GRM is available they can drop it in.

o It is also beneficial in the reverse case when a GRM is not behaving properly, and a vendor can provide the user with an SRM that can be dropped in without having to modify any code.

o The decision was made to keep the same interface for both RM’s. The shared components such as the GRM and Formatted I/O shall have a rule to

implement IProvideClassInfo2. The same rule shall apply for vendor specific SRM’s. For other interfaces the rule is that if the vendor is implementing Co-classes, they should implement IProvideClassInfo2. This will go in the spec.

The IGpibIntfc and IMessageIntfc interfaces will remain the same way they are in the spec except that there will be one property (DevStatusByte) moved from one to the other and one method (AssertTrigger) will be added to the IMessageIntfc interface.

Question from Jochen W about the GPIB spec including properties and methods related to HS488 which is not defined as part of 488 yet.

o Dave G mentioned that these show up in a previous spec and they assumed that these have been discussed previously.

o Dan M added that this is an optional functionality used to determine whether the controller supports HS 488.

o Jochen W said that he still had some concerns about that. There was a discussion about IVisaSession being used as a base class for many

classes. The concern was that it is strange to have the same methods performing the same functionality on each interface. The reason it had been done that way was to make common tasks easier for the user. Since it works and it favors the user, we will keep it that way.

Concerns about the overuse of the word “component” in the specs and whether that is confusing to readers. NI will look at each use in the spec and clarify.

Similar concerns about the use of the terms “Resource Class” vs. “Resource Component”. NI will look at each use in the spec and clarify.

Question about the why the status parameter is added to some functionso Because VB does not let you get to a return value if it is positive. This way

the status is explicitly given there and allows the user access to it.o NI will go through the spec and make sure this is included for each

appropriate VISA function. How does VB handle optional Out-only parameters

o All Out-only parameters should be In/Out except for the retval.o All status values will go to the end and become optional In/Out. We need to

make sure this will work correctly. Joe M had some comments about Formatted I/O that he didn’t pass along before


o (Pages B77 and B103) In IDL the help string on the ReadNumber method said that it will flush the buffer. It should be “optionally flush the buffer”.

o The WriteNumber method specifies a list of ASCII values of NR1/2/3 NR1=Integer, NR2=decimal somewhere, NR3=scientific notation Is NR2 needed? Many instruments use just NR1 or NR3.

o At the bottom of page 79. Rule 7.1.18 says that quotes should be added to the string. According to 488.2 rules, in addition to having enclosing quotes, each embedded quote should be doubled:

Example code snippet

Array[1] = “abc”Array[2] = “a\””Array[3] = “ \”\” ”Array[4] = “\”help\””Writelist (Array)

Bus monitor sees:”abc”,”a”””,” “””” ”,”””help”””””

Because of all the confusion that this might cause, rule 7.1.18 should be taken out of the spec. The burden is on the user to pass valid strings.

o The ReadList function should be able to read strings separated by any separator.

Example:

Session.WriteString “READ?;READ?”Session ReadList foo

12,56;78,89^NL

On ReadList the separator will now be a multi-character string and each separator is treated equally. The default separators would be a comma and a semicolon (“,;”). One way to implement this would be to use strtok to check each character of data against the separator string.

The type of the separator list is a VARIANT but must really be a BSTR. This is needed because default BSTR values don’t work well. If the type is not a BSTR, ReadList SHALL return an error.

o Rule 7.1.23 & Rule 7.1.24 termination character rules will be updated based on the discussion within the group (Dan M, Joe M, Scott K, and Dave G) – Dan M has specifics

o Why is there not a very simple Read function that reads from the instrument and throws it into a Variant?

Discussion about whether it is better to have type safe methods versus a generic method – type safe methods favor users.


No conclusion was reached and this will be thought off by the interested parties later on.

BREAK FOR 10-15 MINUTES

Joe M mentioned that according to 488.2 you cannot read indiscriminately. The burden is on the user. If a read operation occurs without a previous prompt, the user will have to wait for a timeout.

Dan M began discussion on how to proceed with trying to get this spec to a vote. Ron W described the process:

o Once VISA TWG has a complete spec that they are comfortable with.o We put it up on the Web and send out a notice to VXIplug&play alliance list

server (& IVI).o We have a 2 week period for review of spec and feedback to be returned to

the chair (Dan M).o Feedback is incorporated (usually it is only spelling and grammar)o After that, we have 2 weeks to have a vote on the spec. This will be done

through a FAX Vote (or e-mail)o Usually Ron W will have to contact some of the old members and try to find

people in order to obtain a quorum. (some contacts have left companies, etc..)o Once the vote is done, the document will be official and placed on the web.

Question was brought about why this is the VXIplug&play Alliance and not IVI since most likely this will only be used in IVI.

o Ron W answered that it seemed that there was work that needed to be done and the VISA working group was still active

o Since IVI also states in its charter that it builds on VXIplug&play, it could also make sense to have the spec in IVI

o Maybe what makes most sense is to eventually move to a world where the VISA spec gets officially moved into the IVI specifications.

Shared components have to be owned by IVI since they are incorporating.

Ron W will investigate what it would take logistically to transfer ownership of the VISA spec into IVI.

o Fred B mentioned that you have to keep in mind that this depends on what gets decided in IVI in terms of the I/O requirements for drivers.

Dan M discussed an issue that relates to both the C and COM API.o DisableEvent will guarantee that no future events are generated on that

session. It will not guarantee that no callbacks are currently executing. In other words, it does not synchronize with the callback thread. This allows the user to call DisableEvent from within the callback handler.

o UninstallHandler will guarantee that the specified handler is not being called when the function returns. This function SHALL synchronize with the callback thread. The user may not call UninstallHandler from within the callback handler.


o Making it consistent across the board (both COM and C) seems to be the most logical choice. We will add a RULE to this effect.

Shared Componentso Ron W can’t see why the need for IVI-owned shared components can’t be

separated from the existence of the VISA TWG. The VISA TWG can be one thing and the owning of the shared components can be discussed independent of the spec. i.e., there is no reason why the shared components cannot be owned by IVI separately.

o Jochen W said that what is important is to ensure vendor interoperability.o An issue was brought up about having a Shared Components Working Group

that will handle the nitty-gritty process of shared components. Should this be a separate TWG? Probably not, as this might introduce potential quality problems.

Should we bring up the issue of moving the VISA specs into the IVI Foundation at the General Membership meeting? Sounds like a good idea. Ron W will talk about this tomorrow and will also talk to the VXIplug&play alliance.

Question from Badri M about what exactly is the shared components in this context and what the I/O requirements are

o Known shared components as per the spec: Global Resource Manager Resource Conflict Resolution Manager

o Other components are identified by the spec as being vendor-specific. These would most likely be proprietary unless source code is contributed.

o Even for the components which we plan to have as shared, who will contribute their time and their code? This needs to be resolved.

Jochen W asked if there are any plans to standardize on the Passport model?o Dan M explained briefly what the Passport spec is, the problem it solves, and

the current state of affairs.o There is also an Agilent solution that solves the interoperability problem. It is

called TULIP.o The decision is to figure out what model to follow? ACTION ITEM:

Discussing the C interoperability issue at the next IVI meeting should be on the Agenda.

o Will tomorrow’s IVI I/O requirements discussion be a good forum to explore some of these issues?

Tomorrow we should be able to brainstorm on what some of the solutions for this problem are.

The discussion will happen in the IVI 3.1 meeting on Thursday morning, November 16, 2000.

Part of tomorrow’s discussion should be what do we discuss in 3 months (at the next meeting) and in which forum?

Motion to Adjourn. Adjourned

The next VISA TWG meeting will be held in conjunction with the next IVI meeting in San Diego sometime during the week of February 26 – March 2.



21. Digital Working Group

21.1 General Meeting Info:Date of Meeting: November 16-17, 2000Location: Dallas, TXChairperson: Teresa LopesMinutes Prepared By: Teresa Lopes

21.2 Meeting Attendees:Name E-Mail Phone



Documents

Meeting Minutes - Nov 2000 - IVI Foundationivifoundation.org/meetings/2000Nov/2000NovMeetingSummary.doc · Web viewUpdate the Word documents with hyperlinks based on the index produced