I occasionally hide controls on my FP and control their visibility programmatically during the execution of my program. The problem is that if I edit my UI and the control is hidden, it's very easy not to be aware that it's there and to accidentally overlap it, hide it or even move it off the screen.
To solve this, I usually try to save the VIs with all the controls visible, but that's not always feasible.
A better solution - LabVIEW should always show hidden controls in edit mode. It should just have some way of differentiating them from visible controls. This mockup shows them as ghosts, but it can also be any other solution:
In run mode, of course, the control would not be shown. This is similar to the black border you get when objects overlap a tab control.
The recently introduced Raspberry Pi is a 32 bit ARM based microcontroller board that is very popular. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK (or other methods of getting LabVIEW to run on it).
The Raspberry Pi is a $35 (with Ethernet) credit card sized computer that is open hardware. The ARM chip is an Atmel ARM11 running at 700 MHz resulting in 875 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power. So, about 15 times the processing power!
Wouldn’t it be great to programme the Raspberry Pi in LabVIEW?
Typical question in development process: "How quickly does my code execute? What runs faster... Code A or Code B?" So, if you're like me, you throw in a quick sequence that looks like this:
AHHH! What a mess! It's so hard to fit it in, with FP real estate so packed these days!
We need this:
Just like my other idea, and for simplicity's sake NI, I would be PERFECTLY happy even if you had to set up the probes during edit mode, and were not able to "probe" while running.
As a bonus, this idea may be extrapolated into n timing probes, where you can find delta t between any two of the probes.
Here's how we currently make cluster element labels appear, and a proposed idea for improvement.
The problem that height of local variable is 17 pix, and terminal - 16 pix, but distance between terminals in unbundle function is 15 pix.
As result - aligning to vertical compress caused steps in wires:
Right nowterminals/local variables should be slighly overlapped for "step edge free" wiring.
Please synchronize size of these icons with distance between terminals (to 16 pixels - seems to be ideal size)
Not sure if it was already in Idea Exchange or not.
I'd like there to be an option to show some kind of indicator on string controls that you aren't seeing the entire string. This should also apply to string constants on the block diagram.
I searched for a similar idea, but couldn't find one. Let me know if there is already a similar idea.
Currently, it's a crapshoot when you drag an ant trail selection box around items on your FP or BD. It's truly an art to become good at selecting objects in LabVIEW - we all learn "hot spots" to place our selection rectangles, and we all heavily rely on the "Shift+Click" method of adding or removing objects from our selection. Below is an example of what actually might be selected when dragging a selection box:
All horizontal wires were selected down to "ABCDEF", even though just a very small portion of the visible wire was inside the selection box. It's not intuitive to try to not select wire that is hidden behind the Unbundle.
I propose a method that mimics selection in some graphics editing and CAD programs: the idea of "Enclosed" and "Inclusive" selections. An Enclosed selection is made by dragging the mouse from L to R. This operation selects only the objects THAT ARE COMPLETELY ENCLOSED by the selection box, ignoring objects that are partially outside the selection (the red arrow is not part of the BD, it merely represents the motion of the cursor):
Alternatively, if you drag your mouse from RIGHT to LEFT for a selection box, you select every single object that is fully or even partially contained within the selection box:
Voila! Selection is now a TAUGHT SCIENCE instead of a LEARNED ART!
Browsing through menus to replace a numeric conversion node is tedious. How about allowing the selector tool to select from a pull-down menu, just like it does from an unbundle by name node?
Existing unbundle node behavior is shown at left. Desired numeric conversion node behavior is to the right.
The smaller footprint of the Local Variables in 2010 has increased usability of the IDE and readability of the LabVIEW language. Another node that could benefit from a smaller footprint is the User Event Ref Constant.
Below is some conceptual artwork on what a smaller footprint might look like. Feel free to post more concepts!
When you develop with multiple LabVIEW versions, it is sometimes difficult to identify which version you're using or launching based on the icon of the LabVIEW EXE:
Here's my Windows 7 taskbar with, among other things, LabVIEW 8.0, 8.5, 8.6, and 2009 icons. Which one is which? There are ways to tell, but it sure would be easiest if the version number were overlayed on the icon. Note the Visual Studio 9.0 icon in the taskbar...I think we should do something very similar with the application icons of future LabVIEW releases.
NOTE: The icon should also reflect differences between the 32-bit version of LabVIEW and the 64-bit version of LabVIEW
I think structures should have a better label system. Currently I use free labels of the same color as the loop which looks great and makes the code easy to read and debug. But if I resize my loop I have to manually resize the label as well. I think this should be built into a right-click option.
(structure) rick-click » visible items » Structure label
The font dialog lists them as units of pt, but for some reason they are quite different in size from the same sizes in any other applications (browser, word, etc.). LabVIEW also shows other problems, for example tahoma 14, 15 all look exactly the same... why??
Here is a side-by-side comparison of a wordpad document and a LabVIEW panel. Each line is configured for the indicated font size.
As you can easily see, LabVIEW is the exception. Any other applications I tried agrees with the left panel.
Idea -->LabVIEW should also standardize here!
I don't like the way that long file paths are shown in path controls and indicators: If the path is longer than the textbox (and it usually is!), the user only sees the first several levels that fit. This can be pretty confusing.
One way to solve this issue is to truncate the path in the middle in such a way that the filename or last folder (which is usually what's most important) is always shown. I've seen this in other UIs and it should be a natural thing for users to understand.
Here's an illustration:
I think this should be a built in feature of the path controls and indicators, accessible through right-click menus and/or the properties menu of the control at edit time.
The size of the Close Reference VI makes it impossible to draw a proper block diagram.
It is too big! It does not match with the Property Node vi.
Therefore I would propose: --> Make the Close Reference VI smaller!
Currently if you right click on a subVI from the block diagram and choose properties, it brings up the Object Properties dialog. The only options you can change there are label options, which can easily be changed in the "Visible Items" submenu. I can't think of one time when this has ever been what I wanted out of this action. Instead, I think this action should open up the VI Properties Window for the VI.
When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:
Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:
To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):
The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.