meeting minutes - june 2001 - ivi foundation€¦ · web viewadd signal types where parameters...

IVI FoundationMeeting Summaries

May 11-13, 2004Fort Collins, CO

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

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

3. IVI BOD MEETING MAY 13, 2004........................................................................................................... 3

4. TECHNICAL COMMITTEE.................................................................................................................... 11

5. DOT NET WORKING GROUP................................................................................................................17

6. IVI OPERATING PROCEDURES MEETING........................................................................................21

7. MARKETING COMMITTEE MEETING MINUTES.............................................................................23

8. IVI SHARED COMPONENTS MEETING...............................................................................................26

9. SIGNAL INTERFACE WORKING GROUP...........................................................................................28

10. LEGAL COMMITTEE MEETING MINUTES....................................................................................32

11. USER WORKING GROUP................................................................................................................... 34

12. Counter/Timer Working Group.................................................................................................................36

IVI Foundation Meeting Minutes 1 May 11-13, 2004

2. Meeting Attendees

Name Company Phone Email

Joe Mueller Agilent Technologies (970)679-3248 [email protected] Greer Agilent Technologies 970 679-3474 [email protected] Oblad Agilent Technologies 707-577-3466 [email protected] Jamison Agilent Technologies 970-679-5136 [email protected] Bode Bode Enterprises 619-297-1024 [email protected] Davis Boeing 314-234-2722 [email protected] Burke Boeing 314-233-4501 [email protected] Burnside National Instruments 512 683 5472 [email protected] Bellin National Instruments 512-683-5516 [email protected] Rust National Instruments 512 683 5680 [email protected] Fertitta Pacific MindWorks (858) 587-8876 [email protected] Granieri Phase Matrix 703-644-6015 [email protected] Neblett Raytheon Missile Sys 520-663-6845 [email protected] Wolle Rohde & Schwarz ++49 89 4129 13044 [email protected]

schwarz.comJohannes Ganzert Rohde & Schwarz -13356.02155 [email protected]

schwarz.comPatrick Watt SEI 314-553-4435 [email protected] Malynur Tektronix 503-627-5880 [email protected] Gaudette The MathWorks, Inc. 508-647-7759 [email protected] Neag TYX Corp. (703)264-1080 x132 [email protected]

IVI Foundation Meeting Minutes 2 May 11-13, 2004

mailto:[email protected]

3. IVI BoD Meeting May 13, 2004Called to order at: 10:54

3.1. Directors in attendance

Present Director CompanyJohn Rosenwald

X Kirk Fertitta Pacific MindWorksX Tom Gaudette The MATH Works

Jeff HulettDavid Huddleson

X Badri Malynur TektronixX Scott Rust National InstrumentsX Jochen Wolle Rohde & SwartzX Joe Mueller Agilent

John RylandTeresa Lopes (Teradyne)

Quorum is a majority of directors. 6/11 satisfies the requirement.

Review Agenda

3.2. Reminder of the IP Policy, Anti-trust, and Duty of Trust of Directors

The IVI Foundation has an IP policy that could require that some of your corporations’ IP be licensed to the IVI Foundation and its members at no cost. Every participant in the IVI meetings should be familiar with the obligations that participation in the standard incurs on your company.

Every member of the consortium is encouraged to familiarize themselves with legal requirements regarding anti-trust violations. Members need to be cautious and refrain from discussing markets and pricing.

Directors have a duty to the IVI Foundation. They are legally and ethically obligated to do the “right thing” for the IVI Foundation since they serve as a principal of that organization, if this conflicts with other responsibilities such as their duty to their employer, they need to take appropriate actions to resolve the conflict of interest.

3.3. Resolutions passed by electronic means since last meeting

At the behest of the marketing committee, the following resolution was moved and passed:

The BoD authorizes the marketing committee to spend up to an additional $1000 on the development of the IVI web site.

3.4. Review Minutes of Previous MeetingMinutes were read, no comments.

IVI Foundation Meeting Minutes 3 September 8-11, 2003

3.5. Action Items from Previous Meeting

Item Owner updateTransfer IVI trademark to IVI (from NI) Dany Cheij Trademark was completed and has been

confirmed by the USPTOMerge SCPI Foundation into IVI Joe Mueller &

Jochen WolleMerger document fully executed and at Foundation Office

Ron Wolfe execute the VXIplug&play merger with IVI

Dany Cheij Merger document fully executed and at Foundation Office

Acquire COM Drivers Session Factory license Fred Bode CompletedIssue Press Release regarding donated components

Dany Cheij Probably complete, will check with Dany.

Eliminate member sanctions from Operating Procedures draft

Joe Mueller Done

Evaluate legal impact of changing IP Policy Legal Committee

Was not done. Some discussion, scheduled upcoming weeks

Update VISA 3.0 spec with notation regarding IP rights

Dan Mondrik Done

Post VISA 3.0 to both IVI and VXIplug&play web sites

Fred Bode Done

Update official IVI Membership roster, including who is entitled to vote on specifications, to be completed every January

Fred Bode Done

Send message to IVI List Server regarding IVI position on hosting ATML

Joe Mueller Not done, ATML group decided to work with IEEE.


3.6. Financial Summary (Fred Bode)


IVI Foundation, Inc. 2515 Camino del Rio So Ste 340 San Diego, CA 92108 San Diego, CA 92 Ph 619 297-1210 – [email protected] IVI Net Worth to January 1 to March 31, 2004 Total Net Worth to January 1, 2004 $68,326.10 2004 1st Quarter Income 25,680.00 2004 1st Quarter Expense 29, 839.93 Net Profit (loss) for the Quarter < - 4,159.93 > IVI Net Worth March 31, 2004 $64,166.17


IVI FOUNDATIONProfit and Loss Statement Plus 2004 BudgetJanuary 1 - March 31 2004

1st Qt 2004 BudgetOrdinary Income/Epense

Income2003 Associate Dues $500.002003 General Dues2003 Orlando Mtg Revenue 180.002004 Associate Dues 0.00 $1,500.002004 General Dues 5,000.00 $17,000.002004 Sponsor Dues 20,000.00 $30,000.00

TOTAL INCOME 25,680.00 $48,500.00

