X___

I am afraid I have nothing to contribute to that question, but this post calls for that question from me: is there a possibility, in addition to setting the number of threads, to specify how many cores are used?

Parallelism is great, but when using it indiscriminately, this can hog a PC. Having an option to programmatically (*) limit the numbers of cores that LabVIEW can claim would be nice, assuming that this is not something that is under the exclusive OS control.

(*) the tool pointed out in the OP seems to require a restart of LabVIEW, which calls for the related question: how does this work in a standalone executable?

That's correct. Moreover, there is no versioning for NXG, and users of LabVIEW version 6 and under are apparently not qualifying either...

Sort of squares with the links I posted. But that's the life of software or most products in general...

It would be preposterous for NI to claim that they will bring LabVIEW to the TIOBE index or similar ranking lists, but there is a difference between running out of idea for a product (which might be the case and justify your prediction of the future demise of the language) and corporate double-speak like what we were served when they axed NXG: https://forums.ni.com/t5/LabVIEW/Our-Commitment-to-LabVIEW-as-we-Expand-our-Software-Portfolio/td-p/4101878

8 hours ago, Rolf Kalbermatter said:

But if you look at what is happening with LabWindows CVI now, it may be an indication about what they are heading for with LabVIEW in the coming 10 years. And NI's track record with acquired software and how they treated it is not very encouraging either. Ever heard of HIQ, Lookout, BridgeVIEW, Electronics Workbench and a few others?

What is happening with LabWindows/CVI?

I have heard of HiQ, even tried it when it became an NI product. It appears dead according to the forums: https://forums.ni.com/t5/HiQ/bd-p/160

The others ring a bell, but I never tried them.

This thread on Lookout tells it all: https://forums.ni.com/t5/Lookout/NI-Lookout-Support/td-p/3278274

BridgeView is now LabVIEW DSC according to this: https://forums.ni.com/t5/LabVIEW/What-is-or-was-BridgeVIEW/td-p/248264

Electronics Workbench is now MultiSim according to Wikipedia: https://en.wikipedia.org/wiki/NI_Multisim

16 hours ago, ShaunR said:

Tin foil hat time

We know there were discussions about SaaS that the LabVIEW dev team were resisting. I think this is the real reason why AQ left.

He didn't leave and in fact should be back by now: 

5 hours ago, Rolf Kalbermatter said:

Unfortunately I do think there is a strategy behind this. In the past NI was a company centered around hardware sales in the form of computer plugin cards. The fact that they were a lot better in providing good and well designed supporting software for that hardware was for years a distinguishing factor that made them grow while the competition had a hard catch up game to do and eventually all more or less faltered. The software in itself never really was the money maker, much of it even was given away free with the hardware and was considered a supporting expenditure that was financed with part of the profit for the hardware. 

When they had pretty much the whole market of what they possibly could get, they run into the problem that there was very little grow in this market anymore for them. So they set out to find new markets and moved towards turn key semiconductor testers that they could sell a dozen a time to the big semiconductor manufacturers for big money. Suddenly those pesky DAQ cards and DAQ boxes were just a margin anymore and they were at best a supporting technology, but the accompanying software was getting more an more a costly burden rather than a supporting technology. Nowadays there isn't one NI marketing but each division has pretty much its own marketing department and is also its independent profit center. And then an independent software/LabVIEW division suddenly shows mainly as a post in the cost category that doesn't bring in as much as it costs. So they try to increase the income but I think they missed that train already 15 years ago when they were refusing to consider other venues for LabVIEW. Nowadays the LabVIEW community is a marginalized small group of enthusiast who are looked at by the rest of the industry as a bunch of crazies who can't let go of their pet IDE and the rest of the world has moved on to Python and .Net and will move on to another hype in a few years.

And the higher NI management is likely aware of that. While I do believe that the LabVIEW developers and the managers who directly work there really would like to make LabVIEW a good and flourishing product, I feel the higher management has already decided that this is going to be a dead end and have very little intentions to do anything else than let it bleed to death, so they can get rid of that liability.

That is about my feeling also, but it has more value coming from a former insider. At the very least, I don't expect any official denial coming from NI 🙂

23 hours ago, ShaunR said:

You can put a lot of stuff in a VI and unpack it when run.

That was what the Advanced Plotting Toolkit was doing, storing a minimal Python exe as a string constant and running it as soon as started.

But that was not as a tag, which I still don't see what it can do besides store stuff (not just strings).

7 hours ago, ShaunR said:

If they had put "Synergy" in there we would have had a full house in BS Bingo.  This seems to have been written by PR and is usually an indication of few tangible achievements.

Maybe not:

https://www.edn.com/profiles-in-test-eric-starkloff-ni/

https://www.chron.com/news/article/BW-National-Instruments-Leader-to-Deliver-D2M-1663383.php

https://www.ni.com/pdf/q400newsletters/us/q400inlpg1to13.pdf

https://www.electronicdesign.com/search?ebm_electronicdesign[query]=eric starkloff

10 hours ago, Mads said:

What I do not understand about the decision to change it into a subscription model is the timing (and pricing). With the (predicted) failure of NXG, NI should lay low and try to save as many customers as possible from running off scared. Looking at the numbers and seeing how much money they threw at NXG it seems as if they think; well we need to cover that cost...

What they should do is conclude that they need to seriously change (revert?) how they run their business (especially the LabVIEW development projects). The true cost of NXG will continue to rise by causing damage to their brand; unless they *simplify* ownership, *lower* the price, increase the work to recruit new (starting with students) and keep customers -AND invest the required amounts into developing a proper "NXG" (it is the foundation for the ecosystem that makes NI great, the cost of it has to be divided on the whole system, not just the SW itself).

When that work is well on its way, and only then, they can think about subscriptions (the SSP solution is much more customer friendly though) and increased prices.

You need to talk to this guy: https://wallmine.com/people/16547/eric-howard-starkloff whose bio on NI's website (https://www.ni.com/en-us/about-ni/leadership/starkloff.html) says:

Quote

Eric began his career at NI as an application engineer and, for more than two decades, has been instrumental in defining and implementing the company’s strategic direction. His leadership is focused on delivering results to NI’s key stakeholders through a strategy that’s built on disruptive technology and informed by customer needs to get accessible technology to market faster.

There is a typo above though: read shareholders instead of stakeholders. I guess "disruptive" should be understood as meaning "disrupt your customers' ability to stay ahead" and "informed by customer needs" means... exactly the opposite. At least the "get accessible technology to market faster" was not what I would have called NXG's experiment.

3 hours ago, ShaunR said:

If it is what I think you are referencing then it is when the VI is run (run when opened), rather than the source code itself. It is also detectable by inspection but double clicking on the VI runs it. This is why most of us place a new, unknown, VI on a diagram or run something like this.

Tags Detect.vi 12.61 kB · 3 downloads

 

Why is the "RunOnOpened" PN in the loop and why are persistent tags suspicious?

5 hours ago, Gribo said:

Got to love how the 1 year subscription is 6K CAD and the 3 years is 24K CAD..

NI might know something about the value of the Canadian dollars that you may want to know...

17 hours ago, JB_1592 said:

I don't know about that. Maybe for someone that buys an entire new license at full cost every X number of years, but for those that kept their SSP up to date it seems like it will more than double the annual cost.

The lower startup cost is nice, but irrelevant when we have had our licenses for years, and doesn't make up for the higher long term costs, IMO. I really hope they start talking about renewal discounts at some point, but... who knows?

The only benefit I see to this is that it might make the decision to add/drop licenses from our VLA simpler. Now we tend to renew unused licenses every year just so we don't get slammed with the 5x higher cost if we need to rebuy them.

Interesting. I forgot that maintaining an active SSP was cheaper than paying for the software upfront (I am not dealing with that aspect).

