LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Communicate with 3rd Party Instrument through .NET DLLs (HTTPS)

Solved!
Go to solution

Hello,

 

We have an instrument running web services that are used for control and monitoring of the device.  All of the controls are built within a set of .NET DLLs that we are using in other software applications (C#). 

 

We are now trying to use these DLLs from LabVIEW.  We are doing this in LabVIEW so we can do some additional data analysis and synchronization with other instruments already running in LabVIEW.

 

Everything works fine when the DLLs and instrument are using HTTP.  However, as soon as they switched to using HTTPS we can no longer get the DLLs to work properly in LabVIEW.  They continue to work fine in our other C# applications.

 

Our problem is very much like the one posted here https://forums.ni.com/t5/LabVIEW-Web-Development/xmlhttprequest-from-LabVIEW-as-client/m-p/3554863#M.... We tried the same solution (ignoring the self-signed certification errors) but that didn't resolve our problem.  Unfortunately, we're not getting any errors in LabVIEW or useful exceptions within the DLLs.  The only exception shown in the DLLs is that the connection was closed.

 

I feel like we're missing something simple (perhaps a LabVIEW environment configuration setting).  We would appreciate any help that others could offer to help us narrow this down.

0 Kudos
Message 1 of 3
(947 Views)

This helped me with .NET\HTTP(s) in the past:

 

AS ADMINISTRATOR, run:

C:\Windows\system32>add urlacl url=https://+:80/myurl user=users

 

See add urlacl - Win32 apps | Microsoft Docs

 

The details elude me.

0 Kudos
Message 2 of 3
(892 Views)
Solution
Accepted by topic author JAD10

We were finally able to figure out the problem.

 

After further investigation we were noticing that the HTTPS connection was being closed somehow when the DLLs were called with LabVIEW.  We realized that we needed to configure the SSL protocols at the lower HttpClient interface level within our .NET DLL and not use the global .NET ServicePointManager.

0 Kudos
Message 3 of 3
(862 Views)