Expense2003 Munich Mtg Fees 11,342.642004 Orlando Mtg Fees 4,740.34Bank Service Charges 102.00 $30.00Credit Card Fees 0.00 $150.00Director of Services 10,470.00 $36,000.00Legal Fees 1,109.98 $2,500.00Shipping Expense 0 $100.00Software 0Telephone 0 $1,000.00VXIpnp Web Fees 0.00Website 2074.97 $1,900.00

TOTAL EXPENSE 29,839.93 $41,680.00

Net Ordinary Income -4,159.93 $6,820.00

Microsoft Word Document

Microsoft Word Document


3.7. Report from Legal group (Scott Rust)Discussed the IP Policy. Agreed that we need to update it to simplify operations. Will have a meeting, inviting all members of the foundation along with corporate attorneys to discuss how to resolve. Conference call in mid to late July, meeting notice in next couple of weeks.

Will post legal documents on the web site so available to anyone that needs them.

3.8. Report on Licensing Common Components and Patents (Scott)

Legal committee believes there is no additional licensing needed of IP or shared components. Does anyone think otherwise?

No one knows of anything.

3.9. Report from Marketing group (Scott Rust)Reviewed the status of the web site. A few items still need attention, will be addressed in next few weeks.

Group created a new privacy policy and posted on the web site.

There will be an IVI Session at Autotestcon.

Discussed context for a press release. Has not moved forward. The group will not pursue any further.

Group decided to do a “messaging exercise” to help develop a message. Will plan on 4 hours at the next meeting to discuss face-face. Agilent will provide a process expert to help facilitate the discussion.

Dany will confirm that the promotions activities fully satisfy the IP license requirement from NI.

Tom Gaudette Moved that the foundation allot an additional $1000 for the development and maintenance of the web site. Scott Seconded.5:0:0

3.10. Report from Operating Procedures group (Joe Mueller)Group has completed its initial assignment and Joe will call for a vote in the next week or so.

3.11. Report from Users Group (Don Davis)The FAQ’s are now on the web under the users group section. Might want to put in a more prominent location on the web page.

Users group requests that marketing committee look at the best place to put the FAQ.

Users group would like to help coordinate between people that are developing drivers. Allow collaboration between driver users that need to create their own. Might be nice to have a bulletin board where discussion and sharing could take place. This could also facilitate the creation of new classes. Not clear how to move forward, the group will continue to work on this.

Fred will be creating an additional list server for implementation discussions along these lines.


3.12. New business

Adjourn 11:25 AM


4. Technical Committee

General Meeting Info:Date of Meeting: May 13th, 2004Location: ColoradoChairperson: Scott RustMinutes Prepared By:

4.1. Meeting Attendees:

Name Company

Joe Mueller Agilent Technologies

Roger Oblad Agilent Technologies

Stephen Greer Agilent Technologies

Fred Bode Bode Enterprises

Don Davis Boeing

Philip Burke Boeing

Glenn Burnside National Instruments

Jon Bellin National Instruments

Scott Rust National Instruments

Kirk Fertitta Pacific Mindworks

Bill Neblett Raytheon

Jochen Wolle Rohde & Schwarz

Johannes Ganzert Rohde & Schwarz

Patrick Watt SEI

Badri Malynur Tektronix

Thomas Gaudette The MathWorks, Inc.

Topics To Be Discussed:- Introductions- Review Agenda - Review Voting Members In Attendance- Approve minutes from the Jan 2004 Technical Committee Meeting- Review Action Items from Previous Meeting- Working Group Status

- Counter/Timer Working Group Charter- IviDMM Class Editorial Changes- IviScope Class Editorial Changes


- IVI – 3.13: Conformance Verification Specification- New Business- Discuss upcoming meetings- Adjourn

4.2. Voting Members In Attendance

Company Voting RepresentativeAgilent Technologies Joe Mueller

National Instruments Scott Rust

Pacific Mindworks Kirk Fertita

Rohde & Schwarz Jochen Wolle

Systems & Electronics Inc. Patrick Watt

Tektronix Badri Malynur

The Boeing Company Don Davis

The Mathworks Tom Gaudette

TYX Corp Ion Neag

There are 8 voting members in attendance, which satisfies the requirements for a quorum.

4.3. Approve minutes from the January 2004 Technical Committee Meeting

No issues were brought up with the minutes. The TC chairman accepted the minutes.

4.4. Action Items from Previous Meeting

Owner Action Item Status

Scott Rust Follow-up with Kirk on his action item from the September 2003 meeting. He was to have sent Noel a detailed description of the changes that would be required in the 3.1 and 3.2 specs in order to correct this behavior (Locking and Unlocking). The specs will then be changed according to our normal operating procedures.

Need to modify 3.2 spec. Need to agree on timeframe.

Scott Rust Run the appropriate processes to update the Shared Components Installer and IVI-3.1 specification to add the uninstaller to Add/Remove Programs.

In progress. Change Doc needs TC Vote.

Rengan Coordinate testing of MSXML 4.0 parser with shared components. Unknown. Scott to follow up with Rengan.

Joe Mueller Draft operating procedures around how to handle working groups that become dormant, how to disband them, how we restart them, and how we handle updates to the spec when there has been no work on the specs for a period of time.

To be handled as an enhancement to the Operating Proceedures after current


Owner Action Item Status

draft is voted and approved.

Scott Rust Post May meeting schedule by April 1st Complete

4.5. Modifying IVI 3.2 for correct IVI-COM Locking BehaviorKirk sent an email with a proposed change to the Lock and UnLock functions. Discussed whether we should make the change. It is a technical error. It is impossible to implement the specified behavior. Therefore, making this change will not affect the behavior of instrument drivers. Therefore, the group agreed that it would be an editorial change and requested that NI make the change to 3.2.

Agilent, Pacific Mindworks, and NI will review the editorial change.

4.6. Update the Shared Components Installer and IVI-3.1 specification to add the uninstaller to Add/Remove Programs

The group agreed that the change to the shared components is bug fix and does not represent a technical change. The Shared Component Management working group will follow the process for changes in the spirit of the original specification. That is, the change to the shared components does not require a vote of the Technical Committee and will be posted after the Shared Component management WG has preformed the appropriate reviews per their process.

Later the TC will hold the appropriate votes to update IVI 3.1.

4.7. Counter/Timer Working Group CharterThe Counter/Timer Working Group created the following charter:

IVI Counter/Timer Charter

