Meeting Minutes - June 2001 - IVI Foundation€¦ · Web viewName Company Phone Email Roger P...

IVI FoundationMeeting Summaries

January 27th – 30th, 2003Marriott Austin Airport South

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

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

3. JANUARY 2003 IVI BOD MEETING........................................................................................................ 4

4. TECHNICAL COMMITTEE...................................................................................................................... 9

5. .NET WORKING GROUP........................................................................................................................ 15

6. EO NXTEST WORKING GROUP............................................................................................................ 17

7. INTEROPERABILITY SESSION AND DEVELOPER FORUM MEETING SUMMARY...................20

8. USER WORKING GROUP....................................................................................................................... 26

9. MARKETING COMMITTEE................................................................................................................... 29

10. VISA WORKING GROUP.................................................................................................................... 32

11. IVI SIGNAL INTERFACE WORKING GROUP.................................................................................38

12. CONFORMANCE WORKING GROUP...............................................................................................44

13. ACTION ITEMS:................................................................................................................................... 50

14. IVI NET WORTH – JANUARY 27TH, 2003...........................................................................................51

IVI Foundation Meeting Minutes 1 January 27-30, 2003

2. Meeting Attendees

Name Company Phone Email David Gladfelter Agilent Technologies (970) 679-5329 [email protected] Mueller Agilent Technologies (970)679-3248 [email protected] P. Oblad Agilent Technologies (707) 577-3466 [email protected] Greer Agilent Technologies 970 679-3474 [email protected] Bode Bode Enterprises 619-297-1024 [email protected] Davis Boeing 3142342722 [email protected] Raney Boeing [email protected] Ryland Keithley Instruments [email protected] Shah Keithley Instruments 440-498-2934 [email protected] J. O'Donnell

Lockheed Martin 407-306-4325 steven.j.o'[email protected]

Mario Saracino Lockheed MartinKeith Cheshire Lockheed MartinDan Mondrik National Instruments 512-683-8849 [email protected] Cheij National Instruments 5126835286 [email protected] Rohacek National Instruments 512-683-5540 [email protected] Burnside National Instruments 512 683 5472 [email protected] Bellin National Instruments 512-683-5516 [email protected] Adorno National Instruments 512 683 5071 [email protected] Rust National Instruments 512 683 5680 [email protected] Matysek Northrop Grumman ES 410-765-9754 [email protected]

mKirk Fertitta Pacific MindWorks (858) 587-8876

[email protected]

John Rosenwald Racal Instruments 210-699-6799 x 212

[email protected]

Dan Masters Racal Instruments 949-460-6760 [email protected] Ta Racal Instruments [email protected] Ptacek Rockwell Collins 319-295-0198 [email protected] Wolle Rohde & Schwarz ++49 89 4129

[email protected]

Johannes Ganzert Rohde & Schwarz -13356.02155 [email protected]

David Barrington SSAI 321-724-5566 X293

[email protected]

Ronald C. Salley Support Systems (321) 724-5566 [email protected]


Name Company Phone EmailAssociates, Inc. x294

Badri Malynur Tektronix 503-627-5880 [email protected] Nelson Tektronix 503-627-3138 [email protected] Hutchinson Teradyne 978-370-1277 [email protected]

mTeresa Lopes Teradyne 978-370-1377 [email protected] Gaudette The MathWorks, Inc. 508-647-7759 [email protected] Neag TYX Corp. (703)264-1080

[email protected]

Dan Wolfe U. S. Navy Contractor 904-317-2080 [email protected] Hulett Vektrex 858.558.8282

[email protected]

Rengan Rajendran Vektrex 858.558.8282 x20

[email protected]

Howard Savage SCI 561-586-9254 [email protected] Biriagris US Navy 301-995-6408Mark Hanchey Eagle 301-872-0291Kenn Bates Raytheon 310-952-4336 [email protected] McHugh SBIR 805-965-3669 [email protected]


3. January 2003 IVI BoD Meeting

IVI Foundation Directors in attendance:

Director Company Designee (if any) PresentJohn Ryland Keithley Instruments YesScott Rust National Instruments YesKirk Fertitta Pacific MindWorks, Inc. YesJohn Rosenwald Racal Instruments Dan Masters YesJochen Wolle Rohde & Schwarz YesBadri Malynur Tektronix YesAndy Hutchinson Teradyne YesNarayanan Ramachandran

TYX Corp Ion Neag Yes

Jeff Hulett Vektrex Electronic YesJoe Mueller Agilent Technologies Yes

3.1 Agenda

Review previous meetings minutes Introduce new members Outstanding License agreements Report on Merger with SCPI and VXIplug&play

- Review history of SCPI and VXIplug&play- Report from Fred on work with attorney- Review IP transfer with SCPI and VXIplug&play

Vote on VISA 3.0 (at request of VISA working group of VXIplug&play foundation) Treasurers report Discussion of electronic voting

- Establishing Quorums and abstaining- Composing resolutions- Resolutions from subcommittees

Report from Marketing committeeo Especially interested in report from Autotestcon and Electronica (Munich)o Question about Autotestcon paperso Progress on web site (per $5K allocated in July)

Revision of the web site Note upcoming vote for BoD on digital certification requirement – possibly authorization to

spend money on both legal opinion and certification fees (Verisign)


Next meeting


3.2 Minutes10 directors establishes a quorum.

3.2.1 Review previous meetings minutes

Approved as submitted.

3.2.2 Introduce New MembersFour new members.VXI TechnologyAeroflex - 2003Selectron – associate memberRaytheon – associate member

3.2.3 Outstanding Licenses required (Per July meeting)

Licensor TechnologyNI Patents relating to IVINI Common Component Installation & Clean-upNI C Shared ComponentsNI Floating point servicesNI VISA-COM Global Resource ManagerNI IVI TrademarkRacal Session FactoryAgilent Configuration ServerAgilent Event ServerAgilent VISA-COM Formatted I/O

Fred volunteered to urge directors of these three members to issue licenses for their items. The legal committee created a form for these licenses. The board would like these licenses by February 28.

3.2.4 Report on Merger with SCPI and VXIplug&playo Report from Fred on work with attorneyo Review IP transfer with SCPI and VXIplug&play

Actions- Fred take the lead on re-constructing Agilent/HP license/transfer to foundation of

SCPI Patent (5,086,504)- Fred to ask attorney if it’s possible to exclude the transfer specifications from the IVI

IP policy. If it is, have the attorney include that exclusion. If not, have attorney advise us on how to proceed. Fred will distribute answer to list server by February 14.


Scott moved to re-create the legal working group. Jochen seconded. Its purpose is to resolve the potential IP issues associated with merging with SCPI and VXIplug&play. Unanimously approved.Fred, Joe, Dany, and Badri will participate. Fred is chair.

The board will continue pursuing the merger.

3.2.5 Vote on VISA 3.0 (at request of VISA working group of VXIplug&play foundation)

Technical work on 3.0 is complete. All members present are ready to vote on the specification. Once the IP issues associated with the merger are resolved, the president will conduct an e-mail vote.

3.2.6 Treasurers reportFred presented an income and expenses statement for 2002. He then presented a proposed budget for 2003. Board will vote on the budget electronically after it can be distributed in final form.

Jeff Hulett requested that the budget include a more complete analysis of the cost of the web site.

Scott moved that working group chairs are responsible for the cost of tele-conferencing being distributed among the working group members. Andy seconded. Approved 7-1-0.

3.2.7 Discussion of electronic votingo Establishing Quorums and abstainingo Composing resolutionso Resolutions from subcommittees

Scott moved to establish a working group to document operating procedures and voting procedures for technical committee, bod, and shared components management with Joe Mueller as chair. Kirk seconded. Approved 7-0-0Members: Scott and Dany

3.2.8 Report from Marketing committeeo Especially interested in report from Autotestcon and Electronica (Munich)o Question about Autotestcon papers

3.2.9 Revision of the web site

Ion mentioned that the current web site has several defects. Ion will send his list to Fred. Jeff agreed to find someone to help Fred to fix the worst defects. Scott moved to allow Fred to spend up to $500 to fix the most egregious defects. Badri seconded. Approved 7-0-0


3.2.10 Note upcoming vote for BoD on digital certification requirement – possibly authorization to spend money on both legal opinion and certification fees (Verisign)Dany may already have material on digital certificates which he will send to Joe and Fred.

3.2.11 Next meeting- Catering – leave the decision on whether to cater lunches to the host.-

Adjourned 3:30 pm.


4. Technical Committee

4.1 General Meeting Info:Date of Meeting: January 29, 2003Location: Austin, TXChairperson: Scott RustMinutes Prepared By: Dany Cheij

4.2 Meeting Attendees:

4.3 Topics To Be Discussed:- Introductions- Review Agenda - Review Voting Members In Attendance- Approve minutes from the July 2002 Technical Committee Meeting

- Case Sensitivity Issue- Shared Component Management status- Help files- Voting process for shared components- Location on Website for shared components- VISA shared components are ready for review- .NET – How/where to specify new requirements- Request from the Marketing Committee for volunteers to work on IVI Specification

Guide- New work to pursue- New Business - EO Working Group request for help- Process for updates to existing specs- Upcoming meetings- Discuss agenda and times for Munich Meeting – - Discuss timeframe and location for upcoming next meeting- Adjourn

