LLBs always had the capability of marking a VI as toplevel.
I wonder if it would be possible to set a flag inside a VI so a VI is recognized as such from within e.g. windows explorer. (e.g. different default icon). Since this requires OS integrations, I don't know if this is even feasible.
Still, It should at least integrate with the LabVIEW project.
The default settings could be very simple:
Many times, people attach a zip full of VIs without telling us the name of the toplevel VI, so this idea would limit the number of candidates to inspect.
Currently you cannot perform a binary compare on two 'identical' exe's or installer builds. We need a way for our configuration management folks to build an exe per instructions and verify it is the same as what I built. But there are differences in the binary files due to time stamps and other things. Does anyone else need this functionality?
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.
Adding or allocating a secondary axis in Excel chart/graph using Report Generation is a good to have feature. We can however use Macros to do this, but if we have a VI in Report Generation that would be great.
It drives me crazy when I have unwired cases and I want to see which cases I have not passed the wire through. I have to go clicking through every case to find them. I propose a right-click menu option on a unwired node coming out of a case structure which will either take me to the unwired case if there is only one, or pop up a list that has all the unwired cases. From this list I should be able to double click and show that particular case. This should also work for event structures.
Is this feature already there? If so, it should be added to the right-click menu IMO.
Currently the 'array build' gives you only the option to merge by rows. If you want to merge by column you first need to transpose the two (or more) input arrays then merge them and then transpose the array again. See VI example attachted. I think this should be changed because it gives a overhead on transpose VI's on your diagram. Therefore I suggest that the 'array build' block gets a option where you can select to merge on columns or rows when a 2D array is used as input.
When you have to work with multiple LabVIEW projects at the same time, you may point to a VI of the second project, or save a VI in the other project ... This occurs frequently when you have to work with a project template which you have to duplicate !
The problem is that your project works fine ! But you point on misplaced VI's !
The problem will only be seen when you have to give the project to someone else, or 2 or 3 year after the project completion, when you want to made some updates. And then AIE ! A VI is missing !
It should be nice to generate an "Optional" warning (Popup), when any user action (save, insert VI on front panel ... ) handles with a VI not located under the project path.
This visual warning could be interresting to avoid this kind of error.
This way it's a pain to "copy past" image from one to the other control. It should be possible to customize two controls at a time
For some days i had to create multiple CRio targets in my LabVIEW project, using the same Labview Code.
( I wanted to test my application on different CRio versions, in order to check CPU usage)
I first try to use the contextual menu to find out the available commands on targets, CRio backplane, and FPGA target.
=> I don't find any command to easily duplicate my target.
=> So, i had to create a new target, completly, step by step
(Create a new Crio target, a new backplane, a new FPGA target ... new FPGA FIFOs, new FPGA C series modules .... .)
Yesterday, i talk with our NI commercial about this problem, and he says ... you have only to copy and paste the items of your project.
=> This work fine !
It should be nice to made the copy/paste command (and perhaps other commands) available in the project treeview context menu.
All available commands on items should appear in the treeview context menu, in order to guide the LabVIEW users.
It would be great if you could create a comment that would stick to the case selector label in a case structure. If this were implemented, in the screenshot the "5PLL" comment wouldn't fly off to a random place when I cleaned up the diagram, but would stay with the case selector, making the code easier to read.
In the error list window, when "Show Warings" is enabled, there are shown warnings for event structures. (More precise for event data nodes in the event structure.) This is wrong because the programmer is not responsible for this duplicate names. And probably there are no duplicate names anyway.
This code (snippet, paste it in a VI for testing):
Generates this warning:
This warning is there at least since LV 8.6 and is still present in LV12.
When copying a control/indicator/constant, the new label name is generated automatically by incrementing a trailing number, or adding one if it didn't exist. I almost never keep the suggested label (so this would also be useful), but I do have other predictable changes that will usually be made. Most commonly, it will be to "auto-increment" a lone letter, either at the start or end of the label. For example:
"X Axis" -> "Y Axis" and then "Z axis"
"e_a" -> "e_b", "e_c", ...
My suggestion is for a simple smart algorithm to recognise where there is a single letter (defined by either punctuation or spaces) at either end of the existing label, and if so, to increment that letter rather than add a number. The existence of a trailing number should take preference over this check, and could still be added if one doesn't already exist (though see here).
I'm using Key Down? and Key Up events to turn the keyboard into a series of switches for a behavioral experiment. For example, I want the user to push down Caps Lock with the left hand, Return with the right, then use the appropriate hand to do a specified task. By monitoring Key Down and Key Up events, I can capture the timing of the user's "button sequences" (to the accuracy of Window's clock).
Key Down? provides three indicators of what key is pressed -- Char, which is an I16 representation of the Ascii character (and hence can be "converted" easily into a string one could test, e.g. is this "A"?), VKey, an enum saying if the key is an Ascii character or a "special" key (such as Caps or Return), and ScanCode, which is another I16 that corresponds (somehow) to each key on the keyboard. There are also boolean indicators that can tell you if Ctrl, Shift, or Alt are being simultaneously pressed. Of these, the least "transparent" is ScanCode, as there is no obvious way (other than placing a comment on your code) to know that 58 corresponds to CapsLock.
Unfortunately, Key Up only provides ScanCode! So while I can write "nice" code that can more-or-less self-document that I'm testing for Caps Lock or Return (simply wire VKey to a Case statement, which will allow me to have a case labelled "Caps", pretty obvious, no?), I don't have such functionality with the Key Up event.
Suggestion -- add Char and VKey inputs to the Key Up event! This will make it "symmetrical" with respect to Key Down?, and will enable producing Key Up code that doesn't need to rely on "magic numbers" (Scan Codes) for specific keys.
LabVIEW should support loop unrolling...
For those who do not know what loop unrolling is (from wikipedia http://en.wikipedia.org/wiki/Loop_unwinding)
Loop unwinding, also known as loop unrolling, is a loop transformation technique that attempts to optimize a program's execution speed at the expense of its binary size (space-time tradeoff). The transformation can be undertaken manually by the programmer or by an optimizing compiler.
The goal of loop unwinding is to increase a program's speed by reducing (or eliminating) instructions that control the loop, such as pointer arithmetic and "end of loop" tests on each iteration; reducing branch penalties; as well as "hiding latencies, in particular, the delay in reading data from memory". Loops can be re-written instead as a repeated sequence of similar independent statements eliminating this overhead.
Example with textual programming language:
for (x = 0; x < 100; x++)
for (x = 0; x < 100; x+=5)
Who is with me
If you are using Global Variables in a project, and you drag the control from the Global VI's front panel to the block diagram of another VI, the item gets placed on the BD as a constant. It is more desirable that this action drop as a global variable node associated with the dragged control. If either the global VI in the project or the global VI's icon is dragged to a diagram then the result is a global variable node, but then always defaults to the first control in the global so you have to manually change it (this default choice is natural as LV would have no clue which control you wanted, fair enough).
This idea is to create some way of moving a control from the front panel of the global VI to the block diagram of another VI in such a way that LabVIEW knows to drop a global variable node instead of a constant. Because changing the standard behavior for dragging a control from any panel to any diagram would result in user interface inconsistencies, the suggestion is that ctrl+alt+drag be used to indicate that the user is performing a special drag, and when this drag is from the FP of the global VI to the diagram of another VI, LabVIEW should drop a global variable node.
Note: before I get people commenting that GVs are bad bad bad and should be removed, this idea does not attempt to rationalise the need for (or hatred of ) GVs, lets try and leave that for a different thread.