Working Group to define the specification of the IVI class for counters. The IviCtr class conceptualizes a counter as an instrument that can measure frequency of a signal. The class also conceptualizes common extended functionality, to reflect that counters can often perform one or more of the following:

Measure periods Measure pulse widths Measure rise and fall times Measure intervals between two events on different channels Measure phase between two signals Measure duty cycle of a signal Measure ratio of frequencies of two signals Totalize events

Working group will also define the requirements of the microwave counter class to include the following:

CW microwave Pulsed microwave

Working group to determine if the microwave counter class shall be defined as an extension to the IviCtr class or a separate class specification.


Joe Mueller moved the TC Chairperson to call a resolution by electronic vote to initiate this new technical work. It may be impractical to do this prior to the Legal WG making progress on the IP Policy issue. The TC will conduct the vote when there is appropriate clarification of the IP Policy. Jochen Wolle seconded the motion. Motion Passed with 8 YES votes.

4.8. IviDMM Class Editorial Changes

Email from Zulfiqar to IVI List Server describing the editorial changes made to the IviDMM spec.

Greetings,

At the January 2004 IVI Foundation meeting, I was directed to make the following editorial changes to the IVIDmm Class Specification:

- Change the 'IsOverRange' parameter name to 'IsOver' for the Measurement.IsOverRange COM method.

- Replace the IviDmm IDL version 12 with version 13 in Appendix D.

The attached version of the specification contains the above changes. I am posting this to the IVI list the server so that it can be reviewed by members before the May IVI Foundation meeting.

Scott Rust: Since I will be unable to attend the May IVI Foundation meeting, please add this to your list of agenda items to discuss the technical committee meeting.

Fred Bode: I don't believe that these editorial changes will be controversial. Please upload this version to the IVI Foundation Website.

Best Regards, Zulfiqar Haider:

4.9. IviScope Class Editorial ChangesEmail from Srdan regarding IVIScope Editorial Change

Scott, Since I will not be attending the May IVI Foundation meeting, please add this topic to the agenda of the technical committee meeting: Kirk F. brought up the valid point of missing function prototype in the IviScope Class Specification.I recommend the following editorial change to the IviScope Class Specification: Add the function prototype for the IviScope_GetChannelName function to the Appendix C: ANSI C Include file; this function exists in the specification (section 4.3.11) but was omitted from the appendix by mistake.

The editorial change involves adding the text to the appendix as follows:


/* Utility */ ViStatus _VI_FUNC IviScope_GetChannelName (ViSession Vi, ViInt32 Index, ViInt32 NameBufferSize, ViChar Name[]); -Serge

The group agreed that the IviScope editorial change described above should be made.

4.10. IVI – 3.13: Conformance Verification SpecificationWe’ve created a Conformance Verification Specification that is on the verge of being voted. An observation was made that the Conformance Verification Specification contained only a few items

- Procedures for dealing with invalid claims that a driver is conformant- Rules for using the IVI Conformant logo and driver registration

There was a general discussion at the Operating Procedures meeting. Concern was expressed regarding having a spec named Conformance Verification Specification without having conformance testing rules. The group talked about two options:

1. Moving the relevant pieces into Operating Procedures and IVI 3.1.2. Change the name of the specification to something like IVI Logo Usage Requirements and Driver

Registration.

Concern was expressed that Jeff H. the Chairperson of the WG is not present to participate in the discussion.

The TC working group discussed that there are really 3 options:

1. Moving the relevant pieces into Operating Procedures and IVI 3.1.2. Change the name of the specification to something like IVI Logo Usage Requirements and Driver

Registration.3. Leave the specification alone.

Straw Poll:Option 1. - 4Option 2. - 7Option 3. – 3

Badri made a motion that we change the name of the specification to IVI Conformant Logo Usage Requirements and Driver Registration. Tom Gaudette seconded the motion. Badri withdrew his motion.

Kirk moved that we move the relevant pieces of the current specification into the Operating Procedures specification and IVI 3.1. Tom Gaudette seconded the motion. Kirk withdrew his motion

Kirk moved that the TC direct the Conformance WG to find new homes in the existing specs for the current content of Conformance Specification. Ion seconded the motion. 6 – YES, 2 – NO. the motion Passes.

4.11. New Business

Shared Components Management Working Group moved that the Global Resource Manager and the Basic Formatted I/O Shared Components be approved by the Technical Committee. 6 YES votes. The motion passes.

Rengan should put the updated versions of these shared components on the public web site.


4.12. Discuss upcoming meetings

The next meeting is scheduled for October 4th – 6th which The Mathworks will host in Boston.

Working Group Time

.NET ½ day

Technical Committee Meeting, BoD ½ day

EO Working Group ??

Signals Working Group ½ day

Users Committee ¼ day

Conformance Working Group ½ day

Legal Committee ¼ to ½ day

Operating Procedures 0 day

Marketing ½ day

Shared Components Management ¼ day

Digital Working Group ½ day

Network Analyzers 0 to 1 day

Counter/Timers ½ to 3/4 day

Totals

Group agreed to postpone Operating Procedures work regarding lifecycle of a WG until the January Meeting.

The preference of the group is to expand the number of days of the meeting instead of expanding the number of tracks.

The meeting following the October meeting is tentatively scheduled for the week of February 1 st . The meeting would start on a Tuesday. NI volunteered to host the meeting in Austin. We will confirm the date at the October meeting.

Adjourn


5. Dot NET Working Group

General Meeting Info:Date of Meeting: May 12, 2004Location: Ft. Collins, ColoradoChairperson: Jon BellinMinutes Prepared By: Jon Bellin and Glenn Burnside



Jon Bellin (chair) National Instruments (512)683-5516 [email protected] Burnside National Instruments (512)683-5472 [email protected] Ganzert Rohde & Schwarz (503)627-5823 [email protected] Fertitta Pacific Mindworks (858)558-4622 [email protected] Gaudette The Mathworks (508)647-7759 [email protected] Greer Agilent Technologies (970)679-3474 [email protected] Mueller Agilent Technologies (970)679-3248 [email protected] Neag TYX (703)264-1080 [email protected] Malynur Tektronix (503)627-5880 [email protected] Neblett Raytheon (970)663-6845 [email protected]

Topics To Be Discussed: Review the conference call results via the issues summary document. Review and discuss the prototypes that NI sent out. Discuss the universe of possible prototypes. Assign prototypes assignments to willing participants. Discuss the open issue regarding repeated capabilities (refer to summary document). Discuss namespaces.

