LabVIEW Idea Exchange

Control and indicator references are currently 19 pixels tall. They should be 16 pixels tall. References would then align better with other items which are already 16 pixels tall, such as the Bundle By Name and Unbundle By Name nodes.

This idea is inspired by this idea and this idea.

Problem: Many native VIs use the Non-reentrant execution reentrancy setting.

Solution: The vast majority of native VIs should use the Preallocated clone reentrancy setting.

• The native VIs that need to use Non-reentrant or Shared clone are few and far between - they should be identified on a case-by-case basis. Their Context Help and/or Detailed Help should explain why they need to be set to Non-reentrant or Shared clone.

The following is a selection of vi.lib VIs that should use Preallocated clone. This selection is meant to serve as a starting point and is not comprehensive.

Notes:

• This idea is related to: The reentrancy of new VIs should be "Preallocated clone" . They both argue in favour of using the Preallocated clone setting more.
• A significant number of native VIs are already configured to use Preallocated clone, which is great.
• There are curious cases where closely related VIs are set to different reentrancy settings. For example, Color to RGB.vi is rightly using Preallocated clone, while RGB to Color.vi is Non-reentrant. Similarly, Trim Whitespace.vi is rightly Preallocated clone, while Normalize End Of Line.vi - which lives next to it on the String palette - is Non-reentrant.
  • This suggest that the reentrancy setting of some native VIs was chosen haphazardly. This needs to be rectified.
• The fact that so many native VIs are non-reentrant partly defeats LabVIEW's remarkable ability to create parallel code easily. Loops that are supposed to be parallel and independent are in fact dependent on each other when they use multiple instances of these non-reentrant native VIs. When an application uses multiple instances of these native VIs it is as if there are "hidden semaphores" that are added between the various call locations that call these native VIs. This leads to less performant applications (more CPU cycles, longer execution time, larger EXE compiled code size).

After working with text-based languages recently, I've become more aware of a very painful flaw in the LabVIEW IDE.

First of all, as software engineer, I like to perform experiments. Make a small change, test it. If it doesn't work, then just use Git to roll back the changes. I've been doing this for years, and with LabVIEW it has been fairly painful. Until recently I didn't realize there was a better way.

Why is it painful? Everytime I use Git to check out a different branch or roll things back, I am forced to close LabVIEW or at least close the project so that LabVIEW detects and loads the new code from disk instead of whatever it has in memory. I lived with that for years because I didn't know any better.

Enter text-based programming and IDEs: VSCode, PyCharm, probably any other modern IDE. I try an experiment, it doesn't work. I roll the changes back in Git and guess what? I don't have to open and close anything! The IDE just automatically detects the file has changed and loads the new file!

When is LabVIEW going to get with the times?

A number of people, myself included, have found it necessary to parse ISO-8601 time strings into time values. The ISO standard has a lot of options, so a complete solution is pretty time-consuming. It would be nice if the string parsing functions in LabVIEW included a format specifier that allowed parsing of ISO-8601 time strings directly.

This is an idea I've been working on for a while. It's time to let others start evaluating it. 🙂

 ^ I included the above for Dmitry Sagatelyan and similar folks who have asked me for these things over the years so they know the mindset to use when evaluating the idea. But it's written up below for LabVIEW users who only know LabVIEW as it stands today (Q3 2024).

Feedback and questions welcome. 

When I add block diagram comments inside a structure, they are often long enough to require several lines.  Since auto-grow is on, I need to stop typing before the comment reaches the edge of the structure, resize the comment to be multi-line, select inside the comment again, and re-start typing.  From then on, the comment word wraps at  my sized width.  Could you make a special character like ctrl-, alt-, or Shift-comment move me to the next line and make the comment that wide, so it word wraps at that width from then on?  While you're at it, could a word-wrapping comment autogrow in height to fit the comment, like a one-line comment auto-grows in width?  Subdiagram comments could use that feature, too.