Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
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?
For those of you who haven't signed up yet, you should go and have a look at the Next Generation LabVIEW Features Technology Preview (a mouthful, but in short, it is a UI and Development Environment demonstration version of what NI is cooking up for future versions of LabVIEW). There are some cool things and some downright awful ones.
One of them has been sneaking its ugly neck in LabVIEW 2016: reduced contrast. I am (my eyes) getting tired of it. A few examples of the changes introduced in 2016 are shown below:
Considering that the trend is for displays to not increase that much in size but increase in resolution, we have now to factors to fight against: the reduction in size AND the reduction in contrast. I won't mention laptop displays going in economy mode and reducing their luminosity, but the point is that it is making LabVIEW even more difficult and unengaging to use. Way to go to loose any chance to attract new users, and run the risk to loose old timers due to added eye strain.
Put simply: Restore high contrast icons and please, do not go ahead with the washed out IDE and UI objects showcased in Tech Preview.
I propose that if an array is wired into a for loop, the tunnel should be auto-indexing by default (current behavior) UNLESS there is already an auto-indexing input tunnel in that for loop (new behavior).
Generally, when I wire an array into a for loop, I want an auto-indexing tunnel, so I am happy that it creates one by default. However, when I wire a second array into the same for loop and it creates another auto-indexing tunnel by default. This is usually not what I want because it will cause the loop to stop early due to one array being smaller. I'm afraid that this default behavior may cause bugs for new programmers because they may not realize to change it (in fact, this has even happened to me before). Default behavior should be the "safe" behavior. Making the decision to have more than one auto-indexing input tunnel in a loop is one that should be carefully considered, so it shouldn't happen by default, but rather should be changed explicitly by the user.
I know there have been many ideas posted about the current auto-indexing default behavior, but I didn't see this specific one anywhere, and I think it is an important suggestion.
As everybody knows there are two ways for generating an empty string constant in the block diagram: Using the "empty-string"-constant or creating a genereal string constant with no content.
Both ways have advantages and disadvantages:
- The "empty-string"-constant shows much better that the string is empty but it can't be used e.g. in arrays.
- The string-constant can always be used, it is easily generated by right-klick to a string terminal and selecting "create -> constant". Furthermore its value can be changed to somthing non-empty if required. Disadvantage: It's hard to see if the constant contains nothing or just a blank sign.
My suggestion: LabVIEW shall show a string constant which contains an empty string always with the symbol that is currently used for the "empty string"-constant. This is also valid if the empty string is within an array or cluster. If this behaviour is not wanted in a particular case, there shall be the conext-menu-option "show symbol for empty string" which could be deactivated.
For changing the value of such a new string constant, the symbol shall change to a classic string constant if the user moves the mouse (with selected text-editing-tool) over it.
Similar behaviour is also suggested for general-path- / empty-path-constants.
Remark: I'm using LV2015SP1 - maybe there is already a change in LV2016.
Sometimes it's very useful to modify a front-panel decoration element programatically. E.g. moving it, changing its size, color or visability. All of those properties do already exist.
Because a decoration element does not have a property node, it must be searched via the decorations-property of the pane. The problem here is, that there no possibility identify a particular decorcation element because there seems not to be any identifier property.
What I'm requesting to resolve this awkward situation is to give all decoration elements a label-text property (or any other identifier property) which can be set during programing time by the LabVIEW programmer.
We've been saying it for years now. Enums should be typedefs.
Why not make EACH and EVERY dropped Enum into a typedef automatically. Drop a new Enum from a palette, it is a typedef. Copy it, it's linked to the original. For my taste, even ask for a save path after dropping the enum but for the sake of our sanity, just make each and every enum a typedef already.
The getting started windows fills with irrelevant entries if we open many VIs and projects from the forum. We probably never want to see them again. Also, if items exist that have the same name, but reside in different folders, they will show with the full (often very long!) path and the filename is not directly visible unless we e.g. hover over it or make the window gigantic. Here we want to remove the stale one, even if a copy still exists on disk.
We can currently do some cleanup by editing labview.ini but it is tedious. (just try it!)
I would like to request a feature that allows us to easily and permanently remove any entry in the list. (...maybe it could even show for pinned entries?)
IDEA: I suggest to show a special glyph that, when clicked would remove that entry from the list.
It could also be e.g. an "X" (or similar) that shows next to the pin when hovering so we can either pin or thrash an entry.
These are just some suggestions, but there should be a way to easily weed out unwanted entries from the GSW. Of course the actual files will not be touched. We would just go back to the state before we opened that item.
I'm developing some software for a colleague, to run on (one of) his machines. I do my best to follow Good LabVIEW Practices, including using Version Control (SVN) to maintain my code. Hence my Project "jumps" from computer to computer.
I recently noticed an old problem re-appear, namely occasional Front Panel and Block Diagram labels appearing in a different Font Size (18) than I've set as the default on my Office Desktop and home Laptop (15). This was really irritating (especially having to find those wayward labels and "fix" them), forcing me to re-examine the Where and How of setting Default Fonts in LabVIEW.
This still appears to be a Dark Art, one (perhaps) involving LabVIEW.ini (and some undocumented keys, not present in the "vanilla" configuration file). There appear to be several such INI files, with LabVIEW.ini attuned for development, and an INI file in the Data folder of a built Executable for that Executable. But still, the values are bereft of documentation (i.e. documentation is conspicuous by its absence) and not everything is explained (like why some values are in quotes, what they mean, and how one sets a specific Font, e.g. Arial).
One thing that I, in particular, would like to see would be the ability to set the Font Defaults on a Project basis. For myself, I "own" the Project, and would want it to have a consistent Font (size) on all my VIs (unless I specifically decide to Emphasize something), no matter on what machine I develop them and when. If I have to set the Font Default on a machine-wide basis, then every time I develop on my colleague's PC, I'd have to (a) note his settings, (b) change them to mine, and (c) remember to set them back when I finish. As such sessions are often an hour here, an hour there, this "machine-centric" setting becomes a nuisance fast.
I recently had the opportunity to discuss this with an NI Applications Engineer, who assisted me in finding (some of) the obscure references to Font Setting Tricks. I noted that a lot of what the Community knows seems to come from "Reverse-Engineering" NI's settings, and that some Documentation and Standardization (let's get away from designating Fonts as "1", "2", or "3", which have no intrinsic meaning, please) would be a good idea. Hence this LabVIEW Idea.
This is not directly a LabVIEW idea, but it is still an idea that impacts many LabVIEW programmers.
To keep my distribution small, I distribute my installers without run-time engine and instruct the users to download and install the relevant run-time engine. I provide a link to the run-time download page.
Note that these users are NOT NI customers and not interested in any NI products. They are my customers (well, my programs are free) and are only interested getting my programs to work on their PC. Theydon'tevencarewhatwasusedtodeveloptheprogram.There is no extra hardware involved. If they already use NI hardware, chances are they already have a profile.
My users don't need a NI profile and don't need the follow-up phone call or e-mail from NI, etc.
Typical phone exchange yesterday:
me: "just click my installer and install the program"
him: "OK, done."
me: "now run it."
him: "OK, ...... error about 2013 run-time engine".
me: "OK, install the run-time engine using the link I sent you in the same e-mail".
him: "clicking the link to go to the run time engine page....
(..30 second discussion to decide between downloader and direct download...)"
him: "click..(wait for it!)... .it wants me to register..."
me: "OK, let's forget about that. come down to the lab and I will do it for you."
End result: more delays (it was late Friday and I was ready to leave), more work for me, more hassle.
While gazillions () of registered users sounds good on paper for NI, these are false numbers because many profiles are one-time use and quickly forgotten.
I think downloading a run-time engine should NOT require a NI profile. Maybe it should still offer to log in or create a profile, but there should also be a bail-out option similar to " I don't want to register at this time, just download the run-time!".
Note that even better long term solutions have been proposed, but this idea could be implemented quickly and does not even need to involve any LabVIEW developers.
With a case structure I can place the mouse cursor over the structure and Ctrl + scroll wheel to cycle through the cases without it being active. If I try doing this on arrays it doesn't work.
For front panel arrays the numeric indicator must have focus for this to work. Doesn't work when the array data is selected. I understand that multidimensional arrays would be a problem, but for 1D arrays it would be nice if it cycled through the elements.
For array constant block diagram elements, no scroll action works regardless of what is active. Again it should allow the user to cycle through elements for 1D arrays simply by hovering over the item and Ctrl + scroll wheel.
After some searching, this ideas was already discussed in the comments of this declined idea. but I think it deserves to stand on its own, so here we go.
We have a nice menu entry "Menu...Edit...Make current values default" that (if nothing is selected) does just that. In 99% of my cases only the controls are important, because all the indicators, while often containing tons of data (graphs, arrays, etc) can be easily re-created from the control values at any time.
So while the control values are useful to be able to run a VI out-of-the-box with reasonable input values, default values for indicators just contribute to VI bloat, increasing the size on disk.
Making indicators default is useful for the rare cases where a forum users want to show what he gets or expects to get, but not in general development. Yes, we can of course select all controls first, but they might be scattered all over the panel and over several tab pages, so that's not a good solution. (We could also request a menu in addition to the "edit...select all" e.g. called "edit...select all controls", but that is probably a different idea.)
In summary, there should be a menu entry that ignores indicators when making values the default.
It should also work if multiple items are selected "Make Selected Control Values Default", in which case it would ignore any selected indicators.
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.
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.