HYH

Related to mcduff's good reference. Carsten Thomsen was hired as VD to be the mastermind/driver of PXI development and high-speed DAQ. So he has a sentiment for the LabVIEW/DAQ concept. Which ruled the world for some years. And I fully agree with his observation : NI does not directly say what that future is. But it could well be giving up LabVIEW as a general programming language and refocus it to being glue logic for TestStand. This makes sense, seeing how NI has behaved in the recent years. NI once tried to cover all engineering bases creating software toolkits and modules for LabVIEW. There were once more than 100 such. Now "Sound and Vibration 'Toolkit' and 'Measurement Suite'" is one of the last still supported. So they are clearly pulling out of general engineering. Probably too much expensive engineering knowhow required and too little revenue. And then there is the world approaching a World War aspect. With restrictions of what can be sold where in the near future. You don't want to empower a future enemy with advanced tools. The article The Edge referred to, included this nice graphics : I think I have seen that specific illustration too many times over the years. NI is clearly in for re-use. Regards

Hi This is a longstanding problem. Read this long thread and try the options relevant for your situation : https://forums.ni.com/t5/LabVIEW/LabVIEW-community-edition-won-t-activate/td-p/4111658/page/4 Hint : Check whether your Linux version is supported at all. Also read this short text about how it should work in the ideal world : https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000kPkECAU&l=da-DK Regards

Hi It disturbs me that you mention 2018 having the problem. 2018 SP1 is my daily trusted version for whatever I develop, if possible. The last version before NI started optimizing the compiler and who knows what else. And generating problems a galore since then. I have not myself seen the problem in 2018 SP1. Regards

Hi The strength and weakness of LabVIEW is that it is not a clearly pattern'ed development platform. The problem is that a newcomer to LabVIEW will try to google the world to get ideas how to use LabVIEW. And the suggestions will point in all directions. Directions : Classic ( legacy ? ) LabVIEW - Making programs without using events. That is how we did it ( at least ) until 2001 LabVIEW 6.1, which introduced the Event. So all the mechanical engineers lured into the world of the simple LabVIEW suddenly had to consider Events, as used in common Windows programming. They had to become programmers instead of just being engineers solving a problem using this simple system called LabVIEW. There are plenty of books about this. Both describing the legacy concept, as well as the Event concept. Objects in LabVIEW - LVOOP was introduced in 2006/2007 LabVIEW 8.0/8.2. So now the non-programmer was really in trouble. And probably dead by a heart attack. There are not that many books about his subject. But NI was on a wave of innovation. So the next was Actor Framework introduced in 2012. Even fewer books about his. And there were more exotic ( ~ programmer specific ) additions to the LabVIEW language world later on. With even fewer books explaining that. The problem here is not that LabVIEW developed into something with Bell'ls and Whistles. That is natural. But the problem is that NI never clearly stated who were the intended target of all those benefits/additions. The users/customers had to figure out that themselves. Just to make it clear. A mechanical engineer can still use the legacy methods of programming LabVIEW, ignoring Events and Objects. For simple tasks. But he/she will surely be suggested to do 'better'. I am not a mechanical engineer. And use advanced topics, like FPGA's .. Regards

Hi This is an old flaw. It was first mentioned in LabVIEW 2021 SP1, and reported fixed in LabVIEW 2022 Q3 : But apparently not. Regards

Hi I would try various LabVIEW versions and platforms. I assume you use Windows. So I would try opening it on a Mac or even Linux. And of course also using the version of LabVIEW matching the version used for generating the VI. Regards

Hi The original question "Can I ride the LV/TS train to retirement" needs to divided into at least two cases, even if you tie them together as here. Not all are experts in both LV -and- TS. You might be an LV expert, yet know nothing about TS. And you could live fine with that. At least in the past. The other way round is also true. You might be an TS expert, yet know nothing about LV. I guess that is much less likely though. And as TS supports many adapters, you could even get away with only implementing the actual do-something-code-snippets in HTBasic. Probably hightly relevant 20 years ago. So let us 'forget' the TS experts, They will survive for the foreseeable future. The LV experts is a much more endangered species. Just being able to code -good- LV code will not save you. What will save you is having application knowledge. RF and Radar knowledge. Audio knowledge. Electric Car related knowledge. Rocket knowledge. You probably get the picture. Applications where simply calling into Python Packages has not taken over yet for one reason or the other. If you have that knowledge you might be able to be allowed to implement it in LabVIEW. What else could save the LV expert ? Well, it could be that the initial glory of Python has gotten some stains. Using unknown quality Packages is an increasing worry : I hope it helps in directing where to head towards. As a little bonus, try look up well deserved Knight of NI, Rolfk's new icon. For ages it used to be a now ancient photo of himself. Now it is something else 🤔 Regard

