Meeting Minutes - February 2006 - IVI Foundation · Web view(scope) 0 (at least start) PMW Phone...

IVI FoundationMeeting Summaries

Oct 10-12, 2006Boston, MA

IVI Foundation Meeting Minutes 1 October 4-6, 2005

Table of ContentsTABLE OF CONTENTS....................................................................................................................... 2

CHAPTER 1 MEETING ATTENDEES................................................................................................3

CHAPTER 2 IVI BOD MEETING OCTOBER 12, 2006.....................................................................4

CHAPTER 3 TECHNICAL COMMITTEE........................................................................................10

CHAPTER 4 AC POWER SOURCE WORKING GROUP...............................................................20

CHAPTER 5 IVI.NET MEETING......................................................................................................24

CHAPTER 6 VISA............................................................................................................................... 32

CHAPTER 7 MARKETING COMMITTEE MEETING MINUTES................................................41

CHAPTER 8 COUNTER/TIMER WORKING GROUP....................................................................46

CHAPTER 9 64 BIT OS AND DATA TYPE SUPPORT....................................................................51

Chapter 10 IVI Signal Working Group Meeting Minutes........................................................................61


Chapter 1 Meeting AttendeesNAME COMPANY EMAIL/PHONE PHONEJoe Mueller Agilent [email protected] 970-679-3248John Harvey Agilent [email protected] H. Burke Boeing [email protected] 314-233-4501

Kevin LamCalifornia Instruments [email protected] 858-677-9040

Don Essner DRS-SSI [email protected] 314-553-4750

Omar VitobaldiElgar Electronics [email protected] 858-458-0257

John RylandKeithley Instruments [email protected] 440-248-6168

Jon BellinNational Instruments [email protected] 512-683-5516

Scott RustNational Instruments [email protected] 512-683-5680

Dan MondrikNational Instruments [email protected] 512-683-8849

Dirk Schmischke

On hotel list only

Jochen WolleRohde & Schwarz [email protected]

49-89-4129-13055

Johannes Ganzert

Rohde & Schwarz

[email protected]

49-89-4129-13405

Murali K. M. Sreedhara

Tektronix Engineering Dev. Pvt. Ltd. [email protected] 80-22105535

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

Rob PurserThe Mathworks [email protected] 508-647-7131

Tom GaudetteThe Mathworks [email protected] 508-647-7759

Ion Neag Self [email protected] 703-264-1080Christophe Grard

TYX Corp/EADS [email protected]

Hugues Valois Pacific Mindworks 858-587-8876

Hugh R Smith Raytheon [email protected] 520-663-7811


Chapter 2 IVI BoD Meeting October 12, 2006Called to order at: 11:15 October 12, 2006

Directors in attendance

Present Director CompanyX Joe Mueller Agilent TechnologiesX John Ryland (leaving

early)Keithley Instruments

X Scott Rust National InstrumentsX Jochen Wolle Rohde & Schwarz

Badri Malynur TektronixX Kirk Fertitta Pacific MindWorks, Inc.

Dave Ptacek Rockwell CollinsX Don Essner DRS Systems and Electronics

?? TYX Corp

Quorum is a majority of directors. 5/9 satisfies the requirement.

Agenda Review

IVI BOD MEETING MAY 18, 2006

1. DIRECTORS IN ATTENDANCE

2. AGENDA REVIEW

3. REMINDER OF THE IP POLICY, ANTI-TRUST, AND DUTY OF TRUST OF DIRECTORS

4. RESOLUTIONS PASSED BY ELECTRONIC MEANS SINCE LAST MEETING

5. REVIEW MINUTES OF PREVIOUS MEETING

5.1 ACTION ITEMS FROM PREVIOUS MEETING

6. FINANCIAL REPORT (BALANCE AND PROFIT/LOSS)

7. REPORT FROM LEGAL GROUP

8. REPORT FROM MARKETING GROUP

9. REPORT FROM OPERATING PROCEDURES GROUP

10. LIAISON REPORTS

11. NEW BUSINESS

11.1 RESOLUTION: MANAGEMENT CHANGE


11.2 ACTION REGARDING NCRPA

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.

Resolutions passed by electronic means since last meeting

The following two motions were passed by the Board of Directors since the last face-face meeting.

RESOLUTION 1: The Technical Committee resolves that we remove 98, ME, and NT4 from IVI 3.1.

RESOLUTION 2: The Operating Procedures Committee resolves that the Board of Directors adopt version 1.3 of the Operating Procedures as expressed in http://www.ivifoundation.org/Downloads/IVI_1.2_OperatingProcedures_v1.3%20Proposed_2006-05-30.pdf

This update includes:- An Appendix on class spec development- A better explanation of certain procedural issues - A brief section on basic parameters around shared component

management


http://www.ivifoundation.org/Downloads/IVI_1.2_OperatingProcedures_v1.3%20Proposed_2006-05-30.pdf

http://www.ivifoundation.org/Downloads/IVI_1.2_OperatingProcedures_v1.3%20Proposed_2006-05-30.pdf

Review Minutes of Previous MeetingThe minutes of the May 2006 meeting are posted on the IVI Web Site.

Action Items from Previous Meeting

Item Owner updateContact BAE regarding if they intend to remain as members.

Bob Helsel Done. They are interested in maintaining membership

ACTION (Bob Helsel) Will check and see what we have been billed for legal costs to-date

Bob Helsel Done -- ~$1900.

Call for BoD vote on operating procedures

Joe Mueller Done

Financial Report (balance and profit/loss)

Report from Legal group

No activity (yeah!).

Report from Marketing group

Web site


Web site --- generally needs to be updated – especially problems with the driver registration page. We evaluated bids from two companies (Kavi & Studio MultiMedia (SMM)). The Kavi bid was too high for IVI, so plan to go ahead with SMM (at $4500-6000).

Bob Helsel reported that a reasonable estimate for the complete web site update, including appropriate re-design will probably be close to $10K.

<John Ryland no longer voting>

Getting Started with IVI documentGroup has determined that we should produce a “getting started with IVI document” to have a chapter for each major ADE. Plan on moving forward with the project. Have one bid back (about $7200), had hoped for a lower cost bid of about $5000, however, the extent of the work was increased to include ADE’s of all foundation members (i.e., MATLAB with Instrument Control Toolbox, Measure Foundry, PAWS, VEE).

Likely this will cost about $10K with the addition of the additional chapters, and PR work to promote the specification.

Motion #1: Motion to raise the dues by 50% (Motion- Scott Rust, Seconded by Don Essner). Requires that the BoD create an appropriate letter to the membership.

MSC 4:0:0

Motion #2: Authorize the marketing committee to move forward with the web site improvements and IVI getting started document with the expectation of $20K expenditures, but not authorized to commit to more than $12K at this time. (Motion: Scott Rust, Second Don Essner)

Discussion: A further motion to authorize any additional expense from $12K to $20K will be necessary.MSC: 4:0:0

Report from Operating Procedures groupReport: BoD voted on 1.3 (it is now posted). It is finalized and posted. No pending changes.

Consideration of change to by-laws to simplify changes to specifications.

Would like a proposal some of the key elements are:- Able to take technical action of TC at face-face meeting- No “Nay”’s


- Any two voting members can raise the issue to the full membership- “properly called meeting” Topic in the agenda?

ACTION: Joe will report on this for the next meeting.

Liaison Reports

Kirk Fertitta (EO)They are continuing to meet. They met at Autotestcon that Kirk attended. They are developing their test specifications. They want to complete test specifications and then look and see if there is a cohesive set of instruments that come out of that. They expect that to be done by April – then will decide if IVI specs make sense for what they are doing.

John Ryland (LXI group)<not present>

Ion Neag (DoD RAI (Resource Adapter Interface) Working Group)Tom Gaudette will do this.

Ion Neag (DoD SI I/O Working Group)Tom Gaudette will do this in the future.

Two major things have happened. They decided on a procedure to vote and voted to enable PMW to prepare IVI specs for four modules. The Navy is willing to fund this.

Second, the SI working group has two specifications – thos on SW and those on HW. The specifications that describe the HW requirements for each of those modules has been moved in the short term to be voted on in the NDIA. In the long term these specifications will become example instance documents inside of ATML.

Also, there was a determination that they need a high speed bus. They chose PXIe as their high-speed bus.

Ion Neag (ATML group)Tom Gaudette will do this in the future.

Test Results will be voted on within the next couple of months. The other thing of interest is that the schema’s are intended to be out for ballot by the end of the year. Hoping to finish by the end of 2007.


Will most likely dissolve into the IEEE SCC-20 subgroups.

New business

RESOLUTION: Management change

RESOLVED: That the Company accept the resignation of Fred Bode office of Director of Services of the Company, effective immediately and that Robert Helsel be, and he hereby is, elected to the office of Director of Services effective immediately, until his successor is duly elected and qualified or the earlier of his death, resignation or removal.

General discussion of the letter that the attorney proposes that our president send to the attorney to further appoint Bob.

Motion to accept resolution proposed by Updegrove et al (Don Essner) Second (Kirk Fertitta).

MSC 4:0:0

None


Chapter 3 Technical Committee

General Meeting Info:Date of Meeting: October 12, 2006Location: BostonChairperson: Scott RustMinutes Prepared By: Scott Rust

Meeting Attendees:

Name Company

Joe Mueller Agilent

John Harvey Agilent

Omar Vitobaldi Elgar

Bob Helsel IVI Foundation

John Ryland Keithley

Jon Bellin NI

Scott Rust NI

Dan Mondrik NI

Kirk Fertitta Pacific Mindworks

Hugues Valois Pacific Mindworks

Johannes Ganzert R&S

Jochen Wolle R&S

Don Essner DRS Systems & Electronics

Teresa Lopes Teradyne

Murali K. M. Sreedhara Tektronix

Philip Burke The Boeing Co

Tom Gaudette The Mathworks

Topics To Be Discussed:- Review Agenda- Review Voting Members In Attendance- Patent Call- Approve minutes from the May 2006 Technical Committee Meeting- Review Action Items from Previous Meeting- Review outcome of recent eVotes, IPR Declarations and Reviews- Review Spec Status Document- Working Group Topics

o Summaries of Previous Days Working Group sessions VISA, Vista/64-bit, Counter/Timer, Signals WG