4.4 Voting Members In Attendance

Company Voting RepresentativeAgilent Technologies Joe Mueller

Boeing Don Davis

Keithley John Ryland

Lockheed Martin Steve O’Donnell

National Instruments Scott Rust


Company Voting RepresentativeNorthrop Grumman Gayle Matysek

Pacific MindWorks Kirk Fertitta

Racal Instruments Dan Masters

Rohde & Schwarz Jochen Wolle

Support Systems Associates Ron Salley

Tektronix Badri Malynur

Teradyne Teresa Lopes

The Mathworks Thomas Gaudette

TYX Corp Ion Neag

Vektrex Electronic Jeff Hulett

There are 15 voting members in attendance. Being more than 25% of the total voting membership (22 voting members), this satisfies the requirements for a quorum.

4.5 Approve minutes from the July 2002 Technical Committee MeetingNo issues were brought up with the minutes. The TC chairman accepted the minutes.

4.6 Case Sensitivity IssueJon Bellin gave a presentation on case insensitivity for the IVI logical names and other data in the config store.

Jon Bellin then moved to direct the config server working group to change the IVI 3.5 specification to specify case insensitive compares on the names of IVI objects in the config store (such as logical names and software module names but not XML tags and attribute names), and to direct the Foundation to make corresponding changes to the shared components.

Gayle Matysek seconded the motion.

Discussion ensued. Ron Salley, Kirk Fertitta, Gayle Matysek, Jeff Hulett, Dave Gladfelter, Tom Gaudette, Joe Mueller, Johannes Ganzert, Steve Greer, Ion Neag, Badri Malynur gave opinions on the issue.

Steve Greer read from the IVI-3.5 spec about the requirements for using the config server to access the config store. The spec states that the config store can be accessed directly but this is highly discouraged.

Dave Gladfelter asked whether case insensitivity was limited to the ASCII character set or the full Unicode character set. The answer from Glenn Burnside was that he used a function call that compared based on the Unicode character set.

A vote was taken with the results 3 in favor and 12 against. Motion failed.


4.7 Shared Component Management status

4.7.1 Help filesRengan said that at the meeting in San Diego there was a commitment to create help files for the instrument classes. Currently there are no help files being installed with the shared components.

Steve Greer talked about the fact that Agilent used a proprietary tool to create the compiled html files for the help. It may be a problem to have to share the source to the files for review by the shared components review committee.

The solution is to provide html files as the source code for review by the Foundation which would overcome this issue.

Steve asked about an official logo to include in the help files. Dany will make the logo available to the people involved in this process.

Action ItemsSteve and Johannes will make the help files they have created available to the Foundation.

Steve (working with Fred and the Foundation attorney) will check whether the help files are copyrighted, whether they need to have a mark on them, and if they are copyrighted what members and non-member users can and cannot do with them.

Steve will lead this effort and the people who are interested thus far are Jeff Hulett, Kirk Fertitta, and Johannes Ganzert.

4.7.2 Voting process for shared componentsScott Rust said that he wrote a paragraph in the shared components operating procedures section. His intention was that shared components would follow the same process as the specifications. Joe Mueller said that following a different procedure for the shared components would mainly be for expediency.

Discussion also ensued about how the determination would be made whether something is a major change or just a bug fix. Steve Greer read text from the shared components operating procedures document.

Joe Mueller said that we need a IVI Foundation operating procedures document to clarify some of these issues.

Scott Rust then took a straw poll about whether people believe that the first iteration of shared components should go through the BoD for approval. Members preferred that they do not go through the BoD

4.7.3 Location on Website for shared componentsRight now the shared components are only available in an obscure area of the groups area. They should be available in a more prominent area.


Dan Masters moved to make the shared components directly available through a link from the Foundation’s home page. Joe Mueller seconded the motion.

Noel Adorno moved to amend the above motion to make the shared components installer and cleanup utility with the revision history available on the same page as the approved specifications. Dan Masters and Joe Mueller both agree to this amendment.

Motion approved 11-0.

4.7.4 Update to the shared component installer versionRengan stated that the shared components installer has been updated to a newer version from 1.0.4 which was voted on. The changes are minor bug fixes in the opinion of the group.

Action ItemsRengan will send Fred an updated version of the shared components to post on the website.

4.7.5 VISA shared components are ready for reviewThe VISA shared components will be available for review next week or very soon thereafter. The components will go through a three week review process.

Action ItemsRengan will announce to the list server the review of the VISA shared components.

Because these issues took a considerable amount of time, Scott Rust will schedule a shared components review WG time and a legal WG time at upcoming meetings.

4.8 .NET – How/where to specify new requirementsSteve Greer presented two alternatives: a separate addenda document that specifies .NET or updating existing specifications to include the new content. The mild consensus of the .NET working group was to have it as a separate addenda document. Scott Rust asked whether there are objections to this recommendation.

Action ItemsScott Rust will assign a document number to this addenda document in the next week.

4.9 Request from the Marketing Committee for volunteers to work on IVI Specification GuideMarketing Committee needs help in drafting a document that summarizes all the specs as an “intro to IVI”.

Action ItemsDany Cheij will ask working group chairs to provide summaries of each of their respective specifications and will request volunteers to help the marketing committee pull all the information together.


4.10 New work to pursueThis topic has been discussed at the previous two meetings and postponed because of lack of bandwidth. Scott Rust asked whether anyone would like to start a new group.

Teresa Lopes asked to restart the work of the Digital WG. Racal, Pacific MindWorks, TYX, Boeing, Agilent, National Instruments, and Lockheed Martin expressed interest in joining this group.

4.11 New Business

4.11.1 EO Working Group request for helpSteve O’Donnell asked for interested parties to help the EO WG in drafting their specifications. Vektrex, Pacific MindWorks, TYX, and Agilent expressed interest in helping. These members are individually volunteering and not being directed by the Technical Committee to represent the Foundation.

4.11.2 Process for updates to existing specsNoel Adorno said that there are some typos in some documents and other changes to certain specs. Noel would like the affected parties to create a document that summarizes the changes and circulate to the Technical Committee for approval of these changes. Noel needs clarification of the process of making these changes.

Scott Rust said that the last time this happened, the chair circulated this change document for review and then the Technical Committee and the BoD voted to approve the changes.

Action ItemsScott Rust will ask all chairpersons to review any changes to their specs and create change documents for these changes.

Scott Rust will also push for the appropriate votes to get these changes approved.

The group also discussed what happens to the spec version numbers once these minor changes are made. Joe Mueller suggested that instead of changing version numbers, the words “editorial version x” where x is the change number would be added to the spec.

Action ItemsJochen Wolle will do this for the RFSigGen spec and document the process.

4.12 Upcoming meetings

4.12.1 Discuss agenda and times for Munich Meeting –

Working Group Time

.NET ½ day

Plug-Fest ¼ day


Developer’s Forum ¼ day

Technical Committee Meeting ½ day

EO Working Group 1 day

VISA Working Group ½ day

Signals Working Group ½ day

Users Committee ¼ day

Conformance ½ to 1 day

Legal ¼ day

Shared Components Management ¼ day

Digital Working Group ½ day

Operating Procedures ¼ to ½ day

Annual Meeting 1 hour

Business Meeting or Board of Directors ½ day

Marketing Committee ¼ to ½ day

Totals 3 ½ to 4 days

4.12.2 Discuss timeframe and location for upcoming meetingsJochen Wolle said that R&S would be willing to host the next meeting in Munich. Badri Malynur said that Tektronix would be willing to host an upcoming meeting in Portland.

A poll of the group resulted in holding the Munich meeting in May and a Portland meeting in September.

The dates of the Munich meeting are set for May 12th – 15th.

The dates of the Portland meeting are tentatively set for the week of September 8th.

Lockheed Martin and Vektrex have volunteered to host subsequent meetings in Orlando and San Diego respectively.

4.13 Adjourn Meeting adjourned


5. .NET Working Group

5.1 General Meeting Info:Date of Meeting: 27 January, 2003Location: Austin, TexasChairperson: Jon BellinMinutes Prepared By: Glenn Burnside


Name Company Email

Jon Bellin (chair) National Instruments [email protected] Burnside National Instruments [email protected] Ta Racal Instruments [email protected] Wolle Rohde & Schwarz [email protected] Greer Agilent

[email protected]

Ronald Salley Support System Assoc.

[email protected]

David Barrington Support System Assoc.

[email protected]

Premal Shah Keithley Instruments [email protected] Gaudette The Mathworks [email protected] Lopes Teradyne [email protected] Nelson Tektronix [email protected] Ptacek Rockwell-Collins [email protected] Malynur Tektronix [email protected] Mueller Agilent

[email protected]

Kirk Fertitta Pacific Mindworks [email protected] Ganzert Rohde & Schwarz [email protected]

schwarz.comRengan Rajendran Vektrex [email protected] Gladfelter Agilent

[email protected]

John Ryland Keithley [email protected]

5.3 Agenda:1. Review last meeting’s action items2. Stepehen Greer: Present, Discuss, and resolve work done so far (2 hours)


mailto:[email protected]




















3. Kirk Fertitta: How using PIA’s fits into IVI Foundation’s .NET strategy (4 hours)4. Assign new action items

5.4 Minutes: Steve Greer’s presentation:

o Resolved several issues regarding PIA installation and registration, for IVI Shared components and IVI Com drivers

