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