LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

It would be nice if the LabVIEW primitives for TCP allowed for the creation of a socket without actually connecting it to an endpoint. My thoughts are that there would be two new commands added to the TCP palette:

TCP Create Connection (Advanced)

TCP Open Connection (Advanced)

TCP Create Connection (Advanced) would create the socket but not perform the connect() method on that socket. I would imagine that it would otherwise look and feel quite like the current TCP Open Connection, except that the user would need to manually run TCP Open Connection (Advanced) afterwards that would perform the connect() method on that socket.

I have a need to access the raw socket object before it is connected, using the TCP Get Raw Net Object.vi in the vi.lib\Utility\tcp.llb library. This VI works to get the handle that can be used by winsock and other Windows DLLs, however, it only allows for setting properties for a socket that is already connected.

Specifically I have a need to enable Windows FastPath for TCP to optimize the rate at which I can stream data between two applications. Per the specification, this option must be enabled BEFORE the socket is connected. Right now I can set this for the listener on the server side (TCP Create Listener creates a socket but does not connect), but I cannot set it for the TCP connection on the client side as the first method it calls is TCP Open Connection which returns a socket that is already connected.

View All (6)

Remote Access to LabVIEW using HTML5

HTML5 supports WebSockets which allows low-latency, two-way communication between browser and server. There are various screen-sharing technologies in existence based on this, but integrating a similar server in LabVIEW would enable capabilities that could be accessed from any desktop or mobile browser, no configuration required on the client side. The key to this feature is the ability to configure the server and enable sharing from within LabVIEW or from a VI (i.e. a LabVIEW-aware server).

An idea of what this could do:

Remote control of LabVIEW development machine

Selective sharing of windows, for instance allowing interaction with only LabVIEW windows. The server application would have a mechanism for selecting which of the open windows to share.

A view-only mode so users could check the status of a running application from anywhere, including their cell phone.

A brat or Express VI that when dropped in a VI would automatically share the VI when run.
Third-party toolkits and applications could build in sharing capability for their own app using the API.

This feature would be more powerful than Remote Panels in that:

It would give access to the LabVIEW development environment in addition to running applications.
No configuration or special software required on the client side, enabling multiple platforms including mobile.

Bluetooth Low Energy (BLE) support

View All (1)

The current implementation of flattening and unflattening from XML is quite noisy and includes information unnecessary for the users. Rewriting it or including Pretty Print functionality to LabVIEW would greatly simplify loading settings, exchange of data with other languages, dynamic configurations, visualizations of complex systems, network communication etc.

For community solution and examples of these features please go to -> https://forums.ni.com/t5/LabVIEW-APIs-Discussions/Tree-Map/td-p/3972244

This could include also Pretty JSON since XML and JSON are interchangeable -> http://www.utilities-online.info/xmltojson/#.Xc6XjVdKiUk

Additionally the XML parsing should be implemented without requiring Windows .NET platform components, so it can be done on a real-time system. Current XML parsing functions cannot be called on RT.

View All (7)

Traditionally LabVIEW has treated Strings and Unsigned Byte Arrays as being the same. This is nowadays a little unfortunate as all UI systems use some kind of encoding so Strings are not generally interchangeable with Byte Arrays anymore.

In trying to stay for binary data as much as possible with Byte Arrays instead of Strings, since that would be the sensible thing to do, the Unflatten from String (which should rather be called Unflatten from Stream) puts a totally unnecessary wrench into this.

I always had hoped that LabVIEW would change the default binary data stream format to a Byte Array at some point but this while it would be possible, is a fairly pervasive change that would require many backwards compatibility decisions that I unfortunately don't see NI going to spend time on anymore. This change however would be a very small change that has zero backwards compatibility concerns and almost no work to add to the existing LabVIEW software.

This same change has been for instance made to the TCP Write node some versions back already and could be also applied to the VISA Write!

To support modern web thin clients, the LabVIEW webservice needs to support the OPTIONS request. When a web browser makes a cross origin request there are a few rules that the response must comply with before the browser will provide with the result to the web application. The OPTIONS request is needed to respond to these requests.

A cross origin request is any request where an application running on one domain needs to make a request to another domain. For example, if there was a javascript application running on the domain www.labview.com and it needed to make a AJAX request to api.labview.com, the browser considers this a cross origin request. This is a common setup when the thin client is being hosted by one server, and the webservice is being hosted by another server. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Depending on the request, the browser may issue a "preflight" request. "Standard" requests are GET and POST requests without custom header fields only require the response has an additional headers. Other requests (PUT, DELETE, GET w/ headers, POST w/ headers) require a preflight request. A preflight request is an OPTIONS request. If the OPTIONS request doesn't get an appropriate response, the browser will not even make the actual request. https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request

For example, I'm starting an application and here's how I'd like it setup.

1. Windows PC. This is the central server for the application. There will be a normal LabVIEW application running on this computer. There will also be a web service run on this computer. The web service will mainly host a web application written using HTML/CSS/Javascript (although it could be written using HTML vis from NXG).

