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!
The current error-case only allows two states, when the error-cluster is wired: "No error" or "Error".
My suggestion is, to allow any number of cases which depends on manually defined error-codes (see attached picture). The error-case must be enhanced so that error codes can be treated separately in individial cases.
Previouslyto handlea specific errorcode, first thecode must beread from theerror clusterand than be wired tothecase.This is to be omitted.
Include a python script node that you can create and run python code, functioning exactly as the c script node does but using the python language, there is a growing support for python in the scientific community (I know of a good few university lecturers and professors who use python), and it is a great programming language for beginner programmers such as university students.
This could be included as a feature in labview itself or be a labview addon.
Working in LV2011 right now, so it might have been changed, but here goes:
A wire gets information from the control or outgoing indicator of a sub-vi it's connected to. Looking at the wire, the Help windows shows this information e.g. "DataValues". When activating Label on the wire, wouldn't it be great if it had this info as a default label?
Wires should have the Data type of wire as default label.
If you bring up the contextual menu on a control, you can go to the Find menu item and search for things related to that item. Like, if there is at least one local variable, you can find local variables for that control by picking Local Variables.
This also works for finding the control's presence on the other side (front panel vs back panel), and Property Nodes and References and perhaps some other things. But, it doesn't let you find event handlers for that control.
It woud be very nice to be able to find the control's event handlers through this submenu.
I often use the tab controls to get more front panel real estate for applications where many parameters have to be accesible rapidly. I use the tab control to group my controls according to their fonctionnality. It would be desirable to have the controls from each tabs available as a single cluster in order to pass them to subVI. Of course, the controls from each tab can be grouped using a cluster on the front panel but this leeds to an extra border on each tab (the cluster border). Also, it remains that if one wants to pass all parameters to subVIs, he has to pass the many clusters to the subVI or bundle the clusters to one new cluster then pass this cluster to the subVI. I thought of using a tab control in a cluster but it seems that clusters have a problem dealing with tab control.
My idea would be to have a cluster type which looks and works like a tab control, but instead, each tab would be a sub-cluster of the Tabbed cluster.
This would simplify the development of complex parameter intensive user interfaces and remove lots of control terminals in the block diagram.
Quite often I wish to display or hide one control based on the value of another on my GUI, or switch some other property of a control. Also often I use arrays of clusters to handily provide multiple identical control sets- e.g. where I need an identical set of controls for each of a number of I/O channels. This is a very neat way of reproducing the control sets and it's easy to deal with the resulting array on the block diagram. The problem comes when I want to select different properties on the controls on each channel- at the moment I have to either split the cluster array into separate clusters for display (a lot of work, and more messy code) or work around it in another less than satisfactory manor (e.g. hidden tabs to control visibility).
So the suggestion is- allow arrays to have 'pre element' properties, so I can have the advantages of an array of controls with the flexibility to set the properties of each element individually.
I realise there are memory and performance implications here, so there would need to be a special kind of array or an array setting to designate an array as such.
Type def with an additional Super Strict mode in which case even the actual values are copied across instances. Changing the value in the super strict type def (for example an integet type def being changed from 0 to 1) cause all values to be changed. It would act as a linked constant that auto-updates all instances. Maybe in this mode you can only create it as a constant or greyed-out control.
If I point to a line, it has a title eminating from the source, as viewed in the context menu. If I right-click the line and select "Visible/Label", I would like the line title to be copied to the line, instead of a blank flashing cursor requiring you to enter what is already evident from the context menu.
I find myself going throught the same mouse stokes over and over to make sure I don't leave DVR IPE errors unhandled. Lots of Merge Errors everywhere. It seems unessecarily tedious. My suggestion would be to do one or more of the following
1. An error terminal on the front of the De-ref and Ref icons that performs a merge error
2. A conditional error terminal that halts execution of the whole IPE for incomming errors
3. A conditonal DVR terminal on the De-ref that does not execute the IPE if a 1556 Error is thrown by the incoming DVR. Also would just pass one 1556 error out of the IPE since they are always both thrown with a bad DVR.
A Server/webpage hosted by NI which allows a user to upload a VI from their local machine or URL from the forums.
The Server then Saves the VI for the users desired previous version and provides a download link for the new file. This would allow users of older versions of labview access to more resources from the forums and give the community a rest from saving projects to previous versions for other members.
When building applications that use many different toolkits and classes, my build times can skyrocket. It's frustrating that while i'm waiting for my application to be built LabVIEW is useless for development. This is especially aggravating when I find a bug that takes 20 seconds to fix, but then building the application takes another 20 min. To address this issue I propose that there be an option to launch the build process in a separate process from the IDE so that I can continue working with my code in the meantime. This could mirror the FPGA compilation process where it used to block development but now is separated out.
Why optional though? For smaller applications the build process is very quick so if you can live with it I wouldn't want to always introduce the extra overhead that I assume would be necessary to lauch the build as a separate process.
It is sometimes verry frustrating to replace elements on the blockdiagram or the frontpanel. I have to navigate through many menues. It would be better to have the recenltly used elements in a list, so that i can use them verry fast.
So here my suggetion: extend the context menue on replace and insert by the point "last used ..."