5.2. Record of Discussions:

Review the conference call results via the issues summary documentWe reviewed the tracked changes in the summary document. There was no comment except for the following: We had added a new open issue called “Install assemblies to the GAC?” Steve pointed out that we had already answered this in the very first issue in the list. So we deleted that new open issue.

Review and discuss the prototypes that NI sent outGlenn walked through the source code for the prototypes.

Steve pointed out that the prototype for approach #4A does not have, in the specific driver, a method to get back to the class-compliant class. It was agreed that this would be feasible to add. The ability to get the class-compliant object and inherent capabilties object from the specific driver object would not be


available through casting but instead requires a method or property on the specific driver object that returns the class-compliant object.

NI presented its tentative conclusions. NI prefers #2. Everyone agreed to focus on #1 vs. #2.

Kirk expressed concern that using classes for the class-compliant or specific driver API would restrict the remoting choices that could be made by the creator of the API. There was not agreement about this in general. There was agreement that in approach #4 the remoting choices made by the IVI Foundation in the class API would restrict all the specific driver developers. There was agreement that in approach #2 and #4, the choices made in the first version of the specific driver would restrict subsequent versions.

Jon stated that NI does not care about this because NI thinks that driver developers won’t need to change this from one implememtation to another. Just use Marshal By Ref except when it is obvious that it should by By Value.

A factual issue arose as to whether a single app domain can reference two different versions of the same assembly. Concerns were expressed as to other versioning effects of approach #1.

There was confusion about the relationship between Kirk’s approach and NI’s approach #1. In Kirk’s approach, the IVI class compliant APIs would be presented as interfaces. The specific driver implementation class would have either a separate factory class or a public constructor on the class. In the instantiable class, the specific driver methods are not visible. You have to cast to an interface for the specific driver API. Instantaion under Kirk’s approaches are shown as #1 and #1.1 below.

IAgilent33220 a = new Agilent33220(); // #1 IAgilent33220 a = Agilent33220.Create(); // #1.1 (same as NI approach #1)

vs.

Agilent33220 a = new Agilent33220(); // #2 (same as NI approach #2)

We are assuming that in approach #2 specific driver developers are required to use explicit interface implementation in cases where the class method differs from the specific method such that the a specific driver user should see only the specific method. It is possible that a driver developer might make a mistake. In approach #1, the mistake is not possible. (No difference between #1 and #1.1 here).

Kirk argues that interfaces are for public APIs and that classes are for code reuse. Jon says this is not true in .NET today. Kirk pointed out that Java went through these discussions before and opted for interfaces.

The following are boiled-down significant differences between approaches #1 and #2. Driver Implementation Impact:The only possible significant difference for driver implementation and maintenance would be due to versioning the specific driver API. If there is a problem with having multiple versions of the same interface in a single domain, then #2 is better than #1 because under #2 you can update the class API and supply policy files declaring backwards compatibility. This is not possible when you have to change the interface name. If it is possible to version the interface assemblies and not change the interface names and still use both in the same app domain, there might still be problems stemming from this approach. We will investigate these issues. (No difference between #1 and #1.1 here).

User Experience:Instantiation:An advantage of #2 over #1.1 is that it is more conventional to assign the result of “new” to a class type, whereas users might not realize how they need to instantiate under #1.









The advantage of #2 over #1.1 is that with #1.1 users might try to use “new” and not realize they need to call a static Create method. Mixing Class vs. Specific Programming:#1 is better in that it provides the exact same type of programming between class and specific driver programming. Jon believes this is marginal because the difference is not very significant and because the difference is quite understandable given what the user is trying to do.

Specific Driver Versioning:#2 is better than #1 because (assuming you have to change interface names when versioning the interface) #1 requires maintenance of an ever-increase number of legacy interfaces for family drivers that rev frequently. With #2 you can use the policy file. On the other hand, it is often the case that, when you version an instrument driver, you are also incrementing the model number, and thus the interface name would automatically change.

#1 (assuming interface name changes) is better than #2 in that #1 forces the user to be specific about which interface they are using. In cases of family drivers that rev often, #2 is better because #1 can end up in a mess with users having lots of different interface versions in their program, and thus either having to know which version supports what, and or else having to update all their code on the delivery of each new interface. Kirk points out that this is an issue for COM and that he has a way to get around it and it that this is on his web site, but this applies only when the new functionality is for a different model and not more software features.

Intellisense:In order to get Intellisense right in cases where you want a flat implemenation, #2 requires the developer to create façade classes.

Remoting:#1 allows remote clients to work without having the full implementation, but only if the driver vendor packages the driver interfaces separately from the classes.

Discuss the universe of possible prototypes.We narrowed the choices to #1 and #2. Steve wants to add to prototypes #1A and #2A to include IIviDriver functionality, both in the driver implementation and the client code.

Assign prototypes assignments to willing participantsSee 1.4.3.

Discuss the open issue regarding repeated capabilities The issue here is whether the name and index properties be on the collection or on each individual object. (In IVI-COM it is on the collection, but it is more natural for it to be on each individual object.)Glenn pointed out that, given an instance of a repeated capability, you might want to get the name of the instance. You can do this if the repeated capability instance owns the name and index properties, but not if the collection owns them (unless you pass extra parameters along with the instance.) For example, if you are down in a subroutine that has only the instance and the subroutine wants to report an error, it might want to find out the name of the instance. This limitation in present in IVI-COM drivers. Steve says that no one has complained about this in IVI-COM drivers.Glenn also pointed out that the foreach construct in .NET allows you to iterate through a list of repeated capabilities without using an index. Kirk says he run into this several times where he has had to use a conventional loop rather than foreach.Steve says that he does not see why we shouldn’t add the name and index properties to the repeated capabaility instance, but he wonders about the case where the driver does not really have a name for the instance. It was agreed that this was only hypothetical.Steve and Glenn agreed that it would be good to add the name property to the repeated capability instance, but not add the index property (because the index is only in relation to the collection as a


whole). We will still have the GetName (given an index) method on the collection. We will also keep the Item property that takes a name or index and returns an instance.We will define an interface with the Name property and the instance will implement the interface. We will call this IIviRepeatedCapabilityIdentification. We will call the collection interface IiviRepeatedCapabilityCollection.We agreed to use the Select approach for IviFgen.