Now I wonder what "access to historical versions" means. Can we try to run LabVIEW 1.0 on a Macintosh VM? LabvVIEW 2.5 on a Windows 3.1 VM? That could be a lot of fun.

NI stock is doing fine. Some corporate brass sold a bunch of their shares (to the benefit of some family trusts...) either creating a dip in the stock or anticipating it, but that was transitory, and things are back to normal.

The point is that LV was most likely never a driver of sales and as someone said before, they don't need it to sell their hardware anymore, thanks indeed to the free support of other development environments, which did not exist in the 90's.

I am repeating myself, but as much as I enjoy graphical programming, I see no future for it in the academic field, where open sourcing and reproducibility (R, Jupyter or Mathematica notebooks being one way of ensuring it, preferably online), is (slowly) becoming the norm.

Obviously, the situation is a bit different in industry.

I honestly don't see what the big deal is with this announcement (which I pictured earlier as a price cut), as surely a couple thousand dollars per workstation per year can't create that much of a difference for a successful company, even a small one that would decide to wait and see before upgrading to the new yearly bug fix.  Last year's official abandonment of any effort to revamp LV, was the nail in the coffin. This is just a confirmation that there is nothing more to expect from it.

Sounds reasonable. In this scheme, it seems that you can hold off on upgrades, as long as you pay your subscription. So, for most practical purposes it is a cleverly framed price cut...

I'd be curious to know what will happen to released applications (standalone) and toolkits.

As an update to my specific case, just in case this can be of use to someone facing the same issues, I finally managed to get access to support, after some surrealistic back and forth with the same guy at NI (part of the surreal nature of the experience is due to my decision to call repeatedly despite having faced failure after failure - I guess there is merit in repeating the failed attempt over and over again after all!).

He finally mentioned a "product ID" number associated with our departmental account (even the name of which for some reason is not recorded properly by NI).

No one thought about mentioning this number until that umpteenth call, even though it is listed as one of the options to verify the service program membership:

The question now is whether anyone with that service ID can request support irrespective of them being officially associated with our service program membership.

I wouldn't bet on Ni knowing the answer to that one...

Let me throw a wrench into that ambitiously engineered green picture.

As an academic researcher, I have witnessed a progressive retreat of NI from campuses over the years. This will completely dry up their potential pool of users when students become engineers. Consider us the canaries in the coal mines.

Recently, I was denied online support (couldn't fill a service request) because supposedly I was not associated with the Departmental license number I have been using for over 20 years. Trying to add my name to a putative authorized users list failed (NI seems incapable of figuring out how to do that), so I was invited to go through the IT person who is nominally in charge of renewing the license (which NI forgot to remind them to do during the pandemic, which added to the confusion). Imagine how convenient that would be... 

Before this, my last experience with NI support was rather negative (I discussed the symptoms I was experiencing - and still am - here:

). I provided all the logs I could, had a live demo session with no less than 2 support engineers, and they finally decided to give up after supposedly escalating the issue. Unsurprisingly, their last resort suggestion was to upgrade to the newest version (I cautiously stuck to 2019 SP1 to avoid the ripple effects of the pandemic and the NXG fiasco). So if this was due to a bug, the hope was that this undiagnosed bug had been fixed in the latest version...magically I suppose.

On 11/12/2021 at 7:50 AM, Rolf Kalbermatter said:

When I started at NI Switzerland in 1992, things were indeed very different.

Tell us more about that time... Was that before the release of the first Windows version?

I have the two demo disks for the 2.5.1 Windows version sitting on a shelf (never used by me, I just found them among stuff left by a retired employee).

It does hang in LabVIEW 2019 SP1 f4 64 bit Windows 10. I am betting this one will never be fixed.

This being said, how did you create that graph? If I pick a new one and try to manually enter the same upper and lower bound, it will usually just swap their order and not let me change the second one. If I try programmatically to set the max and min range of the scale, I get the following displayed values:

0.000125173

0.000113794

Playing with increment or precision doesn't help...

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.

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.

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.

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.

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...