Hi Revenue is a complex issue. Consider this : This nice piece of software, MATRIXx, has not been marketed since about 2008. But NI still releases updates to it here in 2023. Must be some important customers, getting that kind of support. And then NI killed both CDS ( without warning ) and MathScript ( with years of warning ) here in 2023. CDS was NI's own re-implementation of MATRIXx, which they got/bought back in 2003. Regards

Hi Anybody interested in the history of LabVIEW and NI could start by reading by Jeff Kodosky's rather long entry published from 2020 : ACM Reference Format: Jeffrey Kodosky. 2020. LabVIEW. Proc. ACM Program. Lang. 4, HOPL, Article 78 (June 2020), 54 pages. https: //doi.org/10.1145/3386328 It is 54 pages long and includes a proper index. Pitty NI stopped making quality documents/manuals like this after ~ 2008. There are also references on LabVIEW Wiki : "History of LabVIEW" presented by Jeff Kodosky, the "Father of LabVIEW," as he looks back at the creation of graphical programming and shares fundamental programming concepts vital to the next 25 years of graphical system design for meeting the most demanding application challenges. (NIWeek 2011) "Future of LabVIEW" presented by Jeff Kodosky, the "Father of LabVIEW," talks about the beginnings and future of LabVIEW. (NIWeek 2016) "Evolution of LabVIEW" presented by Jeff Kodosky, the "Father of LabVIEW," discusses the early beginnings of LabVIEW and how it has evolved into what it is today. (NIWeek 2017) "LabVIEW History & Timeline | Jeff Kodosky & Dr Truchard Interviews" by ElectronicsNotes, LabVIEW was first launched in 1986, since then, it has been developed to provide many new facilities and keep up with the needs of the latest engineering requirements from development and research through to control, monitoring and data acquisition. Regards

Hi again Fortunately I didn't have to make a living using LabVIEW 2. It was just a proof of concept and I first jump'ed in on LabVIEW 3. It was a splendid version to interface to the mighty NI-DAQ. Some really powerful data acquisition systems could be made then running on WfW 3.11. NI's claim to fame is really NI-DAQ and less LabVIEW. But I don't miss the countless hours spend on configuring memory managers like Quarterdeck's and manually setting I/O addresses and Interrupts and DMA channels on dumb ISA boards. Regards

Hi I found two original floppies with a Demo version of 2.5.1 from 1992. I hope NI won't mind I share them. They were handouts to prospective buyers of LV back then. LV crashed immediately with a divide by zero in WfW 3.11. LV also caused a Win386 error in Win 95, which could be ignored. So here is the glorious screen image : The computer is from 2000. The CPU is a Pentium Pro. Regards LVD251D1.zip LVD251D2.zip

Hi Mentioning the new fuse name, made me find this sad list : NI has finally kill'ed everything MATRIXx related. Regards

Hi The wire shifting issue will hit you if you use default font size. Which is now 15. I have for many years used my preferred typeface and font size. I preferred 14. This now seems to be a fortunate choice. Using this choice there is no wire shift from 2022 Q3 to 2023 Q1 : Such a profound visual change should of course have had a proper ini setting so you can continue editing using the old size configuration. Regards

Indeed interesting. Such an acquisition makes very good sense to substantiate the value of the recent entry into power electronics testing. See this from 2022 as an example : https://www.businesswire.com/news/home/20220524005382/en/NI-Releases-Latest-Battery-Test-System-to-Enhance-Safety-and-Performance-of-Electric-Vehicles Regards

There is this interesting blog on Linkedin : https://in.linkedin.com/posts/jimkring_upgrading-to-new-labview-versions-is-for-activity-6972085040700686336-5gGw?trk=public_profile_like_view Lapsus : the person in question is CTO not CEO. Regards

