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!
Loops that generate arrays with each iteration sometimes need to be appended or concatenated together and retain the same number of dimensions when brought out from the loop. Currently this can be done using a shift register along with Build Array, Insert into Array or Replace Array Subset for example . Such wiring could be eliminated and diagram space saved if the generated arrays could simply be wired to the loop output border and an option to Auto-Append or Auto-Concatenate provided. This would be similar to the existing Enable Indexing option except that the array dimensionality would remain the same. This would be useful for example in while loops that are extracting currently available data from an acquisition process where one wants to build up one array containing all the final data.
It would be nice if under options that highlight execution speed for debugging was configurable. It could also be not an option but placed just next to the light bulb icon. With experience we become able to folloe the code much faster and having 2 or 3 speeds of highlight execution could save some waiting time. I know that there are many debugging options already but sometines the old light bulb is easiest.
The context help that appears when you hover the wiring tool over the various inputs and outputs of a subvi or function should display the data type required by the vi/function.
That way we would not need to guess the datatype to get rid of the coersion dots. Currently I end of making a constant from the terminal and then hovering over that to see what data type it is. Since the IDE knows the data type to create the constant, there is no reason it cannot be appended to the help description.
It would be nice to have bookmarks (possibly based within the project) so that you could quickly jump to certain areas of your code that has to be modified or reviewed frequently. Obviously, things like state machines are self documenting, but it would still be great if you could quick jump to certain areas. Being project based, you could also jump to any bookmark in a subvi.
If you want to fork a VI (start a parallel running VI), you have to load the VI reference, use the set control elements values method to initialize the controls of the VI, and than start it with the run VI method without waiting to finish. Quite complicate, if you ask me.
It would be cool, if there would be a fork VI method, which you call inside the VI you want to fork. The method copies the VI to a new place in memory including its actual running state. The new copy just goes on as it would without the fork, while the calling VI would get back the values of the ouputs, which they have at the moment of the execution of the fork method. Of course this does only work with reentrant VIs.
I can think of a LOT of applications which can use this!
here are my ideas about expanding the functionality of Event structures:
1.) Make it possibly to dynamically register references like tcp/ip, visa, queues, etc. for Event structures. Possible events are "new bytes at tcp/ip", "new bytes at seriel port", or "connection closed". In the case of queues it could be the same function as "Dequeue Element" or "Queue referenced closed". There are certainly a lot more of similar references, which could be registered for catching events, which up to now we have to poll regularly or use other event functions (as in the case of visa -> new bytes at seriel port). Benefits are: no more regular polling of changes, better integration of several functions (like using queues to communicate with GUIs instead of dynamic user events), and in my opinion just better code.
2.) Allow for better handling of the event buffer for fired events of Event structures. I would like to have a feature to list and remove item(s) from the buffer of fired events. Otherwise you have always to write some code to catch events, you d'ont want just to execute or you want to remove, because you just pressed the stop button. This could be realised by new leftside and rightside nodes inside the event structure.
3.) It should be possible to configure events to run first (placing the fired event as the next event to execute like the queue function "Enqueue Element At Opposite End"). Or add priority to events.
4.) Make it possible to add conditions to events, e.g. only allow event foo, if condition bar is True. I'm not sure, how this should look like. Some static conditions could be "key pressed == a" coupled with "key down" event. Conditions could also be coupled to controls via registering the control reference like dynamic events. If my 1st idea is realized, a condition could also be something like "tcp/ip connection is online". If a condition is not fullfilled, than either nothing happens or there is a leftside node, which indicates the status of the condition. This should be configurable.
Be able to open the block diagram with a hot key or right click menu even when you use custom menu on user interface. This option should be available for debugging in development environment and when debugging an executable with debugging enabled.