The NISwitch driver function is returning some garbage value.

[haari]

Hi,

The NISwitch driver function is not returning correct value.

I also checked all parameters passed to it,they are correct only.

i32err1=(*ProcAdd1)(resourceName,topology,simulate,resetDevice,vi);

ProcAdd1 is the function pointer for niswitch_Initwithtopology

i32err1 ,it is giving some garbage value.

Please suggest one solution for this.

Regards,

Harika.

[Srđan_Zirojević]

Can you please post the garbage value? Is it consistent? Or always different?

[haari]

Hi,

That garbage value is consistent.

It is -1074130544.For every driver function i am calling it is giving same value.

Please suggest some solution for this.

Regards,

Harika.

[Srđan_Zirojević]

Harika,

That value is not a garbage value - it is a valid error code that is defined by IVI.
-1074130544 = 0xbffa1190, which means "The session handle is not valid."

This means that you are either not calling the driver Initialization function (either init, InitWithOptions, or InitWithTopology), or that function is failing. The resulting VI session will be NULL, and all subsequent driver calls will return the above mentioned error.

To get the text error message for any error number, you can call niSwitch_error_message function.

Now, in your original post you stated that you are getting this error from the call to InitWithTopology. That I find extremely unlikely - that function returns the session, it cannot return an error stating that the session is invalid. I agree that every OTHER driver function that you call would return this error, but not THAT one.

I'd like you to give it another try and get the error number returned by the Init call. You can also (and you should) call, in case of failure, the niSwitch_GetError function, and obtain the extended error information. You can call this function even if you don't have the session, you just pass NULL for the session, and make sure that you call it from the same thread that made a call to original function (in the absence of a valid session, the driver keeps the error information in a thread-local variable).

Another thing that I'd like to know, in order to try to help you better, is what development environment do you use? Why did you opt to create your own indirection layer with function pointers, and did not use the libraries provided with the driver?

best regards,

-Serge

[chericks1]

Hi Harika,

May I ask if Serge's post provided you with all the information you need?  Do you still require further assistance?

Thanks!

Chad Erickson
Switch Product Support Engineer
NI - USA

[haari]

Hi,

Here we are using Labwindows/CVI development environment.Its version is 8.1.

For automation of test equipment we are using "ATETOOLKIT",its a Honeywell proprietary tool.Its environment is such that we have to call driver functions through function pointers.

That is giving the same error-Invalid session handle.

I have posted the same problem in Labwindows/CVI forum.They suggested that it is related to Ni switch driver so they told me to post this in Ni Switch forum.

Please suggest some solution for this.We have no time here.August 4th is our deadline.

Regards,

Harika.

[haari]

Hi,

That problem is not yet solved.

Please provide some solution for this.

Regards,

Harika

[Srđan_Zirojević]

Harika,

Thanks for pointing out your post to CVI thread. The error ("CVI has detected inconsistency in runtime stack.This may be due to calling convention mismatch in last function call.") is due to your own definition of the function. Why don't you use the provided instrument driver for NI SWITCH? That will eliminate errors like this one, and you get absolutely no benefit from developing and using your own functions.

In order to figure out what else is going on, please do what I told you to do in the previous post. Once you call into driver correctly (remember, if the calling convention is wrong, the parameter you *think* you are passing to the driver DLL are not read from the same place in the DLL where the callee put them, so if you think that you are passing some values to the driver, the driver might be reading complete garbage).

Step 1: Use the niSwitch_InitWithTopology function. To do that, just add the niSwitch.fp instrument driver to your CVI project.
Step 2: Run your code in debug mode. If there are errors, CVI will pop up a dialog box explaining what the error code means.

It would also be a good idea to run one of the niSwitch examples that the driver installs for CVI - and see if those would work for you. These examples are very simple, but the error handling inside of the examples is exceptional and will, in case of error, point out exactly what went wrong and provide a helpful hint on how to fix the problem.

Best regards,

-Serge

[Srđan_Zirojević]

Oh, and one more thing - I said that you "get absolutely no benefit from developing your own functions." I'd just like to give you an opportunity to explain why did you choose to not use niSwitch instrument driver and write your own wrapper instead?

I do realize now that August 4th is your deadline, and I am convinced that we can get over this issue quickly. I can assure you that I understand what the problem with your code is, and that with following the instructions you will be able to get it to work before the day is over. Incidentally, what time zone are you in?

If you could try out the things I outlined in the previous post, and quickly respond with the findings, we may be able to help you on time for your deadline.

best regards,

-Serge

[Srđan_Zirojević]

I'm repeating myself - oh, and one more thing!

I looked at the snippet of your code that you posted to CVI thread. You are basically doing this:
-load library(niswitch_32.dll)
-get proc address for niSwitch_InitWithTopology
-execute function
-free library

I imagine that you have the intent to use the session that you obtained in the call to init later somewhere in the code. Freeing the library that produced the session for you is a very bad thing to do. SUch code design can lead to crashes, and here is why: the instrument driver defines callback functions and those are stored within the instrument driver session. The callback functions are stored as physical addresses of driver functions, as loaded into memory. You cannot guarantee that the repeated LoadLibrary calls will load the DLL into the same location in memory each time. You may get this behavior 99 times, but 100th time it will load the DLL elsewhere, and when you call a function which invokes the callback at address XYZ, you guessed it - there won't be any code at the address XYZ, or worse, there will be some other unexpected code there. An exception C0000005 is guaranteed.

So, please do not load and free the niSwitch library all the time. You have to keep the library loaded at least while you have the session open. You may unload the DLL safely only after you close all open niSwitch sessions.