LabVIEW opens the file in the version of LabVIEW that was most recently opened instead of the version the file was saved in. Add a header to the file to allow LabVIEW to open the file in the correct version. This will save a lot of time and lower frustration of accidently saving a file in the newer version.
If I have many objects on the FP and I want to add event to "event structure", it takes time to found and select object from “Event Sources” list. It will be nice to add new event directly from FP by right clicking on the object. This option will be available if event structure exists on BD
There are times that I wanted to use a numeric constant or control as a string data type. In order to use a different data type, I would manually copy and paste the control/constant values to another data type. Moreover, if the control or constant is an array of values, it's tiring to do a manual copy of the values. Creating a vi that would convert the data type would also take time. As a suggestion, I hope LabVIEW can include in their "right-click" property box a method of converting the Path to String, String to Path, String to Numeric and Numeric to String.
I don't know if this is a big thing or not. Just a piece of thought.
Whenever you are looking for a Mouse Move, Enter or Leave event over a 2D Picture indicator, it takes into account the frame and returns negative values.
It is easy to control that, but I think it will be a good idea to give the user the option to choose if the event has to be fired whenever you enter the actual indicator (without the frame). Another option would be to take the frame away of the indicator.
What do you think?
PS: I attach a VI.
I would like to have multiple windows for the same VI available for LabVIEW. One example of this is in onenote. If you hit 'control M', another window pop's up and you can edit, drag and drop, etc, both tied to the core file. This would be useful for debugging, coping code to a different case, etc.
How many times have YOU right-clicked on an output of a function to select Create... --> Indicator, or on a function input to select Create --> Control? I find myself doing that operation over-and-over-and-over-again. Wouldn't it be handy if the first choice of the drop down was Create Indicator (or Create Control for the inputs), i.e. above "Visible items >"?
These two would help to sort out VIs when you want to make llb plugins, to determine who goes where.
I'd like to right click on an item in the project explorer, and have two more options "Open private callees" and "Open public callees.
By "private callees" I mean: the callees that the selected VI is the only one to call in the whole project.
By "public callees" I mean: the callees of the selected VI that are called by at least one other VI in the project.
(I mean directly called and not dynamically of course, the developper would have of way to distinguish his VIs that are called dynymically).
Again, I've done it for personal purposes, here's the snippet in 8.6 for those who might like it.
In "Image Displays", Images are locked in the center position when the area is bigger than the image. Could we have more control onver their position ?
This feature would be useful for those who need to show images with different sizes in the same "Image Display" (not simultaneously).
I guess a new ImaqImage property like "center position" or "top left corner position" or "alignment" would be enough ?
When you have something to print you can develop a VI with the option : 'print after execution'
With complex information, you can have a printable VI for graphical data, a VI for array data, ...
When you print all data you have a lot of paper.
But when your printer is a PDF printer, you have a lot of file with 1 page and not 1 file with a lot of page !
I suggest to have a way to create a print task, add a VI to print (with a option like 'add to print task after execution') and to have a command for run the print.
Advanced option :
A option to create more a print task.
So you can prepare the print task and juste run it on a event (and no loose time to build or re build the data if the same event comes again).
Currently when a search is made in the "find examples" window of LabVIEW it is not possible to find its folder path in the browse tab.
I would like to suggest the ability to right-click the search result and to have an option to find that search result in the browse tab.
This would be extremely useful when locating an example and then posting online the location in the example browser.
Here is an example of what it would look like:
National Instruments UK
when you place some control in the front panel, You don't have any idea of his position, You don't have posibility to control de exact position of this control, and You can't edit this position, only you have a small tip strip display when you move this control.You cant change the position of a control wiht the properties nodes in execution time, but this is not enough.
place a display in the front panel, to display the absolute position of a control, and his size, and when it is selected, to able to put his position, in additional way in the properties of control, having the posibility to do the same operation.
A) You right-click in your project and instead of adding a new target e.g...you can add a data source. This data source could be a web service, an XML file (eithe local or at a http address...), an ODBC database, a modbus TCP/IP register etc. etc. You can now access the data from this by dragging the source icon in the projects list onto your block diagram. This would give you a reference and polymorph accessor VIs.
B) You drop a data source express VI onto the diagram and it pops up with a dialog that allows you to select the type of source.
C) Perhaps we could even integrate this even more; if I right click on a table e.g. I can choose to link it to a data source - and have a wide variety of sources to choose from. Yes, we already have the shared variable or data socket based data binding option, but we should be able to bind it to lots of different, open and industry standard sources.
When LV 2012 was released many examples (especially the DAQmx ones) were refurbished (comments added, controls updated to silver scheme,...). Nevertheless there are still a lot of "Zombie"examples that need to be re-worked so that they accord to the LV style guide and have a common "look and feel".
Most SCC systems expects the source files to only contain source, and not (as in LabVIEW) both the source and compiled code.
This means that most SCC system flags the sourcecode file (i.e the VI) as changed whenever a recompile is performed and saved.
Since LabVIEW wants to recompile the VI's very frequently regardless of real sourcecode changes, it would be better to split the VI into two files, one containig only the sourcecode and another containing the compiled code.
This way we could configure the SCC system as with other languages to ignore the compiled files and only handle REAL source changes.
Note that the flag "Don't save automatic compiles" only helps for readonly-flagged files, which isn't enough when when working in SCC systems that doesn't use locking
The built-in LabVIEW comparison and array sort primitives are inadequate for many applications involving clusters. For example, the clusters may contain elements that
For example, consider the following cluster:
Now, suppose I want to sort an array of this cluster, but I am uninterested in the VendorCode or the Password, and I want the Server, Database, and User to be compared caselessly. The Sort 1-D Array primitive will not do this properly. The common pattern for overcoming this is something like the code below.
This does the job, but it is not particularly efficient for large arrays. I could code my own sort routine, but that's not the best use of my time, nor is it very efficient.
A similar argument can be made for simple comparison (lt, le, eq, etc.) between two clusters, although this is easily done with a sub-VI.
My proposal is to take an object-oriented approach and allow clusters to decide how they are to be compared. This would involve something like attaching a VI to a cluster (typedef). This would allow the default comparison of two of these clusters to be determined by the provider of the cluster, rather than the writer of the code that later needs to compare the clusters. I will leave it to LabVIEW designers how to associate the comparison code with the cluster, but giving a typedef a block diagram is one way that comes to mind.
Of course, different elements may need to be compared in different ways at different times. This leads to the thought that Sort 1-D Array ought to take an optional reference to a sorting VI to be used instead of whatever the default is. This idea was touched on in this thread but never thoroughly explored. The reference would have to be to a VI that conformed to some expected connector pane, with well-defined outputs, like this:
Strictly speaking, the x > y? output is not required here. Another possibility is
which simply outputs an integer whose sign determines the comparison results. Clusters that cannot be strictly ordered would somehow have to be restricted to equal and not equal.
The advantage to wiring a reference to such a VI into the Sort 1-D Array primitive is obvious. It is less obvious that there would be any utility to be gained from providing such an input to the lt, le, eq, etc. primitives, but consider that this would allow the specifics of the comparison to be specified at run-time much more easily than can presently be done.
I searched on "polymorphic" and did not find this idea posted.
I just learned over here that when you use a polymorphic VI, all flavors of that VI load into memory! That's why a VI hierarchy gets so cluttered so fast when you use them.
In the object-oriented version of polymorphism, all possible polymorphic cases need to be coded and loaded into memory, since any of these possible cases could be called depending on the execution of the program. In the LabVIEW-specific version of polymorphism, where a function has many flavors, perhaps due to a change in data type on one of the inputs, it is not usually the case that all of the different polymorphic members can execute at run time. In fact, I believe it is usually the case that only ONE of the cases will ever be called or execute.
So, why are all of the other polymorphic members in memory? I don't know. I think they shouldn't be. They seem to be eating RAM for no good purpose.
Load only the specifically called version of a polymorphic VI into memory.
I am communicating to parker motor controllers through the Ethernet (parker sample code). Apparently since it is Ethernet based, the code uses socket, where the sockets require admin rights (another discussion about ethernet based and admin rights). In order for my VI to connect to the controller I need to run LabView as an administrator. The problem is I am making this program into an executable for production work.
When I create the executable it will not connect to the controller unless I am running the application as an administrator. As this program will be used in production I want it to be as simple as possible to perform. I don't think there is a simple way to change the environment to run without the need to run application as an admin. Are there any ideas to either change the executable to run as an administrator through the application builder? My plan is to create an installer through the application builder.
Some ideas that I had is to create an installer file and create the executable. Change the privilege level of the executable (properties>compatibility>privilege level>run this program as an administrator). Use a batch file to install drivers and application, then replace application with the one with the elevated privilege level. Another idea I had is use a batch file to do a runas command to run application as an admin. I cannot get either method to work. Does anyone have ideas?
I was inspired by the idea 'Color properties should default to colorbox data' to post this one.
You can drop the listbox symbol constant from the pallet onto the block diagram. But, if you create a control or convert it to a control, you end up with a numeric control, not a pict ring of the symbols.
It would be nice, when including the listbox symbol in a data structure to allow for it's graphical representation. That way you would not have to lookup the index number with the constant to figure out what symbol had been set in the data structure when you are debugging.
If there is a work around for this, please let me know!