LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (3)

View All (2)

Fixed Size For Array Control

It would be helpful to have an array control property that fixed the number of elements in the array control to the specified size. This would allow the developer to programmatically set the array control dimensions such that the user is unable to add new elements to the array. This is specifically necessary when the number of elements in the array control may vary and may also be too large to display all of the elements. If the scrollbar(s) are visible, then the user will always be able to add a new element add the bottom by editing the available empty element value. This is undesireable if the developer wants to prevent the addition of new elements by the user.

Please see the discussion forum post below for the details of the issue and current workaround.

http://forums.ni.com/t5/LabVIEW/initialize-array-control-dimension/m-p/1221930#M520867

Thanks
Dan

View All (2)

Error Wire Feature

Hello NI,

I am thinking of a feature that if I hold a certain key such as CTRL and then move a vi that has error in/out wire in it, it will automatically snap to the error line that gets close to it such that the feature will automatically connect the moved vi in between the error wire it is closed to. This will cut the error line and insert the error in and out of the vi that gets close to it. Thus a person will not need to do the following steps:

1) click to error line, then click to input of the error wire of the vi.
2) click to error line again, then click to output of the error wire of the vi..
3) click the unwanted wire/broken path and delete.

Regards,
Mark J.

This is an extension of Darin's excellent idea and touches on my earlier comment there.

I suggest that it should be allowed to mix booleans with numeric operations, in which case the boolean would be "coerced" (for lack of a better word) to 0,1, where FALSE=0 and TRUE=1. This would dramatically simplify certain code fragments without loss in clarity. For example to count the number of TRUEs on a boolean array, we could simply use an "add array elements".

(A possible extension would be to also allow mixing of error wires and numerics in the same way, in which case the error would coerce to 0,1 (0=No Error, 1=Error))

Here's how it could look like (left). Equivalent legacy code is shown on the right. Counting the number of TRUEs in a boolean array is an often needed function and this idea would eliminate two primitives. This is only a very small sampling of the possible applications.

Idea Summary: When a boolean (or possibly error wire) is wired to a function that accepts numerics, it should be automatically coerced to 0 or 1 of the dominant datatype connected to the other inputs. If there is no other input, e.g. in the case of "add array elements", it should be coreced to I32.

View All (3)

Error List Window - Errors by Category

So I'm going through a bunch of VIs and relinking them. So I go to a folder and select say 100 VIs and drop them into a new blank VI. A bunch of dialogs come up telling me VIs are missing and I ignore them all at the moment. Then I go to the block diagram to find which ones are broken to review them one at a time. The only problem is the error list window displays over 100 errors that aren't "SubVI is not Executable". I have all kinds of errors about required inputs not being wired, and for "This VI cannot access the referenced item in private scope". Well I don't really care I'm not trying to run these I'm just trying to find all broken VIs and fix them.

Which got me thinking, can we have a category view of some kind in the Error List Window?

Required input not wired.png SubVI not executable.png

When writing a string key to a configuration file with the Config file "Write Key.vi" on the File I/O palette, the value will always have quotes around it because of the "Add Quotes.vi" in that particular method as you can see in this image.

Not all external programs handle ini files with quotes around strings as well, and this question was already asked and answered in 2010, but for some reason NI never added this VI or the option to remove the quotes to the actual palette.

I would like to have the option to have my string keys with and without quotes.

For distribution, only package necessary libraries in installer packages built with the project. A lightweight UI, server, or client does not need a full 70MB+ installer that bloats out to a few hundred MB's once installed! A colleague has remarked that the total size of our LabVIEW application+RTE EXCEEDS the entire size of the XPe image running on the embedded computer! This becomes an issue when distributing software upgrades to places in the world without high-speed internet connectivity.

View All (11)

Hi,

when I have to rework a vi, i usually start by putting the existing code in a disable structure

and then start working in the disabled 'case'.

Quite often I end up trying to replace the disable structure with a case structure to test the new or reworked vi.

Now I have to copy everyting into a temporary vi, remove the disable structure, put a case structure in place, paste again and rewire iputs and outputs.

Please add the ability to replace the disable structure with a case structure.

View All (5)

View All (2)

Using the application builder is problematic if the destination folder is monitored by syncing tools such as Google Drive (Backup&Sync), Onedrive, etc.

During building, there are tons of file operations in rapid sequence, potentially crashing the sync tools or causing false file conflicts (recent example).

To avoid these issues, I wonder if the building steps could be forced to take place in the temporary folder, followed by a final clean move to the destination. My guess this would make building more stable and compatible with external folder syncing tools.

NI updater kindly informed me that LabVIEW 2014 SP1 was released (even though I uninstalled it shortly after I tried it last year) and out of curiosity, I took a look at the known issues list.

I learned a few interesting things I did not know about, and also that some problems had been reported as long ago as version 7.1.1. This type of stuff looks like bugs that won't be fixed, ever.

For instance, CAR #48016 states that there is a type casting bug in the Formula Node. It was reported in version 8 and the suggested workaround it to use a MathScript Node instead of a Formula Node (where is the "Replace Formula Node by a MathScript Node" contextual menu item?).

