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).
I use disable structures and conditional disable structures more and more as my coding starts to spread over multiple targets (Host, RT and FPGA).
I like to include some debugging indicators for my code so that I can (with the proper conditional disable symbols set) debug my code more easily but still remove the bloat for actual release code.
What I have noticed is that controls and indocators which are disabled int his way are NOT accurately represented on the FP. As such I am surrently unable to determine by looking at the FP of a VI that perhaps half or all of the visible indicators are or are not actually being used in the code.
Even when the code is running, the controls and indicatory which are actually disabled are still visible (and supposedly still available over VI Server for example). I think these controls should be actually removed or at least have a visual indication that they are diabled on the BD (distinct to the appearance caused by writing to the "Disabled" property of the control).
The LabVIEW help states: "When compiling, LabVIEW does not include any code in the inactive subdiagrams of the Conditional Disable structure" but I question how true this statement really is.
Although these controls are DISABLED (Not present in the source code)........
Here they are.....
This raises issues on the FPGA level more urgently than on the PC side, but I feel the sentiment behind the idea is the same.
Of course things get more compilcated when the controls are connected to the connector pane, but perhaps simply prohibiting the presence of a connector pane terminal in a conditional disable structure would solve that problem.
Since LabVIEW 2011 installs many things in a standard install, what I would like to see is what it takes to deploy a specific function either in the Help window or somewhere. Just because it is on the functions palette doesn't mean it is free to deploy and before using something I will have to pay extra for, I would like to know that before I use it. Also, this should help in trying to figure out what is needed to deploy your executable, since there are many different RTEs. Thanks
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.
Well, I think the title says it all...
There are many threads on the NI website about this certain topic, but none of them really shows how to deal with this "problem" correctly!
It is a very common task to synchronize a AI signal (let's say 0-10 V from a torque sensor) with a Ctr signal (e.g. an angular position of a drive which causes the torque). How do I correctly display the torque over the drive angle in a X-Y graph?
It would be great if NI offers a reference example in the LV example finder, how to solve such a task elegantly and efficiently.
I'm not sure if this is the appropriate place for this suggestion, but anyway...I would love to see this in the LV example finder!
We can save a VI for a previous version. If it is feasable, it would be nice if there was an option to include an older version along with the current version. For example I save my VI in 2013 with the option to include 9.0. This would effectively double the size of the VI. LabVIEW would open the newest version possible. This would be useful for uploading example code or posting it to the forums.
If it is not feasable then maybe Ton Plomp could implement this in his code capture tool.
You have many VIs saved into one single directory on the hard disk drive. In the project explorer of LabVIEW, the VIs are well-organized within virtual folders.
I'd like to have a possibility to "synchronize" the project explorer with the hard disk drive. That means, all virtual folders of the project explorer will be created on the hard disk drive an the structure will be transfered. All VIs within the virtual folders in the LV project will be moved to the new created real directories on the hard disk drive.
Before the "synchronization":
After the "synchronization":
I've had a look around and can't see anything in here like this already (which surprises me so I'm suspicious that it's just the search algorithm failing) but I'd like to see options in the LabVIEW Project tree for changing target hardware.
For example, I have a development underway using a cRIO-9114 chassis with a 9024 controller, and a 9144 EtherCAT expansion chassis. The primary chassis is about to be upgraded to a 9116, as we need a bigger FPGA, and although the hardware upgrade process is straightforward, upgrading the chassis in the LabVIEW Project is not a possibility. Instread, I need to create a whole new target, and copy and paste every VI, node, FIFO, DMA etc. across. There's quite the possibility that I'll miss something, or the new target won't have all the same settings (Scan Mode period and priority settings for example), leaving me with that niggling feeling that something under the hood will be wrong. It would be much neater if this was an automated migration.
Furthermore, as the hardware is not here yet, I need to create the new target and all it's modules manually, which will take me quite some time. An automated migration would save me that trouble.
I feel like frustrated when there is a lack of connector in the existing VI and need more. Because, when I update it to new pattern as shown below, I need to update the VI's instance in all other VIs in the project. Since I am updating the pattern from lower number of connectors to the higher number of connectors, it would be better if all the instances in other VIs get updated automatically.
Pretty self explanatory subject. I would like the ability to open a VI directly from the QD dialog.
There is already a QD plugin that performs this action (Open from QD), however this seems like something that should be native to QD.
The XY Graph should be able to switch from a Linear scale to a Logarithmic scale and back again without any fuss. While the VI is running.
How it should work:
Notice that the linear scale changes back to -2500 -> 2500 when switching from Log to Linear.
Here's how it currently works:
(A Hobbit's Tale)
2 things to notice:
1. The Log scale did not automatically take the absolute value of the Y values. This should be optional, with both a Properties Dialog option and with a Property Node available to edit.
2. When changing back to the linear scale, the minimum value remains at 3. It should return to the original autofit scale, which LV chose to be -3000 to 3000.
Why This Should Be Done:
Currently, the work around takes up quite a bit of BD space, needs an event structure, and can be memory intensive. If you have data that you want to view on both a linear scale and a logarithmic scale arbitrarily, you need to have, at the very least, a case structure (or Select) that takes the ABS if the scale changes to log.
Here's the simple, made-in-10-minutes workaround example of what I'd like the XY Graph to be able to do natively:
I don't think that there should be a need for extra code just to switch between linear and logarithmic scales nicely.
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 ...
Not so much a new idea as a request to maintain current functionality. LV2010 does not support importing of LabWindows/CVI function panel drivers, can we have it back ASAP please!
For more info see:
(CVI Certified, CLAD, Alliance Member)
Possibilité de changer une condition ou Séquence Par le bas dans LabView
Pour les diagrammes qui ne tiennent pas toujours sur 1 fenêtre, ça pourrait être interessant de pouvoir modifier ou changer une condition (ou séquence) par le bas.
Translated from French:
For diagrams that do not always fit on a window, it might be interesting to modify or change a condition (or sequence) from below.