It would be great if we could specify a set of VIs to run on LabVIEW startup. It could be similar to the Windows Startup folder in which anything placed in the directory will start before the getting started window. This could be useful for running certain tools at startup or personalizing the way the LabVIEW environment starts up.
I would like to be able to obtain the IP Address of an application instance.
Here is one scenario:
Plug in architecture.
Host machine loads plugin VIs that monitor several targets via VI Server.
The main VI opens the connection to one of the targets' application and sends the application reference to the plugin so this VI knows what target is communicating with.
It would be nice to be able to obtain the IP address from the Application Reference via a VI or a property node.
Now, I know I could be sending the IP Address instead of the application reference, but if I know I am going to be calling several VIs in the same target, why do I need to open an application reference for each VI, when all could share the same application reference.
Another scnerario for this was posted here: http://lavag.org/topic/6861-address-of-an-applicat
Currently, the configuration file object only has access to save a file when you close the object. I'd like to be able to save the file at any point in time and keep the object open.
OK... i have been using LabVIEW from 2003 (i guess) and i started using 6i or a version less than that.
Ever since i see that the size of the installer is getting bigger and bigger due to RTE and now it takes aroud ~100MB. I suggest to get rid of this so that i can straight away run the executable in any PC/MAC without ever requiring to install the RTE. (may be even replacing the RTE with a .NET or other technology which gets installed automatically when windows OS is installed)
I am a big fan of the DVR and LVOOP. Consequently, I use lots of DVR's in my class data. The problem is that if you configure the DVR reference to show the type control, and right-click the type control, you get a truncated shortcut menu. The controls can also not be operated. This is especially painful if your DVR is a cluster with lots of enums that have to be edited often. One solution is to make the DVR type a typedef and use the control editor. But since the class data is a typedef of sorts, this method amounts to creating a typedef for your typedef, so to speak. You can also use "customize control" from the edit menu to fire up the control editor and apply changes without saving the custom control. But you can't check your work because you can't operate the control. Another solution is to temporarily copy the enum out of the DVR edit it, and cut and paste it back in over the original. However, it really would be better if type controls are fully editable/operable when shown.
Currently, type controls show a reduced shortcut menu when right-clicked, and the control cannot be operated
It would be better if controls inside typed references could be properly edited and operated
Okay, so I am not really convinced myself if this is a good idea or not, or perhaps it has been discussed before and heavily flamed. It might be helpful if the LabVIEW class dynamic dispatching paradigm would recognize the GOOP-style naming convention for child class methods. If LabVIEW ignored all except the last two sections of dot-notation filenames (only for the purpose of dynamic dispatching!), then the GOOP-style naming convention could be used for child methods. This could reduce the risk of heavy LVOOP users potentially having thousands of different files in their code repositories with the same name, like "Initialize.vi","Configure.vi","Create.vi","Destro
Filenames must be the same for dynamic dispatching.
In this example, PXI and cRIO are descendants of DAQ.
Only the final two sections of a dot-notation name are compared for
dynamic dispatching (sections shown in magenta are ignored).
Allows for GOOP-style filenames by those who wish to use them,
but will not disturb the current paradigm
Quick drop is fairly limited when dealing with .NET or activeX code (or any other property/invoke node heavy application), since there is no way to access anything but the property node itself. To improve this, I propose adding support for dot notation in quick drop to access properties. My idea:
If nothing is selected, and the user begins typing the name of a class, offer the class as an option with [VI server] or something appended to it. If the user types a "." after the class, populate the quick drop window with all of the properties and methods of that class. For example:
If the user selects a property with subproperties, repopulate quick drop with all of the subproperties, for example :
Once the user reaches a property with a value or a method, quick drop would create the node with the selected property/method for you to drop:
The closest thing to this idea that I know of is the Ctrl+B shortcut which allows for changing the class, but I think that adding support for dot notation would make programming with property nodes much easier, and would also make it easier for .NET programmers to use LabVIEW.
Up to LV 2010 the "Nonlinear Curve Fit.VI" has an Input for the data weighting. For sure this could somehow be related to measurement errors of the data, but as this is not documented and not for a daily user well known it would be nice to have an additional instance were the input is not the "Weight" but the "Std. Dev. of y".
In a similar way it is not totally straight forward to calculate the standard deviation for the "best fit coefficients" from the "covariance matrix". So an additional output "Std. Dev. of best fit coefficients" would be very helpful.
The current Graph Properties Including a Boolean for "Show plot legend":
I'm suggesting to add more options here:
I've added an Enum:
Sometimes, the graph is empty, there are no plots, so I don't want the plot legend to be visible.
The same is true for the plot legend scroll bar - If there is only one plot I don't need the scroll bar.
It could be nice if I wouldn't have to do it programmatically.
When using Block diagram constants wired to Sub VI's, some times we prefer them to be placed exactly below or above the sub VI when they are connected to the bottom and top terminals respectively. This is just to compress the code, so that block diagram looks neat.
When using LabVIEW Code Cleanup
Prefered - would make code cleaner
For this it will be great if we have terminals for constants from top and bottom also. So every constant will have three terminals top,bottom and the ususal one to the right. When user wires to any one of this terminal the other two can become disabled, this will make sure user connects only one wire to the constant. I guess people wont prefer left terminal.
So our new constants will look like this:
At any time only one of these terminal will be active like this:
Hope I'm not duplicating ideas already in this forums (couldn't get to read all the ideas)
I propose a new floating/Dockable Text formatting tool for editing the FP controls/Indicators as shown below.
Presently it takes multiple iteration to make a control Label to justify, bold,change the color , change the font etc.
This new floating bar can have the following features like
-> Bold, italic,underline
Also this floating bar can be put as part of the existing tools window here (circled in RED)
or as a replacement for the "Application font" selection ring
I frequently see people posting messages about issues they have using the application builder. They report an error number and the text of the error description.
Here are some recent examples:
The error description always has a long path through numerous VI's that make up the application builder package pointing to where the error occurred. But the description never seems to give any detail about what actually caused the error. It is often too long of a file name, or too deep of a path that gave too long of a path/filename which the app. builder VI's could not handle.
It would be helpful to both the people who are having the issue, and to the people trying to help on the forums when they post their message asking for help, to have some information as to where to look.
Maybe that information is already available and I just don't know where to find it. Fortunately for me, I don't think I've come across this problem. One, I haven't need to build a whole lot of executables. Two, I keep my project folders at the root level of my hard drive, so the initial part of the path is always short. (e.g. c:\ProjectFolder\......) I know if you stored projects in a My Documents directory, the initial path is ridiculously long because of the way Windows locates My Documents on your hard drive (e.g. C:\Documents and Settings\My UserName\My Documents\ProjectFolder in XP) so you've already wasted 40-50 characters even before you give the directory name for you project folder.
My request: Let's show some meaningful information in the error dialog box for Applicaiton Builder errors that can help people figure out how to fix it.
Application builder should output an errormessage when building an app from a vi, which uses property nodes, that are not available in LV runtime engine.
I have made a little test and have found out that the app is just build and in the app default values of the corresponding datatype is output from a property node without availability in runtime engine. I would expect an errormessage during app build, or at least during runtime of the app. I have performed this test with LabView2009SP1, because I have just got the 2010SP1 DevSuite version some days ago and have not installed it yet, because I use the SP versions only, you will guess why ... ;-)
Some times a test must check an output that doesn't have a precise value and this output is expressed as a value +/- a band.
The current "In range" implementation requires that we provide the max and min value and indicates if the value was coerced or not.
I believe that we could have an LabVIEW primitive that works likes it but just check the value against a reference with a safe band expressed in absolute value or percentage.
The code would be something like this:
If I build an executable that incorporates any kind of .NET, such as the Simplicity AI PDF Toolkit, it obviously requires.NET on the target computer to work. If .NET is absent, the VI will load as a broken VI and an awful error message is displayed to the operator, typically along the lines of:
It would be great if we could place all our .NET code inside a Conditional Disable structure that accepts something like ".NET == True" as a parameter, thus allowing .NET code to run on a machine with .NET installed, but not resulting in a broken VI should it be absent. This would also give developers the opportunity to place something useful into the other case, such as a popup message stating ".NET is required for PDF generation." for example, or even some other replacement code if they so wish.
Therefore I would like to see the list of Conditional Disable structure pre-defined symbols include a new one for "Windows .NET"
LabVIEW has a good starting point for a text-based run-time menu. How about the option for a run-time toolbar in the same fashion with a base to start customizing from. It would have the "typical" buttons: New, Open, Save, Cut, Copy, Paste. The LabVIEW project explorer already has all of these icons, I would just like to see an option for an easily customizable toolbar similar to the run-time menu.
It would be great to be able to organize build specifications under a project into groups or virtual folders and also to reorders them. Currently, if you have a lot of build specs, it just becomes a long list, sorted by creation date.
My application uses a series of files to configure it self and I need to search in arrays to find which are similar to a given reference.
My solution is to use a for with a Match pattern VI and some logic to do the operation.
I believe that "Search 1D Array" would be faster than this implementation if it had the option to use wild cards ("*" and "?") as "element" input.
Other option would be include a flag "Exact match", by default set to TRUE to behave as is today or FALSE to stop on first occurrence of "element" in the array that contains it somewhere.
For example, if element = "ode" and array element = "model", it should set as a match if Exact match is set to FALSE.
Reading your sample code in http://decibel.ni.com/content/docs/DOC-12287 I had the idea that we would be able to inform Read from spreadsheet that the file has row headers and / or column headers.
When setting this, a table indicator should be created as defined by the file instead manually:
- remove the first row and set it as table column header
- make column header visible,
- remove the first column and set it as table row header,
- make row header visible.