 |
|
||||||||||||
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.
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.
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.
Andrey.
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!
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
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!
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?
Once in a while I complain about font issues in general (here, here, or here), but one of the really weird things are the font sizes as used in LabVIEW.
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!
If you are not using the Data Event Terminals in an Event Structure, you might customarily hide them - roll them up so that only one terminal is showing. I would like to hide that remaining terminal. The idea is to not grey-out the Remove Element option when you are down to one terminal. That way, you can remove it. A stub remains to right-click on in order to bring the terminal(s) back if required.
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.
I don't know how many times I've added a case statement post-programming, but I do know that there isn't an easy way to make a tunnel the case selector. Usually I delete the tunnel and then drag the case selector down and then rewire, there should be an easier way. For loops and while loops have an easy way to index/unindex or replace with shift register, why can't a case statement be the same?
Block diagram string constants have a useful feature "Size to text" which is accessible through the standard right click menu. One way in which this is useful is to ensure that information in an array of constants is not hidden: Right click on an element of a string-constant array and select "Size to text" and it will expand to show the full length of all the strings it contains.
What's needed is an equivalent for numerics (including rings and enums). When dropped singly, these constants expand and shrink around their contents. But if you drop a numeric constant on an array constant, it takes the size of the numeric and can only be expanded manually. If you then enter a constant that is longer, only the first part will be shown, and there is no indication that the values are truncated. (see image)
I think that arrays of numeric constants should resize to show everything entered, automatically.
There's a common convention in LabVIEW where if a control is not a required input, you place the default value in parentheses:
For the most part this make sense and is useful when calling VIs, but there is one place where it's really annoying:
We know there's no error by default. I suggest that NI simply remove this. This can be done today by going to <vi.lib>\errclust.llb and modifying the control, but that's annoying to do with every installation.
I would even go so far as to say that NI should write a VI which will go through vi.lib and remove the text from all the existing VIs. I doubt this would have any backward compatibility issues, because I think the only place where those would be relevant is if someone is calling a VI in vi.lib dynamically AND setting the error in value, and frankly, those people deserve to be punished.
There are times when I leave a VI with modal properties open and then I run the main application that also calls this VI if opened in the development environment. This locks all running windows due to the modal VI. I propose a button in the taskbar that aborts all running VIs OR perhaps a list is opened on right-click of all running VIs 
Have a LabVIEW Idea?- Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
- If your idea has not been submitted click
Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea. - Watch as the community gives your idea kudos and adds their input.
- As NI R&D considers the idea, they will change the idea status.
- Give kudos to other ideas that you would like to see in a future version of LabVIEW!
|
||
|
||
My Profile | Privacy |
Legal |
Contact NI
© 2011 National Instruments Corporation. All rights reserved. |  E-Mail this Page
|
||
|
||