Many LabVIEW functions use the UI thread, like DataSocket (due to ActiveX events IIRC), everything VI Server etc., and since there is only one UI thread (per LV instance, no matter the number of logical processors, right? Also on Real-Time?) these functions are blocked when the UI thread is occupied by something else.
What I find particularly troubling is the fact that you can't dispatch VIs dynamically when the UI thread is blocked - for instance if a dialog is open or a user is selecting something in the menu. The latter can be an application blocker, if you are dispatching 20 VIs to populate your UI for example, and the user clicks the menu bar (without selecting something), your app might freeze since you won't be able to dispatch anymore VIs until the user lets go of the menu bar. There are many much simpler scenarios that you'll hit more often (a DataSocket read with a long timeout may block your dynamic VI from loading?).
Upping the count of UI threads from one to several would be great, but probably out of the question due to the implications to the LabVIEW core.
Instead, could we at least get the 'Open VI Reference' function and the 'Run VI' VI Server method freed from the UI thread? That would enable dynamic dispatching while the UI thread is blocked. Other VI Server calls aren't that important to get out of the UI thread, since there are other (and better) ways to transfer data to your dynamic VI for instance, than with VI Server. One curious thing is that it's possible to open all the 'One Button Dialogs' you want in parallel for instance - I'd think they'd run in the UI thread, and hence the first one'd block the rest?
A (somewhat contrived) example that fails due to this limitation:
The blue statement is true even when DynVI doesn't touch the UI thread, and even when no VI in the hierarchy runs in the UI thread etc. It's simply the 'Open VI Reference' primitive and the invoke node that gets blocked, due to the one button dialog being open.
Sometimes I do not wish to delete a file permanently or keep the path of the delete file for later restore. Usually this is done in Windows by sending the file to the recycler and getting it back from there.
Two possibilities to get this functionality into LabView:
- Add "Recycler path" to the VI "Get System Directory.vi" to return the path to the recycler. The file can than by moved to the recycler and eventually back again
- Add a new VI "recycle" to the files palette. It should work like the "delete.vi" and return the path to the recycled file in the recycler.
Local/global/Shared variables or properties nodes (that are read/writeable) are usually placed in read mode.
For Power users it would be great if by holding e.g. the Strg.-Key the local variable or properties are placed in write mode. Also a good idea would be that the node adapts to the wire (input or output), but this idea is already in the idea exchange.
When you use a case statement, the situation arises where in a particular case there is no need to pass an object to an outbound tunnel, while in other cases you do in fact want to pass an object out the tunnel. To keep Labview happy, you must either provide a bogus item to the tunnel, or you can set the tunnel to "Use Default if Unwired".
I *hate* "Use Default if Unwired" because once set, if you simply forget to wire a tunnel, you will not get an error indication telling you that you screwed up.
I do however have a suggestion for how to resolve this:
1. Rename "Use Default if Unwired" attribute to "Use Default if Unwired (all cases)".
2. Add a new tunnel attribute "Use Default if Unwired (this case)". This will cause the tunnel to pass the default value if a tunnnel is unwired, but only for the case you set it in. In that way you suppress Labview complaints for cases where you explicitly don't CARE what is passed on, and will still get complaints if you forget to wire to the tunnel in one of the other cases.
3. Add a new tunnel graphic for the new "Use Default if Unwired (this case)" attribute to differentiate it on the block diagram. Use the existing graphic for the "Use Default if Unwired (all cases)" option.
4. When you set "Use Default if Unwired (this case)" on a tunnel, Labview should check to see if "Use Default if Unwired (this case)" is set in all other cases for the same tunnel. If so, have a dialog pop up to ask if you want to convert to "Use Default if Unwired (all cases)". But don't set "Use Default if Unwired (all cases)" by default; ask. You might be adding more cases later...
5. The "Use Default if Unwired (all cases)" and "Use Default if Unwired (this case)" attributes are mutually exclusive. If you select one, the following behavior occurs and the other is de-selected:
See the attached picture to see how the current and proposed behavior differs, and to get a look at what the implementation might be.
Display VI version in Tools bar For any vi
My use LabVIEW 2010，Often saved a vi(8.5) as high-version .
Alternatively, when saving the vi, the programmer could be proposed to choose the former LV version.
Sorry ,My English no good.
My suggestion is a change to the UNDO function.
A common annoyance is when making a large number of changes to the block diagram that fundamentally alter the way a VI works and then you go to the front panel and set up a few default values before you press play. You then find that the code doesn't work anymore so you then try to undo the changes... You then find that the undo only undoes the changes to the front panel and not the code that really matters. not you have to manually recode what you had before or reload from disk (hopefully you haven't saved yet)
My proposal is to have 2 separate undo functions - One for each edit screen ie Block diagram, and front panel.
see the diagrams below.. the shortcut keys can be differet - this is just an example and it could be implemented differently. also an icon could exist on the menu.
Likewise for the Block Diagram
Here are some options to consider:
The UNDO function will work differently depending whether you are in Front page view or Block Diagram view. - but the global undo functions the same as it always has.
Have the UNDO function work differently regardless whether you are in Front page view or Block Diagram view - but you must press the correct button on the menu or shortcut keys (ie CTRL + Z + F for front Panel or CTRL + Z + B for block diagram) or CTRL+Z for Global UNDO which will function the same as always.
Don't have a Global UNDO - and instead the UNDO button will only UNDO the changes on the front Panel or the Block diagram depending on what view you are currently in.
Perhaps these options could be set under "tools/options" etc - not sure what tab would be best.
I favour Method 1 or Method 2.
Note: the CTRL + Z + F for Front Panel and CTRL + Z + B for Block diagram is just a suggestion. but something similar should work...and likewise for the redo functions..
Hopefully this is clear.
Did you ever want to add a password-protected VI to a library or use it independently from that library? You can't do that because the password protection of the VI also forbids you to change its membership in a library.
Viewing/editing a VI and adding it to or remove it from a library are different things, however:
Imagine the following situation:
I prefer to organize my projects using lvlibs and lvclasses. Many third party libraries still come as llbs or even plain VIs. I'm not supposed to have passwords for these libraries. But these third party VIs cause naming collisions in my project. All I want is to put these things into lvlibs to prevent name collisions or build a packed
library for reuse in my projects.
Membership is not necessarily implementation hiding and thus should be treated differently. The VI's vendor should have the opportunity to decide whether changing library membership is allowed, independently from locking the block diagram.
A modified VI security properties dialog could look like that:
A VI with these properties is password protected but can be moved freely between libraries.
Currently, a class is created with a Class Private Data Cluster. Each data member of that cluster is scoped exclusively to the owning class. For access to these data members outside class member VIs, getters and setters (accessors) must be established individually for each element. These accessors can then be scoped accordingly, allowing access to the private class data through the accessor VI, or in 2010, through an accessor Property Node.
Quite frankly, I like the IDE interface for accessing class data members using Unbundle/Bundle by Name. This feels natural for LVOOPers who have a background with clustered typedefs (which means everybody). Unfortunately, this method of data access is reserved for callers within the scope of the class data. Currently, since all class data is private, you can only use Unbundle/Bundle within Class Member VIs themselves.
I would suggest an options interface for setting the scopes of Class Data Members. Having non-private data member scopes has benefits:
The deletion of a Conditional Disable Symbol has no effect on the Conditional Disable Structures which use it.
This is very dangerous because the Conditional Disable Structure ignore the deleted conditional disable symbols and the default case is used.
It should be nice, in case of Conditional Disable Symbols deletion, to make "unexecutable", all Conditional Disable Structures which use it.
Thanks for reading.
I have recently encountered some problems when using libraries in my code whilst needing/wanting to disconnect multiple VI's from that library. I have found the process of manually selecting the VI's for disconnection to be rather tedious and time consuming (especially if they have enums and subVI's associated with them), I would suggest that perhaps the option of "disconnect all VI's from library" could possibility. After a brief discussion with some of my colleagues, some of which are very experienced developers, I have found they are reluctant to use them for this and various other reasons. I have managed to find a workaround for the solution on LAVA with this handy little script. I was surprised this functionality was not included in the development environment. Any input from other users with regards to the pro and cons they have encountered when using the libraries and other suggested workarounds would be greatly appreciated. Thanks!
I'd love to see a handful of built-in false-color colortable choices for the Intensity Plots.
I know there's programmatic control over these things - I wrote my own 4-5 years ago. But the black-blue-white should be one of several common selectable colorschemes.
I labeled my own as:
Blue Red Green
Perhaps one of the front panel (and Property node please) off of the Z-Axis submenu, listed by title.
I also have the ability to invert top/bottom or choose the color-inverse (photographic negative) for even more colors.
Attached is a sample of some common colortables I routinely use.
2nd attachment is a snap of the VI I use to create the colors based on colortable constants.
3rd attachment is my messy but functional code (Block Diag of attachment 2)
Rather than a surface plot, it would be really nice to have a 3D scatter plot.
Right now, you have to pass a 1D x-array, 1D y-array, then a 2D z-matrix.
This is very non-intuitive, and takes quite a bit of poking around to figure out why this is the case.
It would make much more sense to be able to pass in a cluster of 3 1D arrays of equal length, the same way you do with an XY graph.
In this case, it would be an XYZ graph.
In a complexe project, when you make Packed Librairie (lvlibp) or dll it is very important to compil your lvlib in a good order.
(from lvlib with less depencies to lvlib with more depencies)
But we don't have a way to see the lvlib hierachy
(we have only vi hierarchie, class hierarchie)
" ... when a TDMS file is open, LabVIEW will create an index structure in memory that is used for random access to the file. The built-in LabVIEW TDM Streaming API will always create this index, even if you're just writing." - Herbert Engels
This feature will cause an apparent memory leak if your program periodically writes to a TDMS file over a long period of time.
Disable indexing option for "TDMS Open.vi"
It's very rare for me to deal with large arrays, so it's seems very retarded when I'm debugging to
find VIs have not retained their values. I must turn on the "retain values" and re-run and go through
a huge test sequence again to trigger the problem.
All to save 100K of memory, when I've got 2G to through around.
How about a global setting "RETAIN WIRE VALUES" and per-VI setting to override the global.
Wouldn't take much...
I'd find it really helpfull, if there would be a possibility to create a new "value change" case in a event structure by right-clicking the control-terminal in the block diagram. If there is no event structure in that VI, the menu entry ("Create event") should be greyed out or be removed.
I could create cleaner diagrams faster if I had an option on the output tunnel of a case structure to use previous value.
Today if you want to change for example a number of controls to indicators or constants you have to do it one by one. The only option you get when selecting multiple controls and right-clicking is "Properties"
Wouldn't it be nice to be able to change multiple at a time?