Problem: the MathScript RT Module is required. Even in my Professional Development System, this is not included by default. Does this really count as a workaround?

I read: we don't have the resources to fix that bug, or we don't want to break code that expected that bug.

In any case, this bug with most likely never be fixed.

The bottom line is, we can waste a lot of time as users, rediscovering bugs that have been known for a while and will probably never be fixed. As a user, I would really appreciate a courteous warning from NI that there are known traps and have a complete description handily available with the help file related to the affected function.

My suggestion: add a list of known issues (with link to their description) for all objects, properties, functions. VIs, etc, in the corresponding entry in the Help File.

View All (1)

New 1D data container: Circular Buffer

There is a construct I am quite fond of in pointer-friendly languages, using iterator math to implement circular buffers of arbitrary data types. They are a little bit slower to use than straight arrays, but they provide a nice syntax for fixed sized buffers and are helpful in cases where you will be prepending and appending elements.

I am pretty certain that queues are implemented as circular buffers under the hood, so much of the infrastructure is already in place, this is mostly adding a new API. Added bonus: the explicit circular buffer can be synchronous, unlike the queue, so for example you can put them in subroutine VIs.

It should be easy to convert 1D arrays to/from circular buffers. Array->CB is basically free, the elements are in order in memory. CB->Array requires two block copies (most of the time). This can be strategically mananged, much like Reverse or Transpose operations.

Use cases:

You can implement most of the following two ideas naturally:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Looping-Input-Tunnels/idi-p/2020406

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-modes-on-auto-indexed-input-array-tunnels-in-loops/idi-p/2263706

Circular buffers would auto-index and cycle the elements and not participate in setting 'N'.

You can do 95+% of what I wanted to do with negative indexing:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Negative-Values-in-Index-Array-or-Array-Subset/idi-p/960863

A lot of the classic divide and conquer algorithms become tractable in LV. You can already use queues to implement your own stack and outperform native recursion. A CB implementation of the stack would be amenable to subroutine priority and give a nice performance kick. I have done it by hand for a few datatypes and the beauty and simplicity of the recursive solution gets buried in the implementation of the stack. A drop-in node or two would give you a cleaner look and high-octane performance.

Finally, perhaps the most practical reason yet: simple XY Charts.

As for appearance I'd suggest a modified wire like the matrix data type. Most if not all Array primitives should probably accept the CB. A few new nodes are needed to get/set buffer size and number of elements and to do the conversions to/from 1D arrays. The control/indicator could have some superpowers: set the first element, wraparound scrolling (the first element should be highlighted).

View All (1)

LabVIEW for BeagleBoard

The BeagleBoard xM is a 32 bit ARM based microcontroller board that is very popular. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK (or other methods of getting LabVIEW to run on it).

The BeagleBoard xM is $149 and is open hardware. The BeagleBoard xM uses an ARM Cortex A8 running at 1,000 MHz resulting in 2,000 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power. So, about 33 times the processing power!

Wouldn’t it be great to programme the BeagleBoard xM in LabVIEW?

View All (5)

Rotate String

View All (2)

I envision a structure much like a case structure, in which you select your event for evaluating the code inside the structure and the values become constants at the node. The interior would allow code that may normally not be able to run on the host for example, on fpga it might allow the use of doubles and strings and resized arrays, because it isn't actually going to be executed on the host just evaluated and stored as a constant. This would allow for more configuration for fpga and even have some benefits at the traditional desktop environment. For example you could set the structure to evaluate on app build and produce a string constant that is the build date so the build date could be shown on UI to help distinguish builds.

View All (4)

I have pondered this and not sure it is possible but it would be nice to allow using case structures to work with vi server references. It is very tedious to test each type with a cast to more specific and the for each type and check for error (current method or itterating through the class hierarchy).

I know that subclasses pose an issue, I would like to see for the case structure to limit each case to select the highest level (ie g object) and the distince cases are error or any direct class child of the specified parent type class.

The Use case I see is for handling itterating through controls from an array of controls (if the control is a boolean do something different than if the reference is to a string control).

Could be very nice for scripting.

View All (3)

LabVIEW Idea Exchange

Reverse order indexing for Map on for loop

Add support for the TLS Configuration Refnum to "Not a Number/Path/Refnum"

Fixed Size For Array Control

Error Wire Feature

Booleans should coerce to 0,1 when mixed with numeric operations

Error List Window - Errors by Category

Remove quotes in the Configuration "Write Key.vi"

Segment the LabVIEW Run Time Engine (RTE) to ONLY Necessary Components

Add the ability to replace a disable structure with a case structure

Do not apply VI Properties "Run Time Behavior" until the vi is running!

Don't Adapt To Entered Data if you place a DBL

Installer option to "Run executable at the beginning of uninstallation"

Make application builder more compatible with google drive and similar tools.

Include longstanding "known issues" in the help file

New 1D data container: Circular Buffer

Add right-click option to delete class mutation history

LabVIEW for BeagleBoard

Rotate String

Structure that allows constants to be generated at compile time.

Allow vi server reference type as case selector