LabVIEW Idea Exchange

I can search for objects from the Find dialog, but I would also like to initiate the same search by right-clicking on a function in my block diagram.

 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!

 

It would be very handy to be able to probe a queue refnum wire and get generic information about it besides just the refnum number. It would be nice to see the same information that is returned from the Get Queue Status function:

 

•  Max Queue Size
• Queue Name
• # Pending Remove
• # Elements in Queue

The probe could also show the Queue Refnum. If possible, it might be nice to have a boolean control on the probe front panel to select whether to show the elements in the queue as variants, but it would still be helpful enough just to probe the number of elements in the queue.

 

To do this now, you have to manually create this probe for every different queue type, since they're all technically different data types.

Quick Drop (Ctrl+Space) is often used to work with a selected VI (e.g. Ctrl+P replacement). The Quick Drop dialog window opens with blank text box. Default that text box to the VI name if one is selected when Quick Drop is opened. That text should be pre-selected so that typing replaces it (no extra keystrokes for backward compatibility). Furthermore, it would be extra nice if the selected VI was automatically highlighted in the list.

In LabVIEW, data types generally propagate downstream. If you wire a cluster output into an "unbundle" node then the IDE lends a hand by resizing the unbundle node automatically. Nice.

 

I would like to see the same behaviour applied to the "bundle" node. In this case the type information needs to travel upstream. Yes, backwards!

 

Excuse the overly simplistic example... Yes, I know we could just connect the bundle node's middle terminal in this case, but it illustrates the concept.

 

A more realistic use case would be nested clusters or nested private data in a class. In this case propagating the type upstream could be quite handy when bundling various sub-clusters:

 

Note: There are not many situations where the IDE will allow a data type to propagate upstream, but there is already some precedent for this: In certain situations the "Variant to Data" function will automatically assume the type of the wire connected to its output.

Under Distribute Objects, we have the options for setting the gap between selected objects to 0, or to evenly distribute the selected objects, but wouldn't it be nice to be able to select a few FP objects and specify the gap between them in pixels?

 

 

So let's say we want a gap of 6px between some of our objects, we should be able to just select them and type in the gap value in pixels, similar to the behavior of the Resize Objects dialog, where you can type in a value for height and width.

 

This could also be extended to setting the gap between the objects and the FP window edge.

 

Haven't had a chance to play with the latest LV version yet, so I'm not sure if this has already been addressed in some form.

 

 

I have a suggestion for a new LabVIEW open dialog that allows a preview of the VI/control/etc.  Similar to many CAD packages that let you see the drawing or block before actually committing to the open, this dialog would allow a view of the connector pane and any available info similar (if not exact) to the help window before placing it on a diagram or opening it directly.  This would be helpful when looking through various libraries that have a less-than-descriptive name or similar names with different input/outputs.  I have mocked it up with the attachment below.

 

Since LabVIEW 2017, it's possible to build application with a compatibility with future version of run time engine.

This option is set by default but can be disabled.

 

I just discover that this option is set for real time applicaiton and cannot be unset. I mean that if you build your application in with labview real time 2017, it will run with a system installed with a newer version of LabVIEW Real time.

 

This can be a good idea, but I'm a little bit surprise that I cannot have informations on that options for real time application and I can't control it.

 

Here is a way to test it. Tested on a real time desktop with pharlaps.

Install RT target with LV 2017.

Build an application and set it to run as startup. A simple application writting something in the console is enough.

Make sure your applicaiton is running at startup.

Update your system by only installing LabVIEW real time 2019.

Restart your system and your application is still running !

 

Because I faced an issue where LabVIEW 2020 broke my application build in LabVIEW 2017, I'm asking myself how NI can garanty that a real time system will work in any case if we upgrade the system to a higher version of LabVIEW real time version without recompiling the application.

 

Real time system can be used to control system that can be a secure system. If a user update by error a system, I want to keep my system safe for user.

 

So my idea is to remove this option or give access to the user to unselect this option to avoid any bad behavior.

 

best regards

When I installed LabView I realized that a really large number of automatically starting programs is being installed. Even when running LabView not all of them are really needed. But they are still actively working in the PCV's memory ant take the power that would be needed for other applications. Basically when LabView is not running at all. A possibility should be implemented to deactivate these automatic applicatins: -Reduce the number of Autostart-applications to these that are really needed -Give the possibility to switch them all off when there is no intention to run LabView. A reboot for re-activating these autostart applications would not be that problem. -A minimum request is to give a list of Autostart applications that are needed for each LabView-Application. This would help to deactivate the autostart-programs manually.