Virtual Instrument Software Architecture. This is the general name given to this VISA document and its associated architecture. The architecture consists of two main VISA components: the VISA Resource Manager and the VISA Instrument Control Resources. This is the name given to the part of VISA that defines all of the device-specific VISA Instrument Control Resources resource classes. VISA Instrument Control Resources encompass all defined device and interface capabilities for direct, low-level instrument control. VISA Resource Manager This is the name given to the part of VISA that manages resources. This management includes support for opening, closing, and finding resources; setting attributes, retrieving attributes, and generating events on resources; and so on. VISA Resource This is the name given to the part of VISA that defines the basic constraints and interface definition for the creation and use of a VISA resource. All VISA resources Template must derive their interface from the definition of the VISA Resource Template. Conventions Throughout this specification you will see the following headings on certain paragraphs. These headings instill special meaning on these paragraphs. Rules must be followed to ensure compatibility with the System Framework. A rule is characterized by the use of the words SHALL and SHALL NOT in bold upper case characters. These words are not used in this manner for any other purpose other than stating rules. Recommendations consist of advice to implementors which will affect the usability of the final device. They are included in this standard to draw attention to particular characteristics which the authors believe to be important to end user success. Permissions are included to authorize specific implementations or uses of system components. A permission is characterized by the use of the word MAY in bold upper case characters. These permissions are granted to ensure specific System Framework components are well defined and can be tested for compatibility and interoperability. Observations spell out implications of rules and bring attention to things that might otherwise be overlooked. They also give the rationale behind certain rules, so that the reader understands why the rule must be followed. A note on the text of the specification: Any text which appears without heading should be considered as description of the standard and how the architecture was intended to operate. The purpose of this text is to give the reader a deeper understanding of the intentions of the specification including the underlying model and specific required features. As such, the implementor of this standard should take great care to ensure that a particular implementation does not conflict with the text of the standard.
VISA Virtual Instrument Software Architecture. This is the general name given to this document and its associated architecture. The architecture consists of two main VISA components: the VISA Resource Manager and the VISA Instrument Control Resources. VISA Instrument Control Resources This is the name given to the part of VISA that defines all of the device-specific resource classes. VISA Instrument Control Resources encompass all defined device and interface capabilities for direct, low-level instrument control. VISA Resource Manager This is the name given to the part of VISA that manages resources. This management includes support for opening, closing, and finding resources; setting attributes, retrieving attributes, and generating events on resources; and so on. VISA Resource Template This is the name given to the part of VISA that defines the basic constraints and interface definition for the creation and use of a VISA resource. All VISA resources must derive their interface from the definition of the VISA Resource Template. Conventions Throughout this specification you will see the following headings on certain paragraphs. These headings instill special meaning on these paragraphs. Rules must be followed to ensure compatibility with the System Framework. A rule is characterized by the use of the words SHALL and SHALL NOT in bold upper case characters. These words are not used in this manner for any other purpose other than stating rules. Recommendations consist of advice to implementors which will affect the usability of the final device. They are included in this standard to draw attention to particular characteristics which the authors believe to be important to end user success. Permissions are included to authorize specific implementations or uses of system components. A permission is characterized by the use of the word MAY in bold upper case characters. These permissions are granted to ensure specific System Framework components are well defined and can be tested for compatibility and interoperability. Observations spell out implications of rules and bring attention to things that might otherwise be overlooked. They also give the rationale behind certain rules, so that the reader understands why the rule must be followed. A note on the text of the specification: Any text which appears without heading should be considered as description of the standard and how the architecture was intended to operate. The purpose of this text is to give the reader a deeper understanding of the intentions of the specification including the underlying model and specific required features. As such, the implementor of this standard should take great care to ensure that a particular implementation does not conflict with the text of the standard.
vpp432_2018-10-19.docx