LabVIEW Idea Exchange

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

Problem

Maps auto-index just like an Array of Clusters, but the tunnels do not offer the same right-click options. It is not recognised as a cluster:

Right clicking an array of clusters auto-indexing tunnelRight clicking an array of clusters auto-indexing tunnel

Right clicking a map auto-indexing tunnelRight clicking a map auto-indexing tunnel

Hence it is not so easy to place an Unbundle node.

 

Solution

I would love LabVIEW to treat right-clicking on a Map's auto-Index tunnel in the same way as it does right-clicking on that of an Array of Clusters, so then it is easy to choose the appropriate Unbundle node.

The screenshot below shows the welcome or splash screens of LabVIEW 2021 Community Edition and LabVIEW 2020 Community Edition.

The 2021 splash screen should display the version, i.e. "2021".

 

It would also be useful for it to display "Community Edition" like the 2020 version does.

1 (edited).png

Thanks

LV2021 has a new "feature" called "Auto-Routing" (this is not Auto-Wiring, which can be deactivated in the options!). Auto-Routing moves wires around if you touch for example Sub-VIs.

Especially in compact VIs this function is a disaster right now. Sometimes for example wires will go "through" Sub-VIs so that an output leaves the Sub-VI at the wrong side resulting in a VI which is terrible to read:

1. Original Snippet of a VI:

Before.PNG

2. Same snippet, I just moved the "Get Variant Attribute Function" by one pixel to the right:

After.PNG

First we thought this is a bug, but the support told us it is a feature. But please: Let us deactivate this "function" in the options. I have colleagues telling me they would stop using LabVIEW if this remains as it is right now.

There are several great ideas on this Idea Exchange that were marked as Completed because they were implemented in NXG.

Although arguments could probably have previously been made that this wasn't really "complete" for most requestors, it was reasonable given the idea that NXG would replace LabVIEW 202x.

 

Given the updated fate of NXG, can these posts all be reevaluated and marked as either New or In Development, as appropriate?

If the evaluation is too effort-intensive, can they all be marked as New again?

LabVIEW currently allows users to execute a MATLAB script inside the "MATLAB Script" structure, which lets you add inputs/outputs to the edge, set datatypes, and then type your MATLAB code in the central box.

 

If you already have a MATLAB script, you can use the right-click menu to "Import" (and conversely, you can test a script in LabVIEW and then Export it, if you wanted).

 

However, you cannot link to a script by path. Importing simply copy-pastes the content into the Script node. This behaviour, whilst probably useful in some cases (avoid future changes to the .m file breaking your nicely tested LabVIEW code) is different to most other nodes I can think of (Call Library Function Node, Python Node, .NET methods, ...).

 

Please add an option to pass a path to a "myFunction.m" file to the MATLAB execution system rather than copying the contents of a .m file into the structure's box.

(As a workaround, I believe this could be accomplished by running the MATLAB interpreter via command line and using the System Exec node, but that would require various path -> command line string parsing operations, and perhaps complicate cleanup of VIs using MATLAB.)

When you choose Rearrange Cases it should auto-select the current case that you are editing when the window comes up.

This can save programmer time when editing case order.

 

Most of the time I have quite a lot VIs (Blockdiagrams and Frontpanels) opened. Therefore my Windows Taskbar is full of files and it is very annoying to quickly swap between them since they are not identified via their names, only as 'Frontpanel ...' or 'Blockdiagra...'.

 

Most classic programming IDEs keep track of opened files using a taskbar (see picture)

taskbar_IDE.png

 

It would also be nice to sort the opened VIs between Block and Frontpanel.

 

Fixed examples are: Exclipse, Netbeans, Visual Studio Code

Dynamic taskbar (can be positioned anywhere on screen as overlay): Gimp

Here's an enum with a lot of elements:
enum1.png

 

The enum has a built-in right-click menu to 'Select Item', but it's worthless... it does exactly the same thing as clicking on the enum directly:
enum2.png

I think we should replace the 'Select Item' right-click on enums and rings with a Quick Drop-like UI that lets you filter the enum/ring contents and select an item without having to scroll a giant list:
enum3.png

Say I have a VI with an arithmetic function: add, subtract, negate, etc...

 

I would like the ability to programmatically change the output configuration of the function through scripting. Right now (as I understand) you can only read the datatype of the output terminal but not set it. I specifically want to be able to control the fixed-point configuration of the output of these functions through VI Scripting.

 

[admin edit]: I added an attachment to this post pertaining to the first comment on the thread (since comments cannot contain attachments).

