Currently when a vi is called asynchronously, it will live - even when the calling VI stops. This may cause problems in some cases - for example, code that uses the "first call" function. During development, it is not unusual to have a VI stop inadvertantly without proper cleanup. With Asynchronous VIs running in the background, you must shutdown and restart your project to clear out these Asynch VIs. It would be nice to have an option on the OpenVI function that caused the Asynch VIs to abort in the event that the calling VI shuts down inadvertantly.
1) I would like to see the "radix" visible in the probes for "Numeric probes" and "hexadecimal/coded display" for "string" probes
2) A shortcut to make the selected "control label" in the front panel or block diagram to make it BOLD. (CTRL+SHIFT+B) or anything equivalent
So I was looking at the idea submitted "Remove Common Error Functionality From Set/Unset Busy Cursor" and I came up with a more useful, and more generic way of dealing with that problem, and the problem of 'anchoring' code for flow-of-control in general.
I too use flat sequence structures to force flow-of-control, and there should be a better way. There is.
Suppose we simply add 'ignore error' functionality to the error-in/error-out terminals? In that manner you could create a vi just the way that you do now, with error in/out, but by right-clicking on error-in and selecting 'ignore error' the following would happen:
1. The VI would ignore a pre-existing error. It would run as if no error was present on error-in.
2. The error-in terminal would change color (or shape, or size, or relgion) so that it was visually obvious that the 'ignore error' functionality was enabled.
3. The error code passed to the VI, although ignored within the VI, would still be passed thru to error-out.
4. If the VI that was called with 'ignore error' generated an error, that error would still be added to the error codes output.
This hasTWO major benefits: (1) it provides a super simple way to create VI's that need to execute in order but don't need/want error functionality, without requiring the user to add unnecessary objects (like flat sequences) or write special code to use it; and (2) it allows you to write routines that should run regardless of whether an error is present or not, but still allows them to post an (additional) error if they need to.
If I've just wasted time digging through the ridiculous class selection menu, why do I have to waste more going over all the less specific properties?
It is particularly painful when having to scroll to items off-screen, and do it multiple times for nested options.
Hide the higher level stuff! Put it in a menu with a better name than I could come up with or at least hide it with an expandable arrow.
These menus need way more improvement than this, but for a step-1 this is easy to implement, I hope.
I would like a better way to clear the list of recent files and recent projects in LabView. It is often disireable to clear the history when changing to a different project or a different user. Currently the user must close LV, edit the .ini file and restart LV. I would like to see menu selections added to allow the list of recent files and/or recent projects to be cleared.
The mechanism of "system controls or indicators" is very good because you can build User interfaces with an OS like look !
The problem is that many properties of these controls and indicators are no more updatable.
It would be nice if some properties could be changed ... like the colors properties ....
This could be helpfull when you want to highlight an error or a warning ...
How many times i made the same error ... modifying the backgound color of a system control !
And then i had to replace my controls and indicators by classic,modern or silver one ... my HMI get then a very bad look !
The minimum to do would be to hide the unupdatable properties from the properties lists.
Thanks for your help.
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.
I'd like to suggest some improvements to the run-time menu editor dialog: (This is found under Edit->Run-Time Menu...)
1. Allow the window to be resizable. (Scroll bars are no fun)
2. When using source control (Perforce in my case), prompt the user to check out the .rtm file upon the first edit. (Same behavior as when editing VIs) At present, if I forget to check out the menu file I get a very ugly dialog followed by an "Emergency Backup Destination" prompt. [insert muttering of naughty words]
I'm then faced with two choices: Either I can save an "emergency backup," as the prompt refers to it, or lose all of my changes and edit my menu all over again.
3. The manner in which the tree manipulation works seems kind of wonky to me. I've been using it for a long time, but I'm getting to the point where I stop and ask, "Why does it do that?" For instance:
Let's say I select the root node of my "Edit" menu which has several items under it, and I've got that menu open. If I press the yellow, down arrow, the whole Edit menu relocates itself under my File menu. The file menu is above the Edit menu! Why does pressing "down" move the menu up? Intuitively, I'd expect the entire Edit menu to move as a unit and appear after my View menu, exactly as it would if the whole "Edit" subtree was closed. (This is hard to explain and I understand if my explanation is likely confusing.)
4. When dragging and dropping tree nodes, there's no visual cue as to where the item will land. You start dragging the node, mouse over the general area and cross your fingers. Alternatively, you can eschew dragging and dropping altogether and opt for the yellow arrows of wonkiness. Okay, in fairness the arrows are usually alright.
5. I would really like to see Edit->Undo and Edit-Redo on this editor dialog. Having to revert entirely and reopen the file can be frustrating. Mistakes happen often, especially when dragging and dropping.
6. This is less important to me than the other suggestions, but... is there any reason why the menu files couldn't be encoded in XML? Right now they're not very text editor friendly.
Of course, as I offer these suggestions I intend no disrespect toward whomever developed the dialog - I'm simply perceiving room for improvement.
Thanks very much,
When a Preview or Dequeue has an incoming error, it return the default value of the data type. However, I think it could be useful for the Obtain Queue node to store the value of the data type that was passed in so that Preview/Dequeue can return that value on error. This shouldn't be a big complication to implement, and worst case it adds a memory overhead of sizeof(type).
Unless developers wired in a populated instance of a datatype, this shouldn't break previous code which depends on the default value of the data type in error circumstances.
There seems to be a control missing in LabVIEW: an intensity plot that will accept data that has been sampled at a variable rate.
It should be possible to specify the time stamps of each block in the plot (like with the XY Graph) so that you can present such data without having to resample it at a fixed rate.
Being able to box things in w/o affecting the compilation of the program would make code clearer.
Using sequence boxes is not causing any problems for me, but it would be nice to have a proper structure.
LabVIEW has a success story due to it's ability to program graphically. But the new LVOOP features still lacks the graphical touch. On the other hand, the text based SW is catching up with graphical modelling concepts as uml.
So instead of a simple config editor to set the inheritance, I request to have this completly graphical.
It's THE main feature of LabVIEW to do things graphically, so why fall behind this standard? No, not this tree control, but draw a wire to the parent, uml is already showing the way.
I was quite surprised that no one wrote a suggestion about this yet, at least I didn't find after doing a search.
Sometimes, when Highlight Execution is on, you need to see a portion of the code that is not in the screen. Doing a scroll to see the desired code, part of the code being showed goes away, with the values shown by the Highlight Execution. If you bring back that portion of the code that was on the screen originally, the Highlight Execution values will not be there. You need to wait until next turn to see new values, or put probes in the wires to see then right away. Sometimes we need to see the FP or put any other screen over the BD. The result is the same, the Highlight Execution values will be gone.
The idea is to have an option to make the Highlight Execution values stick until you turn the Highlight Execution off.
Another interesting idea is to do implement the idea above and add a button to clear the Highlight Execution values anytime you want. Then the values could remain even after the execution being stopped. The advantage of this idea is that you will be able to edit the code with the values of the last execution on. May look messy, but you just need to press the clear button and all values will be removed, not a problem. With this concept it will be easy to save a screen (print screen) with Highlight Execution values on. Probably this also reduce the amount of probes needed in a daily basis.
This is more of a bug report than an idea suggestion (although the boundary between both is sometimes tenuous).
When creating a Formula Node input or output variable, the name of a control or indicator created by Right-clicking the terminal is "input variable" or "output variable":
It should be named after the variable it is connected to. In the example above, I would expect "delta".
Shouldn't be difficult to do, the Mathscript node does things right:
PS: don't tell me I don't need to declare the output variables in the formula node. I know. I just created the latter for debugging purpose, which reminded me to post this overdue bug report.
OK, I've been working with some reformed txt programmers. They like to decorate their vi names. i.e "Funct-Do-Action-to-Gizsmo.vi" I've just about convinced them that the fully qualified name of "Do-Action.vi on Giszmo" is better but, it is not quite what they are looking for.
My Ctrl+Shift+T keyboard shortcut Launches File>>New... Because it is not available from the RCM when selecting a folder in a project. So if I select Funct.vit templates, create the vi and save it as Do Action in Giszmo project. The displayed FQM is "Funct Do Action on Giszmo"
Perfect decoration!- since Funct(X).vit and Funct(y).vit tell me what type of action I indend to do!
Here's where the story turns sad. When I select a folder in a project and "Ctrl-Shift+T" the new vi is added to the project at root- Not at the selected folder.
This one seems like a no-brainer!
Currently NI_Excel.lvclass:Excel Get Last Row.vi gives the last row in an excel worksheet. I am suggesting to add a last column count as well to the same VI.
Current NI_Excel.lvclass:Excel Get Last Row.vi