o Signal WG Chairmanshipo IviLxiSync Editorial Changeso Topics from the VISA WGo Topics from the Vista and 64-bit WG

- New Businesso Plans for VPP specs – Tom Go Linux support for IVI – Tom G

- Discuss Upcoming Meetings

Voting Members In Attendance

Company Voting RepresentativeAgilent Technologies Joe Mueller

DRS Systems & Electronics Don Essner

Elgar Omar Vitobaldi

National Instruments Scott Rust

Pacific Mindworks Kirk Fertitta

Keithley John Ryland

The Mathworks Tom Gaudette

Rohde & Schwarz Jochen Wolle

Teradyne Teresa Lopes

Tektronix Murali K. M. Sreedhara

There are 9 voting members in attendance, which satisfies the requirements for a quorum of 6 of Voting Members. (Quorum is 25% of Voting Members. There are currently 23 Voting Members.)

Patent CallPlease be aware that this meeting is being held under the Intellectual Property Rights policy adopted by IVI Foundation. If you do not have a copy of this policy, please see me during this meeting. You may also view and download a copy of that policy at the Organization>>Legal Documents section of the Consortium website.

At this time, I would ask that anyone in attendance inform me if they are personally aware of any claims under any patent applications or issued patents that would be likely to be infringed by an implementation of the specification or other work product which is the subject of this meeting. You need not be the inventor of such patent or patent application in order to inform us of its existence, nor will you be held responsible for expressing a belief that turns out to be inaccurate.

*******

No attendees said that they are aware of any patent claims.


Approve minutes from the May 2006 Technical Committee Meeting

The minutes from the May 2006 Technical Committee Meeting are posted on the IVI Foundation web site.

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

Action Items from February October Meeting

Owner Action Item Status

Jochen Wolle

Make editorial change to RF Sign Gen specification (Feb ’06) Pending. Have found a few more editorial changes to make. Will resolve all editorial changes in one step.

(May ’06) Reviewed at TC Meeting. Jochen to run Editorial Change process

(Oct ’06) Still pending

Scott Rust Run process to approve VPP 3.3 and VPP 3.4 changes with regard to 64-bit .fp changes and .sub file hierarchy changes. This is a major change. This does not require an IPR declaration.

Scott Rust to initiate a TC review to last 45 days.

Scott Rust to conduct a vote to approve – vote requires 50% majority vote as the 2/3 supermajority vote to start 64-bit work that has already occurred

(Aug) Review complete

(Oct) TC Vote complete.

Scott Rust Need a way to uniquely label motions and record them in the Spec Lifecycle Status Doc so that we can trace which motions covers what efforts

Complete

Scott Rust Run 2/3 majority eVote to approve Signal WG charter

(June) TC Vote Complete

Scott Rust Run 2/3 majority eVote to approve AC Power Source Charter


Kirk Fertitta

Kirk Fertitta to make a proposal for a bug-tracking system for the Shared Components at the next Technical Committee meeting.

Proposal is to use FogBugs. $100/named user per year.

Question is how/where to host. Kirk to bring specific recommendation, implementation proposal, and demo to next Shared Component Management WG. Some to be sent via list server between meetings.


Owner Action Item Status

This needs to be factored in as part of the web site re-hosting effort.

Scott Rust Run a 45 day formal review and a 50% majority vote to approve the changes to VPP 2, VPP 4.3, VPP 4.3.2, VPP 4.3.4, and VPP 6. These changes are for Win64, 64-bit integers, and PXISA.

(Aug) Review complete

(Oct) TC Vote complete excluding VPP 4.3.4

Joe Mueller

Update the Operating procedures to reflect that the VISA COM Standard Components be handled with the same policies as the IVI Shared Components

Pending Editorial Change

Scott Rust Run vote on MOTION (2006-05-18) #4: Jon Bellin moved that we remove 98, ME, and NT4 from IVI 3.1. Seconded by Kirk Fertitta. This is a major change and requires a 2/3 super majority vote.


(Sept) BoD Vote completed. Changes updated on Web site.

Kirk Fertitta

Bring a proposal regarding better design documents/templates for increasing the efficiency of the spec creation process to next TC meeting

Open

Kirk Fertitta

Drive effort to create a proposal to solve the PIA problems. Report back at next TC meeting

Closed. Dropped in lieu of .NET work that is in progress.

Scott Rust Passage of IviLxiSync requires changes to IVI 3.1. Scott to determine status of the IVI 3.1 changes and finalize them.

Complete – Noel Adorno has posted the updated document to the IVI Foundation web site.

John Harvey

Editorial Changes to IVI 3.4 Style Guide. John to determine status of the IVI 3.4 changes and finalize them.

Changes have been made.

John H to send doc to Bob H to be posted.

John H to run editorial changes process

Kirk Fertitta

Inclusion of Source files in the Appendix of IVI Specs. These files now have a place on the IVI web site. Proposal to stop requiring them in new IVI Specifications.

Run the editorial change process to remove Source file contents from the class spec appendixes and place them in a suitable repository on the IVI Web site and give redundant copies to the appropriate archivers (BoD members).

Open – Pending resolution of web site clean-up.

Review outcome of recent IPR Declarations, eVotes, and Reviews

eVotes Concluded on June 27, 2006The following motions were approved in a Technical Committee eVote that concluded on June 27th.


MOTION (2006-05-18) #1 The Signals WG moved to approve the Signals WG charter. No second is necessary.

MOTION (2006-05-18) #2 Joe Mueller moves that we approve the above [AC Power Supply Working Group] charter as proposed. Don Essner seconded the motion. This requires a 2/3 super majority eVote.

MOTION (2006-05-18) #4 Jon Bellin moved that we remove 98, ME, and NT4 from IVI 3.1. Seconded by Kirk Fertitta. This is a major change and requires a 2/3 super majority vote.

Each motion required a 2/3 super-majority to pass. All Motions were approved.

eVotes Concluded on October 5th, 2006

The following resolutions were recently up for a Technical Committee eVote.

RESOLUTION 1: VPP 2, 4.3, 4.3.2, 4.3.4, & 6 - Changes for Win64 & 64-Bit Integers

RESOLUTION 2: VPP 3.3 & 3.4 - .fp Changes for 64-bit Integers & .sub File Hierarchy Changes

The original vote was to conclude on September 28th. During the voting period a problem was found with changes to VPP 4.3.4. The decision was made to modify Resolution 1 to remove 4.3.4 and extend the voting period to October 5th. The modified Resolution is shown below:

RESOLUTION 1 (Modified): VPP 2, 4.3, 4.3.2, & 6 - Changes for Win64 & 64-Bit Integers

Resolution 1 (Modified) and Resolution 2 were approved on October 5th 2006. Each received 13 YES votes.

Action: Scott to email list server with results of this evote.

Action: Joe M to run BoD votes on the above Resolution 1 (Modified) and Resolution 2.

Review Spec Status Document

Group requested that the spec status document be accessible on the web or emailed via the list server as it is updated.

Group wants to perform 2/3 super-majority vote to start .NET work at next opportunity.


Working Group Topics

Summaries of Previous Days Working Group sessionsRepresentatives from the VISA, Vista/64-bit, Counter/Timer, and Signals working groups summarized their activities from the previous day’s meetings.

Signal WG ChairmanshipDiscussed need to find a working group chairman during the Signals Working Group.

Action: Scott Rust to email IVI list server to ask for volunteers to chair the Signals Working Group. The response deadline is Dec 31st. This is to allow time to determine if we should schedule a Signals Working Group meeting at the February meeting and to have time to make sure that it is productive.

IviLxiSync Editorial Changes

Joe M has a group of editorial changes based on questions/comments since the 1.0 draft was approved. Mainly came from LXI and IVI members.

Believes he will have the changes wrapped up in the next 2 to 3 weeks.

Action: Joe M to run editorial change process to approve IviLxiSync editorial changes

Topics from the VISA WG Recommend a shorter review period for the VPP 4.3.4 changes after the final edits have been made as part of removing the changes related to the IDL split. Review the installer at the same time.

What is a reasonable review period. The group felt that 2 weeks was the minimum. Will likely vote this spec along with others at the end of year, which would allow for 45 days.

Minor changes need to be made to IVI 3.14. We need to start the process on that. John Harvey will be the owner.

IVI 3.14 mentions creating the PIA from visacom.tlb, which does not exist It also does not specify the process for creating config and policy files. Need to modify IVI 3.14 to specify these things correctly and completely.

o No changes in behavior of existing implementations

Group decided that this is an editorial change

Action: John Harvey to run editorial change process on IVI 3.14 for above changes.

Action: Scott Rust to create an editorial change sheet in the spec status doc and include pending editorial changes.


What is the appropriate way to document the mininum OS and service pack requirements for the IVI and VISA COM shared component installers?

Our current plans are to include the minimum OS and service pack requirements for the VISA shared component installer in the specs. Would changing these requirements in the future be an editorial change or would it require a vote?

We currently do not document the minimum OS service pack requirements for the IVI shared component installer in the IVI specs. Should we?

Should we document the minimum OS and service pack requirements on the download pages for the IVI and VISA COM shared component intallers?

The group decided that we should document the minimum shared components requirements on the web site and not in the spec.

Action: Kirk F to make a recommendation on way/mechanism to document the minimum shared components requirements on the web site.

Action: Noel A to run editorial change process to add caveat to IVI 3.1 that points the user to the web site to determine the minimum service pack level for each OS.

Verify that the following was acted upon from the last meeting: Recommend that the IVI Operating Procedures state the VISA COM standard components be managed in the same way and by the same group as the IVI Shared Components.

Action: Joe to run editorial change to specify that the IVI Operating Procedures state the VISA COM standard components be managed in the same way and by the same group as the IVI Shared Components.

Should we have 2/3 super-majority vote on proceeding with a VISA C plug-in architecture for Vista 64?

Resolution (2006-10-12) #1: Jon Bellin moved to start work on a VISA C plug-in architecture for Vista 64 and create new specification to contain the work. Seconded by Joe M. This is a Major change and requires a 2/3 super-majority vote to start the work.

Vista & 64-Bit Working Group Issues IVI 3.1 and IVI 3.2 change documents for 64-bit integers will be ready for review

in a few weeks. o Get approval for Win 2000 placeholder text and future update as editorial

change.

