So I have a problem between the most efficient way to code iterative operations and the way I usually do it for readability/simplicity
Simple and clean
I imagine the last way is way less efficient due to creating a matrix then working through it again.
I'm proposing a merging of these two ideas. A compound tunnel that performs the most efficient method, but doens't mess up my diagrams with a lot of crossing wires and other hard to read messes.
Note, this will only work for commutative functions (add, subtract, and, or, xor... basically anything on the Compound Arithmetic function)
I haven't decided how the selection function should work, so I leave that to the LabVIEW UI coding experts since they've done a good job so far.
If you need to wire cross other wires it would be nice just for the optic to have the error wire always in the background of the cross. Now the wire which is connected first is in the background and all other overlay it.
I just had a case today where I had an existing wire (An array of configuration parameters) and I selected the wire and then tried "Create Sub-VI" on it. Nothing happened.
Perhaps it would be simply consistent behaviour if we then allowed creation of a simple VI with Wire Datatype in and out with input terminal connected to output terminal.
When first launching the Quick Drop tool it can take a while. This isn't a problem in itself, but the fact that you can cancel the loading or continue working in the background is. This is especially annoying if you launch it by mistake.
Not a major thing, just something that could be improved.
Say I paste a function down inside some structure, say a case structure. I wire from the input of the function back to the left hand border of the structure, which creates a tunnel with a 'broken' (dashed) wire to the function.
I would like to be able to right click on the tunnel and hit 'create control' and have it work. Although the wire is dashed, there's no ambiguity about the correct control type as it needs to be the same as the function input.
When I use event structure
and I have quite lot of cases
adding new case causes I have to connect all input and output terminals
which doesn't change in that case.
The idea to is add a functionality to wire between input and output terminal
inside the event (and case) structure to "autowire in all cases".
In example I dont need to connect the wire in all cases but I eventually need
to disconect the wire in one of them.
It is important for references and other signals which can't be unwired and left with default values .
I would love to see inner classes. Inner classes can allow for more elegant code. Sometimes you run into situations where two classes are closely tied together that they appear to be one class, but not quite the same. Inner classes can handle this situation very smoothly. Thoughts and other considerations are welcome. I didn't see it posted and have a few instances where an inner class would be beneficial. I'm not sure how hard it would be to implement such as idea, but definitely think it should be considered.
Should be able to specify tolerance instead of just upper and lower limits. This de clutters the application block diagram when you are checking for a value within certain limits.
. Upper limit becomes : x+ tolerance, Lower Limite becomes : x - tolerance when using tolerance instance of the polymorphic vi.
For even higher level functionality , specify units of tolerance : absolute, percent(1e-2), parts per million (1e-6), parts per billion (1e-9)
I have a large library of general purpose functions and I do a lot of OOP in LabVIEW, and as a result my preferred workflow involves dragging a lot of functions from the project explorer window onto the block diagram. This workflow is slowed down, however by the fact that the project explorer window is regularly hidden by other windows when I click on them.
What I would like to see is something like most development IDEs have, e.g. Visual Studio, where I can have the project explorer always visible in a fixed position on the screen. I suggest this would be an option, so would not affect those who like things the way they currently are.
I have two pre-allocated clones. I probe the same wire in both of them. I go to the probe watch window and click on the first probe.
At this point, one would expect and hope that the probe-watch window would send me to the wire corresponding to that probe. Instead, it sends me to the probe on the same wire in the other clone.
Rather than repeating the unprintable response I gave upon discovering this, I will just say, DO NOT WANT.
Currently, in Array Functions pallete, there is only empty array constant. But, isn't it possible to add constant of numeric, boolean and string arrays also? Anyway, it would be faster then to add them to block diagram, than now. Empty array constant should stay for sure - b/c it's not possible to predict all possible array types - but such common arrays will be useful. It's like in case of Silver Controls - there are already numeric and strings array (but also - why not to add boolean array there too? What was the logic behind it?).
The idea is to change Equal? function in a way, that it will be configurable, and will have one input as function "Equal To 0?". Sometimes you need to evaluate number of loops execution in While Loop (or not just it), and when you put standard Equal? function, some of wires will be not aligned in a straight line (either which is connected to Index output, or which is connected to Loop Condition), and you need to move up/down one of terminals.
So, you can see it from the attached picture.
In my opinion, the access scope warning dialog should not appear when the user modifies mandatory override settings.
Regardless of whether the access scope actually changes, a warning dialog appears, and selecting "Yes" seems to cause the IDE to mark unsaved changes for other classes in the class hierarchy chain. The warning dialog should not appear when all the user does is set the state of the two checkboxes, and to me it doesn't make sense that all of the other classes now have to be saved. (I claim some ignorance on the saving part, though - it's just my intuition.)
Does this make sense?
Hi LabVIEW Users.
LabVIEW Can print front panel. But it there is option for "All front panel" or "visible area of front panel".
One of our customer is requesting it is very convenient if user can select the area of interest and print the area.
What do you think?
If you have made a custom run-time shortcut menu and saved it as part of the control (always necessary for applications due to this issue), it is currently way too easy to lose that menu. If you replace the control, even though it is with the same type of control, the menu is silently lost. So if you have made right-click shortcut functionality, the user will no longer be able to call that funcitonality.
a. As a minimum you should be warned that the control you are about to replace has an embedded shortcut menu.
b. The warning could give you the option to copy the menu to the new control (OK set as default), or
c. The new control could automatically inherit the original's shortcut menu
d. -Alternatively only if of the exact same type (if you for example replace a modern styled listbox with a system style listbox).
I would prefer alternative b, as it would draw the developer's attention to the possible issue of the embedded menu (perhaps it is *not* wanted anymore, perhaps it is...), but make it quick and easy to choose to keep the menu (most frequent I would guess).
On all LabVIEW version, we can use Formula node to evaluate mathematical formulas.
We can define input and output variable freely and calculate using some variety of formula.
But when we use undefined variable as output, can execute VIs with no errors.
We think it is a problem because when programmer makes a typo, they cannot notice the mistake.
When undefined variable is used as output variable, LabVIEW should forbid to run VI.
It would be nice, if the Search Result window for the VI items (property nodes, VIs, indicators/controls) would be possible to put on the top view. Because, if there are many VIs opened, and user double-clicks on the item in the Search Result view window, focus is switched to the VI, which contains found item; and Search Result window is folded to task bar. It's quite annoying, especially when you have many items in the list, and you need to find some in some particular place in the code - you need to double click, verify searched item, find Search Result window in the list of opened VIs in the task bar tray, open it, and select another found item, etc.
In case, when Search Result window can be pinned to top view, it would be very user-friendly - user double clicks on the found items, he sees, where it is located on the block diagram, but he also sees at the same time all others found items, and he can directly go to the next found item in the list.
When creating a state machine it's often handy to use an enum that lists all your states.
You then take that enum and make it a type def so that if/when you update the enum (to add or remove a state) throughout the states, all instances of the enum get updated.
But the thing is, now this potentially simple state machine VI requires this secondary type def file. No other VIs would need access to this type def so making it a seperate file just shouldn't be necessary.
Have the quickdrop catch the keyboard shorcut keypresses while it is loading the list.
At the moment my VIs keep trying to run becuase I've pressed Ctrl+R quicker that quickdrop has loaded the list in.