06-08-2006 08:12 PM
06-09-2006 12:59 AM
06-09-2006 06:03 AM
06-09-2006 11:56 AM
06-11-2006 10:16 PM
06-12-2006 11:20 AM
Hi 还是秘密,
I've reproduced your issue by attempting to connect two channels together that I've set as mutually exclusive. In Switch Executive, click on the Channels/Exclusions tab and check to see which channels are listed under Mutually Excluded Channels. It is likely there are route groups in your configuration attempting to make connections between excluded channels, and this is why you get the following error:
Connecting this route would cause excluded channels to be shorted together.
Best regards,
Chad Erickson
Switch Product Support Engineer
NI - USA
06-13-2006 07:30 PM
05-01-2018 06:17 PM
Not true. All class-compliant IviSwtch specific drivers have the option to initialize the driver with a reset or without a reset. The default instrument setup is applied regardless. So in theory a user should be able to preserve connected paths through initialization. I actually have such a use case where I want to initialize and close some paths without disconnecting currently connected paths. If I do it at IVI level I can bypass switch reset and all works fine. However, when using NISE I can't do that because the NISE initialization call in nise.dll calls "IviSwtch Initialize With Options" with the default value for the "reset device" parameter, which is true.
So while I understand your argument about the benefits of NISE knowing the state of the instrument, sometimes I, the human programmer know better than that and should be able to override it. No, I don't think it's required, I think it's an oversight on NI's part to leave out those inputs. They provide an option string parameter to pass on to "IviSwtch Initialize With Options", but no way to override "id query" or "reset device."
05-01-2018 08:48 PM
Hm, not sure what the 'not true' refers to, but I'll give it a try:
NISE operates on a higher level than IviSwtch drivers. NISE deals with routes, route groups, etc. while IviSwtch deals with connected channels and simple paths through configuration channels.
IviSwtch specification does not mandate that the connections/state is preserved between sessions; if you connect two channels using IviSwtch, close the session, and open the session to the same switch again, CanConnect would not know that the two channels are connected, and the call to disconnect would fail.
Instead, to achieve what you want, perhaps you can go in the direction of preserving the session life cycle. What is your desired lifetime of a session? If it is <= the process in which you're running, then you may make a NISE session singleton in your process. If it is > then the lifetime of a process, the external session manager of some sort could be used. With this approach you would be able to manage the state of your switches without worrying of the specific driver's implementation.
hope this helps!
-Srdan
05-02-2018 02:14 PM
Hi Srdan,
Thanks for your prompt answer. My "not true" statement wasn't very clear, was it?
In principle I agree with everything you say. The disagreement I had with your post was the implication that you can't possibly expect "niSE Open Session VI" to open a session without resetting the switch(es). "IviSwtch Initialize.vi" initializes a session with the option of doing a device reset or not. "niSE Open Session VI" calls "IviSwtch Initialize with Options" and gives the option to pass in the "option string", but leaves out the "id query" and "reset device" inputs, using the default values of TRUE for both. While that covers 95 % or maybe 99 % of all situations out there, I still think it's an oversight on NI's part to leave out those inputs so we the users don't hurt ourselves by using them.
The original post didn't ask how can I avoid resetting the switch on initialization AND keep track of (cache) the state of the switch? It simply asked how can I bypass the initialization. I felt you assumed the state caching was implied. So the "not true" referred to the fact that it doesn't have to be that way, since you seem to argue it has to be that way.
Reality is that in some situations we can't use best practices. For reasons out of scope of this conversation I want to open a session, connect a route, close the session. Then I want to open another session without resetting all switches, leave all as they are and close another route. I am the only user so I know nobody else will touch the switches and that's good enough for me. I don't care that SwitchExec and IviSwtch don't know the state of the switch because I know it. If I need to start with a known state, I can always do a reset or disconnect all switches.
Because of the way "niSE Open Session" was designed it doesn't allow the scenario above. It will always reset all switches on initialization. This forces me (and possibly the original author of the post) to do one of two things: use a session manager to track the SwitchExec session or connect all routes before closing the session.
Due to architectural choices made long time ago in the codebase I'm using, I can't use the first approach, so I'm forced into the second one. Least effort for me would have been to be able to avoid switch(es) reset between sessions. I can't use IviSwtch because I have a complex switch matrix and use SwitchExec.
Scipio Africanus