X___

To add some "clarity" to this mud soup, here is the (verbatim) answer I got regarding our academic license (renewed some time last year) and whether or not I could upgrade to 2021 SP1 now without risking to lose access to my code when my Department decides that the investment in an annual license is too costly: "Dear Customer, Thank you for contacting NI I would like to help you to clarify some information, we can not cancel your Licenses since they are perpetual, what this change means is for these products is that we will not be able to renew its service contract. In order to get again the secondary license for students, access to software updates, technical support and the rest of online services we will need to license you under the new subscription model, but you can still use it. Reviewing your Serial Number, if you don't renew this year and don't want to change to subscription the last version that you can use is the 2021 SP1, you should not have any problem using the 2021 version, since is the last one that you have access." So I "should not have any problem"... unless I do, that is, maybe?

NI is publicly traded and is of course entitled to promote any "forward looking" image of itself as suits its needs. Fundamentally though, there is a difference between the hardware sale expanding and, because it is associated with a LabVIEW sale, a concomitant increase of the "user base", and a language adoption increase. The type of reaction of text programmers to LabVIEW is predictable and hasn't changed in decades. They will revert to text-based development once they realize that drivers exists for their preferred language. The feeling that is expressed here, from long time LabVIEW developers, is that LabVIEW is stale and, after the NXG debacle, dead. There is absolutely no benefit for a new comer to invest the time and effort to become proficient in a development environment that is stuck in 20...10?

Interesting perspective... But on the other hand, it is probably too late to worry about external G developers leaving G. 😒

...

I am using the Compound Arithmetic operator as much as possible. It took me some time to figure out that it is not yet working with matrices. As a side note, the Indicator naming algorithm has problems with the Divide operator (or the ither 3 do wonder to figure out that one input is a matrix 'A' and the other is a constant 'c") 0

I can see why it is defunct... Personally, I would settle with fixing all the decade long bugs and having support be more useful than it has been my experience. Kind of gnaws at one's desire to engineer ambitiously when one has to hack around bugs or longstanding issues.

What are you referring to? "futuristic" features or "super-futuristic" features? Personally, Colonel Kodosky's vision scares the bejesus out of me. I imagine an application whose diagram contains a single icon of itself, which when you click into it, sucks you into the matrix and shreds you to bits... I mean wires.

And meanwhile, Colonel Kodosky is mulling the future of LabVIEW in his fortified Texas compound...

Replacing the Subtract operator by the Compound Arithmetic one fixes the sickness.

Thanks. Not an utter surprise considering that an Intel MBP running Monterey wasn't able to run the standalone either (but runs the development version just fine).

@mahgust BTW, my problem was not to run this standalone app on a M1 machine. The target was an Intel MBP running Monterey. Running it on M1 silicon would be even less likely to work. This being said, if you manage to get it to work, that would be a useful datapoint for me (NI is clueless and doesn't seem to be able to read my report correctly, so I gave up on them).

I am attaching the app (released on a MBP running Catalina). FRETX4.app.zip

This is why I switched to a ThinkPad in Dec. 2020. No regrets whatsoever.

I doubt it. They never asked me for my code, and never answered my questions as to what my failure logs were telling them. Honestly, I had the feeling they really did not care beside just raking the number of support hours they are supposed to log per month. But it's just my disappointed customer opinion, obviously.

We shall see about that. Having to subscribe to get a bug fix release would be the nail in the coffin in my not so humble opinion. But in any case, I am fine with 2019 SP1 as I have no use for secure HTTP. The recommendation to upgrade by the NI engineers I dealt with to solve (and eventually did not solve) my recent problems, take a fresh new perspective in this context! At the time that sounded to me like a stupid advice. Now it sounds like a sneaky marketing ploy...

Discussing the new SaaS LabVIEW model with the IT officer in charge of paying for our Departmental subscription, it dawned on to me that they could very conceivably decide not to continue paying for our license at any point in the future, due to the dwindling demand for LabVIEW in industry (and increasing pull to Python and other alternative). This would leave us peons to have to shell for individual seat licenses from our meager federal grants, something that is not sustainable. In other words, I have concluded that I will try out LV 2021 SP1 when it is released (presumably not yet SaaS), and if no major bugs prevent me from working with it, I will stop there and start migrating all my applications to py-prefix named ones. Otherwise, I will stick to LV 2019 and do the same. To each his/her/their own ambition, I guess.

Sending my source code to my colleague, he was able to run it as a LV 2021 VI on macOS Monterey, which makes me hopeful that it can be released as a standalone app compatible for this platform, but I am not clear why doing so from a Catalina platform fails.

I usually develop LabVIEW code on and for Windows (I used a MBP in the past, but exclusively developed within a Windows VM running on Parallel Desktop). A colleague of mine wanted to run an old app I had released on macOS a few years ago (labVIEW 17 was in the error log), and he reported that the app did not run anymore. I figured that since he was using macOS Monterey on an Intel MBP, there might be a chance that releasing the app using LV 2021 would work. Since my MBP runs macOS Catalina, I released it on that, sent him the executable and instructed him to download the 2021 RTE. That still doesn't work. I can't even make sense of the mangled error message he sent me. I know that Monterey is not even a term on NI's website, but I would assume that some have tried it already and maybe even released LabVIEW apps on it. Any hint as to what could be a problem in my workflow would be helpful. PS: the app is native G, there is no .NET, Active X or whatnot. I can actually upload the executable if someone wants to try it out on a Monterey Mac.

OK. But even with that (very dated) page: https://labview.brianrenken.com/INI/undoc.htm, I am having trouble figuring it out. In fact, assuming that info is still valid, it would appear that you could define Esys.Instrument.Normal = 8 and so on, to get some arbitrary and insane number of threads. It still doesn't give any control on which core is used (probably because there isn't any way to do that).

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

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

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

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 🙂