When you use Quick Drop to insert a division operation onto a wire: you almost always want the numerator to be automatically wired, and the divisor to be unwired.  Yet, Quick Drop always wires up the denominator.

 

Capture.JPG

 

 

I am not happy when I inherit legacy code where VIs have inconsistent alignment grid options, as shown in the image below.Inconsistent Alignment Grids.jpg

 

My team has coding standards we follow, and those standards include alignment grid options. It is labor-intensive to change alignment grid options on legacy VIs because you have to do it by hand, and clicks quickly add up. I wish I could automate such changes.

 

I’d like to see a few new properties to expose settings available in the editor, as shown below.Alignment Grid Property Nodes.jpg

These properties need to support both read and write.

 

Change the Path Type function output from a signed 16-bit integer to a text ring or enum to aid immediate readability of code and save having to look at the help file:

 

LabVIEW_2018-11-05_09-16-13.pngThe Path Type function returns a signed 16-bit integer indicating the following 3 types of paths.

0: Absolute path

1: Relative path

2: <Not A Path>

 

Unhelpful context help.Unhelpful context help.

 

Text ring would have the least impact on existing primatives: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Path-Type-Function-needs-another-return-for-an-empty-path/idc-p/2588549/highlight/true#M25086

It would be nice if the Error Ring would accept enums.

Enum in Error Ring.PNG

So the Error Ring does not accept an enum (A). Format Into String does (B). So now we need the extra step of putting a Format Into String before the Error Ring (C).

 

This would be more convenient in for instance state machines (D) or functional globals with a function enum.

 

While on it %s on FIS also accepts Booleans. Nice to have the error ring accept them as well, just for completeness.

'Database Variant To Data' cannot be placed in an inline enabled VI making it impossible to use in malleable VIs. 

It would be nice to be able to draw on the power of the 'Database Variant To Data' VI in malleable VIs so we could be more flexible when writing database related code.

 

Please make this possible or offer a workaround (like the polymorphic instances of the VI).

How about an NXG home edition, so folks can try it without any heavy time or cash commitment. It would help acceptance and uptake in the LabView community.

Good day forum

 

Upon wiring an error wire to the termination terminal for timed loop, deletion of the error wire will not necessitate the connection of the terminal. 

TL bug.jpg

 

A fix will be appreciated. Thanks in advanced.

 

Regards

CY

I just ran into a situation today where I had a case structure with approximately 64 frames in it, 48 of which I wanted to remove.

 

The method of right-click the selector, select "Remove Case" (This step is right beside the "Insert Case" which is frustrating), repeat 48 times while the mouse is wandering all over the screen between the case selector and the menu selection..... cue carpal tunnel problems.

 

I really wished I could just either use the "delete" and "insert" buttons to mimic the appropriate menu selections

-OR-

Be able to select multiple cases from the "Rearrange cases" window and select "Delete".

Instead of right click on the Array to Cluster for Cluster Size, double click will be ease for the programmer to select the size of cluster

 

Double click should enable this pop up.

ClusterSize.png

Installers should show the public version of dependencies instead of internal versions.

 

This is a specific example, but I presume this behavior is more widespread:  An Add-On that has a dependency on LabVIEW NXG doesn’t list the (public) version of LabVIEW NXG upon which it depends.

 

The OpenG Library v1.0.0.0 depends on LabVIEW NXG v1.0.  But the installer indicates the version of LabVIEW NXG to be installed is v 4.9.3.49152-0+f0.  To someone not familiar with the internal version numbering for LabVIEW NXG, it’s not obvious that this refers to LabVIEW NXG 1.0. This may lead someone to install an undesired version of NXG.

 

Review.png

 

(I had NXG 2.0 already installed, and I assumed, incorrectly, that the version of NXG that the OpenG dependency referred to would also be NXG 2.0.)

 

By changing some NIPM settings (e.g., enable the "Show full version numbers and infrastructure packages" option), one can logically (but not definitively) deduce the public version that the internal version is referring to:

 

Review 2.png

Having a continuous integration system is an essential component of software development:

Continuous Integration ProcessContinuous Integration Process

This system requires automating the building process.

The LabVIEW development environment unfortunately does not have built-in tools to achieve this easily.

But the community has supplied a few sollutions to achieve this: CLI Tool

 

On of the biggest hurdles that yet remain, is the fact that the application builder is inherently tied to the development environment.

This requires a valid license for the environment and all toolkits / technologies used in the source code of the product you intend to build.

 

My proposal would be to have a special "CI" license in which all required modules and toolkits are activated, and that would allow the development environment to launch in some sort of protected mode that prevents users from actively developping code (while still allowing scripting functions), for the sole purpose of building applications.