LabVIEW Idea Exchange

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. 

Many Real-Time Testing (RTT) systems require a mechanism to store data in one central location that can be accessed by the different parts of the application. The Buffered Variable Table (BVT) is a set of LabVIEW VIs that developers use to store and retrieve data asynchronously from different parts of an application.

Normally, when I program applications in RTT, I need store data in one central location that can be accessed by the different parts of the application, for this, I usually use "queue operations" with a fixed size.

But sometimes, I need to insert an element at the beginning of the queue, but if it is full, it is necessary to dequeue and queue again.

To solve this problem, I could use a code similar to the image, but the applications could become unstable.

For this reason, my proposal is that labview provides the function of "Lossy Enqueue Element At Opposite End".

Currently, while inserting node by default insert quick drop Ctrl + I, it inserts node without considering wire branching. Check the picture - first is target place, and second - where it is actually inserted. Using insert menu from right-click menu works fine, b/c it inserts function exactly to proper place.

It would be nice to update this quick drop, to have the same behaviour, as non-quick drop functionality.

Sincerely, kosist90

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.

Currently there are no officially supported frameworks for Unit Testing in LabVIEW for Linux.

A lack of a unit testing framework on LabVIEW for Linux reduces LabVIEW's usability in widely-recognized and industry standard software engineering practices.

A Unit Test Framework created by NI already exists, as well as a 3rd-party tool for free, VI Tester by JKI. However, neither of these are available for desktop Linux (or Macintosh).

NI LabVIEW Unit Test Framework Toolkit

http://sine.ni.com/nips/cds/view/p/lang/en/nid/209043

VI Tester - JKI

https://github.com/JKISoftware/JKI-VI-Tester/wiki 

Currently (LV 2016) performing a "cut" on a file in the project explorer will warn the user that the file will be deleted from the project. Performing a "paste" can often result in an "unable to paste the contents..." message. This leaves drag and drop as the only method to reorganize code in the project explorer, but this is very cumbersome if there are a large amount of files and scrolling is necessary.

This idea is to propose windows-like cut + paste, where the "cut" item has ghosted text, but is not deleted. Once pasted, it is moved to the new location. This should have the same end effect as the current drag and drop feature.

In "Case Structure", when we use "Linked Input Tunnel" and select one end of the tunnel, is it possible to highlight the opposite end? as is the case with "Shift Register".

We have crossed the wires on purpose, because it isn`t always possible to make a straight line. 

Originally suggested by RavensFan.

LabVIEW scripting makes it possible to automate repetitive tasks in LabVIEW, but it is often difficult to find the properties and invoke nodes to accomplish the task. It would be great to have a recording feature that watches what you do in LabVIEW, and then generates the corresponding code for it. I'm sure the engineers at NI could design it much better than any more specific ideas I could throw out, so I will leave the rest up to them. 

I just ran into a situation today where I had a case structure with approximately 64 frames in it, 48 of which I wanted to remove.

The method of right-click the selector, select "Remove Case" (This step is right beside the "Insert Case" which is frustrating), repeat 48 times while the mouse is wandering all over the screen between the case selector and the menu selection..... cue carpal tunnel problems.

I really wished I could just either use the "delete" and "insert" buttons to mimic the appropriate menu selections

-OR-

Be able to select multiple cases from the "Rearrange cases" window and select "Delete".

When you want to look for a specific VI in your project using Ctrl+F you have an handy option to search vi by name. But this is quiet difficult to find the VI you are looking for in this windows : All VIs are listed (without structure) and there is no Filter. Something similar to Event selection window would be much better (That would have a filter and where VI's would be grouped by libraries and class)

This "Find all instance" could also be added directly in the project explorer, in the Right click -> "Find" menu

So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1.  This means the function will wait forever until an event comes in.  But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.

This idea is to have similar functionality when it comes to user events.  I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it.  If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running.  In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.

What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.

before:

after:

Citation from LV help: "LabVIEW categorizes user interface events into two different types of events: notify and filter.".
But, User Events could be registered just as notify events.
Idea is to implement to LabVIEW possibility to handle User Event as Notify event (as it is done now), and as Filter event.
Usecase: Actor Core is used as user interface, and multiply instances are displayed in multiply subpanels. They receive Name + Data payload by same user event, and need to process just their payload (if actor's name == payload's name). If they receive payload without their name, they drop event, do not process data. Currently one could solve it with case structure or something like this, but while having Filter User Event, it would be possible just to filter out event, and drop it.

Good day forum

Proposal: to have a option to check for properties that can behaviourally change during deployment.

Case: recently built a VI that is called from TestStand and encountered error during execution in the end-user PC (installed with TS and LV RTEs) and found this property that can behave differently in RTE environment. Retested in LabVIEW through application build but received no incompatibility or possible error notifications. Installer builds (with automatically select recommended installers checked) also did not indicate the necessity of having the Development System environment.

A optional check on this type of property could be nice.

Thank you

LabVIEW functions "Set Waveform Attribute" and "Get Waveform Attribute" could write/read any attribute name/value to waveform. But, according to help files (http://zone.ni.com/reference/en-XX/help/371361N-01/lvwave/set_waveform_attribute/), there are default attributes such as device number, channel name, etc., which could be set by NI-DAQ, and Express VIs. But sometimes there is need to set them manually (for example, while reading data from FPGA and building waveform from it).
It would be handy to include to Waveform pallete simple API with polymorphic VI to set and get those default attributes. Then one should not remember what exact name it has, but just take the function, select which attribute he needs, and use it.

Sincerely, kosist90.

The VISA test panel is a very valuable tool for troubleshooting instrument connectivity issues.

This used to be included with the VISA runtime, or at least with any installer that also included the VISA runtime.

Now I have to separately download and install the FULL VISA just to get this valuable tool. 

That makes installing a LabVIEW executable a multistep process as now I have to run two different installers. 

NI-MAX and the VISA test panel should ALWAYS BE included in any installer that includes the VISA runtime.

I've got some calls to low level VIs that rely on windows system dlls within a larger top level VI. To make that application work on Windows and Linux, I've put conditional disable structures around the dll calls. When I open the top level VI in Linux, I have to click through a bunch of "Find missing file" dialogs for the Windows system dlls. If I cancel through all the dialogs, the VI still compiles and runs correctly in Linux, so the Conditional Disable structures are doing most of what they should, but the dialogs are annoying and can cause problems with automated builds and other hands-off activities. Since the code is inside a conditional disable structure, it seems to me that LabVIEW has all the information in needs to know it shouldn't load that stuff, so it would be great to get rid of these nuisance dialogs.

Instead of right click on the Array to Cluster for Cluster Size, double click will be ease for the programmer to select the size of cluster

Double click should enable this pop up.

64bit has been the dominant architecture for a decade; any computer with more than ~2.5GB of RAM must use it after all. It is inevitable that 32-bit machines will cease to be made - maybe not tomorrow, but let's be realistic. Let's get ahead of the times and convert modules to support 64 bit. Please!