Hi again I forgot to make a conclusion how to avoid this problem. I avoid the problems related to odd LabVIEW development issues by sticking to LabVIEW 2018 SP1. No essential issues observed. For those not developing large VI's with a horrendous complexity then LabVIEW 2020 may be the sweet spot. The jury is still out whether LabVIEW 2023 Q1 is a good release. The previous had issues. One CEO simple stated he won't allow 2021 in his company. This is a serious problem with anything newer than LabVIEW 2018 SP1 : The two questions we have to ask when presented with a new LabVIEW release : - What did they improve ? - What did they screw up ? Regards

Hi NI is messing with the LabVIEW compiler. A memory leak would just be the latest. They started by eliminating the Hybrid Compiler, introduced in LabVIEW 2010 SP1, in LabVIEW 2019 to make development simpler but it appears to just progress in the wrong direction for every new LV version. They also started messing with the icons when beautifying project libraries in LabVIEW 2021. They haven't solved it yet, it seems. See NI Forum thread NI Library Icon problems in classes. Is there a development pattern here .. Regards

I still have a SSP subscription called "Multi-IDE Bundle". This allows me to use all programming languages from NI. So I am happy. For a little time more, as this Bundle is no more. So I am stuck with what I have. Which is also fine with me. For all the software I don't have SSP for, I can still download them and activate them on a trial basis. You get the usual 7 days or so of trial. However, if you avoided installing a License Manager version newer than 4.7 ( that is software released before 2021 or so ) you will be able to set back the computer clock to the installation time for a certain module and then the module will run as activated again for some days. This is clearly not usable for commercial purposes except testing and learning. So you can download old evaluation software made before 2018..2019 from the NI FTP site as mentioned and test/try it and get wiser. Without stress. The catch here is that you should not install anything new marked as 2021. Like LabVIEW 2021. It will install a License Manager stamp'ed 2020 or newer, where NI has removed support for the clock set-back feature. And you cannot revert to an older License Manager except by re-imaging. 2018 was also the year where NI introduced their "Big Business" initiative. View some the NI-Days videos from 2018 to see the NI Sales excitement. Updated DIAdem, FlexLogger, InsightCM, InstrumentStudio, SystemLink and LabVIEW. But since then nothing meaningful new released related to LabVIEW. So LabVIEW 2018 SP1 will be my final version for some years. Actually, NI deliberately removed features from 2019 so I cannot use it, nor any newer version. Regards Henning

Here is a little story about the dilemma I have with subscription. Should I have one or should I just stop and use what I have now. I have been a happy SSP customer for 20+ years. Because every 4..5 years I run into a problem where I need assistance from NI. Not to fix problems in my code, but to fix problems in LabVIEW. I develop and maintain a test system for our production including an application with a big VI having a complexity of 18. It killed the LabVIEW 2010 compiler which NI resolved by introducing the hybrid compiler in LabVIEW 2010 SP1. And introducing the ini file setting "CompilerCodeComplexityThreshold". Smooth sailing with 2010 SP1 till around 2016 where I decided that it was time to look for a newer LabVIEW base version. Various problems were found before I finally settled on LabVIEW 2018 SP1. Which I am still using. A very nice version. One problem found and fixed was that NI changed the hybrid compiler again in LabVIEW 2015. That meant that every time I pressed Run after a code change the compiler would compile for 4 minutes before actually running, whereas it took 15.20 seconds in earlier versions. This was of course a complete no-go. NI came to the rescue again. And as other customers before me had the same problem NI had made a new ini setting "EnableLegacyCompilerFallback" to solve this problem. Recently I thought it was time to look for a new LabVIEW base version. And ran into the old problem. LabVIEW 2019 and newer doesn't support the "EnableLegacyCompilerFallback" anymore. So I contacted NI support to get help. And the support engineer were able to reproduce the problem. But now comes the real problem. NI R&D told the support engineer that the 2015 ini setting were a hack ( their words ) and that is was now unsupported because they would not maintain the hybrid compiler in the future. According to them it meant that they should write the same code twice. Meaning more testing I guess. So I am stuck at LabVIEW 2018 SP1. No more upgrades. Not that I am very unhappy with that. Not much has been improved since in LabVIEW. NI kindly suggested me to re-write the code to reduce the complexity. Probably a multi year project. But now to the dilemma. Should I continue with a yearly subscription, knowing that I cannot use any new LabVIEW version being released. If NI changes their mind in the future I can jump onto the bandwagon again then without having to pay big money for a new license. Fortunately I have another half year before the current SSP period is running out. So time to think. Regards Henning