What's new in LabVIEW 2021

[FantasticNerd]

18 hours ago, infinitenothing said:

When is LV2021 being released? Seems a bit odd to get everyone excited and then not have the product immediately available.

I asked this question to one of the moderators and they told me the planned release date will be 13th of August.

[crelf]

On 7/28/2021 at 1:16 PM, hooovahh said:

...there had better be a new icon number.  If there is that will be my number one new features of LabVIEW 2021.

We all joke about that, but it's a solid feature that was marketed perhaps a little too much :D

[crelf]

I'm not surprised that the new features/improvements to 2021 aren't earth-shattering.  I expect it will take some time for NI to work out which features from NXG to roll into LabVIEW - but it's perhaps more important for them to determine *how* to roll them in at the moment - I'd much prefer NI to spend time on that for a little while, so we don't get ourselves into the situation of having too many new features in 2022 but the platform becoming unstable.  This is not an easy task.

[infinitenothing]

While I'm extracting "secrets"

Unicode in 2022? (Nods hopefully looking to others to assure me everything is going to be OK)

[ShaunR]

4 hours ago, infinitenothing said:

While I'm extracting "secrets"

Unicode in 2022? (Nods hopefully looking to others to assure me everything is going to be OK)

We've had native UTF8 for years and lots of utils can handle UTF16/32. Just can't display it very easily and none of the file controls/functions support it. It's a UI problem that NI have avoided like the plague.

[X___]

Most relaxing Q&A session of all... 15 minutes of background music. That was necessary to let the breadth and depth of the new features which were crammed within the first 30 min sink in.

I was actually quite impressed that NI finally was on the right track as to what an autowire tool is supposed to do. Not that I am planning to turn it on, but pleasantly surprised nonetheless.

The important link is this: https://www.ni.com/en-us/support/documentation/bugs/21/labview-2021-known-issues.html

1135156 is nasty...

1555422 is sort of amusing for that new functionality. But I guess that is what happens when the feature is not advertised in the public beta site (https://forums.ni.com/t5/LabVIEW-2021-Public-Beta/LabVIEW-2021-Beta-Now-Available/td-p/4144143) 

I believe the "Final Time issued" section is new?

[ShaunR]

10 hours ago, X___ said:

I believe the "Final Time issued" section is new?

A.K.A. Not gonna fix so will memory-hole them.

Was just looking at the SFTP from the beta link you provided.

VI's invoking Command Line? Really?

I've had SFTP for ECL for a while now but never put it in because no-one asked for it. I've been procrastinating about putting in SFTP, SCP, Websockets and MQTT for some time but decided I wanted a better HTTP client first (more configurable than the NI one). I've so many new features I could implement and so little feedback about what people would like to see I've only been updating with things I would find useful which, at this point, is very little than it already supplies.

[X___]

Just curious whether anyone can check whether the 255 character file path limitation is still a thing in LV 2021:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000015AHaSAM&l=en-US

I just got bitten by it again in LV 2019 and it is a silent killer, as it will truncate the input file path to 255 characters without the slightest warning...

[FantasticNerd]

12 hours ago, X___ said:

Just curious whether anyone can check whether the 255 character file path limitation is still a thing in LV 2021:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000015AHaSAM&l=en-US

I just got bitten by it again in LV 2019 and it is a silent killer, as it will truncate the input file path to 255 characters without the slightest warning...

Have you read the KB?

This is still a thing because it is a Windows thing. There is literally nothing LabVIEW or NI can do unless they help Microsoft change this in Windows.

[thols]

3 minutes ago, FantasticNerd said:

Have you read the KB?

This is still a thing because it is a Windows thing. There is literally nothing LabVIEW or NI can do unless they help Microsoft change this in Windows.

And also, its not silent. Creating a file or writing to a file with too long path name will give you error 6.

[ShaunR]

4 hours ago, FantasticNerd said:

There is literally nothing LabVIEW or NI can do unless they help Microsoft change this in Windows.

Of course there is something they could do. I expect the use of the ANSI versions of the file operations is making them resistant. I've my own set of compane equivalent of the native file operations that do it just fine - it's the Path Control that is the problem.

 

 

[X___]

The KB says:

Disclaimer: LabVIEW does not support long path names on Windows. Although Windows includes support to enable LongPaths in the Registry Editor, each individual application must have this support included in the code.

I am reading this as "LabVIEW does not have this support included in the code". Maybe I am reading this wrong. I don't think so, see below.

As for being silent, try the following snippet:

 

When prompted for a path, just navigate down a deep folder hierarchy and enter a name long enough such that the sum "folder path" + "file name" is larger than 259 characters (1).

There is NO error. The file is saved with a truncated file name (so that the path remains smaller than 260 characters) (2).

Note 1: if you type a FILE NAME longer than 259 characters in the file dialog box, Windows will beep and prevent you from typing a longer name, so you would know that something is wrong.

Note 2: you can edit the file name in Windows Explorer (as long as the NAME remains below 260 characters), such that the file PATH length is LONGER than 260 characters, so yes, Windows does support path name than are longer than 260 characters.

[X___]

9 hours ago, ShaunR said:

Of course there is something they could do. I expect the use of the ANSI versions of the file operations is making them resistant. I've my own set of compane equivalent of the native file operations that do it just fine - it's the Path Control that is the problem.

I am trying to understand what you are staying but I am obtuse.

In the snippet above, if I connect a constant path whose length is longer than 260 characters (path length not file name, the file name of course needs to be <260 characters), I get an error 6 as @thols mentioned below (but that is not what I am doing, I am using the native file dialog, which results in the file name to be silently truncated).

If I try to save a file with the same extra-long path in Word, it works just fine, as it does in Notepad++, for example.

I do have LongPathsEnabled set to 1 on my Windows 10 Pro system:

I have read some mentions of this failing in Notepad++ for instance, but this turned out to be related to people having the wrong registry settings.

Anyway, I guess I have my question answered: LabVIEW 2021 manages some wire kinks better than before, but as far as file paths, it is still stuck in the past.

[Darren]

27 minutes ago, X___ said:

I do have LongPathsEnabled set to 1 on my Windows 10 Pro system:

Individual apps have to include long path support in order for this setting to have any effect. And LabVIEW 20xx currently has not added this support. Please kudo this idea (if you haven't already) to increase the visibility of the feature request with LabVIEW R&D.

[ShaunR]

48 minutes ago, X___ said:

I am trying to understand what you are staying but I am obtuse.

To use long pathnames you need

1. Registry setting.
2. Use the filename functions ending in W (not A) e.g. CreateFileW instead of CreateFileA.
3. LongPath in the executable manifest.

The native LabVIEW functions use the functions ending in A, under the hood, which is why I wrote drop-in replacements for the native file functions which uses the functions ending in W. When you create an executable, you have the option to define a manifest file so the replacements work in the built executable. So as long as the registry or policy enables long paths, the built executables work fine for >260.

[X___]

43 minutes ago, Darren said:

Individual apps have to include long path support in order for this setting to have any effect. And LabVIEW 20xx currently has not added this support. Please kudo this idea (if you haven't already) to increase the visibility of the feature request with LabVIEW R&D.

I don't think I'll be around for LabVIEW 21xx.

[X___]

13 minutes ago, ShaunR said:

To use long pathnames you need

1. Registry setting.
2. Use the filename functions ending in W (not A) e.g. CreateFileW instead of CreateFileA.
3. LongPath in the executable manifest.

The native LabVIEW functions use the functions ending in A, under the hood, which is why I wrote drop-in replacements for the native file functions which uses the functions ending in W. When you create an executable, you have the option to define a manifest file so the replacements work in the built executable. So as long as the registry or policy enables long paths, the built executables work fine for >260.

Clearly not trivially hackable.

[Rolf Kalbermatter]

On 9/3/2021 at 11:13 PM, X___ said:

I am trying to understand what you are staying but I am obtuse.

As Shaun already more or less explained it is a multilayered problem.

1) The LabVIEW path control has internally following limitations:

    - a path element (single directory level or filename) can be at most 255 characters.

    - the path can have at most 65535 levels

The only practical limit that is even remotely ever reachable is the 255 character limit per path level, but I think we all agree that if you get that long path level names you have probably other problems to tackle first.  😀 (such as getting out of the straightjacket they for sure have put you in already).

2) Traditionally Windows only supported long path names when you used the Widechar file IO functions and also only when you prepended the path string with a special character sequence. LabVIEWs lack of native support for Unicode made that basically impossible. Long path names are limited to 32000 something characters.

3) Somewhere along the line of Windows versions (7, 8?) the requirement for the special character sequence prepending seems to have relaxed.

4) Since Windows 10 you can enable a registry setting that also allows the ANSI functions to support long path names.

So while theoretically there is now a way to support long path names in LabVIEW on Windows 10 this is hampered by a tiny little snag. The path conversion routines between LabVIEW paths and native paths never had to deal with such names since Windows until recently didn't support it for the ANSI functions, and there are some assumptions that paths can't get more than MAX_PATH name characters. This is simply for performance. With a maximum fixed size you don't need to preflight the path to determine a maximum size to allocate a dynamic buffer for, that you then have to properly deallocate afterwards. Instead you simply declare a buffer on the stack, which is basically nothing more than a constant offset added to the stack pointer and all is well. Very fast and very limiting! This is where it is currently still going wrong.

Now reviewing the path manager code paths to all properly use dynamically allocated buffers would be possible but quite tedious. And it doesn't really solve the problem fully since you still need to go and change an obscure registry setting to enable it to work on a specific computer. And it doesn't solve another big problem, that of localized path names. Any character outside the standard 7-bit ASCII code will NOT transfer well between systems with different locales.

To solve this LabVIEW will need some more involved path manager changes. First the path needs to support Unicode. That is actually doable since the Path data type is a private data type so how LabVIEW stores path data inside the handle is completely private and it could easily change that format to use whatever is the native prefered Unicode char for the current platform. On Windows this would be a 16 bit WCHAR, on other platforms it would be either a wchar or an UTF8 char. It wouldn't really matter since the only other relevant platforms are all Linux or Mac BSD based and use by default UTF8 for filenames.

When the path needs to be externalized (LabVIEW speak is flattened) it always would be converted to and from UTF8 to the native format. Now LabVIEW can convert its Path to whatever is the native path type (WCHAR string on Windows, UTF8 string on other platforms) and it support long path names and international paths all in one go.

The UTF8 format of externalized paths wouldn't be strictly compatible with the current paths, but for all practical purposes it would be not really worse than it is now. The only special case would be when saving VIs for previous versions where it would have to change paths from UTF8 to ASCII at a certain version.

I kind of did attempt to do something like that for the OpenG ZIP library but it is hacky and error prone since I can't really go and change the LabVIEW internal data types, so I had to define my own data type that represents a Unicode capable path and then create functions for every single file function that I wanted to use to use this new path, basically rewriting a large part of the LabVIEW Path and File Manager component. It's ugly and really took away most of my motivation to work on that package anymore.

I have another private library that I used in a grey past to create the LLB Viewer File Explorer extension before NI made one themselves, and I have modified that to support this type of file paths. Works quite well in fact but it is all very legacy by now. But it did have long file name and local independent file name support some 15 years ago already with an API that looked almost exactly like the LabVIEW File and Path Managers.

Edited September 6, 2021 by Rolf Kalbermatter

[ShaunR]

27 minutes ago, Rolf Kalbermatter said:

4) Since Windows 10 you can enable a registry setting that also allows the ANSI functions to support long path names.

Only the Widechar functions support it. The functions are listed at the end of the link I posted.

[Rolf Kalbermatter]

12 minutes ago, ShaunR said:

Only the Widechar functions support it. The functions are listed at the end of the link I posted.

Actually, the Widechar functions supported it since at least Windows 2000 but only with the special prefix. That registry hack and application manifest is needed to not have to use this prefix, so yes porting to Widechar functions is in either case needed to support long file paths. My library adds the special prefix and didn't have to go through manifests and registry settings to use the feature.

Edited September 6, 2021 by Rolf Kalbermatter

[hooovahh]

Also I'd love for proper unicode and long path support for file paths.

I have hit the too long file path when building RT software.  LabVIEW copies parts of the source to the destination location temporarily, and duplicates the hierarchy.  This might mean that your usable practical path, is only have half of your 260-ish characters.  The easy fix I've been doing is setting my build location to some place like C:\RT Build and then having a post build VI take care of the clean up and renaming.