o Developed a proposal for similar issues for VISA-COMo Question for technical committee regarding how to incorporate Steve’s document

into existing specifications. Kirk Fertitta’s presentation:

o Difference between public/private key and using digital certificate: Public/private key prevents unintended tampering Digital cert prevents intentional tampering

o Kirk recommends that the Foundation acquire a digital certificate for the .NET shared components, and that driver vendors be allowed but not required to use them.

o Regardless of whether we use a digital cert, we have to identify a process for applying the private key to the .NET shared components after the assemblies are built.

What future work needs to be done:o Start working on what we think the best native .NET interfaces are for IVI drivers,

and evaluate whether they are worth defining vs. using the primary interop assemblies, for both the development and customer impact.

What is the timeframe for PIA deliverables?o Recommendation from working group on digital cert – by Feb 24tho BoD decision on digital cert – by March 3rdo If (approval == true) {

Acquire digital cert – March 17th Create new PIAs – March 19th}

o Shared component management review process completed – by April 2ndo Verify intellisense files

Review PIA’s for correctness Update shared component installer

Write the batch file for registering PIA’s.

5.5 Action Items: Kirk F: what are the maintenance requirements with a digital cert? Does a digital cert

give us extra protection with regard to maintaining the private key? Kirk F.: Schedule a conference call to occur within one month of this meeting (Feb. 24th )

o Discuss legal and logistic implications of acquiring digital certification Kirk F., Glenn B., Joe M. or someone else from Agilent?, Vektrex?

o Develop prototypes of IviScope driver .Net interfaces and report back at the next meeting on development and user implications.

Stephen Greer, Glenn B. - Develop batch file for registering interop assemblies


6. EO NxTest Working Group

6.1 General Meeting Info:Date of Meeting: Monday, January 27, 2003, 8:30 AM to 3:30 PMLocation: Austin, TXChairperson: Steve McHughMinutes Prepared By: Steve McHugh

Meeting Attendees:

Name Company EMAILFred Bode IVI [email protected] Birurakis DOD/Navy [email protected] Rosenwald Racal [email protected] Oblad Agilent [email protected] Neag TYX [email protected] DAVIS BOEING [email protected]

MMark Hanchey Eagle/Navy [email protected] Cheij National Instruments [email protected] Savage SCI/Navy [email protected] Hulett Vektrex [email protected] Cheshire Lockheed Martin [email protected] O’Donnell Lockheed Martin Steven.J.O’[email protected] Saracino Lockheed Martin [email protected] Raney Boeing [email protected] Bates Raytheon [email protected] McHugh SBIR [email protected] Wolfe Navy [email protected] Fox Navy [email protected]

6.2 Last Meeting in Chicago, Nov 13th-14th, 2002

6.3 Next Meeting will be In February 25th 1:00 pm, 26th all day, 27th till 12:00 in Jax, Marriott Sawgrass, Sign up this week. Will be the same date as the XML – in San Antonio

6.4 IVI IP PolicyNeed to Read the IVI legal documents understand IP guidelines for sharing data


















If we are members of IVI, we are implicitly involved in the agreement to these IP Documents.

6.5 ITOPS- International Test Operation Standard for NATO, NATO is very instrument specific instruction. Steve McHugh has tried to get them to attend.

6.6 Define Plan for developing an IVI Driver. Start of one, what is the technique. – Completed during this Jan 03 meeting; member interdependencies draft IVI committee

Suggest prototype of driver , target date before release of first spec…

At SPIE this year after Easter, update EO IVI and Working Group in afternoon, table discussion on EO Test Philosophy - Bill and Steve are going to write paper, inputs to them by February 25th, 2003Check to see if we can move the next EO WG meeting up one week, Feb 18th – 20th, agenda detailed writing of specifications and software definitions

6.7 Plan for Today’s Meeting, Review IVI Driver Template and Roadmap.

Need to nominate an IVI Expert to EO Specification Review. Steve O’Donnell to present to Technical committee. Ask Committee to provide assistance in the form of as person to review the EO IVI Specification generated by the IVI EO Working group

Reviewed Multi Sensor Boresight - Definition, added laser to laser Produce list of all tests with status of each one. Produce a list of all expected EO documents to the IVI community

Documents can be put on the www.ivifoundation.orgDocuments can be stored under the EO working group folderUser is TWG, Password is ChairmanChairman of individual groups should make sure group members have reviewed the data

Add standard target types with both input and output tolerance, ie. pinhole, square, etc. to the IVI driver spec. Define the targets parametrically and that will be available in the driver. Types of targets could be further defined in extensions or base class. Determine this at the next meeting. Instrument Unique/Crazy targets will be instrument specific.

Make our driver names readable but short.

We need to look at the IVI Style Guide in the specifications folder


Add Black Body Range to the IVI Base functions?

Working group should have a straw man vote of final copy of specification that is sent to IVI Committee

Plan for end of this year (2003) for release for specification. The IVI committee reviews spec for form, fit and function, interchangeability, consistency and approves for release.

6.8 Agile Rapid Global Combat Support presentationBill Birurakis gave the Agile Rapid Global Combat Support presentation, after the noon break.

Problem Statement: there is no standard among all the ATS Support is driving ability to deploy ( EXCESSIVE DELAYS) Support Costs was $50B in 1980 to 1992 on acquisition/support of ATE Congress is going to come down on the Joint Chiefs on this expenditure and the non-

commonality Proliferation of test system types No scalable systems

ARGCS Solution Synthetic Instruments, Bus Emulation and software technology that consists of IVI drivers

ARGCS should be able to go thru 5 phases from design testing through DOD O-level Test

“JAHUMS” is a program , enhanced BIT on Helos, self test and real-time sensors is used t support briefing from pilot on instrument failures

Joint Distributed Status Reporting: provides for communications between Repair export on land with field repair personnel

6.9 Central resource for information for the EO teamWorking group agreed Steve’s administrative assistant, Angie, shall be the central resource for information for the team


7. Interoperability Session and Developer Forum Meeting Summary

7.1 General Meeting Info:Date of Meeting: January 28, 2003Location: Austin, TXChairperson: Noël AdornoMinutes Prepared By: Noël Adorno

7.2 Meeting Attendees:List not available.

7.3 Interoperability Session:

NI provided a Dell Dimension V400 + Monitor + following Ghost images:

Image #1:Win2000NI-488.2NI-VISA beta 3.0LabVIEW 6.1Visual C++/VB 6.0NI GPIB controller card

Image #2Win98IE 6.0

Image #3WinXP

Image #4WinNT4 SP6IE 5.0

Only Image #1 was used.

Agilent installed the Agilent34401A IVI-COM driver plus Agilent’s VISA-COM on Image #1. Steve Greer then used LV to make a call to the Identify property of the Agilent 34401A driver, thus verifying that the IVI-COM driver can be instantiated and properties called on the driver.

Agilent then made several IVI-COM drivers available to other interoperability session participants who installed them on their various laptops. Specifically Tom Gaudette,


Teresa.lopes, and Johannes Ganzert were involved in interoperability testing. These were not clean systems and so provided some good feedback. For example, Tom had a prerelease version of the IVI Shared Components. The release installer did not detect this pre-release version.

Dan Masters and Long from Racal Dana then installed a driver for the 134 and 145 Racal Dana switch cards on Image #1. They made some last minute changes and then verified use of the driver in Visual Basic 6.0, by accessing a substantial portion of the IviSwtch functionality (connect, disconnect, etc.). An attempt to call the driver in LabVIEW was made. When the driver was instantiated directly, we failed to get a response from the Identity property. Similarly, the IVI Session Factory failed to instantiate too. Noel Adorno researched this item after the IVI Foundation meeting. Basically, the IVI Session Factory isn't working in LabVIEW as it requires a single-threaded model. LabVIEW is a multithreaded environment. The solution for end users is easy -- just modify the LabVIEW VIs that use IVI Session Factory to run in the user interface thread. This causes LV to open the component with a single-threaded model.

Rengan Rajendran from Vektrex then gave a presentation about a user application that Vektrex developed that used both IVI-C and IVI-COM drivers.

In summary, Interoperability Session was informal but successful. Several developer forum topics came out of testing during the interop session.

7.4 Developer Forum:

7.4.1 Discussion Items:

1) Putting help files in proper directory and getting directories right.2) Problems or issues regarding implementing IVI-defined features?3) How to get Intellisense to work4) What can go wrong when adding driver entries to config store?

a. Driver installer populating the Published API entries correctly.

7.4.1.1 Putting help files in proper directory and getting directories right.

Issue: IVI 3.1 specifies where driver installers should install help files – specifically help files are required to be in the drivers/<driver name> directory

However, COM default behavior is for help files to be in the same directory as the executable (e.g., the bin directory).

So, Steve Greer from Agilent showed the group how to circumvent this. Basically, in the registry there is a type library entry for the driver. In this entry there is a value for helpdir. This entry tells VB’s F1 help where to find the help files for the COM server. If we use the


COM default then helpdir is set to same value as the bin directory. To get the helpdir to point to correct directory, the installer has to change this entry.

Glenn’s Question: What about the help files that ship with IVI shared components?

Steve: Those should go in the Components directory – based on Steve, Johanes, and Noel discussion (earlier today).

It was suggested that we update the IVI Shared Component installer with help at same time as adding the PIAs.

