Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
The In Place Array Index/Replace Elements function not only can save memory by avoiding copying arrays, it can also create "neater" and more transparent Block Diagrams. For example, here are two ways to triple the third element in an Array of 3 elements:
I needed to do the same thing, but for a 2D array (three channels of A/D data, I wanted to triple the third channel). The Help for the In Place Array Index/Replace Subset function suggests this is possible, using language like "element or element(s) of an array", noting the similarity between this In Place Structure and the two Array Functions that form the Input and Output nodes, and in earlier versions of LabVIEW (specifically LabVIEW 2012), explicit reference to rows, columns, and pages as replacement items. Here's what happens:
The Index Array left node forces you to specify both row and column, meaning you cannot operate on a single row (or single column), "breaking" the functionality with the separate Index Array/Replace Subset functions. This also, I believe, will force an Array Copy operation, something I'm (also) trying to avoid.
At its most benign, there is a Documentation "Bug" that should warn users that this In Place function is only designed for single array elements (which, in my opinion, severely limits its usefulness). I would like to suggest that this function be "fixed" to (a) for multi-dimension Arrays, allow, as with Index Array and Replace Subset, flexible choice of one or more Indices to be specified, with the unspecified Indices implying "All of the Elements", i.e. an entire Row, Column, Page, etc, and (b) maintain the "In Place" functionality by having this function generate the necessary code (behind the scenes) to access the specified elements and do whatever operation is required inside the Structure.
I appreciate that requirement (b) might be difficult. For instance, operating on a row in a 2D array should be easy, as the (row) elements should be continguous, making getting and putting them simple. However, if a column is specified, getting successive elements and putting them back becomes more complex. To the User, it all "looks simple" -- you get a 1D wire out, operate on it (say, multiply it by 3), and stick it back "in place", but the LabVIEW compiler has to "get" elements from non-continuous locations and put them back where it got them, but that's what Compilers are for!
I have a project which compiles to 2 different executable for different hardware targets. I have created 2 Build Specifications which specify different locations for the build output. However, between compiling each one, I must go to the target options, and change a Conditional Disable Symbol definition so that the other .exe is generated. If the Build Specifications definition had a tab to specify the value of Conditional Disable Symbols, and which would take precedence over definitions in the project or the target options, then I could build my 2 executables without changing the target properties.
In LabVIEW if I want to use a property/method of a control I have to right click and select property. Same for second control I want to use same property I have to do same operation again. My idea is if we select all the controls and right click, some common property like value, visible and etc..... Should display and by selection it generate automatically. This can reduce my application development time.
So if this key feature is there in LabVIEW we can select multiple controls or properties and perform some basic operations to reduce our application development timing.
Thanks and Regards Himanshu Goyal | LabVIEW Engineer- Power System Automation Values that steer us ahead: Passion | Innovation | Ambition | Diligence | Teamwork It Only gets BETTER!!!
Currently, the only native way to display a JPEG in memory on a 2D picture control in LabVIEW is to
save to disk
read from disk
This is not only silly, but slow: on a reasonable fast machine with an SSD, this takes almost a second!
A simple request: A VI that can go straight from JPEG binary data (other formats would be nice) to a 2D picture control. This is very useful for applications that download images from a server - a pretty common thing to do.
I'd really like to be able to select the entire top-level cluster in an event structure, if event data is a cluster:
I know this have been brought up in numerous forums over the years, but I feel it's being ignored somewhat by NI? It usually gathers quite a few positive acknowledgements from other users, but I think it's about three years since it's been brought up in the idea exchange. It seems so easy to implement and would greatly simplify many event structures. So forgive me for duplicating something from countless other places, but I think it deserves a second (or ninth or whatever) glance
The conditional disable structure gives the developer to create multi-function applications. However, right now in order to build these applications into different executables the developer must go in and change the project conditional symbols and then re-build the applications and hopefully remember what the symbol states were when the application was built. It would be great if during the application build process the conditional symbols could be set. This would allow the developer to create multiple build specs for each different implementation of the application. An example is shown below:
LabVIEW saves configuration data, including Recent Files and Recent Projects, in a single LabVIEW.ini file, by default saved in National Instruments\LabVIEW <Version>. If more than one user logs onto (and uses) LabVIEW, this "sharing" of the configuration, particularly the path names to files, will probably point to the "wrong" place, as they go by default to the user's <My Documents>\LabVIEW Data. Note that the NI function "Default Data Directory" will correctly "point to" the user's <My Documents>\LabVIEW Data, but there is no guarantee that the (single) LabVIEW.ini file will be correct for all users.
A simple fix is to save LabVIEW.ini in the user's Profile. I notice that there is a National Instruments folder in App Data\Local -- this is one place that could be used. Then if a second user logs on to a PC, he (or she) will have a unique set of saved files/folders in the Configuration file, one that references files in the appropriate <My Documents> folder.
I think it would save a bit of space, and time, if we could use a negative array index value in order to quickly get the last element of an array. This would also work for 2nd to last item, 3rd to last, etc.
When I started working with Python I thought it was rather useful and intuitive to be able to quickly reference the last item in an array in that way. Like so:
I come across many situations where the value that needs to be entered into a numeric control is not readily available but has to be computed (For example: I need to enter the value 679.5/23.2 into the numeric control), then I would need the help of a calculator to compute this division answer, copy and past it back in the LabVIEW control.
So it would be good if we support basic math operations (+-*/^%) in the numeric control (and constants?) so that even if I enter 679.5/23.2 or 2^23 or 172857+3675 in the numeric control, it evaluates the math expression in edit time and assigns the value to the control. This would less than 5% of the time it takes currently in LabVIEW.
(One other option would be to change the code to accept 2 controls and use the division primitive. But this may not be feasible if the VI is built into an application or if the operation is a one time calculation that need not be repeated, or if the math operation that is done to calculate the input to the numeric is different each time,etc)
With text based languages, the For Loop has a programmable starting index, stopping index, and step size. With Labview, the starting index is always zero and the step size is always 1. It is not changeable. I would like to see Labview have a real For Loop where there would be three terminals inside the For Loop that can be set by the user. One terminal for initial value (starting index), one for final value (stopping index), and one for step size. This would be of great value to all Labview programmers. Of course the terminals can be much smaller than what is displayed in the picture. One or two letter terminals, such as ST for start, SP for stop, and SZ for step size would do fine. (or N for initial value, F for fnal value, and S for step size). The real for loop should be capable of going in a negative direction, like starting at 10, ending at -10, with a step size of -2.
By default when a control/indicator is dropped in the FP/BD the Label is on top of the control and the developer needs to realign them for better UI.There must be an option in the FP and the BD with which the Labels can be aligned left, right, or on top based on selection.
See the attached image which better describes the solution
The same utilty can also be used to save some space in the BD as shown
The For Loop is one of the most widely used tools in Labview. However, it has a drawback. The step size and starting point is fixed and cannot be changed. Most of the times this is OK. But there comes a time when being able to change the starting index and/or the step size would become very useful. Consider the following scenario:
You have a test results file as such:
Test1 UUT1 3.4
Test2 UUT1 4.5
Test3 UUT1 5.4
Test1 UUT2 3.0
Test2 UUT2 4.1
Test3 UUT2 5.2
Lets say you wish to extract all the info for Test2 only.
With a conventional For Loop, you would have to create special code to form the index. You could do it with a While Loop:
Or you could have an option to specify the start, stop, and step parameters:
This could be made possible as a right click option. The default would be for the For loop to appear and function as it is now. But if you right click on the border, you would get an option to display and use the extra terminals, as shown below. This is similar to what is being done with the Conditional terminal.
With this option, the three values would be supplied. The i terminal value would follow the parameters. With a start value of 1 and a step size of 2 and a stop value of 10, the i for each iteration would be 1,3,5,7,9.
This would also apply to auto indexing when this option is chosen. In the above test result example. the code could be made even simpler by enabling indexing:
If the start were set to 1, step to 3, and stop to 5 (or the length of the array - 1), the output would be rows 1 and 4. No extra code needed.
I think this idea has great merits. It allows use for special cases, and it allows the normal For Loop to be continued as it is today, making it backward compatible.
When you drop a local or global variable, it always defaults to Write. Wouldn't it be nice to drop a variable down, and it is "uninitialized". It would show nodes on both the read (left) and write (right), and become either read/write only AFTER you wire to the appropriate node.
All the other string/number conversion primitives are polymorphic (i.e. can accept arrays as well as scalars), except for the "Format Value" and "Scan Value" ones. Can we make those polymorphic, too? I hate that I have to do things like this:
Fix the "Write to Spreadsheet File" polymorphic VI in vi.lib so that the error in / out clusters are shown. This will allow the user to do his own error handling. As it is, the user get a nasty error if you don't verify the file path in front of this VI.