IVISwtch

IVISwtch is the IVI class driver for switching products. The specification for this driver class may be found at:

http://ivifoundation.org/specifications/

This driver is intended to encapsulate the functionality of switching products and systems and to provide the features of any IVI driver, that is interchangeability and ease of use.

The main benefits of this standardization are the potential benefits of interchangeability and the availability of software tools to assist developers of switching systems. Other articles in this WIki also refer to use of the IVI driver IVI Driver

This article covers only the use of IVI Swtch class defined functions, specific will be covered elsewhere.

The IVI Swtch Paradigm

The IVI approach to switching differs from the approach taken by the majority of drivers. IVI considers a switching system as a 'black box' viewed from the perspective of its connection terminals and not from the detail of the switching elements used within. Switching routes are established by commanding the driver to Connect or Disconnect terminal pins which it refers to as Channels. Exactly how that route is established is entirely dealt with by the driver developer relieving the user of the need to understand the detail of the individual switches and interconnections within the 'box'.

The driver internally generates a set of channel names which the user uses in Connect and Disconnect function calls. Each manufacturer decides the channels names to apply and so this may differ from product to product, to deal with this variability the IVI system provides a means to 'alias' these channel names; this is one key aspect of interchangeabilty.

In the examples below we use the normal channel naming conventions used by Pickering Interfaces, other manufacturers may use different labelling, but will generally be of similar form,

Shown here is a simple switch

Diagram of a simple switch

The terminals or channels are labelled 'com' and 'ch', the IVI Switch commands to control routing through this switch are:

IviSwtch_Connect(session_handle, "com", "ch");
IviSwtch_Disconnect(session_handle, "com", "ch");

Where 'session_handle' has been previously obtained by opening a control session on the device containing the switch element.

In this case the Connect function will operate the switch so making a path between 'com' and 'ch', Disconnect will open the switch.

Where there are multiple switches within the switch product, each switch takes a numeric suffix to iterate the series of switches.

Diagram of two simple switches

Matrix channels are labelled thus:

Diagram of a simple matrix

A multiplex is labelled thus:

Diagram of a simple multiplexer

When using IVI switching it is important to remember that IVI considers paths between terminal channels and not the internal switching. The driver keeps record of which paths are connected and will normally refuse to allow a path to be made if it comprises a channel already used in another route. The impication of this is that the user must Disconnect an existing route before using Connect to make a path using a common channel. This is particularly evident on a multiplex, if the user issues Connect("com", "ch1") then Connect("com", "ch2") will be rejected. In order to make this alternate route the user must first Disconnect("com", "ch1").

Change-over or Form-C switch

The change-over switch needs some special attention.

Diagram of a change-over switch

The IVI driver is considering routes though the switch object, not switch positions, this leads to the apparently odd situation that the changeover switch has in effect 3 possible states: no route, com-nc, com-no. In reality there can be no physical implementation corresponding to both paths being disconnected, however the concept is needed in order to support routing algorithms. If the user has explicitly made a connection "com", "nc" then another route will be unable to use this switching element to construct another route. If the user issues disconnect "com", "nc", then both routes are available to routing algorithms.

However, there is no definition of what state the physical switch should take in the 'all disconnected' condition and different manufacturers may and do adopt different strategies. Pickering drivers will revert the switch to its default state, that is there will be a physical connection between "com" and "nc" but the IVI driver will record this as disconnected.

In order to deal with possible undesirable consequences of this ambiguity it is important that users are aware that this connection will exist and that they use the full and correct method that is that the previous connection is disconnected prior to making an alternate connect. In the case of Pickering cards it may be tempting to rely on the fact that Disconnect("com","no") will result in the default route "com" , "nc" being made, however if interchangeability is being used and the switch may be substituted by an alternate model in the future, then that alternate may behave differently and not fall back to the "com" , "nc" connection.

Multi-function switch products

Pickering provides a rich variety of switching products and many contain banks of different types of switch element.

In such cases Pickering adds a letter to identify the different banks.

For example, a matrix product with independent isolation switches on the X axis would contain 2 banks of switches. The first bank will be a set of matrix switches, the second bank will contain the isolation switches.

Diagram of a matrix with isolation switches

The letters A and B indicate the different switch banks in use.

Note that in this case the driver has no knowledge of connections between xA1 and comB1, and between xA2 and comB2. In any routing software hard wires would need to be added to complete the route.

How did we do?
0 out of 0 people found this helpful.