Installer will have to change the default entry when upgrading.

Steve Greer provided the following suggestion for msi users: There is a table in msi file called Typelib with column called directory. When the component is installed, takes the value of the directory – copies into helpdir key. The msi table needs to be changed to make this fix.

7.4.1.2 Problems or issues regarding implementing IVI-defined features?

Glenn was surprised that there have not been Developer Forum discussions on how to implement IVI-defined features, such as simulation, state caching, and range checking. This prompted him to ask what the various driver suppliers were implementing.

Steve noted the following regarding Agilent’s IVI-COM instrument drivers:

Ignore coercion.Do not implement state caching.Re: Range checking – sometimes it relies on the instrument to do range checking and other times range checks in the driver. Sometimes it is difficult to determine the legal range rather than duplicate firmware.Do not implement interchange checking.Simulation should work.Status checking is implemented when the flag is set.

Glenn: What range checking happens when you are simulation?

Steve @ Agilent:Don’t know. Also, don’t know if you get the same value you set but get a valid value.

Dan @ Racal made the following comments regarding Racal’s IVI drivers:

Simulation – Yes. Impliments range checking in simulation. Should be noted that range checking for switches is very different than a DMM


Range checking is implicit.

Ion @ TYX made the following comment re: TYX drivers:

Prototyped a signal driver. Implemented some features that were similar to drivers. TYX does this once and then templitizes the code for use with other driver developments.

Glenn: I used to think these features were standard to implement. But they can get quite difficult. For example range checking in the DMM.

Ron Salley @ SSAI & Glenn had a discussion about ranges. Different approaches to solving the problem. Either itemize upfront or go out to instrument to determine factors that influence the valid ranges. Glenn – with state caching, don’t always need to go out to the instrument. Since the user configures the instrument incrementally through various high level functions or attributes. What constitutes a range of valid value for an attribute then changes over time as the user configures other settings.

Ron: Range checking for each function or range checking at a particular state.

Glenn: Can’t make assumptions about how the driver will be used. Maybe a one time configuration setup or round-and-round where state changes all the time.

Ron: Have you found when tested software is loaded, that you go out to all instruments and query the instruments for all their capabilities. Take time up front to discover capabilities. Read it all in and then write algorithms based on the upfront information. What about this approach?

Glenn: Using amplitude and offset, pointed out that this could be a large set of data. Pointed out that the existing approach isn’t so difficult that he is considering a different approach. There are challenging situations, but can be implemented.

Glenn: Explained how caching is implemented. Only stores what the user has specified, not all possible settings of the instrument.

Dan @ Racal: Is there a lot of issues because the documentation was wrong or the actual instrument was different?

Glenn: Most of that is worked out during development. If documentation is wrong, then find out pretty quick with a live instrument. Tests include runs with state caching on and state caching off.

7.4.1.3 How to get Intellisense to work

Teresa @ Teradyne:


While testing Agilents IVI-COM driver – noticed that depending on the datatype of the variable, either got Intellisense or not. For example, for the IIviDriver interface, got Intellisense got from both the Dmm and the IIviDriver. If use the specific interface, got Intellisense for instrument-specific Intellisense, but not stuff from inherented from IIviDriver (e.g Initialize and Close). The last scenario – class interface of instrument specific (use the class definintion).

Tom @ MathWorks: Interfaces have Intellisense but classes don’t!

Teresa: Always get prototype, but no description of parameters.

Teresa: We understand why this is happening, but what do we want to have happen? What’s the right thing to do?

Is it confusing to have two sets of Intellisense for Initialize?

How do we get it to show up once? Teresa: Thinks it is confusing.

Glenn: Let us separate autocompletion from help descriptions from XML file.

Teresa: Demos the problem.

1) Only shows up once in autocompletion list.2) If don’t have xml document, would there be anything? Yes, you’d get the prototype.3) Is the problem in type library or XML documents ??

Action Item: Glenn and Teresa to research problem and report back – with a recommendation!!

7.4.1.4 What can go wrong when adding driver entries to config store?For example, How to ensure that driver installers are populating the Published API entries correctly.

Glenn: There is a fundamental problem where we require installers to put shared items in config store. But the config server considers it an error to create an item that is already there. Seems easy for a driver developer to develop an installer that creates Published API but doesn’t check for errors. This comes out of the requirement for uniqueness. Basically, this requires the developer to be more aware than really should.

If an installer or application does a query for an item that isn’t in the Config Server, an error is returned. In this scenario it doesn’t seem like it should be an error. Has anyone else run into some of these cases? Glenn hits this every time he has to look up a data component.

Steve: There are cases that you do want it to fail – like logical names. Could be a VISA descriptor. Basically, Steve hadn’t run into this problem.


Glenn: Runs into this with data component since all entries are optional components. Also, when you get an error you have to remember to clear the error.

Glenn: In the context of installers, what other hot water areas are there? Software modules?

Steve: Look at the config store before writing so when uninstall make sure it gets taken out.

Glenn: Published APIs?

Action Item: Steve will answer the following questions:

1) Is it sufficiently clear what driver installers should do regarding published APIs?2) If not, what spec and with what content should be changed to make it sufficiently

clear?


8. User Working Group

8.1 General Meeting Info:Date of Meeting: January 28, 2003Location: Austin, Texas, Mariott Airport SouthChairperson: Gayle MatysekMinutes Prepared By: Gayle Matysek


Name Company EmailRoger Oblad Agilent [email protected] Bode IVI [email protected] Ryland Keithley Instruments [email protected] Shah Keithley Instruments [email protected] O’Donnell Lockheed Martin Steven.J.O’[email protected] Gaudette MathWorks [email protected] Adorno NI [email protected] Burnside NI [email protected] Rust NI [email protected] Matysek Northrop Grumman [email protected] Masters Racal [email protected] Ganzert Rohde & Schwarz [email protected] Wolle Rohde & Schwarz [email protected] Ptacek Rockwell Collins [email protected] Barrington Support Systems Assoc. [email protected] C. Salley Support Systems Assoc. [email protected] Malynur Tektronix [email protected] Nelson Tektronix [email protected] Hutchinson Teradyne [email protected] Lopes Teradyne [email protected] Neag TYX [email protected] Rajendran Vektrex [email protected]

8.3 Topics To Be Discussed:1. Simple development of an application using an NI IVI-C instrument driver and Visual C.2. Discussion of impact of case sensitivity3. Questions / issues / other demonstrations / user experiences or information offers4. Demo of Agilent driver in MATLAB5. User mailing list – update information
























8.4 Record of Discussions:

1. Presented agenda

2. Simple app development using an NI IVI-C instrument driver and Visual C. The instrument driver and configuration will use the new IVI Shared Components.

Tools/ software productsVB, VC++, NI VISA, Agilent VISA, IVI shared components, class drivers installed

VC++ application example – DMM demo add H file to file & include path to project settings also need to specify VISA path, library

Dave Ptacek noted no Intellisense appeared. Glenn Burnside stated that it is not automatically pulled in with VisualStudio 6 when header file included

Run with both Agilent 34401DMM & Fluke 45 by switching lib file in project configuration Developed using class driver, shared components – config server, and specific driver

developed using shared components Settings in XML file – configuration information – not in registry – only in config store file

accessed by config server Demo performed using GUI to set information that may not be provided by all instrument

vendors. Badri Malynur asked if other vendors would like to comment on plans of developers to

identify their plans. TEK not planning to provide graphical editor – waiting for market feedback to

determine best approach Racal will have to provide something to support switches, but no plane for system

level swapping Dan Masters - More a shared component – “shared GUI” – than instrument vendor

issue Roger Oblad – All access to config store via config server to avoid conflicts Tom Gaudette – asked if everyone agrees with Roger’s assertion; not certain that

there will be no conflicts Glenn Burnside – GUI should only alter areas that it is targeting and leave others

untouched Issue of shared GUI is the need for a developer who has time & is willing to give it

away as well as the requirement of a specific GUI on developers Is it the expectation that Users will receive some form of editing tool for the config

store? Scott Rust suggested raise issue to BoD if this is an issue of real concern. Gayle Matysek - Since the problem is anticipated. It is better to wait until it

becomes an issure rather than a perceived issue.

3. Discussion of impact of case sensitivity


How does case sensitivity affect the operation? Can init with name or GPIB address

Using name – if Agilent 34401 is set to MyDmm and Fluke 45 is MyDMM – name selection can direct action to incorrect device.

Name may be VISA resource string mapped to an address or a logical name – user must remember map. VISA is case insensitive so will accept multiple forms of alias. Logical name must match case.

Roger believes that tools could help to alleviate this problem Problem for simple users who may induce mis-match

VISA is case insensitive – NI looking for consistent behavior

4. Questions / issues / other demonstrations / user experiences or information offers- Tom Gaudette acquired driver for Agilent DMM, updated shared components and

demonstrated a call into the driver functions from MATLAB- After installation of drivers, Tom had several APIs and software modules – no other

information in config server to allow use by logical name – only means of access would be by address

5. User mailing list – updates (also applies to general mailing list)

Users were requested to update their email addresses on the user list. Unless your current address is on the list, you cannot send email to the list. My (Gayle Matysek) address recently changed and I got caught when I tried to send a message to the users and it was rejected. When changing an address it is desirable to remove old information, but you may only unsubscribe to remove that old entry if you can send mail from the old address. The other means to have old information removed is to notify Fred

