VI Analyzer complains if you use the Build Array function or Concatenate Strings function in a loop because these functions negatively affect memory and processor usage in a loop. Using both of these functions in loops bring certain advantages to code. Primarily, you can dynamically build strings or arrays, which is helpful because sometimes it is hard (if not impossible) to know how big a string or array is going to be when a loop is run.
The first image below shows a loop with both of these functions that will cause a memory leak as the loop is run.
Build Array and Concatenate String in Loop - Will Cause Memory Leak
I got to wondering... Is there a way to dynamically build arrays and strings in a loop that will not cause a memory leak? In my limited testing, it looks like the code in the second image performs the same function as the build array and concatenate strings functions, but without the poor memory performance. I can run the code below for long periods of time and not have a memory leak. The instant I switch over to the case to use Build Array and Concatenate Strings the code beings to chew up memory. My idea is this: Replace the internals of the Build Array and Concatenate Strings functions with the code boxed in red in the image below. It is preferable that the code below gets contained in its own function because it clutters up any diagram with the extra nodes.
If putting this code into the Build Array and Concatenate Strings functions is technically possible, it will allow people to dynamically build arrays and strings in loops without the costly memory performance. One note is that the code that builds an array in the second image is scalable, but the code that builds a string is not scalable. If this is implemented, the code to build a string should be scalable, but based on the code below that does not cause a memory leak.
Replace Build Array and Concatenate Strings with the Code Boxed in Red
Now I come up with a thing I requested 2003....
I would like have a statusbar for some UI. This line attached to bottom of the window, to show up status informations no matter where the user scrolled the frontpanel.
The picture should give a coarse impression (I didn't invest a lot time in editing the picture....)
I think it can already be done with activeX , a bad workaround is moving some indicators with properties (performance with overlayed indicators and flicker)
Currently you only have the titelbar...
I would like to show things like current test runtime, active comports, warnings etc...
Anyone ever run a vi when you left a modal subvi opened burried somewhere in the huge pile of opened windows? Wors yet the moday subvi had hidden toolbar and shortcuts disabled (most likely since modals are used as gui vi and you dont expose this toolbar to users). Now if you dont have your own vi task manager your are most likely stuck and have to force quit labview. Cant there be an option to wanr me before this situation occurs. AGAIN THIS WOULD BE AN OPTION, if you dont like it turn it off. The simple function when you click the run button, it world check the current sub-vi in memory and see if they are modal if so, they would ask if you want to close the modal subvis, ignore or cancel.
I use labview all day everyday and find myself in this situation every so often - but maybe this is just me.
Yes I know I can make my own vi to do this but it would be easier if it was already in labview for each future version.
I would like to have some kind of compiler optimalisation options.
The save time is often to long, Editing is annoying
Editing in LV2010 often halts for 10-20 seconds because it it recompiling the code for some reason.
If we had some option to turn off "advanced optimalisation" things might go fluently, like in the old days.
Often I need to know if a user selected a tool in graph palette, but there is no event for it.
I can handle mouse click events, but when user selects one of the zoom tools, the popup that shows zoom tools doesn't generate mouse click events for the graph at all.
I guess the popup is not considered to be a part of the graph or it is rendered outside the graphs boundaries.
So there is no way to register the fact that user selected one of the zoom tools other then poll for it in a loop. No good. I don't like doing that.
Currently LabVIEW settings like
and auto save information like
last projects and
are saved in LabVIEW.ini
Please split this up in two files (maybe LabVIEW.ini and AutoSave.ini). This helps to check for changes in the settings. I suppose to save the auto save information per user. (See this idea.)
The templates for XControl properties are quite simple, the standerd input and output controls and the boolean Value control. Nine out of ten times however I find myself doing the same action for every property I create, namely inserting a 'bundle by name' node between Display state in and out, selecting the correct element, change the Value control to the correct datatype and align and wire unbundle node to the value control for a write property and doing something similar with an unbundle for the read property.
Wouldn't it be nice to have the template already have the bundle/unbundle node already inserted and aligned?
Or, even better, wouldn't it be very nice if the "Create Property" dialog would optionally let us select an element from the Display State cluster and just create the code for us.. Look ma, no programming!
Problem - Bundle by name causes unnecessary wire bends because the type specifier is on the top.
Make the type specifier terminal on the upper left and the output on the upper right. Also right clicking on an item will allow you to select "Change to Read" or "Change to Write".
Would look something like the following.
A while back, Dany Allard suggested merge and diff tools for projects and libraries. I have a request that is similar, but more specific:
When opening a project, if for various reasons LabVIEW is unable to locate dependencies of a build specification, it would be truly helpful if the user was prompted to locate said dependencies. As it stands, by my observation LabVIEW silently omits missing build spec dependencies - this can be frustrating and dangerous.
Here's some context: I have lots of projects with 5+ build specifications. When I move directories, files, or even change LabVIEW versions, my build specifications stealthily fall apart, sometimes very subtly. Often I don't realize that my build spec is broken until I attempt to build, only to realize that it's a hollow placeholder in my project file. The most insidious case is when the application builds successfully, but is missing dynamic VIs, etc. This omission might go completely unnoticed without rigorous testing. LabVIEW should, in my opinion, give the user some indication that the build specification is missing dependencies or is "broken."
One hypothetical way to indicate this status might be to list the build spec in red font within Project Explorer, and have dependencies listed in dimmed font within respective build spec dialogs. There ought to be a "resolve conflicts" button in the build spec dialog; Perhaps this functionality could be integrated in the main conflict resolution dialog somehow.
Furthermore, there ought to be an option to import build specs from other projects. (Okay, maybe this should be a separate request) When importing, the aforementioned conflict resolution process should be leveraged to make the import proceed smoothly.
Has this already been requested? Thanks for listening.
When using the Sahred variable (SV) with "Bind to source", the SV uses the datatype of its source.
If you are using the datatype "double" you can see all fractional digits.
That doesn't make sense all the time - e.g. if you want to display temperature values.
Our idea is to give the user the opportunity of controlling the number of digit of precision.
Add support for array calculations in Formula Node.
Seems not that much of an effort, since LabVIEW is very array based.
Now only scalars can be dealt with.
(Mathscript is an add-on that can do this, however I would like to see this as base functionality).
Regarding VISION IMAQ Overlay functions:
Currently it is only possible to select the color of points, lines or figures. It would be fine if it would be possible to select:
- line width
- line/figure pattern
The 'Prompt User for Input' express VI (LabVIEW 2010) conveniently sets up the return and escape keys as shortcut keys for the OK and Cancel buttons if you want a 2-button dialog, but if you only want one button (OK), it doesn't get assigned a shortcut key, so you end up having to customize every such express VI . Surely it makes sense to retain the use of the return key to complete data entry in a 1 button dialog?
First of all, this is not a duplicate of this, by Case Selector I mean Case Selector and not the label. It may well be a duplicate of something else...
I doubt that I am the only one who uses multiple conditions. This usually leads to nested Case structures, building boolean arrays, or obfuscated mapping functions between the conditions and some enum. Other times, the case structure is half-of-a-screen wide just to accommodate the values associated with the different cases. I would suggest that NI add multiple Case Selectors to the Case structure. Additional selectors could be pulled down like a shift register, or added via a right-click menu. Either way, I don't think they should be allowed to cross, so the top-down selectors map to left-right selector labels. There could be a reasonable limit to the number.
The ability to right-click an item in the project window and select "apply library icon" to just that particular item. This feature would be helpful to people who manually modify the icons of items in the library. One would do this to have smaller footprint icons per example. If this person goes to the library or class properties and selects "Apply Icon To VIs" then all manual modifications get overridden.
This functionality can also be attained by adding an option to avoid further automatic icon updates on individual items.
An acronym for one of my favorite Spolskyisms. Great article, read it.
When you discover what you consider to be a bug in LabVIEW's IDE or language, it's a difficult process to report the bug and track the bug's status as new LabVIEW editions debut. This idea addresses the transparency and facilitation of this process, and is meant to appeal to both those who create LabVIEW and those who use LabVIEW.
Problems with Current Issue Tracking Platform
"Platform" is a generous term for the current reporting and tracking process:
Comparing LabVIEW Issue Tracking and Feature Tracking Platforms
Before the Idea Exchange, there was the Product Suggestion Center (PSC). What's that, you ask? It's a hole in the internet you threw your good Ideas into. The Idea Exchange revolutionized Feature Suggestions by introducing a platform that allows an unprecedented level of public brainstorming and symbiotic discussions between R&D and customers. Further, we can watch Ideas flow from inception to implementation.
I want to see an analogue for Issue Tracking.
A web-based platform with the following capabilities:
(Picture first spotted on Breakpoint)
Generally: you are voting for a platform that eases the burden of Issue Reporting, additionally offering a means of Issue Tracking.
My suggestions are neither concrete nor comprehensive: please voice further suggestions, requirements, or criticisms in the Comments Section!