LabVIEW Idea Exchange

Suppose that in the scenario seen below we would like to merge the error out terminal of VI 2.vi back into the main error wire. This is, of course, a common programming pattern.

Currently we would need to insert a Merge Errors node into the existing wire (Pressing Ctrl + Space, typing "erg", then Ctrl + I is probably the quickest way to do this), then wire the error wire as desired. Currently creating a wire from the error out terminal and ending that wire onto the existing error wire results in broken wires, as seen below.

It would be useful to have an option that specifies that a Merge Errors node would automatically be inserted in this case. That option could be named something like "Automatically insert the Merge Errors node when suitable", and could be located in the Tools >> Options... menu alongside options such as "Place structures with Auto Grow enabled" or "Auto-insert Feedback Node in cycles".

When the "Automatically insert the Merge Errors node when suitable" option is ticked, a Merge Errors node would automatically be inserted in the scenario described earlier, as seen below. This would save the few seconds required to execute the Ctrl + Space, "erg", Ctrl + I sequence.

Notes

• I would be happy if the default value of the "Automatically insert the Merge Errors node when suitable" option would be unticked, which would maintain the current default behaviour.
• Even if the option would be ticked (enabled) by default, I think it would still make sense from a usability point of view. I suspect that the number of times people intentionally use this feature would be greater than the number of times that people wire error wires together by mistake and would wish for the wires to be broken.

Thanks!

Benefits

• Removes the need to use a separate Color Box Constant and Bundle By Name node when writing to VI server properties that take the LvFontTypeDef.ctl as an input.
• More intuitive representation (a colour displayed as a visual colour rather than just a number).

Notes

• The underlying data type of the Color Box is U32. Hopefully this means that this change would be "transparent" to the compiler. The change would affect only the visual appearance and  would improve the human interaction with this typedef cluster.

Here's how we currently make cluster element labels appear, and a proposed idea for improvement.

Hi all,

image processing is not anymore the "tough stuff"/"niche" of the past. Videos are everywhere now, maybe even more than sounds. So functions that handle video should be included in the cross-platform standard labview, at least for the essential functions (reading/writing files with a minimal set of codecs, acquisition of frames through ip or usb for common protocols, conversion between image format for display and processable data). This would attract a lot of young users. It would also jumpstart future developments of labview in the direction of AI.

Thx

VI Analyzer is great tool but can only perform static analysis on VI (as far as I know). It could be nice to run some tests on libraries / classes or even projects files as well to enforce good practices. 

Every now and then, I stumble upon the following error when trying to use the "Match Regular Expression" node in a inlined/malleable VI:

If I understand correctly this discussion, this is because it is an XNode, which is currently (or definitively) not supported in inlined VIs.

But further in the discussion, it is said that an exception was added in the compiler to allow inlining the "Error Ring" XNode.

My idea is to consider adding the same exception for the "Match Regular Expression" XNode, or make any modification that would result in this node being inlinable.

Also, there is nothing in the generated code of the "Match Regular Expression" XNode that prevents inlining!

All it really does is using a CLFN to call function "MatchRegExpEfficient" from the LabVIEW library.

Regards,

Raphaël.

The problem that height of local variable is 17 pix, and terminal - 16 pix, but distance between terminals in unbundle function is 15 pix.

As result - aligning to vertical compress caused steps in wires:

Right nowterminals/local variables should be slighly overlapped for "step edge free" wiring.

Please synchronize size of these icons with distance between terminals (to 16 pixels - seems to be ideal size)

Not sure if it was already in Idea Exchange or not.

Andrey.

When working in LabVIEW in low light conditions, it would be nice to be able to have a quick way to switch to a dark mode, where the default block diagram colour would be a mid-dark-grey.