relay device resets during initialization

[Kasey]

I have a PXI-2565 relay switch and I would like to check the status of a single channel. I am using a vi called "niSwitch Gte Relay Position", but in order to use this I need to have an instrument handle. I get this by initializing the device with the "niSwitch Initialize with Topology" vi. This vi has a boolean called "reset device" that defaults to "yes".

If I leave the input empty (default setting), my vi runs, but the channel resets before getting the relay position, therefore it always returns "open". But if I set the reset value to false, it gives me an error saying that the device must reset on initialization.

Is there a different way of initalizing the device that won't reset the channel? Or can I get the insturment handle some other way?

Thanks.
Kasey

[Srđan_Zirojević]

The current version of niSwitch will not allow initialization without performing a reset operation.
If you want to access device without reseting its state, you may opt for niDAQmx switch API. This API is session-less, i.e. you can address individual channels and relays by extended name (Dev1/ch0 instead of opening a session to Dev1 and accessing ch0). Unless you explicitly call Device Reset VI, your relays will remain in the current state.
Warning: when using this API, be prepared to error-check and state-check some more. Example: having niSwitch application that initializes a session and then connects channels A and B would work every time you run it, as it will reset the device every time and connection between A and B would be available. Running a DAQmx VI that connects A to B would work (possibly) the first time, but will invariably fail on subsequent attempts, unless some other call disconnected these two. I.e. make sure that your logic is correct and that you have all the guards in place.

I hope this helps

-Serge

[Kasey]

Thanks for the suggestion about niDAQmx. I tried to use niDAQmx, but I'm not sure how to access my relay through those vi's. Are there any examples you can suggest that show how to access a relay with niDAQmx?

Thanks again.

[Kasey]

Never mind. I figured it out. 🙂 Thanks again.

[JPO]

I am using the niSwitch API in Visual Basic and I recently ran into this same problem. I wrote a single function that would connect two channels together when I called it. However, this function would open the session (reset the device), make the connection, debounce, then close. However, the reset is not desired since I want more than just two channels conencted at a time, and the number of channels to be connected varies. None of the niSwitch init functions support a VI_FALSE value for the resetDevice parameter.

So I just wrote my visual basic code so that one session is opened to the switch and remains open for the life of the application. When the code is terminated, so is the session. 

Is there any danger in leaving a session open for extended periods of time? And what kinds of errors do you need to check for? If I tell two channels to connect that are already connected it just says they are already connected and no harm is done... so I am not worried about that...

JPO

[Srđan_Zirojević]

JPO,

this is actually preferred way to program any instrument driver - as there is too much (often unwanted) overhead during the initialization, you probably want to do it only once in your application. Teststand (test management software) offers session management that does exactly this - keeps one session open all the time, so this concept is not anything strange nor unusual.

The only reason I can imagine why you may want to colse the session while wanting to open it again in the same process is if you want to access the same physical device from another process. Having a session open in one process will prevent all other processes from using that same device. And if you ever decided to do something like this (control the same instrument at the same time from two different processes), make sure you implement some kind of messaging or a protocol between the two processes so that they don't stomp over each other.

I'm glad you're keeping them sessions open all the time - it's the way to go!