Most of the time I am able to find solutions to my issues just by reading this forum but I wasn't that lucky this time.
So, i got an issue when i'm trying to install my build.
I got the following message: "This distribution is built with an older version of winMIF that is not compatible with .NET 4.6.2 upgrade to 17.0"
When googling this error message or even "winMIF" i can't find anything that match my request
I tried to uninstall the .NET framework and then reinstall the 4.0 (and 3.5) and I got the same issue. (Exactly the same error even if it's .NET 4.0 or 3.5 ...)
The computer used to build is a Win7Pro with Labview 16.
The target computer is a WES7 (but I got the same issue on my dev computer ...)
In advance thank you,
Ok anyone who can manage to contain their laughter for a minute, help me out with this.
I need exactly what's in the title. Due to the deprecation of TLS1.0 and SSL3, we're disabling both on our web server that receives status information from hundreds of systems across the country via HTTPS. Some of the systems run Windows 7, some Windows XP. All of them run applications built in LV 2012sp1.
In the past we've used the NI HTTP client VIs, which work well, and still work for some (?) Win7 systems. They don't work for the Windows XP systems. Are these VI's just a wrapper for the OS's HTTP client (IE)?
We've also been down the .net WebRequest path, but from what I can tell the webclient class doesn't support any security protocols past TLS1.0, at least not in .net 2.0, and the HTTPClient class wasn't introduced until .net 4.5, which LV doesn't support, at least not in 2012 sp1.
Lastly, we're considering the Encryption Compendium being offered in the JKI package manager, but it's 629 pounds, and if there's a way to do this without it, it would be preferred. Also we're not sure it would work with the given constraints. Has anyone used it/know anything about it?
Any help is appreciated.
How do you decode, unpack a flattened string in python which was sent by a LabVIEW TCP server?
I want to exchange data via loopback. Therefore I take a sine wave and flatten it to string and sent over the network Simple TCP - ServerSINE.viSimple TCP - ServerSINE.vi. Then I have to decode the incoming data in a way that I have the correct numerical values like when I plot them in LabVIEW. I did this so far in python_client.py but the values are wrong.
Does anyone know how to work with the transferred Data in python?
Could you please share your thoughts about problem shown below?
Thanks in advance.
LabVIEW 2013 f2, 32 bit
When trying to read a value of tag from third party OPC server which is not widespread software using NI DSC OPC client we got empty data.
The type of tag in OPC server is Array of U16 and OPC server continuously writes array of values into that tag. However, NI DSC OPC client (and Distributed Systems Manager as well) defines type of that tag as String, thus can not read value of that tag (I suppose that NI OPC client is trying to treat variant data which holds array of U16 as string and because of conversation error issues empty data).
At the same time Kepwareâ€™s OPC client defines type of that tag as a String as well, but can read the values of that tag which holds Array of U16 (I suppose that Kepwareâ€™s OPC client after getting error, while converting Array of U16 into String, starts to look in datatype defined into variant itself).
Can the descriptions above explain the problem and if yes then what can we do to read the value of tag with DSC? Is there any opportunity to get more deep access to NI DSC OPC client to make some changes in order to work with customer OPC Server?
I am using MySQL .NET Connector with my LV2013 application which has been working fine for months. Today the new exe started requiring the user to pick the location of the MySQL dlls. Ironically, the dialog opens to the directory with the dlls in it. Currently, the dlls are in the /data directory. I have tried moving them into the same directory as the exe. I did see this post, but it didn't help. I haven't tried putting the dlls into the GAC because it wasn't entirely clear where in the GAC they would go, and in principal, having the dlls in the same directory path as the exe should be enough.
It would appear this is something related to the OS because the exe works on the dev machine - just not the target.
Any suggestions would be greatly appreciated.