Reading Topology Setting via NiSwitch

[JVL]

I have an application that requires me to switch between 1-wire and 2-wire topologies on a 2503 Multiplexer. I would like to read the current topology setting via code using LabWindows/CVI. I tried to use

niSwitch_GetAttributeViInt32 (SessionHandle, "", NISWITCH_ATTR_WIRE_MODE, &WireMode) ;

The description for this attribute in the documentation is very terse and really doesn't say what this is attribute is. I am assuming that it is the one that I want. Anyhow, when this call is made, I get the error message "Channel or repeated capability name required". Is this even the right approach or is there a better way to get the currently set topology from the device? BTW, the session was established using niSwitch_InitWithTopology.

Thanks,

John

[Srđan_Zirojević]

Before stating the obvious (if you are controlling the initialization of the session, you can keep track of whether the session was initialized to a 1-wire or a 2-wire topology and use that variable later in the code), I can recommend using the attribute you mentioned (wire mode) to determine whether or not you are in 1 or 2 wire topology.

You'll only have to pass a valid channel name to this function, as theoretically at least, different channels on a device might have different wire modes. Using "Com0" as your channel would give you the answer you desire.

This of course is specific solution to your device and to two topologies you are dealing with. Other topologies on other devices would have to have a different approach.

Now, for the  obvious slution - oh, I already stated it above 🙂

I hope this helps!

best regards,

[JVL]

Thanks for the response. I will specify a channel. Your obvious solution did occur to me but in general, I usually let hardware tell me what it's state is rather than rely on variables. Variables can become corrupted and out of synch with the hardware, especially in complex applications using multithreading. The LabWindows code is a dll that is called from a TestStand sequence containing several sockets. Each Test Stand execution thread will switch the mux to the mode needed for the specific measurement. The channels have beein partitioned into 1-wire and 2-wire measurements and each test will dictate what topology is required. I will play with the two approaches and see which makes more sense as the application is developed.

[Srđan_Zirojević]

When analyzing those two options (keeping the variable around vs. getting the state from a session), the second one definitively beats the first one, if done properly. For all the reasons you mentioned, trying to tie the topology to a state of independent variable is probably not such a good idea given the dynamics of your test system. However, while relying on something like a wire mode of a hard-coded channel works for this use case and this switch, it may not scale properly if future expansions of the system include some other types of switches where channels may be named differently.

I'm not sure what the whole architecture of your test system looks like, but a good, scalable solution might involve carrying an object around that contains both the switch session and additional data (such as topology and possibly other identifying elements), and using that object throughout the tests, extracting the session and the topology from it when needed...

Of course, you are the best person to weigh in pros and cons of either approach.

best regards,