LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Estimate and show the Time Remaining during LabVIEW Installs, using selectable and realistic time units:

.

install.png

I don't know how many times I've built an application or packed library during my 25+ years using LabVIEW. What still annoys me extremely much is when the AppBuilder gets a tiny error, like "wasn't able to copy this file" (always at the END of the job), or something else having no effect on the (already built and completed) application or PPL itself. Still AppBuilder deletes the whole build, sometimes 30+ minutes time wasted, and simply tells you the build "FAILED". 

 

My suggestion is: Make AppBuilder just a tad smarter and don't delete the EXE or PPL! Just let the developer know what file(s) to copy manually, or what post action didn't work! 

Current Behavior:

When using the "retain all errors" option of the Merge Errors function the combined error message JSON output is not a valid JSON string.

This is the source output of Merge Errors when retain all errors is active - it is not a valid JSON string.

 

<JSONErrorMultiple_1.0>[{
    "status": true,
    "code": 111,
    "source": "This is a test message including\nnewlines"
},{
    "status": true,
    "code": 222,
    "source": "This is a test message including\nnewlines"
}]

 

 

Desired Behavior:

Make the combined errors source string a valid JSON string so that it can be parsed by other tools.

Valid JSON string:

 

[{"status":true,"code":111,"source":"This is a test message including\nnewlines"},{"status":true,"code":222,"source":"This is a test message including\nnewlines"}]

 

 The above JSON string can be formatted nicely by most tools - e.g. JSON pretty print - https://jsonformatter.org/json-pretty-print

 

The below string including the JSONErrorMultiple_1.0 key (but formatted correctly) also works:

 

{"<JSONErrorMultiple_1.0>":[{"status": true,"code": 111,"source": "This is a test message including\nnewlines"},{"status": true,"code": 222,"source": "This is a test message including\nnewlines"}]}

 

 

I often use LabVIEW projects.  Projects may contain libraries, classes, etc.

 

Changing the contents of any component (such as a library) within a project causes the project file to change -- even though the project definition itself shouldn't have actually changed. For instance, if this is my project:

_carl_0-1656622304965.png

and I delete a VI that is inside an .lvlib, the project file itself claims to have had an attribute change:

_carl_2-1656622426038.png

_carl_3-1656622515498.png

In theory, this top-level project change isn't necessary -- since the project should just reference the library, and only the library should reflect a change.

 

These unnecessary file changes make it trickier to deal with source control, merging code, tracking changes, etc, along with adding one more file that you get prompted to save every time you close a project.

Imagine you save a new VI and LabVIEW automatically creates a suitable icon based on various information, such as the VI name, library, class and documentation.

Even though I use the tools selection in the automatic mode, many times I need some specific tool not accessible in the automatic mode or force one like "Position/Size/Select". Sometimes, mostly designing User Interfaces (UI) that takes all screen, we got the Tools Palette blocking access to something. Then we move the Tools Palette until it get in front of something else.

 

The idea is to have an option to have all buttons in the toolbar. Some programs allows you "dock" just dragging the over the tool bar.

 

Many times we have plenty of space to have all buttons there, if not, we can have a second row of buttons. That will be nice to add more buttons as we wish.

 

tools palette buttons in the toolbar.png

 

PS: I added a swap button between the foreground and background colors. The idea is explained in this thread Swap Colors in Tools Palette.

The request:

The thickness of splitter bars can be resized through the front panel at edit time, but this property is not exposed through property nodes. Why not expose this?

 

Background:

I use splitter bars all the time for resizable GUIs. They're also cumbersome. Many of the feature improvements I'd love to see have already been captured on this forum. In the mean time, I've got tools for automating what I can -- but I've hit a dead end when it comes to resizing the splitters programmatically. This requested property node doesn't exist and pre-sized splitters can't be copied from template VIs using scripting because the "Move" method throws an error.

So the request here is to have an option wherein the array indicators (or controls) can be linked with another array indicator (or control) and can be scrolled synchronously.

 

There could be a property node for that (or invoke node or may be some other way), which will accept the reference of another array and thats all.

 

Sync Scroll

