NISE Test Panel and API fail

[Francois_airbus]

Hi,

I have a problem using NI-SE 18.0 on Windows 10.

This is the situation :

I am using one of my company's homemade switch hardware module for which I developped a IVIswtch Compliant specific driver (using the IVISwtch compliant driver wizard provided with labwindows/CVI). The driver is built in both 32 and 64 bit.

First, I compiled my driver in 32 bits on a 32 bits system (Windows 7, NISE 3.6) : I can perfectly use the device after having created a proper IVI configuration.

- using the NISE test pannel (relays are commuting, I can see in NI-IO trace all function calls at a NISE level)

- using IVIswtch API in a C program (relays are commuting, I can see in NI-IO trace all function calls at a IVI level)

- using NISE API in a C program (relays are commuting, I can see in NI-IO trace all function calls at a NISE level)

Then I compiled my driver on a W10 system with NISE 18.0 in both 64 and 32 bits configuration (because NISE HMI is 32 bits and requires a 32 bit driver, even on a 64 bit system).

For information, I have a virtual device linked to an IVI logical name associated with a driver session that is not configured as simulated ("Don't simulate" is selected in general tab of IVI driver session).

I can create routes using NISE : the driver is initialized with "Simulate=1" option, and all the channels caracteritics are given by the driver to NISE (I activated NI-IO trace and I can see all function calls (niSE_OpenSession...getAttributes....)). Everything works as expected.

The problem occurs when I try to use the test panel on the device. I can see in NI-IO trace the niSe_OpenSession function call that returns "SUCCESS" when i click on "test panel" for my device. And using an ethernet spy I can see that the driver actually communicates with my device. but, when I try to connect a route (exemple Route0 in routegroup0) nothing happens. I don't even see a trace in NI-IO trace (for instance niSE_connect("MyDeviceLogicalName","Route0")), whatever the route I try to connect, until I close the test pannel (niSE_closeSession appears in NI-IO trace).

I checked that in NI-IO trace all API where captured (and iviswtch checkbox is enabled), and I also checked that my driver is not called when calling functions to connect channels (I log all my IVIswitchCompliant-homemade-driver function calls in a log file).

Can you help me please ?

Thanks,

François

[Francois_airbus]

Hi,

I have a problem using NI-SE 18.0 on Windows 10.

This is the situation :

I am using one of my company's homemade switch hardware module for which I developped a IVIswtch Compliant specific driver (using the IVISwtch compliant driver wizard provided with labwindows/CVI). The driver is built in both 32 and 64 bit.

First, I compiled my driver in 32 bits on a 32 bits system (Windows 7, NISE 3.6) : I can perfectly use the device after having created a proper IVI configuration.

- using the NISE test pannel (relays are commuting, I can see in NI-IO trace all function calls at a NISE level)

- using IVIswtch API in a C program (relays are commuting, I can see in NI-IO trace all function calls at a IVI level)

- using NISE API in a C program (relays are commuting, I can see in NI-IO trace all function calls at a NISE level)

Then I compiled my driver on a W10 system with NISE 18.0 in both 64 and 32 bits configuration (because NISE HMI is 32 bits and requires a 32 bit driver, even on a 64 bit system).

For information, I have a virtual device linked to an IVI logical name associated with a driver session that is not configured as simulated ("Don't simulate" is selected in general tab of IVI driver session).

I can create routes using NISE : the driver is initialized with "Simulate=1" option, and all the channels caracteritics are given by the driver to NISE (I activated NI-IO trace and I can see all function calls (niSE_OpenSession...getAttributes....)). Everything works as expected.

The problem occurs when I try to use the test panel on the device. I can see in NI-IO trace the niSe_OpenSession function call that returns "SUCCESS" when i click on "test panel" for my device. And using an ethernet spy I can see that the driver actually communicates with my device. but, when I try to connect a route (exemple Route0 in routegroup0) nothing happens. I don't even see a trace in NI-IO trace (for instance niSE_connect("MyDeviceLogicalName","Route0")), whatever the route I try to connect, until I close the test pannel (niSE_closeSession appears in NI-IO trace).

I checked that in NI-IO trace all API where captured (and iviswtch checkbox is enabled), and I also checked that my driver is not called when calling functions to connect channels (I log all my IVIswitchCompliant-homemade-driver function calls in a log file).

Can you help me please ?

Thanks,

François

[Francois_airbus]

I would like to add a precision if it can help :

on my Windows10 system, NISE V18.0 :

if I use the given switch executive virtual device example, present by default  ("SwitchExecutiveExample"), I have the same problem : I can only see "niSE_OpenSession" and "niSE_CloseSession" traces although I do close and open routes in test panel

on my Windows 7 system, NISE 3.6 :

if I use the given switch executive virtual device example, present by default  ("SwitchExecutiveExample")? I can see all the traces (niSE_OpenSession, niSE_Connect, niSE_Disconnect ...)

So I think there might be a problem with my NI-MAX/NISE config but the devices are declared exaclty the same (the example and my thrid party device).

[Francois_airbus · Accepted solution]

For viewers information after a few more experiments it appears that the NI-IO trace spy blocks NISE function calls ! If you want to actually open/close your relays on your switching device you just have to disable capture in NI-IO trace or simply close it. It is a known issue for NI, they will probably fix it in the next version of their software suite. If you still need to monitor function calls at a NISE level, you can use the NISE debug panel that does NOT block NISE function calls.

I hope it can help readers