LabVIEW Idea Exchange

 Connecting to remote panels using LabVIEW is difficult if private networks, local private and external public IPs (under NAT), and firewalls, etc. are involved. It requires significant knowledge as well as external networking configurations (port forwarding, etc.), and possibly admin privileges to modify those.

There are plenty of companies that have found a way around all this. The prime example is chrome remote desktop, which seamlessly works even if target computers are in hidden locations on private networks, as long as each machine can access the internet with an outgoing UDP connection. The way I understand it, each computer registers with the Google server, which in turn patches the two outgoing connections together in a way that both will communicate directly afterwards. All traffic tunnels inside the plain Google chat protocol (udp based). Similar mechanisms have been developed for security systems (example) and many more.

Since the bulk of the traffic is directly between the endpoints, the traffic load on the external connection management server is very minimal. It simply keeps an updated list of active nodes and handles the patching if requested.

I envision a very similar mechanism where LabVIEW users can associate all their applications and distributed computers with a given user ID (e.g. ni profile), and, at all times be able to get a list of all currently running remote systems published under that user ID. If we want to connect to one of them, the connection server would patch things together without the need of any networking configuration. Optionally, users could publish any given panel under a public key, that can be distributed to allow public connections by any other LabVIEW user.

This is a very general idea. Details of the best implementation would need to be worked out. Thanks for voting!

If you are using TCP to communicate to a different code environment, you may want to set some of the socket options. For example, for responsive control, you will want to disable Nagle's algorithm. There is currently no obvious or easy way to do this. TCP Get Raw Net Object.vi in <vi.lib>\utility\tcp.llb will provide the raw socket ID, but you then need to call setsockopt() on your particular platform using the call library node. You can do this with the code provide here. A much better way would be adding a property node to the TCP reference that allowed you to set and query the options directly.

It would be nice if we had the option to terminate a TCP Read on a single character rather than only a CR/LF. There are many times where you would terminate a read on some end character such as a 0x03 (ETX). In order to accomplish this now we need to have a tight loop which reads from the connection a single byte at a time. Even better would be if we could specify a string as the termination sequence. However, I would be happy with a single character option.

When you are generating data from a source and sending it across a TCP connection, it would be useful to be able to get information about when packets are being dropped and resent in the connection. If lots of drops are being detected, a program might be able to slow down the data acquisition or take other action to reduce the amount of information being transmitted to account for the lower bandwidth connection. Currently there is no way to get this information from the TCP primitives.

This idea comes out of the Certified LabVIEW Architect Summit held yesterday and today at NI headquarters in Austin, TX.

Currently the only way to set/modify Tcp socket options is by directly calling some system library, as done for example in this post.

This not only causes code difficult to understand ("what does that library call do again?") but also poses problems when you want to use your code on different operating systems: Currently the only way to do this is using "conditional disable structures", and then Labview still tries to load the code used for a different operating system...

Labview should have a standard way to set socket options within Labview code, at least for the most important options (Nagle algorithm leaps to mind...). This could either be done as additional inputs to the "Tcp open connection"-VI, or (much better) using property nodes for Tcp connections.

So one can set many of the standard properties for VISA connections.  However the serial port latency setting is not one of these.  It can easily be set by a standard POSIX ioctl call for both linux and MacOS (who the heck knows how Windows does it).  Many character based devices can be manipulated through these ioctl calls.

To be specific, the FTDI USB-Serial port driver chips used in MANY devices as a USB interface or just as a serial port have a slow default latency that is fine for preserving CPU cycles but not great for modern high speed custom communication.

1. Just add a a property that sets the serial port latency using an ioctl IOSSDATALAT property configuration.

2. More generally allow an interface that will call ioctl with a supplied property and the LV programmer can pass the correct property configuration.

3. Less satisfying but possibly easier to implement is to have the VISA property be the file descriptor number.  This simplifies the programming where one has to now get the "Name" property and then search the process information table for that "Name" (or really path) and then extract the file descriptor.  Only then can one set the latency for that device.