Conflict using simultaneously IVI Switch and Switch Executive ?

[mdy]

Hi,

I use IVI Switch and Switch Executive libraries in an Labwindows CVI project, and I meet some problems :

I call SE lib for InitSession/CloseSession/FindRoute and Connect/Disconnect (apply to any switch devices in the SE configuration).

I call IVI Switch lib for SelfTest and Reset (apply to a single device).

But when I do an IVI Switch Reset then a Switch Executive Connect or Disconnect, an error occurs : Switch Executive seems to ignore what IVI Switch operations do to the device ?

Also, can you tell me if :

niSE_OpenSession performs a self test for the devices in the config ? A reset ?

niSE_CloseSession performs a reset for the devices in the config ?

Thanks.

[Srđan_Zirojević]

Hello,

the niSE session talks to underlying IVI drivers using the IVI Switch session underneath, so any additional opening of IVI Switch session to the same device will cause the two driver sessions (that keep the information about the state of the hardware connections) to be either one or both out of synch with the actual hardware state). Because of the architecture of the underlying IVI drivers, niSE session cannot know if and what someone did to the instrument using IVI Switch session.

Therefore, it is not adviseable to use IVI Switch session while having another session open to the same device. If you need to use the invasive operations - which is anything that changes the state of the device, such as Reset and possibly self-test (self-test may be implemented as an operation that cycles relays and it may not but you can't be sure), you must make sure that one session is open and closed before another type of session is open.

The ni Switch Executive Open Session calls IviSwtch_init (with ID Query and Reset set to true) and CloseSession closes the IVI Switch sessions with the call to Close. The niSE session does not make calls to either reset or self-test explicitly.

Always attempt to perform all the operations on the same piece of hardware using the same API. If you need to reset switches, use the niSE_DisconnectAll function. If you need to perform the self-test operation, open a session to IVI Switch and perform the self-test, and then close it before opening the session to niSE virtual device.

There is also a back-door possibility that you can obtain the IVI Switch session that has been open for the constituent devices by niSE, but you must make sure that whatever you do with that session leaves the state of the switch intact when you get back to making calls to the niSE session. If unsure, you can always call niSE_DisconnectAll() as the first thing coming back to the niSE session to ensure that the state stored in niSE session matches the state on the actual hardware.

Again, it is best not to use both sessions, but rather pick one and try to perform all operations with it before switching to another type of session.

[GSides]

Hello,

I am using NI switch executive along with an Agilent 34980A switch box.  I would like to open a session to NISwitch but do not want to reset the entire 34980 chassis.  I read below that niSE_opensession defaults the reset to TRUE.  Is there an option (options seem to be the second argument to niSE_opensession) to set the reset to false when initializing the ivi driver? 

Thanks,

Grant

[Srđan_Zirojević]

The NISE open session passes the option string parameter contents down to IVI driver it tries to open, so the answer to your question may be found in the documentation of the specific driver.
That said, sInce the specific driver allows for not reseting via a boolean parameter, I doubt that there would be an alternative way to not reset it via options string parameter.

Moreover, the option to not reset would really work only if you chose not to reset because you cared about the state of relays that are not touched by the switch executive session operations. The reason why NISE requires reset at the beginning is to ensure known state of the routes, so it could proceed with finding, connecting, and disconnecting all routes correctly.

In theory, even if the underlying switch driver would correctly report all closed paths (by persisting that information somewhere between sessions and processes), NISE session would not know whether to associate the existing connections with a route, route group, explicit path, and with which one if multiple matches occurred. It would not know what is the reference count of existing connections, even if only a single match existed.

For all these reasons, it is likely that it won't be possible for you to not reset the underlying driver when opening a session.

If you still absolutely have to leave some relays closed, would you be willing to describe in more detail which portion of the box you would like to see untouched by open session function, and whether you intend to touch that portion during NISE session operations. I may be able to suggest a way for you to circumvent the reset behavior, but I would qualify this as a hack, and as something that has a high likelyhood of messing up the whole system if the above mentioned constraint (repeat: you are only leaving those connections closed that are not to be touched by nise session) is not honored.

best regards,

[GSides]

The goal is to not reset the card in slot 1.  I have 34921 cards in slots 2 and 3 of the 34980A chassis that may be reset; these are the only cards I use switch executive for.  The card in slot 1 has switches but they are not used, only the I/O features are used and I do not want to reset this card.  So if there is a way for the open session to selectively reset the 8 slots in the 34980A chassis, then we have a solution.  I agree with your comment "since the specific driver allows for not reseting via a boolean parameter, I doubt that there would be an alternative way to not reset it via options string parameter."  However, could the niSE_opensesison set this Reset arguemnt to false?  If so, I think we could use other commands in the 34980 ivi driver to reset specific switches.  Anyway, thanks for the reply and I hope there is a way to reset individual slots in the chassis.

-Grant

[Srđan_Zirojević]

Grant,

I don't believe that there is a way to make NISE open session call the specific driver with the reset=false. However, what you can do is the following:

create a driver wrapper for your 34980 driver. Give it a different prefix and a different DLL name. What you need to do is export all the functions NISE uses: InitWithOptions, close, connect, disconnect, canconnect, all the set/get attribute functions, get error etc. Pretty much, export all of the IVI class defined functions (you can find a list of those in the IviSwtch.h)

Then, implement this driver as a simple wrapper around the 34980. For example, your my34980_Connect would look something like this:

ViStatus my34980_Connect(ViSession vi, ViConstString ch1, ViConstString ch2)
{
   return ag34980(vi, ch1, ch2);
}

and so would every other function you implement.

THe only difference would be in the InitWIthOptions, where you would implement it like this:

ViStatus my349890_InitWIthOptions(ViRsrc resourceName, ViBoolean idq, ViBoolean reset, ViConstString optionsString, ViSession* newVi)
{
   ViStatus error = 0;
   checkErr(ag34980_InitWithOptions (resourceName, idq, VI_FALSE, optionsString, newVi);
   // perform functions to manually reset the cards in slots 2 and 3
Error:
   return error;
}

Now, in the IVI configuration, you would have to create a different software module that would point to your DLL instead of pointing to agilent 34980 dll. Your prefix would be 'my34980', and your logical name would then point to a driver session that uses this software module.

All the calls NISE makes would then go through the my34980, and for all the calls it would add one extra call (a couple of pushes on the stack for function parameters, and an extra call, totalling not more than 10-20 CPU cycles, so I would call it negligible when compared to the I/O overhead of the actual functions).

It would not be too difficult to create this wrapper - it can be done in about the same amount of time it took me to write this message.

Hope this helps some - let me know if you decide to use it how it worked. I've never done something like this 🙂

best regards,

-Serge