Suggested placeholder text for Windows 2000: “In some scenarios __int64 and SAFEARRAY(__int64) might not work correctly on Windows 2000. This will be explained in more detail as an editorial change in the future.”

Group is OK with the placeholder text.


IVI 3.1 change document for 32-bit Vista apps will be ready for review in a few weeks.

o Needs be approved by the end of the year. Another IVI 3.1 change document will be coming regarding C wrapper

conventions.o Group agreed that this is a minor change.

Resolution (2006-10-12) #2: Jon Bellin moved to start work on updating IVI 3.1 sections 5.17 and 6.6.5 to clarify and correct the requirement for C wrappers that are packaged with IVI-COM drivers so that it is consistent, clear, and practical. Seconded by Joe M. This is a Minor change and requires a 2/3 super-majority vote to start or approve the work.

New Business

Plans for VPP specs – Tom GSeveral questions came up recently Framework working group (a DoD funded working group). The group would like to understand the IVI Foundation’s intentions with regard to the VPP specs.

The VXIplug&play organization has gone dormant. The VPP specs where brought under the IVI Foundation umbrella. Some of the IVI Specs refer to the VPP specs. IVI-C drivers build upon VXIplug&play driver specs. In general, The IVI Foundation has been updating the VPP specs as necessary to support IVI Foundation activities.

VISA is specified in the VPP specs. The VPP specs pertaining to VISA have been maintained.

IVI-C drivers are not 100% VPP compliant but the intention was to make them very close. We could consider changing VPP specs to allow for 100% compliance.

NI wants to keep the VPP specs viable to allow for future creation of VPP compliant drivers.

An example of some of the issues is VPP 2 which still contains to references to OS’s that the IVI Foundation does not explicitly support. Some of these OS’s have been removed as part of a recent vote.

Suggestion was made to move the VPP specs to the IVI Foundation web site.

Suggestion was made to survey the VPP specs and make recommendations to leave alone, update, or deprecate.

Some of the VPP specifications are already in process of being moved to the IVI Foundation web site.


Action: Dan Mondrik, Noel Adorno, Tom Gaudette, and John Harvey to survey the existing VPP specs and to list areas that are not up-to-date and to recommend updates and obsolescing of parts or entire specs.

Linux support for IVI – Tom GComment in LXI that IVI drivers are not supported in Linux.

What do the current specs say with regard to Linux?

What should IVI’s message be with regard to Linux?

NI believes that it is possible to support Linux with IVI-C drivers.

Is there a way to clarify the situation or create terminology to describe the Linux drivers? “Linux Ported IVI Driver”.

Action: Jon Bellin to make a recommendation to clarify Section 4.2.1 of IVI 3.1 and include nomenclature for the drivers.

Need time on agenda at next TC to review proposal.

If anyone would like to make Linux be fully supported by IVI, they should make a Motion to do so and be prepared to do some work.

Discuss Upcoming MeetingsThe next meeting will be February 6th – 8th in Austin and be hosted by National Instruments

Working Group Time

.NET ¾ to 1 day

Technical Committee Meeting and BoD (start in morning/mid-morning)

½

Signals Working Group TBD

Users Committee TBD

Operating Procedures 0

Marketing Committee and Web site review ¼ to ½

Shared Components Management ¼

Scope Extensions TBD

AC Power Supply ¾ to 1 day

Counter/Timer ½

VISTA & 64-bit Working Group ½

VISA (same day/track as 64-bit) ½


Working Group Time

Totals

We will attempt to schedule for the meeting to end early so that people can get to flights on Thursday afternoon/evening.

Action Item: All WG Chairpersons are to post completed action items and detailed agendas for the upcoming meeting by Jan 15th.

Action Item: All WG Chairpersons to submit minutes to Bob H in two weeks – 10/26.

The meeting after the February meeting will tentatively be held in San Diego (May 15th – 17th) and will be hosted by Pacific MindWorks.

Adjourn

Meeting Adjourned.


Chapter 4 AC Power Source Working GroupGeneral Meeting Info:

Date of Meeting: October 10, 2006Location: Boston, MassachusettsChairman: Omar Vitobaldi (Elgar)Minutes Prepared By: Phillip Burke, Omar Vitobaldi

Meeting Attendees:

Name Company Email Phone

Kevin Lam California Instruments [email protected] 858-677-9040 ext.263Jochen Wolle R&S [email protected] 1+49.89.4129.13044

Eric Lord Pacific Power Source, Inc. [email protected] 1.800.845.2433 x151Omar Vitobaldi Elgar [email protected] 858.450.0085 ext 2320

Phillip Burke Boeing [email protected] 314.233.4501Scott Rust National Instruments [email protected] 512.683.5472

Agenda:1. Welcome new members2. Review charter3. Results of contact with other vendors4. Review of web site5. Review Action Items6. Review proposed project schedule

1. Develop task list2. assign responsibilities3. set target dates for task completion

7. Discuss setting up monthly WebEx/Audio conference.8. Create Base Group candidates9. Create Extension Group candidates10. Create Action items list


Review Action Items:# Action Item Discussion Assigned To Due Date

1 How to create arbitrary waveforms - SCPI?

Complete Omar 10/15/2006

2 Do most suppliers have single or multiple oscillators, does it matter

Single oscillators are used.

Omar Vitobaldi 10/15/2006

3 Interface with CI to get information Complete Bob Helsel 10/15/2006

4 Define Base Functions Complete, see discussion


5 Define Potential Extension Groups Complete, see discussion


6 Set up monthly audio conference on Fridays at 10 EST, 9 CST, 8 MST, 7 PST

On Hold Omar Vitobaldi No Date

7 How do we configure a master PS In work Omar Vitobaldi 10/15/2006

8Create AC Power Source Web Site

Complete Phillip Burke

Bob Helsel5/30/2006

Discussion:

Welcomed new members from California Instruments

The following charter was approved at the last BOD meeting:

"The IVI Foundation Technical Committee working group for the IviACPwr class specification will develop a specification for AC power sources conceptualized as a power source having a periodic bi-polar sine wave output. It shall benefit from prior specifications and especially IVI-4.3: Fgen Class Specification and IVI-4.4: IviDCPwr Class Specification."


Both Chroma (Taiwan), and Behlman(New York) were contacted to see if they were interested in joining the consortium. There was no response from either vendor.

Review of web site – Phillip will continue to maintain web site. Check on copy right issues – maybe add links, not actual document Kevin will check with company about releasability of CI data

See Section above for Action Items.

Review of project schedule making some modifications Reference the updated schedule on the IVI AC Power Source web site The complete list of deliverables may be found in IVI-3.4: API Style

Guide As a goal define all base class functions, attributes, and behavior models

by February 2007.

Monthly audio conference on hold for now. Will use email and web site to move forward

Base Group Candidates:1. Set Voltage Level - All values in Volts, need to determine if line to

neutral, line to line, or both depending upon single or multiphase system.2. Set Phase Angle (A to B, A to C) - All references to Phase A, must be

positive, or should negative be allowed?3. Output Enabled - If instrument doesn't support, always enable4. Output Voltage Range - This will enable or disable, then use extension

group Set Voltage Range. This is for instruments that have low and high output ranges.

5. Current Limit - Implement like DMM. Does this need to be settable by phase?

6. Frequency - all values in Hz. Multiphase system all use same frequency.7. Query output enable - Is output enabled or disabled.8. Query output voltage range - Is voltage range enabled or disabled.9. Query current limit - All values in Amps, determines current limit set

point10. Query voltage setting - All values in Volts determines voltage set point.

Request by phase, or return all phases?

Extension Group Candidates:1. Ability of the AC source to provide DC Output2. Set Output Impedance3. Set arbitrary waveform generation4. Set transients5. Max Voltage Limit (Protection)


6. High/Low Phase Limits7. Current Limit (Protection) current over time8. Voltage Protection9. Set_Voltage_Range (low or high)10. Measure - implement just one like DMM, if needs other values implement

an extension a. Voltage A/B/C to Nb. Voltage A to B, B to C, C to A

Detailed Discussions: There was considerable discussion on OVP – whether to be in an extension or

not. It will be in an extension, maybe multiple calls, one to enable, then another to set limits (upper and lower)

OIP will also be an extension similar to OVP, sets upper limit and time limit for over current

Action Items:# Action Item Discussion Assigned To Due Date1 Determine attributes and

values for each function Phillip / Omar 2/07/2007

2 User and programming manuals from CI Kevin Lam 10/23/2006

3 User and programming manuals from PP Eric Lord 10/23/2006

4 Investigate OVP limits Kevin Lam 2/07/2007


Chapter 5 IVI.NET MeetingOct 10, 2006

Boston, MA

Agenda Items

1. Proposed changes to the PIA spec.

This spec needs to be updated to correct the command line for creating the VISA COM spec, esp. if we continue with the VISA COM IDL split. It also needs to provide direction for creating .config and Policy files for backwards compatibility.

The description of how to generate config and policy files needs to be added. There is also an error in the command line for generating the PIA for the GRM. Note that the current shared components are correct, but the spec is not.

John Harvey will propose changes to IVI 3.14 re. PIA’s to correct these issues in time for the next meeting. (December 1 proposal)

2. Discussion of infrastructure components required for .NET?

We need:a. Abstract factory (still need to support the interchangeability model – can

not use the existing through interop because the existing factory generates COM objects).

b. Plan on using configuration server with interop. (no new work needed).c. Plan for event server? – per earlier discussion (document . NET issue list)

we will not update this other than the existing PIA interface.

Conclusion: the only infrastructure component necessary is the abstract factory.

3. Minimum .NET runtime version.a. PMW Recommends: .NET 2.0

Reasons: Enable use of generics (collections etc). (very useful for dealing

with repeated capability collections).Per the decision documented in IVI Dot Net issues in document, we should go to 2.0 (statement is to use whatever is current so long as it has been available for 2 years).


4. IVI.NET install directory.a. Proposal to change install dir to IVI\Drivers\<driverName>.

<IVI-std rootdir>\Drivers\<driver supplier>\<component ID>

<IVI-std rootdir>\Drivers\<driver supplier>\<determine by SW vendor – may have subdirectories>

How will we get <drivername>? We have keyed off of the component ID in COM in the past. If we say “drivername with instrument mfg” we need to add that requirement appropriately somewhere.

We will permit the second variant (with sub-directories). <Consensus>

