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!
Add a new button to the search results dialog called "Set Aside" so I can have multiple search results open at the same time. Put it near the bottom just below the search results. When you click it, it changes the title of the window to "Search Results - Set Aside 1". If you click "Set Aside" again when #1 is open, it will open "Search Results - Set Aside 2" ... and so on. This way you can have several different search results open simultaneously. I love the check mark feature in the search results, but it resets every time the search windows is closed or overwritten by a new search. Thus I lose my place if I want to make sure to check every instance of something but need to search again while looking at one item.
When working with serial, tcp or some other odd communication protocol I find myself time and again working on a PC that either has nothing installed, can't install anything or is sitting behind a secured environment. Nor is there always a scope with analyzer readily available to trace the commands being sent & received to an instrument or DUT.
Can't parts of Wireshark or an another sniffer be built right into the Probe Watch functionality? That would be sweet.
P.S. VISA's "Interface Information:Interface Type" has a lot of variations that many devs likely don't even know about as they just drag a VISA onto the BD/FP.
Add an additional search scope in the scope dialog. New scope will be <entire project>. Right now the widest search scope <All VI's in Application Instance> will not reach VI's that are called by reference, but still in the project. I have a few co-workers which are "call by reference" happy and it's a pain to track them down manually.
I am not happy when I inherit legacy code where VIs have inconsistent alignment grid options, as shown in the image below.
My team has coding standards we follow, and those standards include alignment grid options. It is labor-intensive to change alignment grid options on legacy VIs because you have to do it by hand, and clicks quickly add up. I wish I could automate such changes.
I’d like to see a few new properties to expose settings available in the editor, as shown below.
These properties need to support both read and write.
I came upon a need for this capability when I had a rather large project for which I had spent considerable time organizing with virtual folders. I then needed to add a .net container and .net dll, but it appears that can only be done if the lvproj file was created after the .net dll's were installed. The only solution seemed to be to create a new project after installing the .net dll's, then adding my main vi and reorganizing the whole thing. Cumbersome and time consuming! It seems to me that since the lvproj file just contains shortcuts to files on disk, it should be possible to add a project within another project. This apparently is not the case now and there may be some problem introduced by the .net structure that I'm not aware of. Obviously, loading a project within a project could be fraught with potential conflicts but would really be useful in the scenario I describe.
Wouldn't it be great if you could list only the recent files opened while in a particular project? I often bounce from one project to another, closing the projects in between. Thus, I often would like to be able to view only the file recently opened from within a
the project I am working on. Adding a "Recent Files (by project)" to the Getting Started window would be valuable as well.
in recent months I've been working on a huge pile of code that was written by someone else. This left me to do searches for places where TypeDef member values are written to the TypeDef'ed cluster, where Enum constants have a special value etc. It is a real pain in the butt being able only to either search for a text or a specific kind of Labview object. If there was a way to combine these two parameters, things would be much easier: Instead of browsing through hundreds of results of a text search where 99,8% are "Unbundle by Name", but I search for the "Bundle by Name" object to determine, where that darned value is put into the TypeDef I can simply define the search text, choose "Bundle by Name" as Labview object and receive the result list containing three entries.
The Event Messenger Channel, "formally" introduced in LabVIEW 2017 but available as a "Beta" in LabVIEW 2016, provides a useful (if probably under-used) way to provide Channel "Feedback/Input" into a LabVIEW Event Structure. However, there are some "missing Name pieces" that are inconsistent with the naming of "ordinary" User Events (and an interesting internal inconsistency with those Ordinary User Events that I didn't discover until wrestling with these issues involving the Event Messenger Channel).
This Snippet shows two User Events:
A Boolean Control called "Yes" generating an Event Messenger Writer/Reader pair to get the Event Registration Reference for which I created a Constant and gave the Constant the label "OK".
A Boolean Control called "Go" for which a User Event and Registration Reference for which I created a Constant and gave the Constant the label "Stop".
The two RefNums are put into a Cluster to allow the two Refnums to be bundled by name and wired to the Event Loop's Dynamic Event Terminal. Note that the Cluster Names take the names "OK" and "Stop" given to the Refnum Constants used to created the Named Cluster. [It's much less "interesting" if you use a simple "Bundle" and partially lose the ability to Name That Event].
Event Messenger User Event
When you go to choose the Event for the Event Case, you get the following Event Sources:
Note that the Event Messenger User Event, named OK, with a variable named Go, has no "identifier" in the list of Event Sources, only <channel value>. Indeed, if there were several Event Messenger Channel Wires bundled together, all given different names, they would all appear in this "Selection" Screen with identical names, but referring (unbeknownst to the Developer) to different Channels. Note that in the Event Structure, itself, this Event is listed as <OK.channel value>, so it is at least (in the Event Structure) picking up the name the User gave to the Event Reference.
The other User Event Case (for a "normal" User Event), uses both the name used to create the User event (here "Go") and the name used for the Event Registration Refnum (here "Stop"), creating an Event Source named "Go" (the User Event name) and an Event Structure label of <Stop.Go>. I'd "discovered" (don't remember how I learned this) the trick of putting a Label on a Constant used to Create User Event to "Label" the User Event in the Event Structure, and learned the trick of creating labeled Event Registration Constants and bundling by Name to (partly) create named Event Messenger Cases from the Event Messenger Example files (thanks, AQ or whoever developed these Examples).
Stop/Go Event Case
I'd like to suggest that, at a minimum, <channel value> be replaced with the label, if present, of the variable used to create the Channel Writer. The quirk whereby an "ordinary" User Event can get two names (as in Stop.Go), one from the Create User Event, the other from generating the Registration Refnum, probably shouldn't be touched lest other code breaks, but it is amusing ...
Sometimes you want to have a set of VI with the same properties of reentrancy, for this, we can consider the option of having a virtual folder with the option of reentracy desired, as it happens with the option of access scope.
I propose to have the option to define a virtual folder with a properties of reentracy and that VIs are contained in it, change its property. In this way, I think it is easier to know the properties of the VIs reentrancy.
The data reduction algorithm used by Citadel for logging values inherently assumes that only the absolute magnitude of the change is relevant; that means that a single value for the resolution and the deadband is sufficient for the whole value range to be monitored.
There are situations, though, where the underlying value could span several orders of magnitude. In such cases, it would be useful to set deadbands on the minimal relative change, instead.
The current workarounds are either to reduce the deadband to a tiny value (thus logging much more large data than needed) or to log the logarithm of the value, but that involves an additional step in writing to the SV/reading histories. It would be nice to have a built in option for that.
When you navigate through Labview code and go deeper in VIs hierarchy you end up with dozens windows open on your monitor. Lets create special action for opening subVI (like existent Ctrl+RightDoubleClick) which will close FronPanel BlockDiagram of VI from which you open new one ?
If creating a reference to a .Net control you will observe that is reference type of ActiveXContainer is created which is sometimes confusing at a first sight.
Please introduce a .NetContainer (at least cosmetically at block diagram) for a better overview. If you are doing so, you could change as well the color of the ActiveX container with respect to the .Net container on the block diagram. If you have to change the programming interface, it would be much easier to spot where you have to do so.
I search the idea forum and I see many Labview Upgrade suggestions as "DECLINED".
I know there are others out there like me, I HATE upgrading Labview. All the time required to update your custom configuration takes weeks. Heck, Labview upgrade isn't even smart enough to know all the software you're entitled to install...instead you have to force Labview to download and install your paid software individually.
Here's the deal, most of us don't have the time to upgrade because of all the maintenance we do to support our software. For instance, I have a paid Maintenance Agreement (as I do every year), I have been working in LV2015 and now it's time for me to upgrade my computer and I'm installing LV2018.
My wish, Have National instruments create a tool that would allow you to export all your custom settings, device drivers, and software requirements, etc..., so you could import these settings into a new version of LV. Making the upgrade process easier with a single tool.
Since it's so difficult to upgrade, I often wait 3 years or more before I try to upgrade. If it was more seamless to upgrade, I'd probably upgrade every release!
Anyway, we are all so busy we don't have the time to search these forums, so this request will be DECLINED too.
Perhaps NI should accumulate all of these requests to Upgrade and total them as one. Each individual request dies in a year because so many people are sticking with what works...often older versions of LV.
Sure, NI has a few upgrade tools, but, nothing that leaves you upgraded to the latest version of Labview without missing a step.
The Help window doesn't remember the window state when reopening it. If it was previously maximised it reopens it in the normal state with the size of the maximised window. Changing to maximised should also not overwrite the stored normal state size and posistion.
I frequently open the help window and this becomes annoying: