LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

LabVIEW access to stdout and stderr

When using LabVIEW in combination with other languages, it would be really nice for LabVIEW to be able to read from and write to the stdout and stderr streams. For example, when writing a dll in C that is to be used by LabVIEW, it would be really nice to be able to see the output and error streams from within LabVIEW. As it stands you have to jump through hoops in another IDE or create a log file or some other workaround if you want to see what might have happened inside the dll to cause it to crash.

View All (2)

In a simple project, the main entry point into an application is usually easy to find:

However, for more complex projects (particularly those utilising libraries/classes) it may not be obvious where to begin:

Proposal:

LabVIEW should provide a mechanism for tagging one or more VIs such that they are easily accessible to someone unfamiliar with the project.

One possible implementation:

Display tagged items as links at the top-level of the project.
Links would be pinned to the top row
Link names would be editable and need not correspond to the name of the item they link to. (e.g. The link "main" may point to "WidgetTester.lvlib:GUI.lvclass:launcher.vi")
For minimal confusion, developers should be encouraged to name the first link "main" (or similar)
In principle links could point to anything interesting, not just the main VI.
Double-clicking a link should open (or navigate to?) the target item

View All (4)

View All (2)

When you compare two Vis, one with a control, and the other one with the same control but with a change on the test justification (You can modify it by clicking on the dropdown menu of text settings, next to the pause button)

If you compare the vis at this moment it only shows this

----------------------------

Difference Type: text justification

As we can see there is missing information regarding other comparissons like label name, object type and detailed description like the following example

----------------------------

Label Name: Label1

Object Type: String

Difference Type: moved

Detailed Description: Changed from "(168,132)" to "(12,71)"

Consider that this is a small scenario (only comparing two indicators) where the difference can be found easily, but if you try this with bigger VIs it will have a lot of missing information

The fact that this information is not available is time consuming, eventhough they can be walked manually the record of changes is compromised

View All (4)

The Compare VI tool is immensely useful, except when identifying changes in case statements, where it is easily "confused". Take for example two VIs where the cases in the case statement are identical except that in one VI there is an additional case at the end, or has a renamed case. When you run the Compare VI tool, everything is out of whack. It shows differences between two case that are named totally different, ignoring the other case that is named exactly the same. When this happens, you end up manually comparing. It would be great if the Compare VI tool would ignore the case order and compare the actual case names when doing a compare, much like a text compare tool would. Maybe even make it an optional setting.

View All (2)

View All (1)

I think it would be a good idea to enable running code formatter, like Darren's Nattify VI, automatically when saving a VI. Currently, most IDEs have built-in formatting tools which promote a unified, clean code style, and programmers don't have to worry about it because the code is automatically cleaned up before saving. I think a similar function would be a great addition to LabVIEW.

In Visual Studio it is called "Run Code Cleanup profile on Save". You can also configure different profiles (different styles or flavors). This option would be nice to have.

It would be great if it were possible to reduce the amount of time spent cleaning up LabVIEW code while keeping the code in decent visual condition.

View All (5)

View All (2)

"Find Callers" for Class Data

I have wasted ~~days~~ weeks of my life tracking down why dependencies are loaded in LabVIEW.

This is because the "Why is this item in Dependencies?" tool isn't particularly useful in larger projects. And it isn't particularly useful because it highlights any file in your project (and not in the dependencies) that is dependent (no matter how indirectly) on the chosen file.

In this example, if I click on "Why is this item in Dependencies?" on library C, I get pointed to a VI in the project (A.a) which has a very indirect dependency on library C.

It would be far more useful to me if I instead only got shown the VIs that directly depended on my dependency (even if they were in dependencies themselves). If I then wanted to follow this up the chain, I could just click on "Why is this item in Dependencies?" again, but on the found item.

There is a small bug in the sorting of VIs by Name in Project Explorer.

If a virtual folder or an auto-populating folder contains VIs named "abc", "abc def", "abc def jkl", when the folder is set to "Arrange By >> Name" Project Explorer displays the VIs in the order 1. abc def jkl; 2. abc def; 3. abc. In other words, when there's a tie the longer name is displayed first. Breaking the tie in favour of the shorter name seems more logical, and is what Project Explorer does when sorting virtual folders.

The screenshot below shows the issue.

Screenshot 2.png

This was noticed in LabVIEW 2022 Q3. Please excuse if it's already been fixed in 2023 Q1.

View All (3)

Deco Text Enable Wrapping Property

View All (4)

Particularly for refactoring code, it would be nice to have a way to only apply changes to re-parented items if they already have a library/class layer in their icon. With other smaller utility VIs, using the Apply Icon To VIs action causes the layer to be added and then I have to go through and eliminate the created layer so the icons look correct again. I'm fine with that as the default behavior but I'd like to have an option to only update icons that already have the NI_Library icon layer for these kind of updates.

VIMs are awesome but when wire inputs are broken they aren't awesome. They'd be awesomer if there was a way to specify that when specific frames of type specialization structures are active, there is a way to get specific strings added to the error info for the caller. Having a way to add custom strings to VIMs would overcome the general "An unsupported data type is wired to this subVI node." error string we're currently given. This can also help differentiate between LabVIEW breaking during type prop for odd (bug) reasons and properly invalid inputs... Do I need to just delete a wire and re-wire the input or do I need to hope the developer provided good VI documentation?

With some additional frames in Type Specialization Structures and maybe something like a subdiagram label but instead it could be a error reporting field at the bottom of a frame, it would be much easier to provide meaningful information back to a developer such as "GUID input only accepts GUID.ctl or a String". Then if the caller breaks with the unsupported data type error for the VIM, error details from the currently active TSSs can be concatenated to the Details string displayed in the Error list dialog. Alternatively, each error message found in TSSs could be separately listed in the Error list.

My 10 second idea:

TSS Error.png

Resulting in the Error list perhaps showing it as either an error or concatenated into the Details:

TSS Error list.png

Empty Variant Function To Variant Palette

Put a copy of the Empty String/Path? on the Variant palette since "this function is also designed to work with variants...; see https://www.ni.com/docs/en-US/bundle/labview/page/glang/empty_string_path.html .

For an example of the difficulty in finding this function, see https://forums.ni.com/t5/forums/editpage/board-id/170/message-id/1248895

For precedent of the same functions on different palettes see the Array to Cluster and Cluster to Array functions on both the array and the cluster palettes.

View All (2)

Hopefully low hanging fruit? I'm constantly checking the error list when working in a VI that's part of a broken class hierarchy to see if the VI itself has errors or if it's just due to a hierarchy error or dependency error. I often repeatedly check it to confirm if the VI I'm currently working in has the errors and could save a bunch of time if something was different about the broken run arrow and I only had to glance at it to confirm I can move elsewhere in my development as expected, or continue to the error list to see what's really broken.

LabVIEW Idea Exchange

LabVIEW access to stdout and stderr

Project should support links (like bookmarks) to main VI

Allow Wire Labels to Dictate Name Inheritance in Bundles

Add information to compared Vis when the caption changes

Add Right Click Menu option to "Find Objects at Edge" for Auto Grow Structures

Compare VI tools that doesn't get tripped up on Case statement names

Estimate and show Time Remaining during LabVIEW Installs

Run Code Cleanup profile (Nattify VI) on Save

LabVIEW.exe Command-Line Argument to Show Block Diagram

"Find Callers" for Class Data

"Flattened String To Variant" node should return "rest of the binary string"

"Why is this item in Dependencies" should only show items that are directly dependent on it

Add the ablity to monitor a compiled executable to "Profile Perfomance and Memory Monitor"

Project Explorer: Fix small bug when VIs are arranged by name

Deco Text Enable Wrapping Property

Option to only Apply Icon To VIs for VIs with an existing NI_Library layer

Type Specialization Structure Error Message

Empty Variant Function To Variant Palette

Show a different broken arrow when the VI doesn't have errors itself.

On auto-generated class palette, properly scope available VIs