For example, you have 1000 vi, and they all contain the same subvi. You change the name of the subvi. When you open the 1000 vi, it will ask you for the subvi. You would have to browse for the same subvi 1000 times. It labview remember the location of the subvi after you fix the broken link once. That would save a lot of time.
When you have something to print you can develop a VI with the option : 'print after execution'
With complex information, you can have a printable VI for graphical data, a VI for array data, ...
When you print all data you have a lot of paper.
But when your printer is a PDF printer, you have a lot of file with 1 page and not 1 file with a lot of page !
I suggest to have a way to create a print task, add a VI to print (with a option like 'add to print task after execution') and to have a command for run the print.
Advanced option :
A option to create more a print task.
So you can prepare the print task and juste run it on a event (and no loose time to build or re build the data if the same event comes again).
there is an idea about making labview.ini and other user configs to the corresponding user folder .
I propose to go a step further and make the LabVIEW environment project based, which means that you can define a labview.ini file, VI templates (including standard VI, if you create a new VI), palettes, QuickDrop stuff, etc. inside a project.
E.g. templates are saved in a custom location and linked inside the project. If you do this and start the "New..." dialog, than all your templates inside the project are listed first (below project).
If you do not use this feature in your project, the default files are used (default meaning the way LabVIEW works now).
We already have inline VIs that are compiled directly into the code, just as if you had wired the code on your diagram. Imagine if we could designate some of the inputs and outputs as polymorphic. We could create VIs that do simple math operations, comparisons and other stuff without having to create a dozen versions for the different inputs and outputs possible.
I think the outputs would have to be either a fixed type or same as a selected input. Some inputs, such as strings, wouldn't work in many cases. If the input wired to the inline VI was not compatible, it would just fail to compile and give you a broken wire, just as if you had wired the same code into your diagram. It really would just be a block of code that could easily be added to a diagram as a VI, but it would be recompiled based on the inputs.
By using the property node "Allow Multiple Rows" of Tab Control, this allows to arrange any tab extended beyond the width of the Tab Control, but there is no property node to inform the quantity of rows that were added.
It would be interesting to have this property node because it would be possible to perfectly fit the dimensions of the Tab Control when it is resized.
Currently when a search is made in the "find examples" window of LabVIEW it is not possible to find its folder path in the browse tab.
I would like to suggest the ability to right-click the search result and to have an option to find that search result in the browse tab.
This would be extremely useful when locating an example and then posting online the location in the example browser.
Here is an example of what it would look like:
National Instruments UK
When working with reentrant VIs, every time you double click an instance of a reentrant vi on the block diagram, the cloned instance is opened. This is fine during debugging but during development when you want to modify the actual code this requires that you open a clone, then CTRL+M to open the actual master vi. Much more frustrating if you have to dig several VIs deep through a highly reentrant hierarchy.
We have CTRL+RT Click to open the block diagram directly, how about something like ALT+RT Click to open the master VI instead of the clone.
Under normal development this is not such an issue but if you happen to be working with LV FPGA, just about everything is reentrant.
when you place some control in the front panel, You don't have any idea of his position, You don't have posibility to control de exact position of this control, and You can't edit this position, only you have a small tip strip display when you move this control.You cant change the position of a control wiht the properties nodes in execution time, but this is not enough.
place a display in the front panel, to display the absolute position of a control, and his size, and when it is selected, to able to put his position, in additional way in the properties of control, having the posibility to do the same operation.
When you want to save a XControl, you have to save 5 items ... the savefiledialog appears 5 times ...
The problem is, that when you add an XControl to an autopopulating project, the savefiledialog appears 5 times,
without any memory of the last path used ! You have to browse 5 times save all elements.
Here some possible solutions to this problem ...
Hello LabVIEW Experts,
I thought of this recently when I was setting up a test computer. I started up my LabVIEW project file and opened up my host VI only to find that I had some broken wires... DOH! After looking over MAX and googling a few error codes, I found that the test machine I had didn't have RT installed. That's when it hit me, wouldn't it be great if the VI would have recognized that I was trying to connect to a cRIO chassis and gave me a little pop up telling me what software I was missing and where to get it? Sure would have made my day easier.
When I was debugging the RT code it was getting crashed whenever I open more than one VI which has large clusters. For displaying the values in the front panel certain amount of memory is required that was the problem. In some cases it is not required to see the values in the front panel and also it is not required to open the front panel either. So it would be good if we have an option for disabling the values updation to the front panel control and I believe it will increase the efficiency even when we open those vi's. This option can be made available in the control/indicator properties and also if we want to disable the whole control/indicators present in the vi the option can also be made available in the vi properties. By default the option will be enabled and the front panel updation can be disabled by removing the check mark in the check box.
I guess it is not proposed before.
Inconsistency is found in the supported image types for many IMAQ vi's:
For instance IMAQ ROIProfile, IMAQ LineProfile and IMAQ LinearAverages supports U8, I16 and SGL format but do not support U16 format images.
But, a profile along a line drawn in a U16 image should make as much sense as in an U8 image. Shouldn't it? So why is it not supported?
In addition, I would expect it to be easy to add an additional polymorphic U16 version.
These are just a few of several examples of similar inconsistency in IMAQ vi's.
Currently all ROI contours have to be the same color. There have been many instances where it would have been useful to be able to set the color of a specific contour.
Most of the new LabVIEW users will start programming from the scratch. They really find very hard to understand from where did this particular object (function) came from. So if the location of it is displayed in the context help it will give a better way to easily find that object from the location.
Ex: "Create User Event" can be displayed in context help as below
Location: Programming->Dialog&User Interface->Events->
(or in a shorter form that everybody understands).
Sorry if this idea has been discussed before. Or its not at all needed. For a newbie this will help definitely.
LabVIEW opens the file in the version of LabVIEW that was most recently opened instead of the version the file was saved in. Add a header to the file to allow LabVIEW to open the file in the correct version. This will save a lot of time and lower frustration of accidently saving a file in the newer version.
The numeric controls can be configured by specifying Min/max values ... and behaviour when going over these limits (Coerce, ignore ... )
This feature works fine on the front panels ...
But when you modify the value of such controls programaticaly using a property node ... these constraints are not taken in account.
It would be nice to apply the MIN/Max limits also to the "value property" (and valus signaling too)