b. Where should instrument class assemblies be installed? The PIAs are in the “Primary Interop Assemblies” subdir. Do we want an “Assemblies” subdir or just directly under “bin”?

Where do we place the class assemblies? -- Typelibs are all just under <IVI-std rootdir>/bin currently. Presumably add a directory to contain all of them. We will use:

“<IVI-std rootdir>/bin/Assembly”

<Consensus>

5. IVI-COM wrappers on .NET allowed?a. Explicitly mention in specs as allowed?b. Filename standards/conflictsc. Other issues

If someone wants to have a core .NET driver then create a COM wrapper. No apparent reason why that should be illegal. Would like some explicit statement of intent of this group. Have not proved that there is no conflict (for instance with the threading model).

There is clearly a run-time dependency – that is, the IVI-COM driver based on a .NET core would require the .NET runtime.

This group does not anticipate any issues. We agree that this is a legitimate use model. No explicit action required from this group.

<Consensus>


We may need to be more specific with regard to directory names and file names (possibly other details) if we have the formal idea of a COM wrapper on top of a .NET driver.

ACTION: If we come across any issues we will add the necessary detail.

6. What specs must be modified to complete IVI.NET spec 1.0?a. 3.1 – Need to add architecture sections corresponding to .NETb. 3.2 (inherent capabilities) – yes c. 3.3 (standard cross class capabilities) – yes d. 3.4 (style guide) -- yese. 3.5 (config server) – yes – add an entry regarding how to locate the .NET

component to instantiate it.f. 3.6 (COM Session factory) -- Yes g. 3.7 (IVI Event server) – noh. 3.9 (C shared component) – noi. 3.10 IVI-MSS – noj. 3.12 Floating point – nok. 3.14 PIA – nol. 3.15 IVI LxiSyncSpec – Yesm. 5.0 Glossary – if we want.n. 3.n (NET Session factory)o. Various instrument class specifications:

Procedure for doing this will be very important Need a quick and efficient review process

3.1 – 1 Agilent (J/J) & PMW

Next meeting (Feb)

3.2 (inherent capabilities) 1 PMW Next meeting (Feb)

3.3 (standard cross class capabilities)

2 Teradyne (T)

3.4 (style guide) 0 PMW Phone meeting to discuss by 12/1

3.5 (config server) 2 Agilent (JH)3.6 (COM Session factory)

2 PMW

3.15 IVI LxiSyncSpec Agilent4. (scope) 0 (at least

start)PMW Phone meeting to

discuss by 12/1. Perhaps without Word doc

4. (specAn) 0 PMW Phone meeting to discuss by 12/1. Perhaps without Word doc


4. (Fgen) 2 Agilent4. (DC Power) 3 TMW4. (Switch) 2 Agilent(Power Meter) 1.5 Teradyne (T)(DMM) 1 Agilent (JM) Next meeting

(Feb)(Sig Gen) 2 Rohde&Schwarz(Counter) 3 DRS/Boeing(AC Power) 4 Elgar

5.0 Glossary

Plan on phone meeting roughly monthly at 11 Eastern. Beginning 11/9. We will discuss the style guide and/or have a first look at the spectrum analyzer specification.

7. Detailed discussion items (see below).

8. Need to seek a 2/3 vote on the general .NET work

ACTION: Joe will propose an resolution to the technical committee.


Detailed Discussion Items

RecommendationIVI.NET drivers should install in IVI\Drivers\<driverName> to avoid naming conflicts of DLLs, particularly dependent DLLs. Drivers MUST also install into the GAC. Drivers SHOULD register their install directory with each VS.NET version they detect, so that the “Add Reference” will show the driver in the .NET tab of the dialog.

Drivers need to register HKLM/Software/Microsoft/VisualStudio/<each version>/<Assembly folder subdirectory of that assembly installs to> ---- This allows Add References to show the component on the .NET tab.

<Consensus>

RecommendationNaming convention for namespaces should be identical as for PIAs, minus the “Interop” suffix.E.g., Agilent.AgilentE4401

Discussion: generally vendors will want to be able to follow their own corporate standards for namespaces, therefore anything beyond just the software vendor will be a problem. Note that this is a slight change from the past since PIAs namespaces specified the path down through “Interop”.

RecommendationShould be CLS Compliant

<consensus>

RecommendationNo parameterized properties. (This is implied by CLSCompliant).

<consensus>

RecommendationFollow .NET standards for instrument class assembly and driver assembly file names.Ex: Ivi.SpecAn.dll, Agilent.Agilent34401.dll.

<consensus>

From FXCop Enum values should have a value for 0


Enum values are initialized to zero be default. This will make the enum values different from they are in COM. This also requires the zero value be a logical default.

ACTION: PMW to include this in the style guide.

Naming of collection interfaces with ‘s’ or ‘Collection’ suffixDiscussion – we will use “Collection” suffix for collections instead of just “ending in s”.

Avoid out parameters, create class for multiple results and use that as method return type

Will discuss as we see examples of classes.

From CA1819Arrays should be copied when returned from a method, since they are not write-protected.

(i.e., don’t return a reference to an internal array).

<Consensus>

From CA1819Properties should not return arrays.

Too easy for the user to accidentally reference elements of the array then pull the entire array back for each element de-reference.

<Consensus>

From CA1021Avoid [out] and [ref] parameters.Change: ErrorQuery now returns a struct.Change: SelfTest now returns a struct.

<Consensus>

From CA1710Repeated capability collection interfaces renamed to end in “Collection”.

<see above>

From CA2209


Be sure and specify minimum permissions.

Note that some instrument capabilities, such as simulation mode (which does not require permission to do I/O) and disk logging (which would require access to the file system) may mean that the driver developer can not fully specify the permissions required for a driver in any given operating environment.

For these cases, the driver designer may specify the minimum permissions (truly the minimum required). In other cases, the driver designer may choose to specify the permissions that it may need for other operating configurations.

This could result in security exceptions being thrown after the system has been running.

Add the following exception typesModelNotSupportedException -- this means that the driver does not support the

instrument model located at the specified I/O location

CapabilityNotSupportedByModelException – The instrument model works with the driver, but the specific driver call was not supported by that the connected instrument.

Other possible names:ModelCantDoThatExceptionModelDoesNotSupportMethodOrPropertyException

In drivers that support multiple instrument models, need a way to throw an exception for model not supported.

<Open – just need to find right name>

QuestionIs RecordCoercions still necessary now that we have the Coercion event. Why would someone turn coercion recording on and not just subscribe to the event. Same question for InterchangeCheck.

2006-05-18 – Meeting notes show that we discussed this and concluded that we would handle this only through events. We said we would remove these functions.

<Conensus>

QuestionWhat to do about the IviDriver dependency issue.


Client code has to have a reference to that assembly since we derive from it. So even if they do instrument specific code they will need a reference to IviDriver.

ACTION: Need to think through the use cases around potentially working without IVI shared components. (group)

ACTION: Verify the user experience. If we don’t derive from IviDriver, what are the implications? (NO ACTION – we will continue to go down the IviDriver required path, although we will continue to not require the customer explicitly use them).

QuestionWhat is policy for thread safety?

Need to take explicit actions to be thread safe. What do we want to do?

Really need to remain thread safe. Can not say you can use a global lock vs. a finer grain lock.

Don’t want to force driver writers to use an object level block or impose a locking scheme on them. For instance, they may be stateless or have individual locks, or rely on the instrument for locking, or or or…… Therefore this is the responsibility of the driver writer.

Must be safe to operate in a multi-threaded environment.

<Consensus>


Chapter 6 VISA

General Meeting Info:Date of Meeting: October 11, 2006Location: Boston, MassachusettsChairperson: Dan MondrikMinutes Prepared By: Jon Bellin

Meeting Attendees:

Name Company Phone Email

Jon Bellin National Instruments 512-683-5516 [email protected] Mondrik National Instruments 512-683-8849 [email protected] Harvey Agilent Technologies 970-679-3535 [email protected] Sreedhara Tektronix +91-90-22105535 [email protected] Valois Pacific MindWorks 858-587-8876 [email protected] Fertitta Pacific MindWorks 858-587-8876x237 [email protected] Ryland Keithley 440-498-3134 [email protected] Lopes Teradyne 978-371-1377 [email protected] Gaudette The MathWorks 508-647-7759 [email protected] Ganzert Rohde & Schwarz +49-89412913405 [email protected]

schwarz.comChristophe Grard TYX/EADS 703-264-1080x133 [email protected] Schmischke Data Translation 508-303-1281 [email protected] Randow Data Translation 508-303-1281 [email protected]

Topics to Be Discussed: Progress on changes to VISA specifications VISA COM

o Issues surrounding proposed change to create the BasFrmIO.idl file.o Status of VISA COM shared installer (probably ready for review)o Change to PIA spec for creating VISA COM type lib.o Effect of using VS 2005 to build some of the shared components on VISA

COM Action items from last meeting:

o Bob Helsel Make remaining VXIpnp specs available for download from IVI

site. Have VXIpnp download page point to IVI site.

o Joe Mueller Lead conference call to discuss dynamic discovery and aliasing.


mailto:[email protected]














Begin discussions for Win64 framework (i.e., 64-bit user-level binaries).o Preferred directory layout.o Coexistence of 32-bit and 64-bit binaries.o VISA C DLL plug-in architecture, which Agilent has agreed to drive.

Record of Discussions:

Progress on Changes to VISA Specs

The following spec changes have been approved by a vote of the Technical Committee since the last meeting:

o 64-bit data types and beginnings of 64-bit framework VPP 4.3: VISA Library VPP 4.3.2: VISA bindings for C VPP 2: Frameworks VPP 6: Installers

The following spec change did not get approved:o Specify requirements for the shared installer, and fixing an architectural

problem with BasFrmIO.idl VPP 4.3.4 VISA COM

Refer to Section 1.4.2 below.

Issues surrounding proposed change to create the BasFrmIO.idl file

There is one IDL file, with two DLLs implementing it. GlobMgr.dll

o Includes global resource manager Maps resource descriptor to a vendor’s VISA

o Guts of the VISA COM interface implementation BasFrmIO.dll

o Ease-of-use layer

The entire IDL for VISA COM, including the interface and class definitions for Basic Formatted I/O are in GlobMgr.dll.

The only problem with having it this way is that if you register things in the wrong order, you run into a problem.