Remove old entries:Notify Fred to remove an entry from an old email address (unless you can still send a message using that address).

If the old address is still available, from that address:Send a message to: [email protected] in the BODY of the message:

unsubscribe users Firstname Lastname

To subscribe at a new address:Send a message to [email protected] in the BODY of the message:

subscribe users Firstname Lastname




9. Marketing Committee

9.1 General Meeting Info:Date of Meeting: January 28, 2003Location: Marriott Austin Airport SouthChairperson: Dany CheijMinutes Prepared By: Dany Cheij


Name Company Phone Email

Dany Cheij National Instruments (512) 683-5286 [email protected]

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

Joe Mueller Agilent Technologies [email protected]

Jeff Hulett Vektrex [email protected]

Andy Hutchinson Teradyne [email protected]

John Rosenwald Racal [email protected]

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

Jochen Wolle Rohde & Schwarz [email protected]

9.3 Topics To Be Discussed: Marketing materials

o Post Mortem on 2002 Press Events o Does Trifold need more work?o Update status of presentation and white paper

IVI Websiteo Discuss implementation of updates to website

Other businesso Create a calendar of events for the year


9.5 Marketing materials

9.5.1 Post Mortem on 2002 Press Events Dany summarized the 2002 events Jeff and Jochen suggested that we make sure that documents from Electronica are up on

the website (Autotestcon is already up there).










9.5.2 Does trifold need any more work? Trifold was produced from a Word document. Do we need to reproduce more

professionally? Fred suggested that we think about what we would do with the trifold before going

through the effort and expense of reproducing. Jeff said that from his point of view an electronic version is more useful. After discussion it was decided that we will use up the current supply of printed trifolds

as is and have some graphic design people rework the trifold into a more pdf/html friendly format.

o Dany will check with NI graphic design to see how long it would take. Dany will report back to the group.

9.5.3 Update on status of presentation and white paper John worked on the white paper and because of lack of time and bandwidth it was

decided to start working on the white paper starting at this meeting. The white paper and presentation go hand in hand. The presentation is just a condensed

outline of the white paper. Joe suggested that we need to step back and work on the outline first. This would make

the process go smoother. Discussion on the purpose, goals and target audience of the white paper.

o A technical document that summarizes the specs could be usefulo The audience is either driver users or developers

Prevailing thought is that it would require too much effort to write a “marketing” white paper

Questions about how to create this documento Where does the knowledge reside?o Can we get help from the Technical Committee?o What form will the document take?o Can we leverage the ATC 2002 papers?

We need to create a documento It is a guide to the specso It would contain examples of spec concepts (helps explain)o Audience of the document is end-users or developerso We need an owner to drive the creation of the document

Owner will drive process. Group members from TC & MC Fred will take the initial responsibility of driving this group Document will

Be titled “IVI specification guide” Not contain any benefits (no marketing) Not exceed ~20 pages

Scott will inform the technical committee of this effort


9.6 IVI Website

9.6.1 Discuss implementation of updates to website Fred discussed the current issues with the web site The group discussed ways to solve the problems with the current web site

o Do we separate the two portions of the web site based on the different purposes they serve?

John volunteered to put together a statement of work that we can use to solicit companies to help us build our web site. John will email a proposed SoW to the group in a couple of weeks

o We will then send this to companies to give us proposalso Fred has a couple contacts and Racal is currently looking for companieso John will email the list server asking for input on good companies to do this kind

of work Goals for this task, within 30 days of this meeting

o Have an agreed upon statement of worko Have a list of potential developers from interested Foundation members

Goals for this task, by the next Foundation meetingo Have a plan and potential developer to present

9.7 Other business

9.7.1 Create a calendar of events for the year Have a plan for the website and implement it Create “IVI specification guide” technical document Ask overall membership about paper presentations at ATC

o Should we have a coordinated session with multiple papers

9.7.2 Recurring Marketing Committee meetings We will hold the marketing committee recurring meetings on Wednesdays at 9:30am

Central

Meeting adjourned


10. VISA Working Group

10.1 General Meeting Info:Date of Meeting: January 28, 2003Location: Marriott Austin Airport SouthChairperson: Dan MondrikMinutes Prepared By: Dan Mondrik


Name Company e-mail addressDan Mondrik (chair) National Instruments [email protected] Jon Bellin National Instruments [email protected] David Rohacek National Instruments [email protected] Gladfelter Agilent [email protected] Mueller Agilent [email protected] Stephen Greer Agilent [email protected] Fred Bode Bode Enterprises [email protected] Ryland Keithley Instruments [email protected] Shah Keithley Instruments [email protected] Wolle Rohde&Schwarz [email protected] Malynur Tektronix [email protected] Nelson TektronixRengan Rajendran Vektrex [email protected] Kirk Fertitta Vektrex

10.3 Agenda: VISA 3.0 spec update and walk-through VISA COM Shared Components status update Native VISA .NET discussion Discuss how to create a PIA for VISA COM

10.4 VISA 3.0 SpecificationsWe walked through the change list for each of the VISA family of specifications.

There were no questions for VPP 4.3, The VISA Library. Dan Mondrik pointed out the recent change to viClear for Serial. It will no longer send “*CLS\n” but we do not think it could possibly adversely affect any customer, since it did not perform the intended functionality anyway. Now viClear will flush the I/O buffers and send a break, consistent with IEEE-1174.














There were no comments for either VPP 4.3.2, VISA Implementation Specification for Textual Languages, or VPP 4.3.3, VISA Implementation Specification for LabVIEW.

We also walked through VPP 4.3.4, VISA Implementation Specification for COM. This time we had a few discussion points.

Dave Gladfelter asked about vendors uninstalling VISA COM shared components incorrectly. Since anyone can install these components, if not everyone follows the same standard, then any vendor’s uninstaller may inadvertently remove the component even if other remaining components require it. Which of the following should the spec do?

1. Specify that the shared components should be added to the “SharedDLLs” registry key at install time, and be reference counted. Then at uninstall time, the vendor uninstaller can remove the component if the count was previously 1.

2. Require that the shared components never be uninstalled.3. Be silent about this issue. (This is the way it currently is.)

The group understood this issue but did not want to hold up the 3.0 specs for this reason.

Action item for Dan: Determine whether all current installer technologies use the “SharedDLLs” reference counting. It does work with InstallShield. Dan thinks it may be an issue with MSI.

Dan noticed that the “TriggerID” property was missing from Table 5.1.11, as it had been in the previously voted version. Dan will fix this ASAP but it will not affect voting.

Dave asked whether there would be any problems if a user compiled against the old type library. Since the registered type library on a given system was supposed to be the one in the GlobMgr.dll, this should not be an issue. But the old spec allowed the installation of a file named VisaCom.tlb. The new spec does not recommend this and requires the type library to in GlobMgr.dll, whereas the old spec merely suggested that it might be compiled in.

If the VisaCom.tlb file was indeed registered on a system, and a user created an application using a marshaller that looked for a specific TLB version in the registry, then it might be a problem if that TLB no longer exists. But this is just a transitional issue since there was never a “blessed” version of GlobMgr.dll. The group understood this issue but did not feel it was significant enough to address. Dave agreed but wanted to think about it some more to see if he could come up with a strong use case for needing to reopen this issue.

Dan also mentioned that the PXI Systems Alliance was pursuing a definition of VISA for PXI. Dan will be involved with reviewing the definition to ensure its consistency with all the other VISA specifications. The PXISA will want the VISA TWG to incorporate this into the main VISA specifications in the future.

10.5 VISA COM Shared ComponentsRengan joined us for this part of the discussion. Agilent and NI have VISA COM shared components just about ready to review (formatted I/O, global resource manager, conflict manager). Rengan said we should follow the directions on the IVI Shared Components Management web site. It includes a list of deliverables that are needed to start the review.

Dave asked whether there was a test suite for the GRM, and Dan realized he didn’t have it readily available. However, since this is purely a software component, that should be possible soon. After some


discussion, Dave said his test suite for his formatted I/O component ran on a proprietary system (Mickey) that others won’t have access to. This may be a slightly bigger obstacle for verifying correctness.

Action item for Dan: Verify that the GRM test suites are valid for external review. Include the test suites along with the GRM source code and send them to Rengan.

Action item for Dave: Come up with a test suite that is valid for external review. Potentially write a test suite for a common Agilent instrument. (Dan suggested the 34401A). Include the test suite along with the FIO source code and send them to Rengan.

Rengan said that once the review started, it would last for 3 weeks. There would then be a 1-week voting period for IVI members to bless these components. Since they are not part of the IVI shared components, they will not be included in the IVI shared components installer – we are just leveraging the shared components committee for their review process. The binaries will then be made available for any vendor to install.

<Break for lunch.>

10.6 Native VISA .NETNI had a handout that discussed some architectural changes since the previous time NI sent out its .NET API proposal. David Rohacek discussed these changes:

1. No VISA I/O Completion event. Follow the .NET Begin/End I/O mechanism and use an IAsyncResult. Use the VISA queue or handler depending on what parameters are passed to BeginRead/BeginWrite. If the user passes a callback, then use the handler mechanism; otherwise, use the queue mechanism.

2. There is a “Session.SynchronizingObject” property for thread synchronization, based on the idiom found in the .NET classes Timer, MessageQueue, etc.

3. There is a “Session.Handle” used to obtain the VISA I/O handle, in case a user needs to make a direct call to visa32.dll. Dave Gladfelter asked what the value is if this was remote .NET or if the VISA .NET code was not based on VISA C. We discussed what IVI does for their I/O handle – it can be any arbitrary pointer or NULL. We agreed that should be fine for VISA .NET as well.

4. Custom event handlers. These are on the base Session class and are not browseable. The user must know about them and must know what he is doing anyway. This is slightly different from VISA COM, where the custom event was just an optional parameter on the other event functions. In this case the standard VISA events are part of the .NET event API, but custom events are not.

John Ryland asked whether there was a diff list from VISA COM. Dave Gladfelter indicated that they were very similar but he pointed out the main changes:

1. Formatted I/O is not addressed by the NI proposal but could be different from VISA COM.2. Resource manager and creation issues need to be discussed.3. Events are different, as noted above. This is probably headed in the right direction.

Dave had a presentation on architectural choices for the resource manager and session creation. I did not make a list of all the options Dave presented. Basically the presentation covered the issues of how .NET allows multiple interface inheritance but only single implementation inheritance. His presentation showed code snippets and tradeoffs between using just interfaces (like COM) or using classes; it showed code snippets using direct instantiation/creation and also using the resource manager.


Dave also showed the option of having different vendors implement an interface that looks the same, but not necessarily having them inherit from a common interface. This was deemed unacceptable for instrument drivers since they would need prior knowledge of the implementation on a given system.

The options A and C were considered the remaining options friendly to instrument drivers. The option C was deemed to be the most user-friendly and should be our first choice if possible. It uses the letter/envelope idiom. The user could directly instantiate a Session (or derived) object without requiring usage of the resource manager. The envelope in this case is a wrapper which would be a shared component and hold the “real” implementation pointer. A side effect of this choice is that whenever an exception is thrown, the envelope method would appear in the exception call chain, along with the vendor’s implementation. This was not deemed to be a significantly negative impact. Dave indicated that he had prototyped a simple letter/envelope strategy in .NET before and it was not difficult.

Dave asked whether we could do all interfaces for the leaf classes. It was decided this would not work for IVxiSession, which needs multiple interface inheritance on its own (register based, message based, and the VISA session).

Badri asked whether a PIA from VISA COM would be good enough. Is VISA .NET needed? Jon Bellin answered that because of the difference in events, and the desire for good integration with .NET IVI drivers, that would not be sufficient.

Dave Gladfelter asked how VISA could hook into the .NET framework better. For example, what about streams and TCPIP sockets? David Rohacek answered that NI did not view streams as part of the VISA inheritance tree. However, there could be a helper class that uses a VISA Session object as the backing store. Dave said he would look into this further.

Dave asked whether the VISA .NET GRM could use the VISA COM conflict manager. Action item for Dan: Can we leverage the existing conflict manager, either the binary or any/all of source code?

Dan had a question about the resource manager. NI’s prototype has it as a static class. Would this work for the GRM? Dave said that the GRM would have to instantiate each VSRM, and that doesn’t work with static classes, so we would need different types. That would be different than VISA COM.

Jon asked what remained, and ensured that we assigned action items:1. Action item for Dave: Prototype and implement session creation using the letter/envelope idiom.2. Action item for Dan and David: Generate a proposal for the GRM and conflict manager. Decide

on the installation directory (subdirectory or sibling directory of VISA COM).3. Action item for Dave: Generate a proposal for formatted I/O. It was agreed that at least a subset

of the existing formatted I/O VISA COM API is needed for parsing 488.2 blocks. Decide what subset needs to exist in VISA .NET.

4. Action item for Dave: Come up with suggestions for better integration with the .NET framework, including streams and file I/O. Hope is to work better with 3rd party tools.

There was a question about the namespace. For the shared components, we will use Ivi.Visa. For the vendor-specific components, they will use their own namespace. The exact vendor namespace doesn’t matter to the shared components because each vendor installs a text file describing how to load its component, and that text file includes the namespace resolution info.


Jon reiterated that NI plans to ship a .NET VISA-based solution soon. Depending on the timeframe in which we complete the VISA .NET specifications, NI may ship a non-standard version, but will definitely support the standard in the future.

Fred asked how many shipping versions of VISA were known. (NI, Agilent, and Tektronix.) He pointed out that not all vendors ship a full-featured VISA, in other words, not everything documented in the VISA spec. Is this a problem? How do customers know if it doesn’t support something? Should it be in a help file? Or is that too late because they’ve already bought it?

There was a discussion that IVI has a compliance document, and we could use that as a basis if we thought it would help. Badri said it should just be up to each vendor to document what their VISA supports and whether it is full-featured; for example, Tektronix VISA indicates what interfaces it is limited to. Dan pointed out that this was a similar problem to what knowledge base files in VXIpnp tried to solve, and they failed. In general, the group deemed that this was neither a big nor solvable issue, and documents probably won’t help.

Fred reiterated that he would like to see this issue addressed in the future. He anticipates that when PXI is an interface supported by the VISA specification, it is possible that not all vendors will support it. Badri suggested that maybe we could discuss this in the install FAQ section on the IVI web page.

We will have a conference call on Friday, February 28, sometime in the morning (CST). We will discuss the anticipated VISA .NET user experience and potential issues based on what we have learned from working on the action items. Of course, we can discuss issues in the meantime via email. Action item for Dan: set up this conference call.

10.7 PIA for Using VISA COM from .NETSteve Greer went through some of the items from Monday’s .NET PIA meeting:

1. We need a PIA for the main VISA COM library. Action item for Dave: do this, and name the files as discussed below.

2. A PIA is needed for each shared component. However, since the VISA COM GRM and conflict manager interfaces are in the same IDL file as VISA COM itself, these would just be duplicates. Therefore, we do not need a separate PIA for them in this case.

3. Where should the PIA files be installed, and by whom? IVI plans to use a “Primary Interop Assemblies” subdirectory of wherever the COM components are installed, so we should do the same (“VXIpnp\VisaCom\ Primary Interop Assemblies”).

4. How should the PIA be signed? IVI will get a private key. VISA can use it too.5. What should happen if the .NET framework is not installed when the VISA components are

installed, but the .NET framework gets installed later? IVI decided that they will create a batch file, always install the PIA, and the user can go to just 1 location to register all the PIAs on their system later. The group agreed that VISA should take a similar approach. Action item for Dan: get the batch file from Glenn Burnside.

Kirk brought up an issue that he found when running the VISA COM IDL file through his tools. There is a propputref on the formatted I/O that didn’t work for him. This propputref is by design, though. Action item for Dave: discuss this with Kirk to see if this is an issue from .NET.

Steve had several questions that Dan answered and Jon agreed with:1. Is a VISA COM vendor required to ship and install the VISA COM PIAs? Yes.2. Is the IVI shared component installer the right tool to install them? No.


3. Can a vendor driver ship and install them? Yes, but he must follow the VISA rules for creating the VXIpnp directory if needed.

Steve asked in what document this information should be contained. This could be an addendum, it could be left in the IVI document that Steve is creating, and/or it could be incorporated in the next VISA specification. None of these are mutually exclusive, so it’s not a major issue for now.

Dan asked how we later distinguish the VISA API if we have both the PIA and a native VISA .NET API on the same system. Steve answered that PIAs appear in a COM tab but not the .NET tab unless you set some option that we are not planning to set.

We then talked about the filenames for all PIAs that IVI is creating. The 2 suggested formats:1. David suggested Ivi.<technology>.Interop.<extension>2. Kirk suggested Interop.<type-library>.<extension>

The group decided on #1 when Jon pointed out that that option makes the batch file (that Glenn is writing) easier, since what it needs to register with .NET can be deduced from the filename. Therefore, for VISA, the PIA files need to be Ivi.Visa.Interop.dll and Ivi.Visa.Interop.xml.

We will start a VISA COM shared component review a week+ after this meeting. The PIA files can be reviewed later.


11. IVI Signal Interface Working Group

11.1 General Meeting Info:Date of Meeting: January 29 - 30, 2003Location: Austin, Marriott Airport South HotelChairperson: Ion NeagMinutes Prepared By: Ion Neag


Name Company Phone EmailRoger P Oblad Agilent Technologies (707)577-3466 [email protected] Rust National Instruments 512-683-5680 [email protected] Salley Support Systems

Associates321-724-5566 x294

[email protected]

David Barrington Support Systems Associates

321-636-5598 [email protected]

Teresa P Lopes Teradyne 978-370-1377 [email protected] Hutchinson Teradyne 978-370-1277 [email protected] Davis The Boeing Company (314)234-2722 [email protected] Neag TYX Corp. (703)264-1080 [email protected] O’Donnell Lockheed Martin 407-306-4325 steven.j.o’[email protected]

11.3 Topics To Be Discussed:Enhancement to switch model (IviSig spec Draft 0.2, Section 9.3.1)

design overview design issues:

o should SetupConnectivity() wait for signals to settle?o other, if identified

Parameter qualifiers (new feature, IviSig spec, Sections 20.1.2 and 14.2.2) design overview design issues, if identified

Inherent and Common Signal Capabilities (new feature, IviSig spec, Sections 20.2 and 20.3) design overview design issues, if identified

