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!
I think there should be a way to reinitialize a stacked shift register to the originally initialized value so you can clear out the contents of every iteration all at once. For example, the code below, implemented with 4 individual shift registers:
Could be implemented with 1 stacked shift register with a reinitialize terminal:
I would like the maximize button removed from the FP & especially the BD. I typically work with many VIs open at once and I find it very annoying to open a subVI that consumes my entire desktop with a lot of white space. This is true of the FP and the BD.
Lets be real - your code is not that important. The one except might be the main GUI.
At least numeric controls and string controls loose focus after pressing enter. This is especially unpractically when navigating by key. The focus should be held on all controls as it is on boolean controls.
Classes in LabVIEW are a great step over (and finally, with LV 2009 them start to work...) but there are still two 'holes'
It would be great to have the possibility to define abstract methods and interfaces. Now I'm forcing an error into the error out indicator to notify the usage of a method not yet defined but it would be better to make the compiler to recognize the usage of abstract methods during the design time. One way to define abstract methods could be the introduction of a new entry in the 'class menu' and allowing to define them just in term of front panel (block diagram not available).
An object is duplicated on each node, so is not easy to work into parralel loops on the same instance. To use the same instance I have used references, but it is not so easy to use (not as the 'normal' wires) and it hasn't the same performance (working with reference is heavier than working with instances). It would be great to introduce a mechanism that implements the convertion from instance to object, something likes a standard 'getReference' and 'getInstance'.
Append True/False String is a function in LV, and it allows you to append one of the two input strings to the initial string based on a boolean input. I use it to append pass/fail to the initial string.
I think this function should also allow us to select a couple of standard true/false string without needing a true/false string input. I should be able to right click on the node and select pass/fail, true/false, yes/no, go/no go, etc. By doing this, we can make our code even cleaner. When you select these standard true/false string, the appearance of the icon should also change in order to reflect what standard true/false input is selected.
The Block Diagram should look more like a schematic capture tool. It should have the ability to zoom in and out and pan. Users should be able to draw their own Vis like ICs in a schematic capture program. Parts and wires should be drawn on a grid.
Sometimes, a cluster constant is used in LV. Due to the size of the constant, a lot of time, it is sized down, so that only part of the constant is shown. What if you want to see all the values in the cluster? You have to size it up.
At the moment, if we do ctrl+h and hoover over the constant, we will get some information about the constant, but not the values are in the constants. It will be nice if the values are shown in the help window as well.
My apologies if this has already been suggested ... I've written many VIs with a While loop that has True wired to the Stop terminal, making it a "Do Once" loop. This is such a common construct (i.e. a VIG) that it might merit its own "structure", something that "looks like" a While loop but has no Stop terminal, no "i" indicator, and is guaranteed to "Run Once". I think having a unique "look" for this common special use of the While loop would be a useful addition. Among other things, it would clearly distinguish "purpose" as different than a While construct.
We need the ability to manage multiple volume licenses from a single VLM instance. We have several groups from different cost centers that use LV; however, currently all the license administration falls on me. The only solutions available at this time are:
Merge all the licensing needs from each group into a single license. This is a nightmare for me. For one, our internal accounting system isn't set up to easily transfer funds between cost centers, so getting the money to pay for the license has been difficult and usually leads to payment delays. Second, it's very difficult to respond to changing license requirements of an individual group when everything is lumped into a single license file. If a single group wants to discontinue their subscription, rather than just letting the subscription expire (which would cancel the subscription for all groups) they have to pay a fee to "break out" their licenses from the volume license. If a group wants to add products to their license, all requests get funnelled through me. This might be good for NI, but it's a royal PITA for me. (License administration is something I do in my "spare" time.) Third, it's inconvenient having to track how many licenses of each type each group has purchased and cross check that against how many licenses they are using.
Maintain separate computers for each VLA. From an ease-of-use perspective this is almost as bad as option 1. From a practical perspective this is worse than option 1. It's silly to have several different computers sitting around doing nothing other than running a license server. Furthermore, it's harder to loan an available license from one group to another group (which does sometimes happen) as the user has to redirect to a new license server.
Neither of these solutions work very well. I don't mind the license administration part of the job. Creating installers, changing permissions, and stuff like that doesn't really take that much time. What is killing me is the account administration part of the job. The single license model forces me to be an account administrator for several independent groups, and the corporate culture and infrastructure here don't support that model very well at all. What I would like to be able to do is have each group be responsible for purchasing and maintaining their own volume license agreements. When they get the license file they can send it to me and I'll install it in the VLM.
I envision each VLA having it's own root node in the tree diagram. Instead of a single "Volume Licenses" node, there would be one for "Group A Licenses," another for "Group B Licenses," etc. (I have to be able to rename or annotate the root node for each VLA.) The Users and Computers nodes still contain the users and computers from all the groups, but maybe those nodes have virtual directories I can use to organize them.
One minor annoyance with building pop-up subVIs is gracefully terminating the UI execution loop if the user closes the panel using the standard MS Windows "X" close button (upper right-hand corner of all standard Windows panels.)
Of course there are at least a couple of work-arounds -- disabling the Windows functionality completely, or polling to see if the panel is still open using a property node (and programmatically exiting the loop if it isn't). But I was thinking it would be nice if there was an option in the pop-up menu that forces a loop to terminate if the front panel window changes state from 'open' to 'closed'.
Alternatively, there could be a check-box option in the "Window Appearance" catagory of the "VI Properties" dialog that is something like this: "Auto-terminate loops when front panel closes".
It's nice to offer users the familar functionality of the standard OS close buttons, but it would also be nice if there was a simple way to do this, without the programming overhead. (I've enclosed this functionality inside a subVI and it's relatively easy to drop this in and wire it up. Presumably, it wouldn't be too much work to add this capability right into the loop structure itself.)
I realize that this leads to questions about what to do with parameters that are usually passed when the loop is terminated in the 'correct' way -- the whole question of "OK" versus "Cancel". Perhaps Windows itself has a an answer to this question, and that could be adapted into the LabVIEW environment.
Anyway, it would sure be nice if there was a way to enable the standard OS close boxes without incurring the minor annoyance of programmatically terminating an active (while) loop or UI state machine after-the-fact.
Currently when you open a Front Panel or Block Diagram it will open on whichever monitor you previously were working with it. I suggest that when you move a VIs front panel to a specific monitor and then open the block diagram, it should open the BD on whichever monitor the FP is on. This will help save user from having to continuously move many different windows from monitor to monitor. This can also be extended to opening subVIs. The subVIs front panel should open on the same monitor that the caller's block diagram is opened on.
When working on a queued statemachine today, I realized its difficult to keep the wires straight. Usually you want one error wire going through your queue functions and into your subVIs but lining them up to keep the error wire straight often causes wires connected to the top connection terminal to get in each others way. If the queue functions icons were taller, this problem would be eliminated. See attached pictures
Message Edited by for(imstuck) on 02-05-2010 02:37 PM
I want to swap sides
for the scale on my Front Panel Tanks and DSC vessels
like Pressurized Tank.
This is very easy to do with a
Waveform Chart or Graph but impossible with Tanks and
Vessels unless you wire up some property node scheme to change the position of the scale, but then the indicator numbers are now between the vessel
and the tick markers, making it a look a bit unnatural.
This would be very handy, especially for DSC
processes where I'm trying to mimic process flow on the Front Panel and
pipes could enter tanks from different sides.