2. A bunch of CRIOs. These CRIOs will also host their own web service to get system information, measurements, and diagnostics. As new CRIOs are commissioned, they'll report to the Windows PC.

Now a user uses their web browser to access to the windows PC. The Javascript Application (which is hosted on the Windows web service) provides the user with a list of all commissioned CRIOs. They then click on one and the javascript application starts to make requests directly to the CRIO's web service. Since these CRIO's are on a separate IP address, the browser flags this as a CORS request. This means that an OPTIONS request can be sent. Since I can't handle an OPTIONS request in a LabVIEW web service, I can't implement this.

This is just one example. Another case would be an Apache hosted web application hosted on an Amazon EC2 needs to make requests to a LabVIEW web service running in a different domain. Basically any time a web application (AKA something running in the browser) needs to communicate with a LabVIEW web service you'll run into this problem.

Extend the native LabVIEW queues to support network based queues. We have network streams which are very nice but they are point to point. Queues are extremely useful since they allow a many to one relationship. It would be nice if LabVIEW supported network queues. I have worked with a third party implementation which works reasonably well. However it would be nice if this was native functionality. Network queues are essential if you desire communication between different applications or for sending data from a TestStand environment to a LabVIEW front end GUI. They are quite powerful and would make it much easier for users to implement multi computer applications.

NOTE: I need to post an updated version of the Network Queue class. I have improved and extended this implementation.)

View All (1)

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.

View All (3)

The current implementation for remote debugging needs two ports to be opened on a stand-alone firewall in between.

Port 3580 to connect to the NI service locator on the target machine
A random port for the application on the target to connect to
This port is dynamically assigned to the application by asking the OS for a free one

This dynamic port cannot be pre-configured on the stand-alone firewall except by opening up the whole port rang above 1024.

The latter is something no IT person with any sense of security will do !

So we need to be able to pre-configure a certain port for the target application, so that we can open a dedicated port for this connection on the firewall as well.

Otherwise this whole remote debugging feature is useless to many companies.

There have been multiple cases in the last few years where customers (huge ones) have come across this issue.

View All (1)

Hello,

the current functionality doesnt allow to asynchronously call a method that has any dynamically dispatched inputs. This causes a need to create a statically dispatched wrapper around the dynamic method which then can be called.

This is a source of frustration for me because it forces you to have code that is less readable, and this doesn't seem to be any reason for having functionality like that. Since you allready need to have a class loaded in the memory to provide it as an input for the asynchronously called VI why not just allow to use dynamic dispatch there (the dynamic method is allready in the memory).

How it is right now:

Solution: Allow to make asynchronous calls on methods with dynamic dispatch inputs.

Selecting the browse button of a path control of a VI under a real-time target brings up the file system of the host computer. This is completely useless and misleading. If you select any file or directory with this, it won't work when you run the VI.

I propose changing the behavior that selecting browse (on a path control) of a VI under a real-time target to show the file system of the remote target. I've seen X controls to do this before. In fact, Drivven has one. If not, I would at least remove the browse button.

View All (2)

Most people know that Network Published Shared variables are pretty slow. If you write to a SV and then immediately read from it, you probably will not see the new updated value. One way to get around this is to write the value and then continuously read and compare the SV until the value is updated:

Pretty straightforward to do, but takes time to set up, as well as some Block Diagram real estate.

I think it would be pretty convenient (and easy for NI to implement) if there was an option for a SV to wait until updated.

It could either be an option from the right click menu, (that of course would update the icon to signify that it's now a blocking call) or use an input to the variable, or maybe a combination of both:

The current VISA read and write primatives do not have the ability to abort early. Under many circumstances if the timeout values are short this is not an issue but it can be an issue if a long timeout is required. The current work around is to use a short timeout value and loop continually ignoring the individual timeouts until a threshold has passed and then pass the timeout error out. This apporach requires the extra code to "monitor" the process of the communication. It also requires shift registers and associated logic to maintain the data. It would be desireable to simply set the timeout for the desired value and have a separate VISA property that can be set cause the current operation to abort.

View All (9)

LabVIEW Idea Exchange

Allow creation of TCP sockets without actually connecting them

Remote Access to LabVIEW using HTML5

Bluetooth Low Energy (BLE) support

TCP/IP, UDP/IP Get connection information function

Include Pretty XML parsing for map/set/tree data structure

Allow Unflatten from String to also accept an Unsigned Byte Array as input

Add support for OPTIONS request to LabVIEW webservice

Extend native queues to support network queues

Allow user to select the which NIC to use for network connections when multiple NICs are present

Implement More than 14 User Ideas in the Next Version of Labview

Provide email authentication for the SMTP Email library

Protocol Buffers (ProtoBuf) structured data serialization for use in communications protocols

Allow to configure a fixed port for remote debugging a specific application

Allow Dynamically Dispatched Methods to be called Asynchronously

Path control of VI under real-time target should browse target's files

Access to sockets other than TCP/UDP

Shared Variables: Wait until updated for write

Add an "Abort" event to VISA reads and writes

Better HTTP Authentication Support - Starting with NTLM

Creating Dashboards for Data Dashboard app on the PC