Discuss namespacesJon presented NI’s old proposal.We agreed that the namespace should start with “Ivi.” if an only if the component is owned by the IVI Foundation. (To be clear, we are using the .NET naming convention, where only the first letter is capitalized even on acronyms.)Steve noted that since we own the “Ivi.” hierarchy, we do not need verbose naming conventions to prevent conflicts. Therefore, the next name after “Ivi.” should be the name of the component. All agreed.We agreed that each driver must be scoped to a vendor-specific namespace, where the vendor name is at the beginning of the hierarchy.We will specify nothing else.

5.3. Topics to Make Progress on Before Next Meeting Details on exceptions. (Glenn) Configuration Store contents for .NET Assemblies. (Teresa??)

5.4. Action Items:Glenn: Verify whether a single app domain can reference multiple versions of an assembly. Send out result with code. (By June 7.)

Glenn: Investigate what effect versioning IVI defined interfaces without changing the interface name would have on user programs. (By June 7.)

All: Review the issues presented in Section 1.4.2. Particpate in conference calls to discuss them further. Form an opinion and be ready to vote at the next meeting.

Steve: Add to prototypes #1A and #2A to include IIviDriver functionality, both in the driver implementation and the client code. (By July 12.)

Steve: Fold the consensus decisions on Repeated Capabilities into your Style for Repeated Capabilities document. (By June 7.)

5.5. Conference Calls

Friday, June 18, 2004, 8:00am PDT. Discuss issues in Section 1.4.2 of this document. Discuss Glenn’s investigations regarding versioning Schedule second conference call


6. IVI Operating Procedures MeetingAttendance:

Scott RustJoe MuellerTom GaudetteSteve GreerFred BodeBadri MalynurKirk Fertitta

6.1. Discussion of synergies/alternatives with conformance work

The following could reasonably be moved to Operating Procedures:1. Way to register drivers2. Way to resolve disputes

Summary of Conformance spec contents:

Last sentence of 1.2 is dangerously misleading. Because it implies that the foundation assures that drivers are compliant with the specification.

This needs to be stricken

There is a title heading describing a verification process, but not really a process defined other than the statement that the test plan rests with the driver provider.

This should be stricken because the process is not really defined in the document, other than the example in the appendix.

The fact that it is the responsibility of the driver supplier to do testing needs to go someplace. (some question amongst this group).

An appendix that shows an example conformance test.

Do not need this.

Driver Registration requirement. This section establishes that drivers must be registered with the foundation to use the “IVI Conformant” logo.

We want to keep this. Probably does not belong in operating procedures.

Permissible uses of the IVI Conformant logo and an illustration showing the logo, note there is a need to point to the logo somehow.

Want to keep this.

Dispute Arbitration Process (needs some further discussion).

We want to keep this (possibly with changes). Feels like an operating procedures.

This group see’s two alternatives:A. Split the material between 3.1 (4,5) and Operating Procedures (6)B. Leave the material in this additional spec, suggest changing the name to describe the material that

remains: E.g., “IVI 3.13 Driver Registration and Logo Usage”


Regardless, need to get the official logo’s in place.

6.2. Action Items:

Action -- We will raise the question at the technical committee meeting this Thursday.

Action – Joe post the Meeting minutes template on the download page of the web site.

Action -- Group did a detailed review of draft 0.21, creating a draft 0.22. Group recommends this draft for approval by the BoD, even though previous action might result in an immediate addition.

Group also created a version 0.23 that includes a slightly wordsmithed version of the conformance dispute resolution process. We will propose this as the final spec if the meetings later this week request that we shift the document this way.


7. Marketing Committee Meeting Minutes

General Meeting Info:Date of Meeting: May 11, 2004Location: Fort Collins, ColoradoChairperson: Scott Rust, filling in for Dany CheijMinutes Prepared By:




Phillip Burke Boeing

Tanya Jamison Agilent Technologies


Scott Rust NI


Mike G Phase Matrix

Topics To Be Discussed: Review Action Items from last meeting – Scott Rust Review status of Web site – Jeff Hulett Other business

o Plans on AutoTestCon – Fred Bodeo Other plans for promotions – Joe Mueller


Review Action Items from Last Meeting

Owner Item DateDany Call marketing committee phone meeting at the end of February to

review Web site status – by February 13thDone

Fred Remind Jeff H. about sending privacy policy to Fred and/or Dany to forward to Foundation attorney – by January 30th

Done – Created a new (5 page) draft.

Dave Ptacek

Complete FAQ document and notify marketing committee once it is done for publishing on the Web site – After next IVI Foundation meeting

Status is unknown – Dany Cheij to determine status. Should be brought up a User Meeting as well.

Dany, Check with PR groups about helping disseminate PR content – by Done. Once release is up on


Joe, Jochen

January 30th Website, PR groups will disseminate to their contacts

Dany Lead effort to publish PR – by February 13th Done. Up on new website.

With regard to the vendor companies posting IVI Foundation press releases. Many felt it was not newsworthy enough to disseminate via their normal editorial contacts and felt it was enough to place it on the IVI Foundation Web Site.

Want agreement from NI that this appropriate and fulfills the license agreement on the shared components and patents.

Review status of Web siteThe web site is up. Few items still need to be completed or looked at

Registering for meetings and viewing registrations (Fred – by June) Editing working group area via FrontPage (Fred – by June) Driver registration (Dany – work on after next meeting) Template for meeting minutes needs to be placed more prominently (Joe – by Aug) Need to post the Conformant logo (Jeff H – by June) Make new working group page for Counter/Timer (Fred – by July)

Group worked with attorneys to generate a new Privacy Policy and it is posted on the web site. Invoice is in the mail.

Thanks goes to Jeff H (Vektrex) for all the work in bringing the new web site online.

Other Business

7.3. Plans on AutoTestCon – Fred BodeHave an IVI session at ATC. Have 3 papers – Vektrex, TYX, and someone else. None from users. There are potentially other papers that could be included in the session. Don’t know if they are user or vendor submissions. The original idea was for this to be primarily user papers. This does not look like it is going to happen.

7.4. Other Plans for Promotions – Joe MuellerLast May we had discussed that we would try to get contacts for a press release. The primary contacts were to have been Bill Birurakis and other users. Don’t believe anything has happened.

The group agreed that we would not pursue this any further.