In above example, Array 1 is linked with Array 2, so whenever the user will scroll (or change the index of Array 2, the same change will reflect in Array 1.

String containers have display format Glyphs to help us understand the String Values when the display is Normal, Hex or Escape codes.

 

Integer numeric type containers have them too to show radix.

 

Timestamp containers must be inspected for their display format property to determine if they are in System Time or UTC.   

 

Timestamp Controls, Indicators and Contsants SHOULD have a similar optional display format glyph.

 

This could be used instead of the misleading coercion dots when operations are performed on Timestamps as Seen Here 

When I have an array of clusters and I want to locate the array index where a specific element of the cluster has a certain value, I need to first build an array from the Array of Clusters and then search that to find the Array element I want:

 code example.jpg

 

It would be nice (and cleaner and likely faster) if I could wire the Array of Clusters into an unbundle by name function and select String[] to get the array of string element to search.

In addition, if the cluster contained nested clusters, I could access them the same way, using the dot notation alrerady supported.  For example, the unbundle would let me select 'cluster1.subcluster2.String[]' to access the subarray of an element.

 

code example2.jpg 

 

The venerable Array Size function should just resize itself for the number of dimensions on the input array and have each dimension's size emitted with a separate scalar output.

The Find Items With No Callers dialog box in Project could use a Remove From Project feature. Currenly, we have to use Go To, then remove the VI, then generate a new  Find Items With No Callers list.

 

remove_from_project.png

(This is different and less controversional than  this related old idea)

 

Arrays of timestamps only contain legal values and can even be sorted. We can use "search 1D array" to find a matching timestamp just fine.

 

As with DBLs, there might be a very close array value that is a few LSBs off, but well within the error of the experiment so it is sufficient to find the closest value. We can always test later if that value is close enough for what we need or if "not found" would be a better result.

 

If we have a sorted input array, the easiest solution is "threshold 1D array" giving us a fractional index of a linearly interpolated value. For some unknown reason, timestamps are not allowed for the inputs, limiting the usefulness of the tool. One possible workaround is to convert to DBLs, with the disadvantage that quite a few bits are dropped (timestamp: 128 bits, DBL: 64bits).

 

Similarly, "Interpolate 1D array" also does not allow timestamp inputs. In both cases, there is an obvious and unique result that is IMHO in no way confusing or controversial.

 

 

 

IDEA Summary: "Threshold 1D Array" and "Interpolate 1D Array" should work with timestamps.

 

 

 

One of the fiddly things I seem to do more than I'd like is adjust the bottom of block diagram comments to the right height. At a minimum there, but also for similar text boxes on the front panel or subdiagram labels, etc. I'd like to have a snap feature that sizes to a multiple of the text height. Examples:

 

With the three nodes aligned to Top, we get that annoying bend in the error wires. The spacing between Refnum and Error wires is one pixel greater on the Property Node than on To More Specific Class.

 

Align TMSC Terminals.png

 

Thoughts?

Have VI in the project windows behave like SubVI so when you CTRL + Double Click on one the SubVI FP and BD opens (and the BD is frontmost).

                             

                              lvproj : be able to rename a folder

 

SR2.png

 

             SR3.png

Since LabVIEW 2017, the default build specification check the option "Allow future versions of the LabVIEW Runtime to run this application".

 

I don't undertstand why it is checked by default when you read the help that said "Disabling this option prevents any changes to the performance profiles and helps you avoid unexpected problems resulting from compiler upgrades."

 

Because NI and me doesn't know the future, NI will never garanty that your application will run with all the future LV Runtime. I know it well because I'm facing this issue with le LV RT 2020 that breaks the execution of different application that I have buid in 2017 SP1.

 

The behavior is a little strange too, because, even if you have the run-time use to build the application on your computer, the application will use the highest one present one the computer.

 

This options can be very usefull, and I appreciate it, but maybe we need to have more control on it. So my idea is to give to the user the ability to list supported or unsupported LabVIEW Runtime.

 

This will help us managing future LV Runtime without having to recompile the application which seems to be the goal of this option.

 

for Example :

 

[MyApplication]

ExcludeLVRTe = "2020,2021"

 

Regards

Is LabVIEW available for Android based systems and other touch interface systems.If not how about using LabVIEW for mobile measurements using these systems.

The last decade has seen a fantastic development in using neuronal networks to analyze data. Neuronal networks allow doing nowadays feasts that were unimaginable a decade ago at a tremendous speed. The latest release of LabVIEW allows using old TensorFlow versions <= 1.14. About four years ago, TensorFlow switched to TensorFlow 2.0, which resulted in a significant transformation in how models are organized. Models developed in TensorFlow <2.0 are incompatible with current standards. If National Instruments aims to maintain its position in the market of computer vision, developing tools to use current TensorFlow versions is a MUST.