It had been proposed to split the IDL into two. Initially, this was to include both interface and co-class definitions. But there were problems with that, so the idea was to move just the co-class definitions. But there are still problems with that: We would have to have two .NET PIAs. We currently have one PIA, built off the type library in GlobMgr.dll and with everything needed to use GlobMgr and


Basic Formatted I/O. If we split the IDL, then we need two .NET PIAs, and the logical thing to do would be to rename them to match the COM DLL names. Splitting the PIAs makes backwards compatibility impossible. Policy files can’t fix this. It might break drivers.

The new proposed solution is to keep things as they were. Both DLLs will always be installed together by a shared installer. The installer will make sure things are registered in the right order. All registration will be done by the installer.

There was consensus on this solution.

John has gone through VPP 4.3.4 changes to remove the changes related to the split. Only a few more edits need to be made before it can be run through the review cycle.

Lessons learned: If you want to make a change to an IVI approved, IDL, consider impact

on PIAs. If you version an IDL, then you need to version PIAs and create policy

files.

Status of VISA COM shared installer

Alpha testing is in process. It needs to be updated to incorporate the decision in Section 1.4.2 by reverting to the previous binaries. Also, John Harvey may have found a problem with a registry key. Dan wants to start the review process on the spec and installer in November.

Dan proposed that VPP 4.3.4 be modified to allow the VISA COM installer to require Service Pack 3 for Windows 2000. (It currently says that it requires no service packs.)

Tom Gaudette pointed out that if and when we want to change the minimum OS requirements for the installer, the spec will have to be changed. Dan asked whether this would be considered an editorial change or would require a vote. We should discuss this in the Technical Committee meeting. Refer to Section 1.5 below.

After discussion at Technical Committee, Dan will either update the requirements to Service Pack 3, or remove the reference to service packs altogether (instead relying on documentation on the download page and in a readme file.)

[Dan’s notes after the meeting: The spec should not mention any specific service packs but should have a comment that the installer may require specific service


packs. The spec will direct the interested reader to the web site download page for more details.]

Change to PIA spec for creating VISA COM type lib.

IVI 3.14 mentions creating the PIA from visacom.tlb, which does not exist It also does not specify the process for creating config and policy files. Need to modify IVI 3.14 to specify these things correctly and completely.

o No substantive changes.

Other discussions going on about proposed changes to PIA creation from type libraries, etc.

o This is off the table for now – that is longer term.

Effect of using VS 2005 to build some of the shared components on VISA COM

Agilent making the effort to get ready for supporting Windows Vista. Part of this is moving to Visual Studio 2005, which would require that we include the VS 2005 run-time in the shared component installer. When John Harvey mentioned this to Zulfiqar, Zulfiqar initially thought that there are some problems with using VS 2005.

Microsoft includes manifests with the VS 2005 run-time DLLs. Also, uses MSI 3.0 and requires Windows 2000 SP 3 or higher.

Dan believes there should be no problem including the VS 2005 run-time in the IVI shared component installer or the VISA COM shared component installer.

John Harvey believes that our short-term effort to support Vista (i.e., January 2007) does NOT require getting new versions of the components from Agilent and thus does not involve the VS 2005 run-time.

o Only possibility is if some change was needed to the Config Server.

Action items from last meeting

Bob Helselo Make remaining VXIpnp specs available for download from IVI site. (Not

done)o Have VXIpnp download page point to IVI site. (Not done)

Joe Muellero Lead conference call to discuss dynamic discovery and aliasing. (Not

done)


Proposal for a revised directory layout

Dan proposes the following changes:

Create a new IVI Foundation directory Put VXIpnp and IVI subdirectories under IVI Foundation.

o By default only, users could change either of these Remove Data directory from the IVI directory tree For 32-bit user mode, continue to set VXIPNPPATH in both registry and as

environment variableo For 64-bit user mode, set it in registry only

Do this on 2000 and XP as well as on Vistao This would make the installers easier to implement

The presentation is available on the IVI site at the following URL:ftp://ftp.ivifoundation.org/VISA/Documents/ProposedDirLayout.ppt

John Harvey’s initial reaction was that IVI Foundation is a lot of characters and that IVI would be repeated in pathnames, but he also likes the idea of having everything under an IVI Foundation directory.

John also pointed out that Agilent currently defaults to C:\Program Files\VISA. Can they continue to do so? Jon responded that it could be a problem if every vendor could choose the default name of the VXIpnp directory. If we wanted to add a new subdirectory tree in the future, how would we know that our default name is not already being used as a default name for VXIpnp by some vendor?

Dan noted that keeping the instrument drivers under Program Files means that modifying driver source files requires admin privileges. Tools that let users edit driver source files in-place may need to be changed. They would have to copy the files to the user’s Documents directory, so the user can edit it. An alternative would be to install the driver source to the Documents directory. This would then leave the source files editable without admin privileges. The consensus was that keeping the source under Program Files is a good idea because it protects the original copy of the source.

We will consider how to proceed on this in the Vista meeting later today.

Coexistence of 32-bit and 64-bit binaries

On Vista 64, the 32-bit and 64-bit user mode DLLs will both be in the system path. To avoid name conflicts, Dan proposes that “_64” be appended to the names of the 64-bit user mode DLLs. This would apply to all DLLs, including driver DLLs, for both VXIpnp and IVI.


ftp://ftp.ivifoundation.org/VISA/Documents/ProposedDirLayout.ppt

There was consensus on this approach

We will consider how to proceed on this in the Vista meeting later today.

VISA C DLL plug-in architecture

John Harvey: Agilent’s requirements and concerns: Upgrade issues will be difficult. Current VISA 32 is used by a large number

of users.o Plan to do this on Win64 user level only.

VISA “factory” adds an execution layer and might hurt performance. Must be able to handle callbacks via the factory. Must be able to add proprietary extensions to VISA. Must be able to map handles correctly so that the user does not get the same

handle value for two sessions created by two underlying VISA implementations.

What is the behavior of viFindRsrc? What if two plug-in implementations return the same resource string?o Dan suggested doing this the same way as in VISA COM. We should

merge the results from viFindRsrc, and create a conflict resolution database and API.

How to allow user to statically link in the VISA factory and still use vendor extensions, which requires statically linking in the vendor-specific DLL? Unlike with IVI drivers, the vendor-specific DLL will have (for historical reasons) the exact same entry points as the factory DLL.o Jon pointed out that one approach is to have special vendor-specific static

libraries that include just the extensions.o Jon pointed out that some users might want to avoid the factory and

continue to link to a full vendor-specific static library. Installer issues may arise based on the implementation

o Especially if we extend this plug-in model to Win32 (legacy installer behaviors).

NI’s requirements: No source code or configuration changes for current NI-VISA users.

o This includes users who use vendor-extended functions, attributes, and events.

o This includes resource manager sessions as well as I/O sessions. Underlying plug-ins must be able to get the user's session id from the plug-in's

session id.o We need this so that NI Spy can display the user's session id.


Must offer user choice as to which VISA will be the primary one when multiple VISAs are installed and support some of the same resources (e.g., TCP)

o This can be done install time (unless the install is silent)o We need it to be an attribute that is readable and writable (e.g., for

MAX),so that Users can change choice Support personnel can figure whose VISA is being used Users can try different ones if something is not working

We need to cover what happens when a o User first installs vendor A's pre-plug-in VISA and then installs

vendor B's plug-in VISA Could be resolved by the plug-in renaming A's VISA

o User first installs vendor B's plug-in VISA and then installs vendor A's pre-plug-in VISA

Note: Both would be resolved if we did this only on 64-bit and did it before any vendor ships 64-bit VISA

There shall be no user-noticeable performance degradation when one VISA is installed

o Avoid during unnecessary object management and mapping when only one VISA is installed

There shall be minimal performance degradation when multiple VISA plug-ins are installed

The GUI presentation of the choice as to which VISA is primary for a given resource should be similar to the presentation for VISA COM.o Preferably the choices should be presented on the same windowo Preferably, the user should be able to make one choice for botho Users should have a way to make the choices independently, but vendor

GUIs should not be required to present that.o The configuration needs to be stored in a way to make these possible.

Need to add a viParseRsrcEx2 function to determine which vendor-specific implementation the resource resolved to.

[Dan’s additional NI requirements, added after the meeting. 1) Some users might want to avoid the factory and continue to link to a full vendor-specific static library. We should ensure this works. Jon had mentioned this during Agilent’s presentation, as we do believe it is a valid use-case. 2) The factory should also have a way to completely disable any given VISA plug-in, and this should be something a GUI should be able to set, for being able to debug or isolate strange behavior.]

Where to go from here? John Harvey proposes to do the following soon: Getting the above requirements into a document Determine a set of things to prototype


John Harvey will lead this effort and will conduct conference calls (most likely every other week).

Time frame: Jon says NI needs it by July 1, 2008. John says this matches Agilent’s requirements.

Items to refer to Technical Committee:

Recommend a shorter review period for the VPP 4.3.4 changes after the final edits have been made as part of removing the changes related to the IDL split. Review the installer at the same time.

Minor changes need to be made to IVI 3.14 (refer to Section 1.4.4 above). We need to start the process on that. John Harvey will be the owner.

What is the appropriate way to document the minimum OS and service pack requirements for the IVI and VISA COM shared component installers?

Our current plans are to include the minimum OS and service pack requirements for the VISA shared component installer in the specs. Would changing these requirements in the future be an editorial change or would it require a vote?

We currently do not document the minimum OS service pack requirements for the IVI shared component installer in the IVI specs. Should we?

Should we document the minimum OS and service pack requirements on the download pages for the IVI and VISA COM shared component installers?

Verify that the following was acted upon from the last meeting: Recommend that the IVI Operating Procedures state the VISA COM standard components be managed in the same way and by the same group as the IVI Shared Components.

Should we have 2/3 vote on proceeding with a VISA C plug-in architecture for Vista 64?

Action Items:

John Harveyo Start VISA C plug-in architecture effort in earnesto Test the revised VISA COM installer with the current binarieso Make reversions and any other last-minute edits to VPP 4.3.4

Dan Mondriko Make reversions and any other last-minute edits to VPP 4.3.4.

Put on IVI site for review Notify Scott that it is ready for re-review

o Update the VISA COM installer with the reverted binaries, when they are available


