Switch Hardware and Software

cancel
Showing results for 
Search instead for 
Did you mean: 

About NISE Open session.VI

OK, I get your requirements.

 

Now, since there are users out there that depend on the current, documented behavior of the API, I would not anticipate NI changing the API to satisfy your request. 

Also, I do not see you changing your architecture that was developed with a slight mismatch between the desired and actual behavior.

The good news is, I have two options for you if you want to keep the code you have and continue using NISE in the way you want it to work with respect to reset behavior at init:

Option (1):

This option requires that you have access to the source code of the specific drivers you're using underneath IviSwtch devices. You can check the DLL used in your ivi configuration and verify that you indeed have the source code of the drivers in question. If you do, you can edit the prefix_InitWithOptions function and change its behavior when the reset is passed as true, ignoring it. You can also look at the driver and make sure that existing paths are not somehow destroyed with another function call. Recompile the driver, and change your deployment to use the driver you have modified. Your niSE_OpenSession will stop resetting that specific driver.

Option (2): 

If you do not have the source code for the driver used in your ivi configuration, you can write a wrapper DLL, and "overload" the exported functions. The new dll you would write would pass through any arguments to all the IVI-defined functions except the InitWithOptions one, that would hard-code 'VI_FALSE" for the reset parameter. Then all you need to do is put this dll next to your driver's dll (hopefully named similarly  but not the same, something like fake_driver32.dll next to driver32.dll in the ivi\bin directory) and then point your IviSwtch virtual device configuration to the fake driver.

 

Given that you said that you're the only user of the drivers, you should know that whenever you use those new virtual devices, that you will have the reset behavior altered. 

 

Hope  this gets you closer to the resolution of your issue.

 

btw it was fun to come back to a thread that is 12 years old. thanks for the refreshed memories 🙂

0 Kudos
Message 11 of 12
(1,383 Views)

Hi Srdan,

 

And thanks for your answer. I didn't really expect an answer out of a 12 year old post, and definitely not within a couple of hours. You must be a really active user!

 

I realize NI is very unlikely to change the prototype of "niSE Open Session". Behavior should definitely stay the same (if choosing between reset/no reset at initialization, reset is the right choice). I didn't wish for a change in behavior,  but rather a change in the prototype so I can change behavior in my code.

 

Your proposals are very interesting, especially the second one. But both would wreak havoc with my coworkers :). When I said I'm the only user, I meant user of the HW, not the switch driver.

 

I do have access to the driver code and already removed an unnecessary "open all" call (in other words somebody thought that whether or not the user sends true or false for "reset device", switches should be disconnected anyway), and that's as far as I should go. Moving further would mean basically breaking the driver (compliance). Since we deploy code and have a revision control system, adding a wrapper DLL would be questionable and a lot of work for the returns.

 

I'm using LabVIEW and TestStand on top of IVI and Switch Exec, so will make changes there. I certainly appreciated your expertiese and willingness to help!

 

Regards,

 

Scipio Africanus

0 Kudos
Message 12 of 12
(1,368 Views)