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!
I'd like to see something like a conditional disable structure that would be sensitive to fields in an .ini file at runtime, not compile time.
My problem is that I have an application that can access many different third party cameras. For this application to work every VI that accesses a camera specific .dll function must have assess to that .dll or I get a broken VI. When I compile the VI I have access to these .dlls but when I build an application.exe and distribute it I only want to distribute the .dlls for one of the cameras. If I could distribute a .ini file with the application.exe that indicated which camera the drivers were installed for then the application would disable the code for all the other cameras and the VI would not break.
I need a vi which will convert PNG file to GIF file. i could find a vi which is not in palette, do this. But the output GIF file is in uncompressed format. So the size of the file is very large. And also it is not working when i build the application as EXE.
It will be really helpful for me if this feature is included in the next release of LV.
It would be beneficial if nodes had the ability to retain data from their previous execution. Along with "Use Default If Unwired" it would save memory allocation and coding time if there was a "Use Current Value If Unwired" selection which would retain the node's value and pass the last executed value.
This figure illustrates one application where "Use Current Value If Unwired" would save memory and increase performance instead of using multiple property nodes or local variables for retaining the output data. It would also eliminate extra wiring in every case this node is not used.
in LV2009 a new set of VIs have been published for working with configuration VIs. They are now part of config.lvlib. But some VIs of config.lvlib are marked private, therefore I cannot use these VIs as Sub-VIs, if the calling VI is not part of config.lvlib. This is bad (at least for me), since I have written some tools to load a configuration directly from a string and not from a file. To do this in LV2009, I need these private VIs, which I cannot use without changing config.lvlib.
Therefore I suggest to make all VIs of config.lvlib public. In fact, is there a good reason, why these are private in the first place?
When developing LabVIEW automation tools, I miss a way to list the controls connected to a VI's connector pane. That would make it possible for the user to better select which controls to set before calling a VI (dynamic VI call).
An "IsOnConnector" property on a control reference would be very useful. Or better; a property returning an enum with one of the four values: "NotConnected", "Optional", "Recommended" and "Required".
Another solution could be a property like the Controls property on a Panel reference, but only listing the controls on the connector.
When browsing data in MAX (Historical Data Viewer) via the cursors function the time shell be added although after an full minute, hour or day. At the moment when incrementing from 19:59:59 by one second the time will be 19:59:00. Shouldn't the expected result be 20:00:00?
Via the Historical Data Viewer it is possible to export the citadel data to text (compare screenshot). In many cases it is necessary to export only the real datapoints without interpolation (like the read trace VI supports) to avoid an incorrect representation of the recorded data.
In the LabVIEW development environment it is possible to separate the shared variables via virtual folders. In cases with more than 100 variables it is very difficult to keep a structure at runtime. Therefore it would be a great improvement for us to implement a new hierarchical level (name of the virtual folder) to ensure a well-arranged structure also in the runtime. This structure should be kept in the Shared Variable Engine and also in the Citadel Database.
I would like to see
and option to use our development system that is enabled by a hardware key.
That way, you can put it on any machine you want for development without
worrying about licensing. A lot of LabVIEW applications are one of a kind
systems, complex systems. The programmer does not always have time to add a lot
of code for all the errors you can encounter. With the debugging tools in the
development system, debugging would be much easier than trying to debug a built
application. This would enable the owner of the software to load his system on
a target machine and when he is done developing the application, he can build
it as normal. It would be desirable to also be able to use you key for
connecting to a remote site, using remote desktop, pachyderm, etc. This would
greatly help for field support of application. It would also make it easier to support previous versions of LabVIEW, as the project and software would be on the target machine. Changes that could take days could now be done in minutes.
If you use the NI proposed way of creating Sub-VIs for functions (which is good), debugging soon becomes a nightmare with every VI opening two windows, one of which is mostly not needed (the front panel). It would be great if LV gave us an option saying "Do not open front panels when debugging", which would only open the block diagram. Instead of the front panel you could only offer a list of all input/output controls (and maybe their values), and you could put this list in the same window for all open VIs (in some organized way - maybe similar to probe window). That way all front panels would only take up one window instead of many.
I think there should be a way to reinitialize a stacked shift register to the originally initialized value so you can clear out the contents of every iteration all at once. For example, the code below, implemented with 4 individual shift registers:
Could be implemented with 1 stacked shift register with a reinitialize terminal:
I would like the maximize button removed from the FP & especially the BD. I typically work with many VIs open at once and I find it very annoying to open a subVI that consumes my entire desktop with a lot of white space. This is true of the FP and the BD.
Lets be real - your code is not that important. The one except might be the main GUI.
At least numeric controls and string controls loose focus after pressing enter. This is especially unpractically when navigating by key. The focus should be held on all controls as it is on boolean controls.
Classes in LabVIEW are a great step over (and finally, with LV 2009 them start to work...) but there are still two 'holes'
It would be great to have the possibility to define abstract methods and interfaces. Now I'm forcing an error into the error out indicator to notify the usage of a method not yet defined but it would be better to make the compiler to recognize the usage of abstract methods during the design time. One way to define abstract methods could be the introduction of a new entry in the 'class menu' and allowing to define them just in term of front panel (block diagram not available).
An object is duplicated on each node, so is not easy to work into parralel loops on the same instance. To use the same instance I have used references, but it is not so easy to use (not as the 'normal' wires) and it hasn't the same performance (working with reference is heavier than working with instances). It would be great to introduce a mechanism that implements the convertion from instance to object, something likes a standard 'getReference' and 'getInstance'.