Hello to all
I belive that if LabVIEW can have the mouse gestures feature (as we can see on opera browser),
where we can define some common operation to reform it will be very usefull.
Please let me konw what do you think about it
Thanks in advance.
There are a number of very useful Mathscript routines which are not available in the LabVIEW Math or Analysis libraries. I would like them to be made available on the LabVIEW palettes as well. Those I can think of are:
Some even already have nice looking icons
Are there more?
I would like to suggest a new feature concerning prefixes of numeric values like ist is done already when using the "SI notation" setting.
In the world of bits and bytes, prefixes like M(ega) and G(iga) does mean 10242 respective 10243 bytes.
While in the rest of the world M(ega) and G(iga) does mean 10002 respective 10003 lets say Hz.
I may refer to a Wikipedia article:
For the English people: http://en.wikipedia.org/wiki/Binary_prefix
Here in German: http://de.wikipedia.org/wiki/Bin%C3%A4rpr%C3%A4fix
I would see this in the formatting of numbers similar to the SI formatting. In my screen shot you can see how an implementation could look like:
This should work for string formatting, too.
Optional it could probably be implemented by introducing a UNIT "byte" or "bit" which could handle the differences. But you would have to thing about it.
The current set of Bessel functions supplied in LabVIEW Core only allow for real arguments and outputs. This limits the usefulness of LabVIEW in certain areas of science where complex Bessel functions are required for calculations (i.e.. acoustic modeling). The Mathscript RT module has Bessel function calls that support complex arguments so it's not like the coding doesn't exist. This is one area where LabVIEW is deficient as compared to Mathematica and Matlab and can be easily corrected without forcing the user to buy the Mathscript RT Module.
I did a search for explain error - I did find this idea which is similar but for probes.
Explain Error is a feature I have been using more lately but its not available for an error that is in an array (LabVIEW 2010).
It would be great if it was!
In the Run Mode we can set the breakoint by pressing the <Ctrl> key and left click over the probe. To remove it the vice versa applies...
In the Edit mode it would be more handy to set the Break point by Pressing <Ctrl><Shift> key and left click over the probe to set and remove the Break points.
I have checked the Functionaltiy of the <Ctrl><Shift> key when both are pressed the mouse pointer changes into a hand tool and we can move the BD on anyside but it doesn't have any effect over the probe and on the Front panel.
So this idea would defenetly help to make easy debugging..
Wouldn't it be nice to the have a local variable page like the global variable page.
Front panel objects are local variables but sometimes it is not always desirable to see this local variables. There are three options around this: 1) put the local variable off to the side side of the visible display, 2) make the local variable hidden, or 3) use a global page. By putting these variables on a global page they are no longer local and be be changed by other VI's. The scope of a local variable needs to be limited to the VI that uses it. While it possible to use the first two workarounds and make local variable hidden or put them off to the side it makes the front panel messy. Things are complicated even more because if local variables are double-clicked on the block diagram because it brings focus to them on the front panel and this can be a problem if the front panel has a status bar or a toolbar and things are carefully arranged.
Another possibility would be to enhance the functionality of the block diagram constants so they can be variables.
It's good to have tool like Quick Drop...........but it will great if we can see our own VIs/Custom Controls/Custom Indicators/objects present in my PC in the list.
This can be achieved by remembering them while they are made or being used for the first time. So that every time I don't have to got to Select Vi, search the path & call a VI.
The only option to do this right now is by placing the VIs in user or inst directory of Labview.
But this not what we always do right? We manage the folders & VIs in different locations.
Just as good function as any desktop search.
I'd like to re-hash an old idea with a slightly new context:
Here's the original idea:
This idea is currently marked as completed, even though it was completed with another Keyboard shortcut, instead of as a Right-click menu option as described.
I think that Quick Drop should be an option that shows up along with "Specific Pallete" and "All Palletes" anytime that they appear in the Right-click menu.
In general, I would like the ability (in any context) to select a VI from the palettes using the keyboard.
For simple dropping of a node, this is perfectly achieved in Quick Drop (awesome.)
For Inserting or Replacing, I can use Quick Drop too, but the logic is out of order in my mind.
I would prefer to select the action that I want (Insert, Replace, etc) from the Right-click menu, then use Quick Drop to locate the node I want.
In the current implementation, if I choose Insert from the Right-click menu, I am forced to navigate the palletes. If I go to Quick drop, I have to invoke Quick Drop, type/select the node I want, and then remember what I was trying to do ("Oh, yeah, Insert")
and then remember what the Shortcut is for that ("um...Ctrl-I? Do I hold Shift too?").
As a side note, this could potentially get around the limitation in Quick Drop of inserting a node onto a branched wire (see discussion here).
I would like to see the waterfall plot in the Sound & Vibration Toolkit have some useful properties with it like any other Chart or Graph in LabVIEW. For example; a cursor with displayed values would be a good start so that a particular line item of interest could be analyzed.
This idea is about a new LabVIEW feature, the Packed Project Library.
To statically use a packed library as a dependency, you need to add the library to the LabVIEW project. After that's done, all the callers link to the packed library. If you're strictly a library user, then whenever you need a library update you simply ask the developer for one.
But what happens if you're a packed library user and developer of the same library. You can't use a packed library as a static dependency until you build it and replace the lvlib with the lvlibp...but you can't develop the packed library after it's been built and replaced in the project.
If you're a user and developer, it makes sense (to me) to maintain two separate projects. One manages the packed library resource, one manages the application.
What if there were a way to revert the packed library to the LabVIEW library from the same project? You could use the spiral development model and simply switch between the two types of libraries during development. You could also (and this IMHO is the most important part) incrementally deploy and test the project. If you're strictly a packed library developer, hopefully you're incrementally testing anyway.
My final pain point with the packed library is with respect to upgrading the application. Similar to above, if you're strictly a user, you pray the developer is still in business and ask nicely for an upgrade. If you're a user and developer, and you didn't maintain two projects, you might think to replace each static packed library subVI in the application with the original source and then rebuild the lvlibp. Or you might think to create a new project that includes the lvlib and rebuild the lvlibp yourself. I haven't tried it, but I hope that you can replace the original lvlibp with the lvlibp from a new project (not the one that created the original lvlibp).
This leads me to a best-practice for lvlibp: always use them as dynamic dependencies. That way, you can maintain and develop the packed library in the same project that uses the packed library. You'll simply reference the resources differently.
Even if you don't kudo this idea, I'm very interested to hear your feedback and experiences with the lvlibp.
After a brief search I didn't see this one yet:
As I'm gradually changing over my wire labels to the "new" method, I'm noticing some quirks regarding positioning. I'd like to suggest the following:
I'd like to emphasize the "option" part on the latter, as this understandably won't be a good fit for every context.
As with other suggestions, I realize that this is somewhat subjective, so here's an example of how I'd like to use the labels.
Here I've aligned all of my labels on their horizontal centers and have set the respective fonts to center justified. My intuition tells me that, now when I start typing, all of these labels should remain aligned on their horizontal centers. However, when I started typing out "Enable Speed Per Air Flow Rate", the whole label started wandering off to the left. I don't quite understand how the alignment works, but it's not proving efficient in most of the instances in which I use it.
Thoughts? Improvements on this suggestion?
Thanks as always,
Assuming that I have a case structure with numbered cases, I would like to be able to add a case anywhere and have LabVIEW renumber all the cases for me. This would be like the opposite of sort, which rearranges the order of the cases but leaves their numbers alone, instead, this would renumber all the cases but leave their order alone.
I often open a subvi while the calling vi's are open. I make a few changes. I try the changed code and decide I prefer original. If I try to close the vi without saving it is not possible. I must select "defer decision" to save. Then when I later close the main vi, I am asked to decide whether to save the subvi or not. By then I may have forgotten that I did not want the revisions saved or simply use the apply decision to all by mistake. Allowing a close without saving at anytime would be most welcome.
Allow the configuration portion of DLL nodes to see mangled function names, such as those generated by many C++ compilers (@Initv, for instance).
Invoke nodes can have lots of optional arguments, resulting in their taking up a lot of vertical space. I would like to recommend that the arguments portion of Invoke nodes be resizeable, allowing the developer to select the optional arguments to be displayed on the block diagram and, hence, have more control over the layout of the block diagram.
Consider the Save-As Invoke node from Microsoft Word:
which gets longer with each new version of Word.
Now imagine being able to show just the optional arguments that are needed:
And, as an added bonus, this Invoke node would not break when the VI is opened in a development environment that has a different version of Word with the same exposed optional arguments.
When a control caption.text property is called and the caption has not been set in the Properties dialog of the control an error is thrown.
It would be nice for the caption.text to default as an empty string so an error wouldn’t be thrown when it is called in the block diagram. This would allow easier runtime editing of each control on the VI.