Have you ever found yourself wondering what was going on with a sub-VI on a deployment system, but could not view what was going on with the VI without going to your development system? How about an installation that allows someone to view a VI front panel and block diagram that is not locked or password protected?
The Report Generation Toolkit does not allow you to delete a worksheet (or anything as far as I can tell). I realize that it is a "generation" toolkit, but it does have modification functions such as being able to overwrite a cell. Deletion is a modification function of sorts and it seems like it is a pretty basic function. Also, figuring out how to open an existing file is not obvious. You have to use the New Report function. It turns out that you can use an existing file as the "template", but that doesn't show up in the documentation. Rename the function as New/Open, something similiar to the file I/O Open/Create functions and at least add a note to the help file.
It would be nice to be abble to view a case structure in Stacked mode.
This stacked structure would have one common input for the case selector.
All input wire will be automotically duplicated for each case ... and the same for outputs. (Automatic merge)
This could be a way to have a direct view to a "little" case structure ... something like a C like switch !
I would like to have a select ... but with multiple cases ...
This could have a look like this ... ( You will certainly create it smater than my example !!! )
I REALLY don't like the Window Tile feature (Window>>Tile Left and Right, Window>>Tile Up and Down). Mostly because Ctrl+T is right next to to Ctrl+R (which I use for showing the error dialog when a VI is broken), so I accidentally tile my windows all the time -- frustrating. I vote to remove it altogether.
See also this Idea: Undo Tile (ctrl + T)
It would be nice if LabVIEW RT could give more output during the startup process of a LabVIEW real-time executable. For example if the rtexe is started at all or not, if there are missing dependencies during the loading process or other usable stats.
In my case I had problems with the German codepage. The build process was done without failure. But the rtexe didn’t start at all. I used special German characters like “öäü” in some VI names. And the rtexe couldn’t be loaded for that reason. But I didn’t get any message.
So please improve the debug output for LabVIEW RT.
It would be nice if it was possible to create a empty folder with the installer.
I have an application to handle some files that are generated by other applications. Therefore I require that there is some specific folders which these programs can place their files in.
I know I can create them by placing a dummy file in the created folders, but I think it is a mess with non relevant files.
Since the Actor Framework came up, I'm getting more and more into object oriented programming with LabVIEW. But I'm missing one of the biggest strengths of LabVIEW with it:
The ease of bounding your source code with a graphical user interface.
When you create a front panel object from a class object you can neither display nor control data. You can just display the object icon. So this is basically the flipside of the “Cluster as Icon on Front Panel” request. Instead of an icon I want to have my object’s private data in my front panel. So a right click -> show private data would be nice:
This would become handy not only for creating user interfaces but also for debugging, since the probe is often difficult to overview when you are dealing with data strucutres like arrays, clusters and objects.
Right now the workaround is to create a cluster type def and put the cluster into the private data. But this is unhandy. Instead switching back and forth between icon and data, you have to bundle/unbundle and create control/indicator. You have the additional file in your class. And you have the "additional bundle/unbundle mouse maneuver" if you want to access single elements.
Would be great to have an easy access to the mouse scrolling wheel event within any control. In the example below we could zoom in a XY Graph by using X.Range and Y.Range Property, that could be also created as an Invoke Node for this kind of control. I already did it with a user dynamic event and it works great, but took much coding time. I needed to code an event case for "Mouse Enter";"Mouse Leave" to register/unregister the event...
It would be nice, to have a checkbox "[x] automatically store/restore last setting" for every control.
It is annoying to restore a lot of settings at program startup from *.ini, and save current settings at program termination. Every time a control changes its value, I wish to have its current value stored and used as default at next startup.
The diagram disable structure is great for commenting out code, especially during testing when maybe all parts are not functioning. However, I wish as I expanded and contracted it AFTER IT HAS BEEN PLACED ONCE that it would enclose the code already in place. Because it doesn't, I end up removing and redrawing the structure to include and exclude what I want as things change. Please see picture below for what I am proposing.
The probe watch window is not practical. Principially the probe watch window is a nice feature in some cases. But nevertheless when you only just want to place a probe , e.g. a conditional boolean probe, with one click like you are used to do in the past, now you need several clicks to get the same "result": You have to select the probe in the probe watch window again, add an additional probe window explicitely and then hide the probe wath window (because in general it bothers the developer because it covers the blockdiagramms and frontpanels).
My suggestion is to give the option to disable the probe watch window and enable the probe placement like in the past by adding an config entry in the LabView options or a better by adding parameters/shortcuts to the probe watch window.
You don't have the option to set a VI to be inlined in the caller if it is called dynamically. Makes sense--the compiler doesn't know about it a priori, so it can't shoehorn it into the block diagram under the hood. This holds true for dynamic dispatch VIs, such as Override methods in LVOOP. In this case, though, it would seem that the compiler does have enough information to do the inlining---it could basically create case structures for each unique child class of the parent class being overridden.
Similarly, if the compiler were smart enough to do the behind-the-scenes case structure implementation, then it should also be able to preallocate clones for each instance of the Dynamic Dispatch VI.
The reason I bring this up is that I have a situation that screams for OOP implementation, but the dynamic dispatch portion needs to run in a very tight loop--several, tight loops, actually. In parallel. I am trying an OOP implementation of monitoring incoming data for Warning conditions; so I want a generic "Warning" class that has descendent classes for different conditions (i.e. monitoring for Limit violations, value change events, etc.). But, because the data throughput in the system is so high, I don't think I can trust the implementation to OOP--I think the subVI call overhead and jitter from sharing clones will be a bottleneck.
While NI provides (thank you) reasonable support for OS X these days, the support for installs and updates "on line" are very far behind those for Windows.
For instance, there does not appear to be any option to download Labview 2010 for Mac but I can for Windows.
currently the property node only accepts a single reference.
For setting a property or calling a method on an array of references,
it is currently required to surround the node with a for loop.
It would be much easier if the array of references could be directly conected to the node,
especially for situations like enabling, hiding, ... a list of controls
I would like to see more properties & methods exposed with the report generation toolkit vi's. Currently you can do some quick generic reporting but are very limited. When you look at the block diagrams of these vi's there can be a lot more properties added to give this tool set more capabilities.
I think everyone's been there before.
Working on a project and for some reason from somewhere an Insane Object appears somewhere in the code. Not a nice thing to have happen.
At the moment, it's quite a nasty job trying to track these things down. Usually most users resort to trial and error in trying to find the culprit. I myself use the mass compile function to at least narrow down which files have the problems. Recently there was a post on the Forums highlighting the LabVIEW Object Viewer which seems like something which should be much more accessable.
I would like to propose making tools like these more accessable, more usable and maybe adding a tutorial as to how to deal with this. I also would like to see more sanity checks for the LV code so that we could maybe catch these erros earlier. How about an error whenever saving a VI so that we can 1) attempt another save in case the error comes from a write error or 2) investigate the problem immediately so that we can rest assured that we have caught the problem early enough to prevent tearing down the whole project.