LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

LabVIEW needs native SSL/TLS support for the TCP primitives. The HTTP functions support it (see \vi.lib\httpClient\ConfigSSL.vi). There are several great LabVIEW native MQTT libraries that could be commercially usable if there was native SSL/TLS support. Not having this functionality for the TCP primitives makes LabVIEW a poor choice for an IoT platform.

In the current LabVIEW XML Schema, the flatten to XML string supports variants, but not variant attributes (and by extension waveform attributes as well). This is unfortunate as variant attributes remain one of the best ways of implementing a dictionary type data structure and they are also a useful way of adding additional metadata to waveform signals. In both cases, serializing the attributes to XML strings properly would greatly facilitate data exchange with non LabVIEW code.

We were thrilled to see that NI developed an OPC UA API. We develop software for both VxWorks and Windows, so having OPC UA available on RT is great. But having to shell out for the entire DSC suite, run-time licenses and all, just to be able to use the same API on Windows is unreasonably costly and forces us to use a different API on Windows. If we could buy the API as an isolated component at a more reasonable price (and with easier licensing) we would jump for it immediately.

 

A generalized version of the idea:

The DSC can still function as a nice bundle, where the price for the bundle is lower than the total for each individual item, but when NI makes such packages please make it possible to pick-and choose amongst those components as well, so that in cases where you actually have a need for just one of them, you can get it at a price that is reasonable for that individual component.

Most email server need authentication not only for POP3 to retrieve emails but also for SMTP.

 

This issue is coming up for a lot of years from time to time. In deed the SMTP Email library built into LV is unusable today.

 

Everyone is complaining about spam which often is send using open email servers without authentication so you have not the chance to find the real sender of unwanted emails. Since most of use are not this kind of senders we have regular account needing to authenticate.

'Database Variant To Data' cannot be placed in an inline enabled VI making it impossible to use in malleable VIs. 

It would be nice to be able to draw on the power of the 'Database Variant To Data' VI in malleable VIs so we could be more flexible when writing database related code.

 

Please make this possible or offer a workaround (like the polymorphic instances of the VI).