Minimizing RF-stubs in 2593 using exclusion

[thols]

When making a connection from CH0 to COM1 on a 2593 in independent mode, COM0 will also be connected to c0c1c2c3d0d1. I first tried to avoid this happening by creating a mutual exclusion between com0 and ch0 but that didn’t help. So my question here is: why didn’t that help? How can NISE choose to connect com0 to ch0 when I order it not to?

I found out that I can make a connection from COM0 to d0d1 to control this connection, but I still think that a mutual exclusion between com0 and ch0 should not allow connecting com0 to ch0. Or have I misunderstood exclusion usage? I tried to use a Set Exclusion also.

My example path:

 

I should note that I have read http://zone.ni.com/devzone/cda/tut/p/id/2996 and will try to use the tips described in the section “Configuration Channels and RF Stubs” to optimize the other parts of my signal route (It would have been nice though to have some mode selection that tells NISE to allow/prefer the signal to split or not. And to have a graphical representation of the signal path/relay positions would have been great).

[Frank-L · Accepted solution]

Thols,

This problem occurs because as far as the software is concerned, all SPDT switches are considered disconnected in software on bootup. So as far as switch executive is concerned, there is no connection at bootup. This leads to problems which your exclusions will be invalid, as they will say it is disconnected when in reality, it actually is connected. The following except from the KB Switch Executive "Disconnect" or "Disconnect All" Violates Exclusions with SPDT Relay Modules describes this issue.

"

If an explicit call is made to disconnect COM from either NC or NO using the niSE Disconnect VI, NI Switch Executive updates the software connection state such that COM connects neither to NC nor NO, but does not change the hardware connection. Thus, the software state no longer reflects the hardware connection, and verification of exclusion conflicts might be inaccurate. In order to accurately reflect the hardware connection in the software state after using the niSE Disconnect VI, you must then connect either NC or NO to COM using the niSE Connect VI.

If an explicit call is made using the niSE Disconnect All VI, NI Switch Executive connects NC to COM for every relay but does not reflect this change in the software state. Thus, verification of exclusion conflicts might be inaccurate. To reflect this change in the software state, you must then connect NC to COM using the niSE Connect VI.

"

Your best bet to verify that this does not happen is to disconnect all, then ensure that you specifically order the relay KD0 to close before you make the connection between CH0 and COM1.

This is how I would do this. Set up two routes, and ensure that the first route to go is:

[PXI1Slot4/com0->PXI1Slot4/d0d1]

The second route should be:

[PXI1Slot4/ch0->PXI1Slot4/a0b0->PXI1Slot4/b0b1c0->PXI1Slot4/c0c1c2c3d0d1->PXI1Slot4/d1d2->PXI1Slot4/d2d3d4->PXI1Slot4/c4c5c6c7d4d5->PXI1Slot4/com1]

To make this connection work.

Let me know if you have any questions!

[thols]

Thank you for your help. I had read about the SPDT-issue but perhaps not that KB, and I didn't understand the impact of it, but now I do. Thanks also for your description of the proposed solution. This is how I do it now and it works great.

Your link to the KB didn't work so I'll repost: http://digital.ni.com/public.nsf/allkb/52DE58670391A435862575210003089B