X___

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 🙂

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

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

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

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

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

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.

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

I suggest LabdejaVIEW...

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

Clearly not trivially hackable.

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