LabVIEW Idea Exchange

Getting a date / time time stamp is not uncommon while developing. This Type def should have a unique icon rather than the default.

A malleable VI on a block diagram can be converted from an Instance VI to a Standard VI, which I've found useful to aid debugging. Unfortunately this modifies the calling code and requires the changes to be reverted to restore the original malleable VI.

This idea is to provide an additional right-click option for malleable VIs - View Instance VI. This would open the instance VI in memory, and allow read-only viewing of the block diagram.

This is useful when examining how the Type Specialization Structure cases are being evaluated given the currently wired inputs to a malleable VI. It also offers ability to quickly view the instance VI data types, helping determine which malleable input wires are *actually* broken. In the example below LabVIEW shows all of the inputs to Stall Data Flow.vim as broken, though viewing the instance VI shows only one input is actually broken.

When the Instance VI is opened for viewing, it wouldn't offer any runtime debugging, but means no changes need to be made to the calling VI when performing static code analysis at edit time.

The ability to view instance VIs already exists in LabVIEW through VI scripting (see example below), but would be nicer to have quick access to it when right-clicking a malleable VI.

The Swap Values node only supports a Boolean input on the '?' terminal.

It should also support an error cluster input, in the same way as the Select node (pictured) and many other nodes with Boolean inputs.

When a TLS Configuration Refnum is wired to "Not a Number/Path/Refnum" it always returns true, even though the TLS Configuration Refnum has been correctly created and is valid.

The idea is for "Not a Number/Path/Refnum" to handle the TLS Configuration Refnum and return false when the refnum is valid.

Currently, when you programmatically build an application using the "Build" VI of the App Builder API, you have no feedback (such as build details, progress percentage, warnings, errors...) and no ability to cancel while it builds.

So you have no idea how long it will take to build and cannot cancel if it takes too long.

It would be great to have these interactions, just like with the manual build:

The Build VI could have 2 notifiers or user events as additional inputs:

- 1 to receive build details, progress percentage, warnings and errors

- 1 to send the Cancel command

These additional inputs would be optional and default to invalid refnums, which would mean "do not use the feature".

Hello LabVIEW Experts.

I am using LV 2017 (Not sure how it works in Recent Versions of LabVIEW). Sorry if its fixed in Recent versions.

Started this thread to share my recent learning/bug.

It all started like this.

One my Engineer was re-architecturing existing LabVIEW Application and it has 40+ States/Cases Defined- Out of which two were identical and he is not able to figure out the duplicate.

We spend sometime to resolve by sorting and finding the duplicate.

Later i was working on the same to figure out why cant LabVIEW Highlight the issue/restrict from adding.

LabVIEW does restricts User from adding identical Items when using Edit Items of Enum Properties.

But it allows me to add identical items when users adds using shortcut/add items.

During this experiment i also found that LabVIEW doesn't allow user to create (Make Type Def) if the items are identical.

The above behavior is perfect but there should be a warning why they are not able to (Make Type Def)

I have Few Points on this.

1. There should be Error Warning/Highlight  to make user to debugg where the identical cases located (helpful when more states are mapped)

2.There should the restriction in adding items at all levels (all possible options to add items)

3.There should be an warning why user cannot (Make Type Def) when there are identical items.

BSOD with error message: "SYSTEM_THREAD_EXCEPTION_NOT_HANDLED"

-> https://forums.ni.com/t5/FIRST-Robotics-Competition/nipcibrd-sys-SYSTEM-THREAD-EXCEPTION-NOT-HANDLED/ta-p/4198336

Hello community,

I would like to introduce the idea of having the selector label being able to break into multiline if the string of selections, handled by this case, is too long for the width of the case / event structure.

I work a lot with enums, either for indicating states or for named indices in arrays. If one case handles some of them and they are not subsequent, the list quick gets quite long, so I have to stretch the block diagram very wide to have them all displayed. Even more obviously this problem is to be seen with event structures, using the the same frame for a lot of events on a number of different controls.

The size of the selector label could increase downwards like the subdiagram label.

What do you think about this?

It can be difficult to go back to the Search Results window when searching for subVIs or text in a project with many open VIs.

It'd be great if the Search Results window had an "Always on top?" option. The screenshot below shows a possible implementation, using a tickbox.

I'd be happy for the default value of the tickbox to be false (unticked). The default behaviour would be identical to the current behaviour.

When the option is ticked the Search Results window would float on top of other VI windows, similar to how the Probe window floats on top.

This would make life easier when going back and forth between a few results, with many VIs already open, especially when so many VIs are open that all LabVIEW windows have collapsed into one tall list in the Windows taskbar.

This feature is not terribly impactful, but has a high benefit-to-effort ratio, due to the very small implementation effort.

Thanks

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.