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!
It would be nice to improve documentation created by Tools->Import->Web Service... wizard.
Especially, I suggest to automatically create Description in created .lvlib Documentation so that it would be immediately clear which WSDL URL is handled by that library. Currently, WSDL URL is only placed as a String constant in Open Web Service.vi which is not really convenient. Thanks for understanding and support.
I have used labview for a long time and avid user. One issue I have been hitting lately is the "LabVIEW everywhere" slogan never really panned out, it has become LabVIEW everywhere NI allows it to be. I am getting jealous of the Arduino and Rasberry Pi and hundreds of PICS and ARMs not avaliable to me (Yes I have the pro liscence but not embedded). I wish Labview pro opened up the toolchain and started porting to many other platforms by default. I am seeing jobs that labview is loosing ot to where it should be much more competetive like the embedded market.
Essentially I am looking to see the Labview development environment easily work with toolchains for the most popular processors and also open up a simple standard to add targets to projects.
Wouldnt it be nice to program a $25 ardunio dirrectly from labview (NO THIS IS NOT WHAT THE TOOLKIT IS DOING). Add a Ardunio target file (maps the io memory to variables and throw down a loop, boolean shift register, a wait and a digital line variable, download to the micro and the blink led example is done. Really open up the doors for LabVIEW everywhere.
(Unless it's already changed in newer LV's, i'm on 2011 right now)
When opening the connector pattern, the current isn't marked in any way. If i'm after some extra connectors or a symmetrical one (why do people choose 3-1-1-1?) it'd be nice to quickly see where to start looking. A simple bold outline would suffice, maybe in blue?
I can't count the number of times I've seen this dialog:
Of course I want to continue, that's why I right-clicked the structure and chose Remove [Structure]! This dialog must be a holdover from pre-Undo days. Do we pop-up a dialog when you select your whole diagram and press <Delete>? What about when you press Ctrl-B? These actions have the potential to remove just as much diagram content as Remove [Structure].
Please get rid of this dialog, and just let us Undo the operation if we need to, just like we do all the other potentially destructive diagram edit operations.
This is not directly related to LabVIEW but I haven't found any other thread which seems like a better fit. I'm posting it on the Idea Exchange since this is the best place for other customers to potentially agree with me.
NI drivers/software are quite often large, and above 1 GB is not uncommon and sometimes above 3 GB. Having everything in a single file is in my opinion a good thing because I don't have to look for multiple driver parts and download packages, but the file size must be matched by the download speed. Waiting three-four hours or more to download a single driver is not a fun thing to do and quite often you need more than one driver.
Sometimes the speed is okay, but as a general rule I would say it's slow. I'm located in Sweden and of course this issue is dependent on a lot of links between where I am located and the server where NI host the files.
But, download speeds of 200-300 KByte/s from NI are not uncommon but I can run speedtests on for example http://www.speedtest.net/ and get download speeds at 50Mbps using American servers.
I don't know how NI host the files, if it's internal servers or something else but it would be nice if NI looked into the possibility of somehow making this faster.
Add new features, flexibility, and new controls to the Front Panel. The only new controls I've seen were made by LabVIEW Customers, and although they were great, they were not resizeable without being distorted (bitmap). I think it's time for NI to give more options and features for the Front Panel Controls. I attached some suggestions. They are there for example, so don't focus on the controls I've made, but the idea of improvements I am suggesting. NI has done a great job on the Diagrams. I should hope it's time NI improves the Front Panel.
I propose that Case Selectors should accept any type of reference, and the two cases generated are "Valid Ref" and "Invalid Ref". (This would be very similar to the current behavior of the Case Selector accepting errors with the two cases of "Error" and "No Error".)
The current behavior using "Not a Number/Path/Refnum" is very unintuitive. It requires the programmer to use Not Logic (i.e., do something if the reference is "not not valid").
When you feed the 'TDMS write' primitive with a string array containing duplicate channel names, you will get one row of data (when 'interleaved' mode is chosen) , regardless how often you write new data.
It took me really a long time to debug: the string array containing the channel names another developer provided was partly hidden.
The help does not warn you for this and no error or warning is thrown.
Somehow you should be warned and/or LabVIEW should add a sequence number.
This is a very simple improvement, since the features are almost there. I want the block diagrams look like an electric diagram, that is: Controls aligned to the left, with the labels on the left of the control and the indicators moved to the right with the labels on the right, like this:
The problem is that in current LV versions the alignments occurs on the labels as well, making look the diagrams like this:
Normally you should: 1) align labels relative to the object and 2) align the objects (without the labels) relative to the block diagram. This kind of cleaning up saves a lot of space and clutter.
Now I am pushing my luck, but it would even be better if I could have these settings on SubVI's only, because I usually don't want this in my main.
When creating a control or indicator based on a subVI terminal or strict typedef, formatting (speicifically the radix) is preserved. However, when creating a constant from the same source, the format is removed. This can cause incorrect behavior to inadvertantly be implemented when dealing with components that use Octal or Hexadecimal, as incorrect values can be input under the assumption of the correct formatting.
Instead, block diagram constants should display the same behavior as controls and indicators, and maintain the correct radix/formatting when created from an existing source.
The various instances of the polymoprhic XML Close VI all have standard error in functionality. In other words, they run normally only if no error occurred before they run. That can lead to references not getting closed if errors occur in sections of code that execute earlier.
Instead, the XML Close VI instances should run normally even if an error occurred before they run. When calling the XML Close VI, it is a nuisance to have to clear the error passed in to it and then merge the previous error with the error output from the VI.
In addition, most of the other Close functions and VIs in LabVIEW run normally even if an error occurred before they run (Close File, UDP Close, VISA Close, Close Reference, DataSocket Close, etc.).
There may be other VIs and functions that have the same behavior as the current XML Close VI and they should be changed as well. Examples include TDMS Close, Close Zip File VI, etc.
The error ring control is awesome having its parameterized input strings which supprots things like %s, %d, and %f to customize your error string. This is not supported by the error ring when you are defining the string in an external project erorr code file however, and that is a problem since you then can't localize for multi language from external files.
This idea is to add parametrized inputs to the error ring for ALL errors, custom or loaded from project resource files.
If you have a local variable and you either rename it's control/indicator, or you click it to change it to refer to a different variable, all local instances resize based on a centre justified behaviour, which can have undesireable layout issues.
For example here is a what happens when it's made longer next to the bounds of a case structure. (The Boolean is provided to show how it's aligned, and also to show it resized the case structure).
If the local variable were Left justified as a 'Write' type (expands to the right when changed) or Right justified when a 'Read' type (expands to the left when changed) it wouldn't make such a mess of things!
The Timing palatte is looking bad with all thes gaps. A simple fix would be to fill these holes with useful functions. I'm proposing 3 and attaching 2 from my re-use code. (I may re-create the third later)
Time to XL.vi (Attached): and its inverse, XL to Time.vi
12:00:00.0 AM Jan 0, 1900 is a pretty common epoch (Base Date) for external programs and converting from LabVIEW epoch shows up several times a year on the forums. and Time to excel has a few solutions to threads under its belt. Moreover for analisys against external data from other enviornments you are often using Access, Excel, Lotus... All share the same epoch (and Leap year bug) in their date/time formats. These vi.s have been pretty useful to me although the names may change to avoid (tm) infringements
Time to Time of Day.vi (Attached) has also been in my arsenal and proves both valuable and get on a few threads per year on the forum.