Synchronization (new feature, IviSig spec, Section 8, sub-sections in 20.2 and 20.3) design overview design issues

o support multiple triggering mechanisms at the same time?o support SoftwareTrigger?

38





o support level gating?o definition of trigger slope; support “both”?o should sensors generate software event when measurement is completed?o name for “monitor-able” parameter roleo other, if identified

Timing (new feature, IviSig spec, Sections 20.21.5, 20.2.1.6) design overview design issues

o guaranteed time coherenceo other, if identified

Other design issues: IVI-3.2 compatibility issue: reset all signals in Reset(), ResetWithDefaults or new

method? use “double” or “VARIANT” as data type for precision? use fraction or percent for relative precision?

Prototype demonstration IVI-3.2 Compatibility Complexity of Signal Driver development using C++ templates

11.4 Record of Discussions:January 29, 2003

Ion presents an update on status.

Items added according to decisions from the last meeting:- Predefined switch types- Access to collection elements by Name

New items in the spec: - Qualifiers- Inherent and Common Signal Capabilities- Synchronization- Timing

Ion presents the design of new features “Qualifiers” and “Inherent and Common Signal Capabilities”.

Ron asks about the relationship with ATLAS2K. Ion presents a summary of the issue, as discussed at previous meetings.

Ion presents the design for Synchronization.

39

Ron expresses concern that the implementation of this feature could compromise TPS portability. Ion states that the Signal Drivers are not controlled directly from the TPS code, if resource allocation and automatic switching are used.

Teresa asks Ion to present again the IVI-SI architecture, to clarify usage.

Roger: for some sensors the client must wait until the configuration of the instrument is completed. This requires Setup() to be a blocking call. An alternative approach, for synchronized sensors, is to return an error when the trigger occurs before the configuration is completed. It would be also useful to send an event when the measurement is completed. This also applies to switches.

January 30, 2003

Ion recapitulates the issued discussed the previous day.

Continuing the discussion from the previous day, Ion suggests that Setup() and SetupConnectivity() should also have blocking & non-blocking versions and “completion” events. Blocking versions should have a timeout parameter. Roger states that the timeout is often variable and application-specific. Roger and Ion realize they are talking about different things. No other objections are formulated.

Design issue: Support multiple triggering mechanisms active at the same time?

Ron asks what amount of complication does synchronization add to the total design. Ion estimates 20% and describes how this extension is consistent with the rest of the specs. Roger agrees that consistency is valuable.

Scott indicates that in practice instruments do not support multiple hardware synchronization mechanisms but support software triggering as an override for hardware triggering. Ion states his concern that restricting synchronization to a single mechanism prevents this “override” functionality. Decision: try to support multiple mechanisms.

Action Item: Ion to design representation in Signal Capability Description and report back. The group will assess the complexity of the solution and decide if the feature should be preserved.

Design issue: Support triggering mechanism Software Trigger?

Teresa suggests to keep Software Trigger as one of the synchronization mechanisms, not as an extension group. No objections. Decision: keep as it is in the current design.

Design issue: Support level gating?

Steve asks for the reasons this is not supported in the current design. Ion indicates possible interchangeability issues (as described in slide presentation) and describes a

40

workaround – treat gating signals as “regular”, i.e. non-sync signals. Don and Roger estimate this workaround acceptable. Ion describes common usage in instruments - sweep & burst functionality in signal generators. Steve expresses concern about supporting of level gating in synthetic instruments. Decision: investigate usage in synthetic instruments. If workaround solution is not acceptable, add level gating to design.

Action Item: Steve to investigate usage of level gating in synthetic instruments and email Ion.

Action Item: Ion to add level gating if necessary.

Design issue: Support “both slopes active” for External triggering?

Ion indicates that IVI class specs do not support the feature, while some instruments to. Agreement to support it. No change to spec necessary.

Design issue: Should sensors generate a software event when measurement is completed?

This was also discussed yesterday and at the beginning of the meeting today. Ion indicates that non-blocking calls and events simplify the client code, moving the complexity in the driver. Scott points out that complexity is not removed. Ion agrees and remarks that moving it in the driver code makes it appear once, while keeping it in the TPS makes it appear each time the function is called.

Discussion about the need of blocking call & events for Setup() and SetupConnectivity(). Roger indicates that long duration appears in function generators and switches.

Teresa asks how do we get data from a non-blocking Fetch() followed by an event. Ion thinks a second Fetch() call is required. The first one may have zero parameters.

Teresa suggests to use different methods names for blocking and non-blocking versions. The group is in agreement.

Action item: Ion to add support for blocking & non-blocking calls and events for all applicable methods. If a driver supports non-blocking calls, it must be able to generate events.

Design issue: Name for “monitor-able” parameter role

Scott and Teresa suggest name changes: Controllable to Configurable; Capability to Descriptive. General agreement.

Scott thinks that setting trigger levels is a “configuration” operation, so a special role is not required. Ion agrees and indicates that a “monitor-able” parameter may be identified as such in the Signal Capability Description by specifying one or more of the specialized qualifiers.

41

Action Item: Ion to change role names and eliminate “Monitor”. Instead, indicate in Signal Capability Description what identifies a parameter as “Measurable”.

Ion gives a presentation on design for timing (see slides).

Side discussion on method names. Scott indicates that IVI class specs use Initiate instead of Arm.

Action item: Ion to survey IVI, SCPI and A2K about names and report back.

Back to the main discussion topic. Scott: for TimeInterval signal, what does Fetch() return if GATE-FROM event has occurred but GATE-TO event did mot occur. Suggests returning 0.0. and indicates that a mechanism should be provided for software discover of the event state. Ion proposes to use the EventIndicator property of the IIviSigMonitor interface.

Action item: Ion to update specification as described above.

Ion presents an overview of timing support and the time coherence issues (see slides) . Roger indicates the conclusions are consistent with his experience.

Action Item: Ion to implement support for time coherence in Signal Capability Description, as proposed.

Design issue: reset all signals of a Signal Driver

Scot suggests solution 3 (new method). The group is in agreement.

Action Item: Ion to add new method to IIviSigDriver.

Design issue: Use “double” or “VARIANT” as data type for Precision.

Ron suggests to use a special data type for range, resolution & precision. Ion describes how this is achieved in the current design by the IviSigParameter object.

Teresa indicates that VARIANT would be preferable for consistency. No objections.

Action item: Ion to check spec and update if necessary.

Design issue: Use fraction or percent for relative Precision?

Ron and Ion have a general discussion on measurement accuracy. Ion explains the effects measured by absolute precision, relative precision and resolution.

42

Ron indicates that they specify resolution in terms of digits. Ion indicates that this may be limiting when specifying the resolution of an ADC. Roger agrees. No objections.

Ion expresses the preference for fraction, instead of percent. No objections to this approach.

Ion presents the goals of the demonstration (see slides). Discussion on the type of specification. Alternatives: one 3.x architectural spec and one 4.x class spec; or a single 4.x class spec. Andy suggests the second approach. Scott agrees. No objections. Ion indicates that the 4.x spec will have a consistent “Overview and Architecture” section.

Ion shows the driver and client code and runs the demonstration.

Discussion on the IIviSwitch interface. Teresa suggests to support the approach of the IviSwitch class, to simplify client code. Ion indicates that both approaches may be supported by the same interface.

Action Item: Ion to enhance the design of the IIviSwitch monitor, to support from…to connections.

Ion recaps the prototyping works that remains to be done. Steve indicates that LMIS may collaborate in the development of a Signal Driver for a synthetic instrument.

43

12. Conformance Working Group

12.1 General Meeting Info:Date of Meeting: January 29, 30, 2003Location: Austin, TXChairperson: Jeff HulettMinutes Prepared By: Glenn Burnside

12.2 Meeting Attendees:First Last Company Phone EmailNoel Adorno National Instruments (512) 683-5071 [email protected] Bode Bode Enterprises (619) 697-8790 [email protected] Burnside National Instruments (512) 683-5472 [email protected] Gaudette Mathworks [email protected] Hutchenson Teradyne (978) 370-1277 [email protected] Hulett Vektrex (858) 558-8282 [email protected] Malynur Tektronix (503) 627-5880 [email protected] Matysek Northrop Grumman (410) 765-9754 [email protected] Ptacek Rockwell Collins (319) 295-0198 [email protected] Rajendran Vektrex (858) 558-8282 x20 [email protected] Mueller Agilent Technoligies [email protected] Greer Agilent Technoligies [email protected] Wolle Rohde & Schwarz [email protected] Nelson Tektronix [email protected]

12.3 Agenda:

Wednesday:Quick review of charter Review of key conformance group decisionsReview of conformance minutes from July 2002 meetingDiscuss NI supplied testing outlineDiscuss process for submitting test plansDiscuss exchange of test procedures Discuss plugfest logistics

Thursday:Finish test procedure exchange discussionRevise specification Action item review and wrap-up

44












12.4.1 Review of Charter, Progress, and Current WorkJeff presented PowerPoint presentation.

12.4.2 Review of Key DecisionsDiscussed during PowerPoint presentation

12.4.3 Review Of Last Meeting MinutesMinutes were accepted

12.4.4 Discuss NI-supplied Testing Outline Glenn presented an overview of the document he developed, and

re-emphasized NI’s position on providing such high-level test overviews.

Tom Gaudette asked, “What are we trying to get out of conformance?”