Had a discussion of whether the group could come up with better messages for the foundation to promote. A few ideas were discussed as how to do so. Tanya suggested that we run a messaging exercise that would help the group arrive at a value statement that the group can get behind.

Agilent agreed to find someone within Agilent to facilitate a messaging exercise at the next meeting. Fred would be the referee. We believe that we would need approximately 4 hours at the next meeting.

7.5. Action Items: Dany Cheij – Determine status of Dave Ptacek’s FAQ. Dany Cheij – Confirm that the appropriate press coverage and appropriate acknowledgement has

occurred as per the license agreement on the shared components and patents. Dany, Joe, Fred, Jeff – Complete their web site action items. Agilent agreed to find someone within Agilent to facilitate a messaging exercise at the next meeting.

Fred would be the referee. We believe that we would need approximately 4 hours at the next meeting


8. IVI Shared Components Meeting

General Meeting Info:Date of Meeting: May 12, 2004Location: Holiday Inn Hotel, Ft. Collins, COChairperson: Stephen Greer for Rengan RajendranMinutes Prepared By: Stephen Greer


Name Company Phone EmailJon Bellin NI 512-683-5516 [email protected] Burnside NI 512-683-5472 [email protected] Greer Agilent 970-679-3474 [email protected] Gaudette The MathWorks, Inc. 508-647-7759 [email protected] Malynur Tektronix 503-627-5880 [email protected] Fertitta Pacific MindWorks (858) 587-8876 [email protected] Oblad Agilent Technologies 707-577-3466 [email protected] Mueller Agilent Technologies (970)679-3248 [email protected] Rust NI 512-683-5680 [email protected]

Topics To Be Discussed: Review actions items from January meeting VISA-COM shared components review IVI Session Factory Next release?

8.2. Action items from January meeting

InstallerNoel wrote and posted a change document for IVI-3.1. TC needs to vote on the changes followed by a BoD vote.

Zulifiqar has made the change and is ready to have it reviewed. He will wait until he receives a new session factory and then send it to Rengan who will distribute to a review committee. He will follow the established review process.

Authenticating PIAsKirk did not find the time complete the paperwork. He promises to do it real soon.

8.3. VISA-COM Shared Components ReviewAgilent completed a review of the GRM and found it acceptable. TC chair needs to hold a vote on the GRM and Formatted IO components. The Shared Components Review committee will make a motion at the TC meeting on May 13 that the TC approves these components.

The primary interop assembly for the Visa COM type library must also be approved. Jon queried Dan Mondrik about whether the Visa COM PIA was acceptable.


Kirk is concerned the VISA vendors are not distributing both components. Several Visa vendors said both components will be distributed with their next release of their products after May.

8.4. IVI Session FactoryGlenn discovered that calling CoInitialize with apartment threading caused the session factory to create an object where QI always fails. The optimum solution is to add the oleautomation attribute to the IIviSessionFactory interface.

Steve noticed the constructor is calling CoInitialize, though the session factory never calls CoUninitialize. Doing so creates a memory leak. The proposed solution is to remove this call.

Once David McKay has made these changes, he should send the revised component to Rengan for review. This committee feels the changes are clearly a bug fix and will not adversely affect any existing applications.

8.5. Next release of Shared ComponentsA new version of the installer which includes the revised session factory and adds an entry to the Add/Remove programs should be available in July.

8.6. Action Items:Steve Greer – make a motion to Technical Committee on behalf of this committee regarding the acceptance of the VISA-COM shared components.David McKay – send revised session factory to Rengan.Zulfiqar Haider – send revised installer to Rengan.Kirk Fertitta – complete paperwork for authenticating PIAs.




9. Signal Interface Working Group

General Meeting Info:Date of Meeting: May 11, 2004Location: Fort Collins, COChairperson: Ion NeagMinutes Prepared By: Ion Neag



Bill Neblett Raytheon

Patrick Watt SEI


Johannes Ganzert Rhode&Schwarz

Thomas Gaudette Mathworks

Roger Oblad Agilent

Ion Neag TYX

9.2. Topics To Be Discussed:

Topics to be discussed1. Overview2. Status3. Action Items from last meeting4. Demonstration: prototype signal driver for Teradyne M9 using the prototype IVI Driver5. New design issue: Signal Type Specifications6. Review structure of the specification


Overview and status

Changes since last meeting: TYX prototyped Signal Driver implementing the digital parallel signals, using the Teradyne M9

IVI Driver in simulation mode. IDL changes: IIviSigSensor has new property “MeasurementError”; IviSigCapSignal object has

new “Members” property, pointer to IIviSigCapMembers collection Spec changes: new section “Signal Type Definitions”, contains Analog and Digital signal types

Remaining tasks: Finalize & review spec

Action Items from last meeting

26

1. Change IDL and state diagram for Sensor to support retrieval of measurement errors

This was accomplished by adding a property. Alternative solutions: Return string with Description (implemented in IDL) Return Object with Number, Description, etc. Return HRESULT and set COM Error Object

Opinions from the group: It is desirable to have both a number and a string. The number enables decisions to be made

programmatically. The spec can not define error numbers for various types of measurement errors, since these tend

to be signal-type-specific. Driver developers can define error numbers. This is consistent with the approach from IVI 3.1 and 3.2, which allow driver-specific error codes.

Consensus decision: return both a number and an error code. Alternatives: Formatted string Separate properties One property, returns an object with two properties One property, returns COM error object. One property. Reading it sets a COM error object.

Action Item: Ion to investigate alternatives and propose solution.

2. Change design of Signal Capability Description, enabling a signal to be member in multiple groups

Ion presented the change. No observations from the group.

3. Spec updates

TBD

Action Item: Ion to incorporate updates when revising spec text.

Demonstration - Digital Signal Driver

Digital Signals

Ion presents: design requirements; the design approach based on the IviDigital API; results of comparative analysis of terminology in IviDigital, IEEE 716, IEEE P1641; design of digital signals.

Discussion on open issues.

1. Repetitive generation of dynamic pattern

Repetition can be specified via “repetitions” parameter (integer) or “max_time” parameter (floating-point). The current design uses “repetitions”.

Use case (Patrick): continuous generation of signals.

Opinions from the group: Could be specifies as “repetitions” = +Inf. Integer COM data types do not support Inf. Changing the data type of “repetitions” to double is not

a good solution.

27