o After we get consensus on changing the default installation directory, make this change in VPP 6.

Noel Adornoo After we begin work on 64-bit user level stuff, clarify 32 vs. 64 bit binary

naming for both VXIpnp & IVI driver DLLs. The affected VPP specs include 3.2 and 6.

Bob Helselo Make remaining VXIpnp specs available for download from IVI site. o Have VXIpnp download page point to IVI site.

Joe Muellero Lead conference call to discuss dynamic discovery and aliasing.


Chapter 7 Marketing Committee Meeting Minutes

General Meeting Info:Date of Meeting: October 10th 2006Location: BostonChairperson: Bob Helsel (in place of Dany Cheij)Minutes Prepared By: Scott Rust

Meeting Attendees:


Joe Mueller Agilent Technologies

John Harvey Agilent Technologies

Scott Rust NI

Jochen Wolle Rohde & Schwarz

Phillip Burke Boeing

Bob Helsel Bode Enterprises

Don Essner DRS

Dany Cheij NI (By teleconference)

John Ryland Keithley

Kirk Fertitta Pacific Mindworks

Hugues Valeid Pacific Mindworks

Eric Lord Pacific Power

Fred Weigand Raytheon

Teresa Lopes Teradyne

Johannes Ganzert Rohde & Schwarz

Christophe Greord TYX/EADS NA

Topics To Be Discussed: Introductions Review action items from previous meeting Discuss IVI intro document proposed at Fort Collins Periodic review of Web site

o Problems with ISP New business



Review minutes & action items from previous meetingOwner Action Item Deadline Status

Bob Helsel

Get a quote from SW company for doing some updates to the web site, specifically make a proposal (including costs) so that we can make a decision regarding unimplemented features of the Driver Registration page – email notification of new registrations, ability to delete a driver, and bulk upload of driver registrations

4/1/2006 In Progress

Bob Helsel

Fred Bode to work with Jeff Hulett to propose a way to give the user more sorting capabilities to the list of registered drivers. The ideal case would be to click on a column heading and sort by any column. A minimally acceptable alternative would be to export an excel spreadsheet which would allow the user to sort the information using standard tools found in the Excel environment.

TBD Deferred

Bob Helsel

Expand the Driver Vendor column so that it is the same width as the Manufacturer column. Requested by Roger Oblad.

TBD Deferred

Bob Helsel

Expand the truncation limit to allow the Supported Models to go to a maximum of three lines. Requested by Roger Oblad.

TBD Deferred

Bob Helsel

Roger would like to make the Type column wider so that “IVI-COM Specific” does not cause the line to wrap. It appears that it would be possible to take some space from the Supported Models column rather than making the overall table wider.

TBD Deferred

Bob Helsel

Investigate if/how we can get metrics on number of views of the driver registration page

TBD Deferred

Bob Helsel

Investigate hiring an outside writer to create an IVI basics document with the help of member volunteers

Autotestcon 2006

Started

Discuss IVI intro document proposed at Fort CollinsBob has been trying get the IVI Getting Started off the ground. Only one company volunteered to help generate content. Seemed to be general agreement that the group still wants to do this.


Gave a brief overview of the previously agreed upon outline. Took the outline to a couple of contract writers.

Consynia Marketing – $7200 Ken Stitsel – No bid Bode Enterprises – $5000

Data Translation and The Mathworks requested that their ADE products be included in the document: Matlab - Instrument Control Toolbox and the Measure Foundry

Christophe Greord (TYX) suggested that TYX PAWs could also be included.

Since we are expanding the list, Agilent wanted to include VEE as well.

Actions

Bob H to post a new outline in 2 weeks via email. Bob H to create a list of content experts that are willing to be interviewed by the

writer for the document. About an hour of initial work and ½ hour for review. Bob H to collect bids in about 1 month. Will send out to committee via email.

Periodic review of Web site

Bob H – for past 6 to 9 months have had consistent problems with the Driver Registration page. Took 3 months to get back to a working status.

Joe M – ISP changed underlying SW infrastructure without notification. ISP keeps changing permissions such that we can write files to the web site. So WG group chairman couldn’t write files and the driver registration script can’t write updates to the driver registration page. This has happened approximately 3 times in the last year.

eNet is the current ISP. Studio:Multimedia has been helping us with advice/corrections to eNet. eNet doesn’t seem to understand that their changes have big negative impacts on our web site and they don’t understand how to fix it when they make these changes. Therefore, we don’t believe that eNet is a capable enough ISP for our web site.

Bob H has gotten quotes from Studio:Multimedia ($4.5k - $6k to setup and $100/hr for support) and Kavi ($4.5K for initial setup, ~$2K for driver registration, and ~$1.3k/month for support) to host our website and implement requested maintenance and fixes. Everyone contacted said that the underlying structure/foundation needs to be fixed in order to have a long-term solution.

Lowest cost solution is to keep it as is and fix problems, but all consultants say that the current site is a “mess”.


Concerns:Joe M – Can we improve the look-and-feel and the navigation without requiring substantial content changes? Want whatever proposal to use the existing content as a constraint. That is, we don’t want to be forced to create a lot of new content because navigation is improved.

Joe M – are the suggestions coming from a technologist or a usability expert? Bob believes that they do not have a usability expert on-board but they do have some graphic artists.

Scott R – suggested that we structure the contract so that a first milestone is to show us a look-and-feel proposal and pay some percentage of the overall cost at that time.

Are there any licensing costs for any of the technologies that are proposed to be used? Bob doesn’t believe so, but needs to ask for clarification.

Joe M – What is the ongoing expense for support? This would be at on a contract basis and would be $100/hr.

Joe M – What is the expense for a more professional ISP? ~$75/month. This is about the same amount that we currently pay.

Kavi seem is very good at the mechanics of running a consortium and have a large support costs. Seem to be good at charging for maintenance above and beyond the ~$1.3k/month for support.

General Bias towards the following priorities The driver registration must work consistently and not be brittle Customers should be able find drivers easily Need a baseline of capabilites for working group activities

o Mailing listso Place to post docso Ability to download docs that are postedo Modifiable via easy and widely accessible tool (such as FrontPage or

others)o Permissions for working group chairmen that restrict access so that

accidents don’t take down the whole site. Site backup – Minimum is working group areas and driver registration data

Group had a general bias against pursing Kavi. Will pursue something like Studio:Multimedia or other supplier.

General agreement that a dues increase is an acceptable way to fund web site enhancements.

Actions:


Bob H to review finances and come with proposals for how to finance web enhancements to the BoD on Thursday.

Bob H to work with a smaller set of members to flesh out a proposal with Studio:Multimedia: Dany C, Joe M, Kirk F, Jochen W.

New business

Summary of Action Items:

Owner Action Item Deadline Status

Bob H. IVI Getting Started: Post a new outline in 2 weeks via email.

Bob H. IVI Getting Started: Create a list of content experts that are willing to be interviewed by the writer for the document. About an hour of initial work and ½ hour for review.

Bob H. IVI Getting Started: Collect bids in about 1 month. Will send out to committee via email.

Bob H. Web Site: Review finances and come with proposals for how to finance web enhancements to the BoD on Thursday.

Bob H. Web Site: Work with a smaller set of members to flesh out a proposal with Studio:Multimedia – Smaller set of people to include Dany C, Joe M, Kirk F, Jochen W.


Chapter 8 Counter/Timer Working Group

General Meeting Info:Date of Meeting: October 10-11, 2006Location: Boston, MassachusettsChairpersons: Phillip Burke (Boeing), Don Essner (DRS)Minutes Prepared By: Phillip Burke, Don Essner

Meeting Attendees:

Name Company Email PhonePhillip Burke Boeing [email protected] 314.233.4501

Don Essner DRS [email protected] 314.553.4238Scott Rust NI [email protected] 512.683.5472

Joe Mueller Agilent [email protected] 970.679.3248Omar Vitobaldi Elgar [email protected] 858.450.0085 x2320

Jochen Wolle R&S [email protected] 1+49.89.4129.13044

Agenda:1) Review Action Items from May 2006 Meeting2) Discuss Measurement section of COM hierarchy3) Discuss prototype results4) Discuss Extension Groups5) Review latest Counter Specification Document6) Discuss WG direction for October-February7) Create new Action Items


Discussion:

1) Review Action Items from May 2006 Meeting

# Action Item Discussion Assigned To Due Date

1 Nimbus licensing, check with Pacific Mindworks if other IVI members can use license for spec prototyping

Complete, Pacific Mindworks extended licensing and online tutorial offer to any IVI members working on IV spec prototypes

Boeing/DRS 10/10/2006

2 Get the repeated capabilities pattern in the COM hierarchy (count and name) and cross class capabilities

Repeated capabilities added to COM Hierarchy. Cross class capabilities in work.

Boeing/DRS/ Joe Mueller (reviewer)

10/10/2006

3 Add Measurement section to COM hierarchy

Complete, will discuss later. Boeing/DRS 10/10/200

64 Investigate and identify

potential counter extensions.

Complete, will discuss later. Boeing/DRS 10/10/200

6

5 Define Interchangeability Checking rules and place in appendix

Complete, will review later. Boeing/DRS 10/10/200

6

6 Add compliance notes to functions and attributes as needed

In work.Boeing/DRS 10/10/200

6

7 Design COM hierarchy displayed as a Visio drawing

Complete.Boeing/DRS 10/10/200

6

8 Email current API to WG members

Complete. Boeing/DRS 5/22/2006

9 Complete prototypes In work, will discuss later. Boeing/DRS 8/15/2006

10 Draft spec member review Complete, will review later. Boeing/DRS 10/10/200

6


2) Discuss Measurement section of COM hierarchya) Read will have a timeout (consists of initiate and fetch)

This is consistent with other specificationsb) Should fetch have a timeout like DMM, or does this add other implications for

programming? Returned values:i) Max time exceeded (e.g. no response, no trigger, no gate…)ii) Over/under range (e.g. totalized exceeded counter up or down limit)To replicate read using initiate and fetch, fetch requires a timeout.

c) Should there be a “Is Measurement Complete” like Power Meter, or is it accomplished through the status command with the status parameters of “measurement complete”, “measurement in progress”, and “measurement status unknown”.Polling using “Is Measurement Complete” is not recommended. Follow model of DMM specification.

3) Discuss prototype resultsa) Agilent, DRS, and NI are working on prototypesb) What worksc) What doesn’t workd) Suggested changes

