For the reasons eloquently stated here:
defering Panel updates is both useful and a bit tedious. You have to fetch the Panel reference, and while you are doing your presumably time-consuming operation, the entire panel is stuck. I suggest that Deferring Updates should be a property of an individual object and not just the entire panel. Wrap your operation with a pair of property nodes to start and stop deferring and you are all set.
There should be an option to choose which version of LabVIEW want to
build your application, so would only be loading the vi's corresponding to avoid
version compatibility problems.
Further updates NI LabVIEW should create, so each developer would install
the latest version and any patches that were wanted to use.
If I owned the LabVIEW 2010 and would want to work with 8.6 would install
a patch for this version and not like today having to install the LabVIEW 8.6 whole
Currently errors can be connected to the case structure and appropriate case can be executed.
Many languages do error handling with try catch type of code, I think a structure like it would be much more efficient than propagating errors.
normally code will start execution from code case, if any error occurs then it will immidiately switch to error case, and irrespective of error occurance finalyy case would be executed in the end.
Sometimes you want to use local variables and sometimes these were accessed in one state twice (e.g. read it and after that reset it).
To follow the data flow paradigm one can:
a) create a new state called "reset XY variable"
b) place a sequence around it and wire an error code through it
c) use the new error in connector at the local variable
(a) is not always IMHO good style as the state machine gets bigger and bigger
(b) is not always good to read
(c) may be nice...no error handling is needed so "error in" may be enough
(not really related to this idea)
Deferring panel updates is a tedious procedure, requiring a panel reference (not intuitive to get!) and a couple of property nodes. However, deferring panel updates is sometimes very important. For example when coloring the fields of a large table according to their values, a serious performance impact is encountered unless we defer panel updates. There are many other situations where panel updates should be suspended temporarily, especially if property nodes are used in a tight loop.
My suggestions is to make flat sequences a little bit more useful by adding a new function to the right-click menu of each frame: "Defer Panel Updates". Now a new connector will appear on the frame that accepts a panel reference. If left unwired, this applies to the panel of the current VI, but we can wire a reference to any panel we desire (useful for subVIs). There should be a visual indication indicating that updates are deferred, e.g. a slightly different background pattern (e.g. faint checkerboard or similar). Note that this idea does not clutter the palettes with a new structure, but simply extends the functionality of existing elements. Let's put those sequences to some good use!
During execution of such a frame, the panel updates are deferred and automatically enabled again once the frame ends. The configuration should be "per frame" of a multi-frame flat sequence.
This has many advantages over the current situation:
There is a coercion dot here. Anyone see it?!?! Can the color please be changed to something else if the terminal is pink? Especially if it's wired into a bundle.
To check a string for (white) spaces we can use the ‘\’ Codes Display mode for string Control/Indicator/Constant.
With small pieces of text, it is easy to find your way through the text. However, when the piece of text gets larger it is difficult to navigate through the text.
It would be easier if a ‘\n’ and a ‘\r’ character performs an actual <new line> besides displaying a \ code.
It should be an option or an extra mode. I called it ‘\+’ mode.
The name of this VI is a little misleading because the number is rounded to an integer before it is converted to a string. I think a name like 'Number to Integer String,' or 'Integer Number to String' would be more appropriate. I guess the 'Decimal' is just meant to indicate the fact that it is expecting a base 10 number, but I associate decimal with the data types double and float. For those who wish to convert a double/float number to a string (without rounding to an integer first) the 'Number to Fractional String' is the correct VI.
Very often during debugging, you have probes placed all over the block diagram checking wire contents. It would be really convenient if during Run Time we could place more Free Labels, as this would allow a developer to place comments during debugging/running, otherwise you have to stop the VI and then try and remember all the comments (assuming you have not written them down).
Note: I do not know of any other languages that allow you to do this, as you are essentially changing the source on the fly, so I don't think this is a trivial change! (But LabVIEW is better than other languages anyway )
Is there any tool to compare Multiple VIs (more than two i.e. about twenty) at a same time.How can I compare more than two VIs at the same time. I am an Lab Engineer I have to check assignments submitted by students and I want to know how many of them are copied from each other. Labview compare VI can only compare two VI at a time while I want to check about 30 VIs at same time.
The connectors hi(x) & lo(x) on the primitives for "Split Number" & "Join Numbers" do not line up with multi-connector primitives (Index Array, Build Array, Format, Format into String, Scan from String, etc). See below:
When you're running an executable and it freezes, especially in development mode, you have to shut down the entire LabVIEW environment. It would be nice if there was a way to stop just the executing VI.
It would be useful to be able to name (either automatically or manually) the sliders of a Slide control (or needles of a Meter or Gauge). The use-case I have is for saving a configuration file (currently requiring typecast to/from a cluster with names), but it may also be useful to be able to Unbundle By Name. I found this post in the LabVIEW forums showing this idea has been talked about in the past also. Here's an image from that post:
A related idea would be the ability to replace the control with a Cluster control, and vice-versa. Currently, this requires creating a typedef and manually recreating the cluster.
Similar to specifying the Access Scope for multiple VIs in a library by grouping them in a Virtual Folder and setting the Access Scope of the folder, I'd like to specify locking or password protection for multiple VIs in a LabVIEW library by enabling that on the owning Virtual Folder. The dialog would be the same as if you were setting the Protection on the entire library from the Properties menu.
The IMAQ VIs are great for recognizing barcodes that are scanned.
On the flip side, there's not a really portable way to generate a barcode in LabVIEW (without having to install a barcode font). The nicest approach would be to have a custom control that has string datatype, and then on the front panel, the string gets displayed as a barcode!
Other approaches could involve using a picture control or something as well.
I ask for a general rework for selecting controls and indicators in a menu.
There are several locations where you select a front panel element. And it is done in several ways.
What I dislike is ordered by adding order. The other two depend on the front panel (and on my brain). I would like to choose the sorting and maybe some filtering myself. I do not know how it could look but some ideas will probably come from the community.
How about make a new array function that can insert items at the beginning efficiently?
My team has been working with LVMerge.exe for a while. I wish to disable "auto-resolve" as a default, instead of unchecking it after loading. Disabling block diagram cosmetic changes would also be nice. Some method to modify these settings, so that on the next VI load, the modified settings would be used instead. My original post is here.
Give the user the ability to save the LabVIEW source files as un-completed, version independent files capable of being imported to any version of LabVIEW. Of course, newer features won't be recognized, but the vast majority of the code should be useable.