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).
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.
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 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 ...
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.
These two structures can be replaced with each other, but not with a case structure. I can't count how many times I've drafted some code, then want to reuse some or all of the cases selectably at runtime. Changing to a Conditional Disable Structure is halfway there, but then I'd still need to have a project file to define and edit custom symbols, which I often don't.
I recently took the NI Instrument Control class and we came to the topic of creating a VI tree.vi.
It didn't make sense that we needed to update the VI tree.vi AND the palette when we add or delete a VI.
I propose that there should be an option to auto-make a VI tree.vi or just a simple html page with the available VI's in your project/driver.
This currently makes sense since all the VIs should already be categorized in the palette.
Currently we can only get the code from NI if we've purchased the stand alone license and it's double secret zipped & passworded. The object is to select the DSC-RTE "additional" installer at "Installer build time" and build one clean package. Our work around was to buy the customers license, download the code, and add the DSC-RTE installer as a pre or post command (or manually install before running our DSC app.) Vision products are setup for clean Installer builds...follow their model.
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)
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.
Please support the path alias NI_AB_PROJECTNAME fo
When generating a new executable, the default path
Most time this is only an inconsistency and not re
Please do also support the alias NI_AB_PROJECTNAME
+ Interop Assembly
+ Packed Library
+ Source Distribution
+ Web Service
- Zip File
The project file I read out if NI_AB_PROJECTNAME i
There are times that I wanted to use a numeric constant or control as a string data type. In order to use a different data type, I would manually copy and paste the control/constant values to another data type. Moreover, if the control or constant is an array of values, it's tiring to do a manual copy of the values. Creating a vi that would convert the data type would also take time. As a suggestion, I hope LabVIEW can include in their "right-click" property box a method of converting the Path to String, String to Path, String to Numeric and Numeric to String.
I don't know if this is a big thing or not. Just a piece of thought.
We have all been enjoying the advantages and practicality of graph and charts, but when it comes to a vertical plot whe are ONLY LEFT WITH THE OPTION OF USING A XY GRAPH. Working with XY graphs involves creating our own arrays to save the history, extract from the array only what we want to show, deal with the scales, and create a ramp array to use in one of the axis to correlate to that of the signals (basically, build a cartesian diagram). It is cumbersome and time consuming.
WOULDN'T IT BE GRATE IF WE CAN CREATE A VERTICAL PLOT BY SIMPLY DOING : RIGHT CLICK -> ROTATE ??? Is this too much to ask ??
Think about it !!!
Most of applications we write in LV are contained inside of a project. Saving it to disk creates a lot of files (.lvproj, .vi, .ctl, .aliases, etc) and subdirectories. This is convenient when you want to copy one VI or control to another project, but very inconvenient when sending this project to someone. In this case you have to create an archive to put everything together. Make an option to save all items contained in a project in one file.
Making a Windows Explorer plugin to automatically open such files as directories would be also a nice addition in this case.
This Idea applies to all Libraries but my main Use Case relates to Class Libraries
I am not sure how everyone arranges there Classes, from trolling online it seems common that non-publically scoped methods tend to get placed in their own Virtual Folder and public methods are at the top-level.
Unless my Class only has a few methods I would take a similar approach however, most of the time I like to categorize them in more detail. The reason being this is my palette from where I choose my methods, and I like to group them using the following logic so that I can get as much information visually out of the organisation / layout of the Class. I like to have the only top-level method as the constructor if there is one (so I can see that there is one or not for that Class).
I only create the Virtual Folders I need, but usually there are a mix from the follow example:
The problem I have with the current design is that I don't know whether I have scoped my public methods correctly, as I could have forgotten and they are still left not specified - which is the default when you create a new Virtual Folder.
Currently there is no way to tell the difference from the above two Virtual Folders unless you right click on them or possibly look at the contents.
This is not great as there is potential that I could have scoped things wrong which normally leads to me having to check or recheck the scope is correct.
As LabVIEW is graphical by nature, it would be much nicer if I could visually see a public scope glyph to differentiate it from a not specified Virtual Folder.
I selected the color green as it is a natural opposite to red (private) and has not been used yet.
Therefore, my original implementation would look like the below, and I can straight away see if I have scoped the public folders correctly.
I am sure there was a reason not to include it originally.
I am interested to why and if there is a good reason not to show this too.