Is there a possibility to start the VeriStand 2014 Gateway programatically using LabVIEW 2014?

[thumble]

Hello,

This is a reload of the Is-there-a-possibility-to-start-the-VeriStand-2011-SP1-Gateway because what worked in 2011 SP1 does no more in 2014.

I ported the code from the previous topic, do do the same thing (calling "__cdecl Int32 StartVeriStandGateway(out Int32 handle)" in "C:\Program Files (x86)\National Instruments\VeriStand 2014\Data\NationalInstruments.VeriStand.Gateway.dll".

Doing this from a .NET programme (console or windows process) or directly from a DLL node in LabVIEW 2014 seems to have no effect, knowing the .NET code worked in 2011 even when called from a Windows service.

Is there a new way to do it?

By the way, the "NationalInstruments.VeriStand.WindowsRegistry.GetInstallationDirectory()" method has disapeared from the assemblies.

Best regards,

[thumble]

Re,

Some clarification: I was not totaly right: it seems to work when everything is called from a .NET program. But when called from LabVIEW, direct call to the DLL => no effet?, call through the .NET assembly => Licensing error code.

Regards,

[Jarrod_S.]

It certainly should work when called from a LV program if called correctly. NI VeriStand.exe is a LabVIEW-built application that invokes the Gateway. Can you post the configuration page screenshot for your Call Library Function Node?

[Jarrod_S.]

Are you trying to load the VeriStand 2014 Gateway DLL in a LabVIEW 2014 VI? Or is it a different version of LV?

[thumble]

Hi Jarrod,

You're rigth, after PC reboot the Gateway starts when calling the DLL node (OpenWorkspace & GetSystemStatus are called with no errors), but when I try to ConnectToSystem the program stays blocked into the sub-vi, although the code works well if the Gateway was previously started normally by running VeriStand from Windows.

I tryed to change the call policy in the DLL node (UIThread & any thread) but it seems doing nothing.

Please find here joined the test files and debug capture of the stall.

Best regards,

[StephenB · Accepted solution]

I remember a while back I saw this. There was some issue where the dll cannot run in the UI thread, but LabVIEW has no way of specifying any thread but the UI thread. Therefore the workaround was to put the DLL calls in a subVI, set that subVI to run in the 'standard' thread, and set the DLL call to run in any thread. See attached.

[thumble]

Thanks Jarrod,

I'm busy this week, but I forward to a person concerned with this issue. I'll give feedback ASAP.

Best regards

[thumble · Accepted solution]

Re,

You’ve found the reason of the blocking. But it’s not located at the DLL call but at the ConnectToSystem.vi call. Hopefully this code is not locked and I could change its execution policy to standard, so it doesn’t block anymore. Maybe some other calls are suffering from the same artifact, but I didn’t check so far.

Best regards,