Consensus decision: use “max_time” instead of “repetitions”. Use +Inf to indicate continuous repetition of dynamic signal. Continuous means until Setup or Reset are called.

Action Item: Ion to update digital signal design.

2. Not supported now: SENSE_WINDOW

This parameter exists in ATLAS, but not in IviDigital or P1641. Not clear of it is supported by instruments and if it is used in applications.

No opinion from participants.

Action Item: Ion to consult with Teresa and ask guidance from ATLAS experts.

3. Representation of digital levelsThe following alternatives were identified for representing parameters of STATIC_DIGITAL and DYNAMIC_DIGITAL:

1. SAFEARRAY(SHORT) - current design2. LONG - similar to IviDigital; does not support “Not Available” and “TriState”3. String - similar to P16414. VARIANT that may contain either SAFEARRAY(SHORT) or DOUBLE - IVI Stye Guide

advises to avoid this technique5. Add signal types where parameters are DOUBLE; possible names: *_DIGITAL_WORD

Consensus favors alternative 5.

Action Item: Ion to add signal types

4. Detection of HI-Z by sensor signals

This capability exists in ATLAS, but not in IviDigital or P1641. Not clear of it is supported by instruments and if it is used in applications.

No opinion from participants.

Action Item: Ion to consult with Teresa and ask guidance from ATLAS experts.

5. Use of “repetitions” parameter

In the current design, it is used only for sources, not for sensors (reading several times in the same data structure does not serve any purpose); for consistency, it is not used for groups (because they may have sensor members).

Use case (Patrick): continuous generation, measurement and comparison; only words with errors are recorder.

Suggestion (Tom): add parameters that return ATLAS-style error information.

Consensus decision: Enable “repetition” parameter for sensors. The “data” and “result” arrays are overwritten in each repetition. Comparison errors are recorded and may be retrieved by clients via specialized parameters. These parameters may contain the digital words that have errors, the index of these words in the sequence and possibly a count for the total number of errors.

Action Item: Ion to implement design changes.

Analog Signals

28

Ion presents: design requirements; the design approach based on the IEEE P1641 and IEEE 716; design of analog signals; open issues.

Suggestion (Tom): look at IEEE 181-2003 for definitions of parameters that characterize waveform quality (ex. pulses).

Action Item: Ion to look at IEEE 181-2003.

Action Item: Ion to ask guidance from ATLAS experts on open issues.

29

10. Legal Committee Meeting Minutes

General Meeting Info:Date of Meeting: May 11, 2004Location: Fort Collins, ColoradoChairperson: Scott Rust, filling in for Dany CheijMinutes Prepared By: Scott Rust





Tanya Jamison Agilent Technologies


Scott Rust NI


Mike G Phase Matrix

10.2. Topics To Be Discussed: Review Action Items from last meeting – Scott Rust Discuss changes to IP Policy Storage of all legal documents – Joe Mueller


Review Action Items from last meetingThe following is the status of the action items from the last meeting:

Dany Cheij: Verify that NI licensed the IVI trademark to the IVI Foundation DONE Joe Mueller and Jochen Wolle: Send merger documents for internal legal review and sign SCPI merger

document and send to Joe Mueller to sign DONE Dany Cheij: Ask Ron Wolfe to sign VXIp&p merger document and send to Joe Mueller to sign DONE Fred Bode: Ask John Rosenwald to sign the correct license agreement to license the “IVI COM Session

Factory, version 1.0 (including bug fixes up to but not including 1.1)” and send to Joe Mueller for signature DONE

Joe Mueller: Propose the following resolution to the board of directors: DONE

“The IVI Board of Directors resolves to grant all members of the IVI Foundation licenses to use the IVI Shared Components, including:

IVI Configuration Server Version 1.3 (including bug fixes up to but not including 1.4)

IVI Foundation, Inc. Meeting Minutes 30 May 12 – 15, 200330

VISA-COM I/O Basic Formatted I/O Component version 2.4 (including bug fixes up to but not including 2.5)

IVI Event Server version 1.1 (including bug fixes up to but not including 1.2) IVI C Shared Components Version 1.0 (including bug fixes up to but not including 1.1) IVI Floating Point Services Shared Components Version 1.0 (including bug fixes up to but not

including 1.1) IVI Shared Components Installer Version 1.1 (including bug fixes up to but not including 1.2) IVI Shared Component Clean-up Utility Version 1.0 (including bug fixes up to but not including

1.1) IVI Configuration Server C API Version 1.0 (including bug fixes up to but not including 1.1) VISA-COM I/O Global Resource Manager and Conflict Manager Version 3.0 (including bug

fixes up to but not including 3.1) US Patent rights for 5,963,726; 6,223,134; 6,405,145; 6,418,392; and 6,085,156”

Discuss changes to IP PolicyBelieve that we agreed at the last meeting that our current IP Policy does not work for the foundation. That is, it requires voting members to make broader guarantees than they can reasonably make. We believe that we need to create a new IP Policy

We believe that we need to get together with corporate attorneys to determine the appropriate IVI IP Policy. Specifically to address the concern that members are to declare their coroporate IP interests before voting on technical matters.

Fred – Arrange for telephone conference to resolve and make recommendations on the IP Issues. The conference should be in middle to late July. Meeting notice should be sent out in the next two weeks.

10.4. Action Items: Joe & Fred – Create a Legal Documents on the web site, post all legal documents in Joe’s position, and

send a message to Fred that documents other docs that should be on the web site. Fred to post the remaining documents.

Fred – Arrange for telephone conference to resolve and make recommendations on the IP Issues. The conference should be in middle to late July. Meeting notice should be sent out in the next two weeks. Notice should be sent to the list server.


11. User Working Group

General Meeting Info:Date of Meeting: May 12, 2004Location: Fort Collins, CO Holiday Inn Prospect Rd.Chairperson: Don DavisMinutes Prepared By: Don Davis

Meeting Attendees:

Name Company Emailx Don Davis Boeing [email protected] Fred Bode IVI [email protected] Bill Neblett Raytheon [email protected] Patrick Watt SEI [email protected] Phillip Burke Boeing [email protected] Jochen Wolle Rohde & Schwarz [email protected] Mike Granieri Phase Matrix [email protected] Tanya Jamison Agilent [email protected] Scott Rust National Instruments [email protected]

Topics To Be Discussed:1) Survey of users and developers:

a) Who are users of IVI drivers?i) Benefits to IVI from Users Group is maintaining a list of issues and feedback for developers.

b) Examples of use?c) Who are developers trying to develop “IVI – Like” drivers without class specifications?d) Is “IVI – Like” example code available?

2) Can a “fast track” process for generating “IVI – Like” drivers be developed?a) Would such a process be of benefit?b) Does the general membership support such an effort?c) What are essential elements or guidelines for “fast track” process?

Record of Discussions:Open discussions were held on collecting feedback on use of IVI drivers. The general intent is to actively seek information on users of IVI and how they are using IVI. A suggestion was made to add a feedback section on the web page independent of “contact us”. Fred Bode took the action to look into creation of the IVI web page feedback.1 Don Davis will support by helping generate a statement for the page.2 Also, Don Davis will send a notice to the IVI Users Group requesting input.3

A proposal was made to create a forum for developers to collaborate on driver development. The intent of the forum is to 1) provide developers an opportunity to share development efforts if they choose to do so, 2) possibly create an archive of non compliant drivers for future reference, 3) capture documentation and driver source for possible use in faster development of new class drivers. Several suggestions were made that might help in reaching one or more of these goals. It was suggested that a new list server be created to serve developers wanting


to collaborate on driver development. Fred Bode took the action to start the list server. 4 Another suggestion was to generate a bulletin board for exchange of information. Fred also took the action to investigate this possibility. 5

Technical Committee feedbackJoe Mueller suggested that the Users Group try to follow previously established terminology when discussing types of driver development and levels of compliance. Joe suggested a 2002 ATC paper as a reference for correct terminology.

Actions1. Investigate addition of an IVI web page Feedback tab. (Fred Bode Action)2. A statement requesting inputs is needed for the web page Feedback capability. (Don Davis Action)3. A message is needed to the IVI Users membership to request Feedback. (Don Davis Action)4. A request was made to add an additional List Server for developers wanting to collaborate on driver

development. (Fred Bode Action)5. Investigate adding a Bulliten Board capability to the web site. (Fred Bode Action)







12. Counter/Timer Working GroupDate of Meeting: May 12, 2004Location: Fort Collins, COChairpersons: Phillip Burke/Pat WattsMinutes Prepared by: Phillip Burke

Meeting Attendees:

Name Company Location Phone EmailPhillip Burke Boeing St. Louis, MO 314.233.4501 [email protected]

Patrick Watt SEI St. Louis, MO 314.553.4435 [email protected]

Scott Rust NI Austin, TX 512.683.5680 [email protected]

Mike Granieri Phase Matrix Springfield, VA [email protected]

Roger Oblad Agilent Santa Rosa, CA 707.577.3460 [email protected]

Jochen Wolle Rohde and Shwarz Munich, Germany ++49 87 412913044 [email protected]

Don Davis Boeing St. Louis, MO 314.234.2722 [email protected]

Topics To Be Discussed:

Review previous counter/timer discussions Define different classes of counters Create a working group charter General discussion of issues Generate Action Items

Record of Discussions:The meeting was co-chaired by Boeing and SEI.

The attendees introduced themselves.

We started with a discussion of the problems from the last attempt to create a counter timer specification. Some of the issues were:

1. Defining counter/timer measurements2. How to handle triggers and gating3. Routing counters to counters4. Defining the many subclasses - freq time interval, cw, radar, etc.

Scott Rust obtained and distributed a copy of the specification that was created in 1999 (rev 0.3).

We defined the different classes of counters and the fundamental measurements of each class.

Fundamental measurement types:Classes of counters

1. Frequency Counter (single channel)


a. Frequency2. Universal Counter (single channel)

a. Periodb. Totalizec. Duty Cycled. Pulse Width

3. Universal Counter (dual channel)a. Frequency Ratiob. Phasec. Time Intervald. Rise Timee. Fall Time

4. Microwave Countersa. CWb. Pulse

5. Frequency/modulation time analyzersa. MTAb. Frequency vs. time analyzer

We also spent considerable time discussing appropriate wording for a charter. The following Charter was created:

IVI Counter/Timer CharterWorking Group to define the specification of the IVI class for counters. The IviCtr class conceptualizes a counter as an instrument that can measure frequency of a signal. The class also conceptualizes common extended functionality, to reflect that counters can often perform one or more of the following:

Measure periods Measure pulse widths Measure rise and fall times Measure intervals between two events on different channels Measure phase between two signals Measure duty cycle of a signal Measure ratio of frequencies of two signals Totalize events

Working group will also define the requirements of the microwave counter class to include the following: CW microwave Pulsed microwave

Working group to determine if the microwave counter class shall be defined as an extension to the IviCtr class or a separate class specification.

We selected representative vendors and models of C/Ts that should be used as references while developing the IviCtr class specification:

1. Agilenta. 1420 (universal)b. 5313x (universal)c. 5314x (microwave)d. 5315x (CW/ microwave)e. 53181A (RF counter)

2. Phase Matrix (all microwave)a. 25B/28B (CW frequency counter)b. 545B/548B (CW frequency counter)c. 585C/588C (Pulse frequency counter)d. 595C/598C (Pulse frequency counter)


e. 1230A/1231A (VXI pulse frequency counter)3. Fluke

a. PM668x (universal)4. Racal

a. 2461(universal)

Finally we spent time creating action items and assigning responsibilities.

Action Items:1. Create C/T section on IVI web site

a. Fred2. Analyze each C/T functions using high-level block diagrams, waveform diagrams, I/O, etc.

a. 1 July 2004 Boeing/SEI to develop an example and put on IVI web for reviewb. 1 Aug 2004 Working group to provide feedback on examplec. 15 Sept 2004 Boeing/SEI to develop remainder of core functions based on feedback

3. Look at ATLAS constructs for C/Tsa. Boeing/SEI to review (provide reference)

4. Look at scpi hierarchy instrument model for C/Ts5. Define terminology of C/T functions

a. Boeing/SEI to start a glossary6. Make a motion and vote on C/T Charter at technical meeting

a. 13 May 2004 Phillip (Boeing)7. Distribute Jan 99 C/T spec to group members

a. Boeing to place on web site and inform group members8. Conceptualize capability groups of a C/T

a. SEI to make first cut at defining fundamental groups vs. extension groups9. Post C/T minutes on IVI web

a. Boeing to place on web site and inform group members

The meeting was adjourned.