Zulifgar Haider (NI) and Don Essner (DRS) have started prototypes. Zulfigar responded with some issues that he had with the prototyping of the Agilent 53131A/132A (common 2 channel Counter). Many of the problems were from differences between current specification and what Zulfigar was working from. Some significant issues were creating an auto mode for measurements where estimate and resolution were not valid.

4) Discuss Extension Groupsa) Averaging

Delete - The base class configures the measurement resolution which can be achieved through averaging. A post measurement numerical averaging can be done in software.

b) Delay (Time Interval)Retain - Should delay be allowed for all measurements, or just Time Interval? Need to investigate further how instruments implement this.

c) Filter (High Pass, Band Pass)Retain - Need to determine how instruments implement this.

d) Power (power, cable loss)TDelete - the universal counter model makes more sense to measure voltage, maybe a good fit for µW counters.

e) Voltage (max, min, AC rms, DC) Retain - Max and min would be useful and probably are supported by most, need to investigate AC rms and DC availability among instruments.


f) Scale/offset Delete - Can be done in software.

g) Analysis/Mathematical (mean, std. dev)Delete - Can be done in software.

h) Continuous Totalize (resume)Delete - Can be done in software.

i) Gating / Arming Delete - Too complicated for now, other instruments may be better at this.

j) Events Delete - Too complicated for now, other instruments may be better at this.

k) Waveform (Acquisition)Delete - This is instrument specific.

l) Multiple simultaneous measurementsMaybe - Investigate modifying base class to support this?

5) Review latest Counter Specification Document Draft was reviewed. Teresa posted it on the web site for all to review on

Tuesday night for the Wednesday meeting. Certain sections were noted for extended review. Continued review on Wednesday.

Alphabetize Section 4 Attributes and Functions also Attribute ID Values table.

Consider adding some extension groups now for first release In attributes add note to see function for complete description. In function compose a more complete description. For Channel Level (4.2.5) need to determine coercion. Is hysteresis missing, or part of level? Replace geometric with another

word. For COM Enumeration Type, put in N/A or remove based upon other

specifications. For Defined value and Compliance notes, use “None.” or remove based

upon other specifications. 4.2.8 used as a query (read only). It probably should be used as set

mode (r/w) that would set enumerated types. Joe will look at adding Standard Cross Class capabilities to replace the

TTL0-7 and other similar trigger lists in the IVI specifications. Need to modify Description under all functions to be more verbose. Need to add place holders for .NET in document (refer to action item from

.NET WG).

6) Discuss WG direction for October-Februarya) Incorporate comments and suggestion into spec document

Will update specification using comments from this meetingb) Implement and test counter prototype drivers

Will continue work on prototypes.


7) Create new Action Items

# Action Item Discussion Assigned To Due Date

1 Determine how to implement delay (Time Interval?) from item 4b above

Boeing/DRS 2/6/2007

2 Make corrections/changes to Specification

Boeing/DRS 2/6/2007

3 Joe will look at adding Standard cross class capabilities to replace the TTL0-7... lists in the different documents.

Agilent 2/6/2007

4 Investigate attributes listed by Zulfigar that are not supported

Boeing/DRS 2/6/2007

5 Investigate how to support an auto function

Boeing/DRS 2/6/2007


Chapter 9 64 bit OS and Data Type Support

General Meeting Info:Date of Meeting: October 11, 2006Location: Boston, MassachusettsChairperson: Jon BellinMinutes Prepared By: Jon Bellin

Meeting Attendees:


Jon Bellin National Instruments 512-683-5516 [email protected] Mondrik National Instruments 512-683-8849 [email protected] Harvey Agilent Technologies 970-679-3535 [email protected] Sreedhara Tektronix +91-90-22105535 [email protected] Valois Pacific Mindworks 858-587-8876 [email protected] Fertitta Pacific Mindworks 858-587-8876x237 [email protected] Ryland Keithley 440-498-3134 [email protected] Lopes Teradyne 978-371-1377 [email protected] Gaudette The Mathworks 508-647-7759 [email protected] Ganzert Rohde & Schwarz +49-89412913405 [email protected]

schwarz.comRob Purser The Mathworks [email protected] Mueller Agilent Technologies 970-679-3248 [email protected]

Topics to Be Discussed: Review Previous Meeting Action Items Jon Bellin

o Review progress on spec changes Vpp 3.3 changes for 64-bit integers and extended .sub file

hierarchy Vpp 3.4 changes for 64-bit integers IVI 3.1 changes for 64-bit integers IVI 3.2 changes for to add 64-bit integer attribute functions for

IVI-C IVI 3.1 change document for 32-bit apps on Vista

Jon Bellin for Zulfiqar Haider o Progress on changes needed to the shared components for Vistao Changes in Vista since the last meeting

John Harvey








o Clarification of IVI 3.1 spec with regard to C wrappers on IVI-COM drivers.

o How to express 64-bit integers in COM.o Issues with Event Server on Vista:

Unpredictable results in spawned Event Server after spawning process terminates.

Only one instance of server receives events when two users run sources and sinks.

Dan Mondriko Propose revised directory structureo Coexistence of 32-bit and 64-bit binaries

Jon Bellino Sharing Config Store between 32-bit and 64-bit applications

Identify items to refer to Technical Committee Identify action items


Jon: Vpp 3.3 changes to add 64-bit integers and extend .sub file hierarchy

This has been approved by a vote of the Technical Committee.

Jon: Vpp 3.4 change document to allow use of 64-bit integers

This has been approved by a vote of the Technical Committee.

Jon: IVI 3.1 change document to allow use of 64-bit integers

Held in abeyance from previous meeting pending Agilent’s decision on proposed data types for IVI-COM.

Reviewed the change document.

John Harvey: _int64 does not work on Visual Basic 6. Known issue. _int64 may not work on Windows 2000 in some scenarios. Nevertheless, _int64 is the only reasonable choice. So we just need to document where it does not work so that driver developers can

intelligently choose whether to use 64-bit integers.

Add a cautionary statement in the spec that 64-bit integers don’t work in VB 6 (applies to both IVI-C and IVI-COM).


We also need to add a cautionary statement about Win 2000. John wants to take some time to determine the techincal facts. So he would prefer that we put a placeholder in the spec and go ahead with the review process now. The final version of the Win 2000 caution can be made as an editorial change.

Suggested placeholder text for Windows 2000: “In some scenarios __int64 and SAFEARRAY(__int64) might not work correctly on Windows 2000. This will be explained in more detail as an editorial change in the future.”

Jon: IVI 3.2 change document to add 64-bit attribute functions

Reviewed the change document. Ready for review along with the IVI 3.1 64-bit change document.

Jon: IVI 3.1 change document for support of 32-bit apps on Vista

Reviewed the change document.

Hugues: In Section 6.5.3, bullet 3: Does this mean to say that our default should not be the ProgramFilesDir for 64-bit applications, or also that the Shared Component Installer should prevent users from choosing the 64-bit ProgramFilesDir?

What should it do? Consensus is that the installer should prevent users from doing this. The text should be clarified.

Section 6.5.3, bullet 2: This is only an interim fix. We should add a note to that effect.

Ready for review after above issues are resolved. This change document really needs to be approved by the end of 2006.

Jon for Zulfiqar: Progress on changes needed to the shared components for Vista.

Moving registration from Event Server to Shared Component InstallerThis has been done. The IVI Event Server now registers successfully..

Changes to the Shared Component Installer

Add C:\Program Files (x86)\bin\ to system path on Vista 64o No longer needed. Fixed by Vista rc1.

Write fully qualified path for cleanup utility in ARP registryo No longer needed. Fixed by Vista rc1.


Modify attributes of <IVIStandardRootDir>\Data directory to disable virtualization and allow write access to processes running with standard privileges

o Done for entire directory so users can edit driver source without virtualization.

o We still have an issue when the shared component installer MSI is run with standard privileges (cannot request admin privileges for an MSI via a manifest). The installation appears to succeed except that the IviStandardRootDir directory attributes are not modified.

Hugues says that you can arrange for a custom action to request elevation by using a “Deferred” custom action and setting “Impersonation” to False.

Changes to the IVI Cleanup Utility Has been built with a manifest and now works correctly. If launched standalone, it prompts the user elevate privileges. Just like when run from ARP.

Not yet digitally signed. Kirk can do that.

Upgrade installation issue Problem can occur if user uses a non-Vista ready version of the Shared Components installer on Vista or upgrades to Vista with a non-Vista ready version of the Shared Components already installed, and then uses non-Vista aware software to modify the Config Store.

The Config Store will already have been virtualized. Latter, when you install Vista-aware software, it uses the non-virtualized copy.

The user does not have a very good workaround in this case, unless he can be sure that the virtualized Config Store is completely up-to-date. In that case, he can copy it to the non-virtualized location.

Zulfiqar proposed a utility that renames the existing master config store file during installation, fixes up the registry entry for the master config store location, disables virtualzation on the copy, and merges the changes in the vitualized Config Store file(s) into the master copy.

Some skepticism voiced about the following: How hard this would be to implement. There cases that it would not solve (for example conflicting driver session names

across mutliple users). How likely it is that users will have this problem.

Jon suggested that we give Zulfiqar a chance to implement this utility. Conflict situations can be handled by renaming the conflicting items and notifying the user.


Zulfiqar: Changes in Vista since the last meeting . General

o Improved stability and performanceo Less frequent and less annoying UAC pop-upso Better hardware and software compatibility

Vista64 Fixeso SysWow64 directory implicitly included in search path for 32-bit

applicationso MSI property ProgramFilesFolder correctly evaluates to C:\Program Files

(x86) instead of C:\Program Files

John Harvey: How to express 64-bit integers in COMCovered in Section 1.4.3 above.

John Harvey: Remaining Issues with the Event Server

From last meeting:

When one process spawns another, the spawned process generally inherits the privileges of the spawned process.

If the spawned process outlives the spawning process, you may get unpredictable results. Example: The Event Server is spawned by unelevated process. If later, an elevated process tries to send an event, the Event Server cannot process it.

Preliminary results still to be validated: If two users both run an elevated Event Server source and elevated Event Server sink, they all run, but only one sink receives events.

John has not been able to get to this. He pointed out that the common, straightforward scenarios on Vista work properly.

