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 in LabVIEW NXG 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!
When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.
When using the waveform datatype in my applications I noticed that the T0 field of this datatype is getting out of pace with the system clock of the machine of where it is running on.
The origin of this behaviour is that time synchronisation only takes place at the start of a measurement session after which waveform timestamps are derived from the measurement device's clock and not from the system's clock. Small differences in clock accuracy cause the clocks to run out of phase.
This effect is especially noticable on applications that are running 24/7 e.g monitoring Industrial continuous processes for weeks at a time.
When this happens and data is saved for analysis afterwards there could be problems synchronizing this saved data with data of other sources because timestamps are different.
The only way to prevent this is stopping the task and starting it again but this is not always possible due to the nature of the processes monitored.
It would be very nice to have an option in the AIread function that can automatically synchronizes waveform timestamps with the systemclock on a timely basis.
Funtionally this would be something I programmed in the attached VI.
After reading Restore High Contrast Icons I procrastinated as long as possible before installing LV2016. When I finally did, I was disappointed by the additional space required for the palettes; all of them! I have been using LabVIEW since 5.0 and switched to an Icon view of the palettes shortly after getting comfortable with the graphics. Now, I have to move my mouse further to get to each sub-menu and VI selection. It's a waste of developer's time and apparently done for absolutely no good reason except to make a change; very similar to the washed out icons.
This extra space needs to be removed or at least an option provided to set the spacing back to the condensed spacing always available.
These images to show the relative size of the palettes LV2016 vs. 2015.
Yes, this might seem trivial, until you think about traversing several palettes to get to your needed VI.
*Random example, if one were doing FTP development they'd pin the menu.
** The original size of the above graphic is 1030 pixels wide; less than 800 for 2015.
Quit messing with what works and has become the standard with regards to options. At least when that ridiculous "default" setting for icons instead of terminals was introduced we could undo the setting in Options.
It seems that NI has hired some non-G experts to mess up the interface simply so they can enumerate all the "great" improvements they've made. Or, was all the extra space to make sure newbies couldn't miss the folder tab, since connecting the "right arrow" on an icon to it being a sub-folder would be too difficult for children?
LabVIEW on just looks awful. Here's a little gallery of horrors. In my opinion it makes LabVIEW looks very unprofessional. These are all taken from a "stock" LV2016 Full license, installed on Windows 7, taken from some of the windows I see all the time. This list could go on forever!
A lot of these problems seem to originate from using LabVIEW-style controls and indicators into its own windows and panels, which are not rendered correctly. Please save LabVIEW from itself!
Basically I'd like more control over the text in listboxes. I want the same level of control that you can get from a string control, where each character in a string element can have custom font settings. At the moment each line in a listbox must have the same settings. This idea is to have more control over the font settings of listboxes, and multicolumn listboxes, as well as implementing the property nodes that allows for these settings to be controlled problematically.
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.
A customer of mine want to create multilingual applications. They are sloving this right now by im- and exporting strings. They found a tool in the Internet, that can extract texts which can then be processed and be imported again. The VI has then to be saved and compiled, which is very time consuming.
He programmed a tool for a Windows Applications which is working similar. In that tool it is then possible to change the language. But we would need some soft of language lists.
His Idea to slove it easily is to implement subtitles (maybe around 5) in every forntpanelelement in which you could set the translation similar to a button text. The same way could be applied for the tips and the description. These Subtitles should then be switchable during the test to get the proper language version.
We can right-click a string object and change the state (control, indicator, constant, array, element) by right-clicking. Unfortunately, the current behavior is (partially) inconsistent in the way the display format (normal, /-codes, pass, hex) is handled. Here are some results (list is incomplete), the symbol <> means in either direction.
Control<>indicator: The display format is retained
Array<>array constant: The display format is reset to "normal". *(Also see below)
Control|indicator<>constant: The display format is reset to "normal".
(*note that if I drop a string constant into an empty array container, the format and element size is retained. Converting to array using right-click should do the same!)
Whenever a conversion involves a diagram constant, the current display format is lost. I think it should be retained!
Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!
In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.
Here is a simplified example to illustrate the problem (see picture).
In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.
However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course ). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!
What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.
The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.
Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.
(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)
Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.
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.
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.
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.