o Stepping back to the mission statement for the committee Paul had a question regarding the ability of vendor tools to help

guarantee complianceo Is there an assumption that the tools are implemented and

tested successfully, and should this group do the verification of those tools?

Badri asked, “are we assuring conformance or are we assuring quality?”

o To which Jeff answered, “Yes.”o The difficulty is that quality and conformance intersect.

Badri suggested that we could divide testing into three stages:o Basic spec conformanceo Recommended checklist of basic testingo Checklist and/or report page

Glenn pointed out that enumerating the testable items for IVI compliance would re-create the specs themselves.

Badri felt that stating some basic testing in different environments is a greater value to driver evaluators than a statement that the driver implemented the IUnknown interface as required.

Tom stated that a plugfest process could help to establish a pattern of quality for companies interested in acquiring a conformance logo.

Fred asked if we were still intending to require a testing checklist to ship with drivers

o That checklist might still be required, or might get merged into a test suite or methodology requirements, etc.

45

12.4.5 Discuss Process for Submitting Test Plans Jeff presented a draft process Badri is concerned that we would get bogged down in the review,

and in the subjective nature of the review process. Fred wondered about the viability of getting volunteers to do these

methodology reviews, and about the timeframe proposed (2 weeks) as being sufficient.

Dave thought that different people would have different opinions about all of this.

Glenn felt that the approach of submitting a methodology allows users to acquire logo usage regardless of the IVI Foundation meeting schedule.

Paul stated, “This is not a trivial undertaking.” Badri said he liked the idea of IVI-certified vendors. Paul stated that the interop sessions at VXIPnP were valuable in

helping to ensure compliance. Badri asked if we could create an online forum for discussing

support issues with drivers.o There was general agreement that realistically, this would

not be where users go for support issues – it would be to the vendor of the driver.

Fred stated that we need to make sure we have a way of revoking the logo when we discover that a driver writer’s drivers don’t work.

Glenn asked, how would we revoke a developer’s use of the logo? Based on what?

o Jeff stated, there would be obvious things like not conforming to IVI 3.2. (inherent capabilities.)

Gayle reviewed the original creation of this working group:o When users have source code, they can live with bugso If source code provision is optional, driver writers better “test

the hell out of them [the drivers].”o When they might not get source code, they cannot tolerate

problems in source code at all. Badri felt that there was nothing this group could do to address

Gayle’s issues. Glenn asked Gayle, what would you require this group to do to

address those user concerns?o Gayle: provide a guarantee via a checklist that the driver has

been FULLY exercised. David P. suggested that we re-entertain the notion of requiring

source code with IVI drivers, sans the sections that constituted intellectual property.

Glenn asked, who would be willing to take on coming up with the checklist?

46

Jeff will take on the task of developing a checklist between now and the next meeting of what he thinks would constitute test conformance.

12.4.6 Discuss Exchange of Test Procedures Jeff questioned if we want to actually be responsible for reviewing

developers’ test plans, vs. publishing a testing checklist that developers would need to meet.

Badri believes we need to do the following:o We produce a 10 page checklist of testing requirementso Developers deliver a 2-page report of environments tested,

operating systems, etc.o Create a web solution where driver users could submit

complaints about drivers or suppliers of drivers These kinds of complaints could result in the

revocation of the logo usage.o Develop the notion of IVI-certified vendors

Primarily focusing on vendors that provide IVI driver development tools

Tom/Glenn/Joe M: But tools can be abused.

12.4.7 Discuss Plug-fest Logistics Tom: Drivers are going to get used in a lot of different

environments.o The vendors of those environments are going to be the

people who get the initial support calls, not the vendors of the driver.

o His concern is with the quality of drivers from smaller developers, and how it impacts people’s experience with MatLab or other environments.

Plugfest would afford him an opportunity to be exposed to a lot of drivers.

Joe M. stated that standards bodies tend to have concern with doing testing and granting conformance certificates, in that some people may claim they did not have a fair opportunity for contracts that require that certificate because of the schedule of the foundation meetings.

Glenn suggested that if we worked to strengthen the structure of the interop session, it might act as an arena to address most of the issues that the “plugfest” idea was designed to handle.

12.4.8 Thursday morning discussion Joe: test plans on file may provide an unintended shield to

providers of low quality drivers, who can claim, “I have a test plan on file – what are you complaining about?”

47

o Requiring a test plan helps to regulate quality, but is not the right approach to take to give teeth to controlling the use of the foundation mark.

Tom: I could implement an “IVI” driver that only did the bare minimum for compliance, put everything else in the instrument specific interfaces, and use the logo.

o Noel: There are already requirements in IVI 3.1 that drivers document as part of their installation what class and what extension groups in that class the driver supports.

Badri: Could we go back to creating a testing checklist and a revoking of logo usage based on negative feedback from customers to the IVI Foundation.

Jeff Should we go down the path of requiring a submitted test plan?

o Nobody voted for this approach. Paul: could we provide recommended templates for a test plan? Jeff: What about requiring developers to send in a certificate for

each driver stating that they intend to be compliant with the drivers that they write?

o Straw poll indicated general interesto Noel: This content is already in the document required to

ship with driverso Glenn: wouldn’t that involve the working group having a lot

of documentation.o Tom: we could make this an automated process where

driver developers submit their documents and they are archived by the foundation.

o We could extend this to include information about what drivers are available.

Joe: the Foundation should arbitrate, not police, disputes about conformace.

Badri: Each time a developer creates a new document, wouldn’t they have to re-submit a new document?

o Couldn’t we define a new document for this more legal information we’re requiring?

o Joe: Why don’t we agree on what we think the document needs to be, and then see how close it is to the existing information in IVI 3.1.?

o Noel: you have to update the IVI 3.1 compliance file anyway, why is it any harder to re-email that document to the foundation?

Badri: There is more information than present in the compliance document that would be valuable to users

48

o Glenn/Joe/Tom/Jochen: However, we cannot mandate that information’s presence when defining what is required for granting of the conformant logo.

Glenn: could we take on the task at defining what the document ought to be, and discuss those proposals?

o Jeff is willing to take a stab at making the necessary additions.

o Jeff: We should also consider adding something into the document to identify what has been tested.

o Jeff: We should move this document out of the 3.1 spec and into the conformance spec, so that it is more visible to the developers.

(Note from Jeff: moving the compliance document out of 3.1 was discussed. Noel was alarmed about the potential impact of this change. Joe noted that it was a good idea, but probably not worth the effort. I agreed with this. My understanding of this is that I will create a draft of the changes required to the compliance document, once this is reviewed and approved by the Conformance committee, we will decide where best to make this change.

o Jeff: will complete this work within 2 weeks (by 13 Feb), with a conference call on Feb 27, at 8:00am pacific time.

Jochen: who will have access to the registered information?o We would make it available to members, but maybe not the

general public, unless we start to extend the reach of this registration process.

o Gayle: if the instrument selection people had access to more information about drivers, they would be more likely to select instruments for use based on the software information.

Badri: a web-form based approach with a database backend would allow us to make decisions later about who has access to the information.

Tom: Could that information still be made available via email redirect to interested members?

o Sure, why not?

12.4.9 Revise Specification Andy: consider making the specification a document that describes

the process required to achieve compliance, including the submission of the compliance document, and the documentation of the operating procedure.

o Joe: Not comfortable with providing a process document.

49

o We’re spending too long on this: Let’s write down what we want, examine our minutes, examine 3.1, and figure out what needs to go where of the things that aren’t currently written down.

12.4.10 Action Items

13. Action Items:

Who What By

Jeff H. Extend the IVI 3.1 compliance file 13 Feb

Jeff H. Develop prototype of testing checklist. 13 Feb

Jeff H. Revise specification 13 Feb

All Review updated specification 20 Feb

Jeff H./Paul N. Set up conference call 20 Feb

All Have conference call 27 Feb, 8am pacific.

Fred B. Provide information on website about recommending attendance at IVI Foundation meetings to become more informed about conformance, testing, etc. to be embodied on a conformance page. –coordinate with John R.

Next Meeting

Fred B. Will develop a prototype form letter for informing a developer that his driver is non-compliant.

Next Meeting

Jeff H. Will work with Joe M to develop an idea of what the non-compliance arbitration process should be.

Prior to conference call below.

Jeff H. Set up arbitration discussion conference call

7 April?

50

14. IVI Net Worth – January 27th, 2003

IVI Checking account - 12/31/02 = $49,929.90

Less outstanding checks :Director of services – 4th quarter 2002 $9,270.00VXIplug&play web maintance (9 mo 2002) $1,800.00Lucash (outstanding) $1,115.30Conference calls – billed from NI 697.86Refund – Ken Bates 10.00

14.1 Total outstanding: 12,893.16

IVI Net Worth after outstanding obligations $37,036.74

Projected Total Income 2003 (including SCPI) $51,500

Projected Expenses – 2003 $52,630

Projected loss -$1,130

Projected IVI Net Worth December 31, 2003 $35,906.74

Budget was presented. Group asked that it be reworked to include Web redesign after we had formal quotes.

51

Meeting Minutes - June 2001 - IVI Foundation€¦ · Web viewName Company Phone Email Roger P...

Documents

Transcript of Meeting Minutes - June 2001 - IVI Foundation€¦ · Web viewName Company Phone Email Roger P...