Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
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.
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 (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.
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
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.
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.
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.
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.
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.
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!
One of the fiddly things I seem to do more than I'd like is adjust the bottom of block diagram comments to the right height. At a minimum there, but also for similar text boxes on the front panel or subdiagram labels, etc. I'd like to have a snap feature that sizes to a multiple of the text height. Examples: