Modeling (incomplete) switch matrix in Switch executive

[h192]

Hi,

is it possible, to model a switching matrix in NI Switch Executive where not all NxM (row to bus) combinations are possible/allowed?

In IviSwtch-drivers one has to create a connection matrix,which defines the available and not available switching points of a switching matrix (refer to How to Develop an IviSwtch-compliant Driver to Use with National Instruments Switch Executive).

e.g. a switching (matrix) device where each channel can be connected to 2 lines of a bus

   r0 r1 r2 c0 c1 c2 c3 c4 c5
r0 x  x  x  0  0  x  x  x  x
r1 x  x  x  x  x  0  0  x  x
r2 x  x  x  x  x  x  x  0  0
c0 0  x  x  x  x  x  x  x  x
c1 0  x  x  x  x  x  x  x  x
c2 x  0  x  x  x  x  x  x  x
c3 x  0  x  x  x  x  x  x  x
c4 x  x  0  x  x  x  x  x  x
c5 x  x  0  x  x  x  x  x  x

 

[Srđan_Zirojević]

Can you give us some information about the underlying drivers that your switch executive virtual device will be using?

It seems like the driver should be responsible for imposing such restrictions if they are really driver restrictions (i.e. the device is really a sparse matri, and not a fully connectable matrix that you want to restrict).

If the driver is correct in all it does, you have a chance to make the switch executive disallow certain connections. Although not meant for this type of use case, you can create a list of exclusions, and exclude connections that you do not want to allow. For example, and from your example, row r0 can only connect to c0 and c1, but not to c2 through c5. If the underlying driver allows for those connections and you want to prevent them, you will need to create a mutual exclusion, and put r0 in one group, c2 through c5 in another,  and save it. repeat the same thing for the rows r1 and r. 

If your matrix is bigger than this, you can export your virtual device into excel, and edit the exclusion configuration there.

While doing so,  please understand that exclusions have effect of prohibiting those connections from ever being made on this virtual device, and not only prohibiting direct connections. Make sure that your application does not have a requirement to connect those two channels somehow through a hardwire or otherwise before you apply this reasoning.

Moreover, please share your specific underlying switch topology with us if you can, I'm curious to learn where does your requirement for sparse matrix comes from.

Hope this helps!

[h192]

Hi,

the driver is not yet implemented. I'm just interested in the main principles and whether it is possible anyhow.

Since IVI implies to create a connection matrix, the "not complete" NxM matrix can be reflected in the driver. A try to connect e.g. r0 to c4, will be denied by the driver.

My question now is, if there is a way to also reflect the matrix "incompleteness" in NI Switch Executive.

The work-around with the exclusions is not useful, because it might be possible and also required, to connect e.g. r0 to c4 indirectly (over some other connections) - but this is not possible, if its excluded.

I would expect that there should be a way to define a switching device (e.g. a not fully switchable NxM matrix) with the same connection matrix like it is used in the IVI driver.

[Srđan_Zirojević · Accepted solution]

OK, this makes it simple (or I believe so). The routing logic per device is the responsibility of the IVI driver that the switch executive uses to connect/disconnect routes. NISE makes no assumptions about the topology of your device - it reads the channels and queries for possible connections using the IVI instrument driver. Therefore, if you implement those restrictions in the instrument driver (as you correctly pointed out in your original post's screenshot of the connection matrix), then switch executive will only be able to establish those connections.

My comments about using exclusions were aimed at making switch executive create those restrictions when the underlying instrument driver incorrectly neglected to do so.

I hope this makes sense.