John Harvey: Clarification of IVI-3.1 regarding C wrappers on IVI-COM driversJohn wants clarification with regard to the scenario in which the C wrapper is distributed with the IVI-COM driver. The fundamental problem is that the spec was ambiguous. Under one interpretation, tools that look for C drivers do not find all the pieces. Under another interpretation, there are name conflicts between the .h files from IVI-C and IVI-COM.

John proposes the following changes:

A driver with a C wrapper shall create only one directory in the Drivers directory, and that shall be named after the C wrapper prefix. (Currently, the spec is ambiguous


but seems to imply the directory is named after the Component ID of the IVI-COM driver.) The one directory will contain the files for both IVI-C and IVI-COM.

All files that the driver installer installs shall be named after the C wrapper prefix. (The specs for IVI-COM say use the Component ID, and the specs for IVI-C say use the C prefix. The spec does not resolve this conflict for the wrapper case.)

The C wrapper will be implemented in the IVI-COM driver DLL. (This is what the spec says today.)

The COM .h and _i.c files will not be delivered. (They are not need because the C wrapper is available instead.)

To avoid further confusion, either the specification text on wrappers must say that it this an exception to the rules for IVI-COM, or the IVI-COM specs must acknowledge the wrapper specs as having precedence in the case where the IVI-COM driver is distributed with a C wrapper.

What happens when you upgrade from an existing IVI-COM driver to one with a C wrapper that follows the new rules? The only problem we could think of is that the Software Module entry name in the Config Store might be different. This could be fixed up by the driver installer.

The specs that need to be changed are IVI 3.1: Sections 5.17 and 6.6.5.

John Harvey will take a first stab at modifying these sections. He will send his suggested changes to Noel and Jon.

Dan Mondrik: Proposed revised directory structure

Dan proposes the following changes:

Create a new IVI Foundation directory. Put VXIpnp and IVI subdirectories under IVI Foundation. Remove the Data subdirectory from the IVI directory tree.

o Move the Config Store to the <All Users><App Data> directory (CSIDL_COMMON_APPDATA), which is C:\ProgramData on Vista by default.

Shared component installer will ensure that it is writable by all users

For 32-bit user mode, continue to set VXIPNPPATH in both the registry and as an environment variable. For 64-bit user mode, set it in the registry only.

Do this on 2000 and XP as well as on Vista. o This will make the installers easier to implement

John Harvey’s initial reaction was that “IVI Foundation” is a lot of characters and that “IVI” would be repeated in pathnames, but he also likes the idea of having everything under an IVI Foundation directory.


Dan noted that keeping the instrument drivers under Program Files means that modifying driver source files requires admin privileges. Tools that lets users edit driver source files in place may need to be changed. They would have to copy the files to the user’s Documents directory so the user can edit them. An alternative would be to install the driver source files to the Documents directory. This would then leave the source files editable without admin privileges. The consensus was that keeping the source under Program Files is a good idea because it protects the original copy of the source.

Dan Mondrik: Coexistence of 32-bit and 64-bit binaries

On Vista 64, the 32-bit and 64-bit user mode DLLs will both be in the system path. To avoid name conflicts, Dan propses that “_64” be appended to the names of the 64-bit user mode DLLs. This would apply to all DLLs, including driver DLLs, for both VXIpnp and IVI.

There was consensus on this approach

Jon Bellin: Sharing Config Store between 32-bit and 64-bit applications

Possible Goals► User programs ported from 32-bit to 64-bit (coexisting on Vista 64) should work

without the user having to change either the logical name used in the application or the config store entries for the logical name and driver sessions.

► Do we want to allow having a 32-bit driver from one vendor and 64-bit driver from another? How feasible is it to allow or disallow this?

► Do we want to allow having a 32-bit driver that has a different version than the 64-bit driver from the same vendor? How feasible is it to allow or disallow this?

► Do we want to leverage SxS for 64-bit drivers?

Option #1► Keep one SW Module entry in config store for both 32-bit and 64-bit

Add a “ModulePath64” property How to avoid duplicate SW Module entries?

► Revisit IVI 3.1 Section 6.6.1 and 6.6.3 regarding how to determine whether a driver for an instrument is already on the system and what to do about it.

► Pros Least amount of change to existing implementations Very transparent to user programs Extends current model of pointing to both C and COM modules

► Cons


Does not allow for 32-bit and 64-bit drivers to be from different vendors without adding complexity

Does not match how the DLLs are installed (i.e., in different directories)

Option #2► Have separate SW Module entries for 32-bit and 64-bit

Append “_64” to SW Module entry name To allow transparent porting of user programs, Session Factory and Class

Drivers need to handle the “_64” when looking for SW Module entries ► Pros

Small amount of change to existing implementations Very transparent to user programs Matches how the DLLs are installed (i.e., in different directories)

► Cons Small amount of change to existing implementations Possible oddities with the auto-redirection on SW Module names Affects other clients that don’t go through Class Drivers

Option #3► Two separate config stores

Config GUIs would have to write to both config stores when user makes changes

► Otherwise, user would have to configure both config stores separately

► If the user does not, odd results might occur Users do not necessarily choose or even know whether the

apps they run are 32-bit or 64-bit► Pros

No modification to the config store format or to the Session Factory or class drivers

► Cons Would make config GUIs (and other apps that write to the config store)

much more complex► No leverage from IVI Foundation supplied components

Jon said that NI prefers Option 1.

John Harvey thinks it is a good idea to disallow having a 32-bit driver from one vendor and a 64-bit driver from another vendor for the same instrument.

Kirk: It is a con to Option 1 that adding properties to the Software Module entry require us to rev the Config Server IDL and PIAs. Could be done at same time as adding the Assembly property for IVI.NET.


Do we need separate Prog IDs in the Software Module entry for 32-bit and 64-bit COM DLLs? Due to separate registry sections for 32-bit and 64-bit applications, we probably need only one.

Do we need separate Assembly properties in the Software Module entry for 32-bit and 64-bit .NET assemblies?

Items to refer to Technical Committee for a voting: IVI 3.1 and IVI 3.2 change documents for 64-bit integers will be ready for review

in a few weeks. o Get approval for Win 2000 placeholder text and future update as editorial

change. IVI 3.1 change document for 32-bit Vista apps will be ready for review in a few

weeks.o Needs be approved by the end of the year.

Another IVI 3.1 change document will be coming regarding C wrapper conventions.

Action Items: Jon Bellin:

o Let Zulfiqar know about Hugues’ fix for MSI to request elevation.o Let Zulfiqar know that Kirk can digitally sign components.

Zulfiqar:o Resolve Hugues’s question regarding the IVI 3.1 change document for 32-

bit Vista apps. Need to clarify the text either way. o Try out Hugues’ fix for MSI elevation.o Try to implement the utility to fix up virtualized config stores.o Prepare thoughts for next meeting on sharing Config Store between 32-bit

and 64-bit applications Noel Adorno:

o Update text in IVI 3.1 change document for 32-bit apps: Section 6.5.3, bullet 3: Refer to Zulfiqar’s action item. Section 6.5.3, bullet 2: Add note about being interim solution

only.o Add VB 6 and Win 2000 cautions to the IVI 3.1 64-bit integer change

document.o After updating, post for review the following change docs: IVI 3.1 64-bit

integer, IVI 3.2 64-bit integer, and IVI 3.1 for 32-bit Vista apps. IVI 3.1 change document for 32-bit apps on Vista should be posted

by October 25.o Create change document based on John Harvey’s proposed changes to IVI

3.1 Sections 5.17 and 6.6.5. Dan Mondrik:


o Add text to VPP 2 and/or VPP 6 similar to the IVI 3.1 change document for 32-bit apps on Vista.

John Harvey:o Characterize precisely what does not work properly in the Event Server on

Vista.o Create a plan to fix Event Server problems on Vista.o Send Noel and Jon proposed modifications for IVI 3.1 Sections 5.17 and

6.6.5 by December 15.o Prepare thoughts for next meeting on sharing Config Store between 32-bit

and 64-bit applications.


Chapter 10 IVI Signal Working Group Meeting Minutes

General Meeting Info:Date of Meeting: October 11th 2006Location: BostonChairperson: Ion Neag (interim Chairperson)Minutes Prepared By: Scott Rust

Meeting Attendees:

Name Company

Joe Mueller Agilent Technologies

Ion Neag Reston Software

Scott Rust NI

Jochen Wolle Rohde & Schwarz

Phillip Burke Boeing

Don Essner DRS

Andreas Randow Data Translation

Dirk Schmischke Data Translation

Omar Vitobaldi Elgar

Christophe Grard TYX/EADS NA

Record of Discussions:Ion opened the meeting as the last known chairman of the working group.

Ion is no longer working for TYX. He is willing to continue working on the spec, but wants to gauge the interest and effort that other members are willing to provide.

Ion reviewed the current status of the specification

Charter of group was recently approved. Have a draft version of the specification. Remaining work

o Prototyping – Some prototypes have been started, but are not complete and are not consistent with current spec.

o Align with ATML o Coordinate with IEEE 1641o Possibly add C, .NET versions of the API


o Final technical review spec Benefits

o Signal Driver API Interchangeability across classes Accuracy can be guaranteed Cost savings by supporting ATLAS and non-ATLAS test

programs Usable in AEEE 1641 & ATML systems Usable for controlling Synthetic Instrumentation

o Standardized API Obsolescence protection Candidate for DoD DISR

People who have previously expressed interest in prototyping: The Mathworks, Pacific Mindworks, R&S, Teradyne, and TYX.

Ion says that he will not be able to help with prototyping but would be willing help with general working group activities including reviewing the spec, writing the spec, and coordinating with other standards bodies and the military.

Discussed need to find a chairman for the working group.

Action: Scott Rust to email IVI list server to ask for volunteers to chair the Signals Working Group. The response deadline is Dec 31st. This is to allow time to determine if we should schedule a Signals Working Group meeting at the February meeting and to have time to make sure that it is productive.

TYX expressed an interest in seeing the work completed, but could not commit at this time as to their level of involvement.

Meeting Adjourned.


Meeting Minutes - February 2006 - IVI Foundation · Web view(scope) 0 (at least start) PMW Phone...

Documents

Transcript of Meeting Minutes - February 2006 - IVI Foundation · Web view(scope) 0 (at least start) PMW Phone...