Leaderboard

To all things there is a season. Jeff Kodosky helped found National Instruments and invented LabVIEW. He inspired hundreds of us who shapes its code across four decades. But Jeff says it is time to change his focus. Today, NI announced Jeff’s retirement. He will probably always be noodling around on LabVIEW concepts and will remain open to future feature discussions. But his time as a developer is done. Maybe you didn’t know that? Jeff still slings code, from big features to small bugs. He’s been a developer most of the years, happy to have others manage the release and delivery of his software. I spent over two decades working at his side. He taught me to look for what customers needed that they weren’t asking for, to understand what problems they didn’t talk about because they thought the problems were unsolvable. And he built a team culture that made us all collaborators instead of competitors. Thank you, Jeff, for decades of brilliant ideas and staying the course to see those develop into reality. Your work will continue on as one of the key tools on humanity’s expansion to Mars.

June 3 will be my last working day at NI. After almost 22 years, I'm stepping away from the company. Why? I found a G programming job in a field I love. Starting June 20, I'm going to be working at SpaceX on ground control for Falcon and Dragon. This news went public with customers at NI Connect this week. I figured I should post to the wider LabVIEW community here on LAVA. I want to thank you all for being amazing customers and letting me participate vicariously in so many cool engineering projects over the years. I'm still going to be a part of the LabVIEW community, but I'm not going to be making quite such an impact on G users going forward... until the day that they start needing developers on Mars -- remote desktop with a multi-minute delay between mouse clicks is such a pain! 🙂

How Software Companies Die – Orson Scott Card The environment that nurtures creative programmers kills management and marketing types - and vice versa. Programming is the Great Game. It consumes you, body and soul. When you're caught up in it, nothing else matters. When you emerge into daylight, you might well discover that you're a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already. But you don't care, because your program runs, and the code is fast and clever and tight. You won. You're aware that some people think you're a nerd. So what? They're not players. They've never jousted with Windows or gone hand to hand with DOS. To them C++ is a decent grade, almost a B - not a language. They barely exist. Like soldiers or artists, you don't care about the opinions of civilians. You're building something intricate and fine. They'll never understand it. Beekeeping - Here's the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. You can't exactly communicate with them, but you can get them to swarm in one place and when they're not looking, you can carry off the honey. You keep these bees from stinging by paying them money. More money than they know what to do with. But that's less than you might think. You see, all these programmers keep hearing their fathers' voices in their heads saying "When are you going to join the real world?" All you have to pay them is enough money that they can answer (also in their heads) "Jeez, Dad, I'm making more than you." On average, this is cheap. And you get them to stay in the hive by giving them other coders to swarm with. The only person whose praise matters is another programmer. Less-talented programmers will idolize them; evenly matched ones will challenge and goad one another; and if you want to get a good swarm, you make sure that you have at least one certified genius coder that they can all look up to, even if he glances at other people's code only long enough to sneer at it. He's a Player, thinks the junior programmer. He looked at my code. That is enough. If a software company provides such a hive, the coders will give up sleep, love, health, and clean laundry, while the company keeps the bulk of the money. Out of Control - Here's the problem that ends up killing company after company. All successful software companies had, as their dominant personality, a leader who nurtured programmers. But no company can keep such a leader forever. Either he cashes out, or he brings in management types who end up driving him out, or he changes and becomes a management type himself. One way or another, marketers get control. But...control of what? Instead of finding assembly lines of productive workers, they quickly discover that their product is produced by utterly unpredictable, uncooperative, disobedient, and worst of all, unattractive people who resist all attempts at management. Put them on a time clock, dress them in suits, and they become sullen and start sabotaging the product. Worst of all, you can sense that they are making fun of you with every word they say. Smoked Out - The shock is greater for the coder, though. He suddenly finds that alien creatures control his life. Meetings, Schedules, Reports. And now someone demands that he PLAN all his programming and then stick to the plan, never improving, never tweaking, and never, never touching some other team's code. The lousy young programmer who once worshiped him is now his tyrannical boss, a position he got because he played golf with some sphincter in a suit. The hive has been ruined. The best coders leave. And the marketers, comfortable now because they're surrounded by power neckties and they have things under control, are baffled that each new iteration of their software loses market share as the code bloats and the bugs proliferate. Got to get some better packaging. Yeah, that's it. Originally from Windows Sources: The Magazine for Windows Experts, March 1995

Nice! While you are there please convince Elon to buy NI and turn it back into an engineering company 🤣

Usual disclaimer. Method described below is strictly experimental and not recommended to use in real production. N.B. This is based on .NET, therefore Windows only. This text is sorta lengthy, but no good TL;DR was invented. You may scroll down to the example, if you don't want to read it all. One day I was stalking around NI forums and looking at how folks implement their callback libraries to call them from LabVIEW. After some time I came across something interesting: How to deal with the callback when I invoke a C++ dll using CLF? There someone has figured out how to make LabVIEW give us a .NET delegate using a dummy event. This technique is different from classic way of interfacing to callbacks, because it allows to implement the callback logic inside a VI (not inside a DLL), but still it requires writing some small assembly to export the event. Even though Rolf said there that it's not elegant, I decided to study these samples better. Well, it was, yeah, simple (no wonder it was called SimpleProxy/SimpleDemo/SimpleCallBack) and very instructive at the same time. It worked very well in both 32- and 64-bit LabVIEW, so I had fun to play around and learn some new things about .NET events and C#. After all I started to think, whether we really need this dummy assembly to obtain a delegate... Initially I was looking for a way to create a .NET event at the run-time with Reflection.Emit or with Expression Trees or somehow else, but after googling for few days and trying many things in both C# and F# I came to a conclusion that it's impossible. One just can create event handlers and attach them to already existing events, not create events on their own. Okay. First I decided to know how exactly LV native Register Event Callback node works. Looking ahead I'll say it was a dead end, but interesting. Ok, the Register Event Callback node in fact consists of two internal functions - DynEventAllocRegInfo and DynEventRegister - with the RegInfo structure filling between them. The first one creates and returns a new RegInfo with a Reg Event Callback reference, the second one actually registers the RegInfo and the reference in the VI Data Space (the prototypes and the struct fields are more or less figured out). But when I started to play with the CLFN's to replace the Register Event Callback node, I ran into few pitfalls. To work properly the DynEventRegister function needs one of the RegInfo's fields to be a type index of (hidden) upper left terminal of the Constructor node. This index is stored in the VI's Data Space Type Map (DSTM) and determined at the compile time. I did not find a reliable way to pull it out of the DSTM. Moreover the RegInfo struct doesn't have a field for the VI Entry Point or anything like that. Instead LabVIEW stores the EP in some internal tables and it's rather complicated to get it from there. For these reasons I have given up studying the Register Event Callback node. Second I turned my attention to the delegate call by its pointer. I soon found out that LabVIEW generates some middle layer (by means of .NET) to convert the parameters and other stuff of the native call to the VI call. That conversion was performed by NationalInstruments.LabVIEW###.dll in the resource folder (a hidden gem!). This assembly has almost everything that we need: the CallbackInfo and CallbackHandler classes, and the latter has two nice methods: CallLabView and CreateCallbackHandlerDelegate. Referring to the SimpleDemo/SimpleCallBack example, when we call the delegate by its pointer, LabVIEW calls this chain: CallLabView -> EventCallbackVICall internal function -> VI EP. All that was left to do was to try it on the diagram with .NET nodes, but... there was another obstacle. Sure that you'll connect the inputs right? You will not. These parameters are not what they seem (at least, one of them). The viref is not a VI reference, but a VI Entry Point pointer. It's not a classic function EP pointer, but a pointer to a LabVIEW internal struct, which eases the VI calls (it's called "Vepp" in the debug info). The userParam is a pointer to the User Parameter as for the Register Event Callback node. The cookie is a pointer to the .NET object refnum from the Constructor node (luckily NULL can be passed). And the type and flags are 0 and 0x80000000 for standard .NET callbacks. Now how and where could we get that VI EPP? Good question. There is a function inside LabVIEW, that receives a VI ref and returns an allocated VI EPP. But sadly it's not exported at all. Of course, this ain't stoppin' us. I used a technique to find the function by a string constant reference in the memory of a process. It's known to be not very reliable between different versions of the application, therefore many tests were made on many versions of LabVIEW. After finding the function address, it's possible to call it using this method (kind of a hack as well, so beware). Is this all enough to run .NET nodes now? For the CallLabView yes. It's simplier than CreateCallbackHandlerDelegate, but doesn't provide a delegate. It passes the parameters to the VI, calls it and returns. The return and parameters could be utilized onwards, of course, but nothing more. To obtain a delegate it's necessary to call the CreateCallbackHandlerDelegate. This method wants the handlerType input wired and to be valid in .NET terms, so proper type must be made. Initially I tried to use .NET native generic delegates: Action, Predicate and Func. Everything went fine except the GetFunctionPointerForDelegate, which didn't want to work with such delegates and complained. The solution was in applying some obscure MakeNewCustomDelegate method as proposed here. Now the GetFunctionPointerForDelegate was happy to provide a pointer to the delegate and I successfully called the callback VI both "manually" and by means of Windows API. So finally the troubles were over, so I could wrap everything into SubVI's and make a basic example. I chose EnumWindows function from WinAPI, because it's first that came to my mind (not the best choice as I think now). It's a simple function: it's called once with a callback pointer and then it starts looping through OS windows, calling a callback on each iteration and passing a HWND to it. This is top-level diagram of the example: I won't be showing the SubVI's diagrams here as they are rather bulky. You may take a look at them on your own. I'll make one exception though - this is the BD of the callback VI. As you could know, EnumWindowsProc function must return TRUE (1) to continue windows enumeration. How do we return something from a callback VI? Well, it's vaguely described here, I clearly focus on this. You must supply first parameter as a return value in both Event Data clusters and assign these two to the conpane. On the diagram you set the return as you need. These are the versions on which I tested this example (from top to bottom). Some nuances do exist, but generally everything works well. LabVIEW 2023 Q3 32 & 64 (IDE & RTE) LabVIEW 2022 Q3 32 & 64 (IDE & RTE) LabVIEW 2021 32 & 64 (IDE & RTE) LabVIEW 2020 32 & 64 (IDE & RTE) LabVIEW 2019 32 & 64 (IDE & RTE) // 32b - on one machine RTE worked only w/ "Allow future versions of the LabVIEW Runtime to run this application" disabled (?), 64b - OK LabVIEW 2018 32 & 64 (IDE & RTE) LabVIEW 2017 32 & 64 (IDE & RTE) // CallbackInfo& lvCbkInfo, not ptr LabVIEW 2016 32 & 64 (IDE & RTE) // same LabVIEW 2015 32 & 64 (IDE & RTE) // same LabVIEW 2014 32 & 64 (IDE & RTE) // same LabVIEW 2013 SP1 32 & 64 (IDE & RTE) // same + another string ref + 64b: "lea r8" (4C 8D 05) instead of "lea rdx" (48 8D 15) LabVIEW 2013 32 & 64 (IDE & RTE) // same + no ReleaseEntryPointForCallback, CreateCallbackHandler instead of CreateCallbackHandlerDelegate LabVIEW 2012 32 & 64 (IDE & RTE) // same + forced .NET 4.0 LabVIEW 2011 32 & 64 (IDE & RTE) // same LabVIEW 2010 32 & 64 (IDE & RTE) // same LabVIEW 2009 32 & 64 (IDE & RTE) // same EnumWindows (LV2013).rar EnumWindows (LV2009).rar How to run: Select the appropriate archive according to your LV version: for LV 2013 SP1 and above download "2013" archive, for LV 2009 to 2013 download "2009" archive. Open EnumWindows32.vi or EnumWindows64.vi according to the bitness of your LV. When opened LV will probably ask for NationalInstruments.LabVIEW###.dll location - point to it going to the resource folder of your LV. Next open Create Callback Handler Delegate.vi diagram (has a suitcase icon) and explicitly choose/load NationalInstruments.LabVIEW###.dll for these nodes marked red: It's only required once as long as you stay on the same LV version. For the constant it may be easier to create a fresh one with RMB click on the lvCbkInfo terminal and choosing "Create Constant" entry. Now save everything and you're ready to run the main VI. Remarks / cons: no magic wand for you as for the Register Event Callback node, you create a callback VI on your own; the parameters and their types must be in clear correspondence to those of the delegate; obviously .NET callbacks are X times slower than pure C/C++ (or any other unmanaged code) DLL; search for CreateVIEntryPoint function address takes time (about several seconds usually); on 64 bits it lasts longer due to indirect ref addressing; no good way to deallocate VI EPP's; the ReleaseEntryPointForCallback function destroys AppDomain when called (after such a call the VI must be reopened to get .NET working) - usually not a problem for EXE's. Conclusion. Although it's a kind of miracle to see a callback VI called from 'outside', I doubt I will use it anywhere except home. Besides its slowness it involves so many hacks on all possible levels (WinAPI, .NET, LabVIEW) that it's simply dangerous to push such an application to real life. Likely this thread is more of a detailed reference for the future idea in NI Idea Exchange section.

I've been surprised today with one of the LabVIEW's most useful functions (imo) which I use all the time. After so many years and only now seeing this behavior/feature. I thought I share it 🙂 I've always used an empty array of N-Dim for my desired type input. only to accidently find out today that I can also use a scalar for the type. ha!

I'm excited to release ViPER ViPER is an Object Oriented design Framework that supports dependency injection and recursive object creation. Systems are assembled at runtime from a collection of pre-built components defined by an Object Definition Document. Please visit the project on GitHub https://github.com/kurtafriday/ViPER I've presented this framework at several GLA Conferences, for an overview and guidance please view. GLA 2021 https://labviewwiki.org/wiki/GLA_Summit_2021/Open_Source_ViPER GLA 2020 https://labviewwiki.org/wiki/GLA_Summit_2020/ViPER_-_A_LabVIEW_Dependency_Injection_Framework This branch of ViPER has been used by us to develop systems in regulated industries for several years, it's solid and reliable, however its windows only. I'm working on ViPER_WinRT which is compatible with Windows and RT and we have already used it for several systems. I'll be releasing ViPER_WinRT in the coming months. I'll work to get ViPER onto the VIPM Tools Network soon. I'm looking forward to the feedback and I hope you enjoy and get value from this framework. Ping me if you have any questions. kurt@medulla.net

My new motto No more comments in my LabVIEW code. No icon customization. All VIs named 'untitled<n>.vi'

Powered by LabVIEW NXG 😋

The conference went well. We got lots of good video, but it will take a while to edit. I don't have an exact timeframe, but they should be posted within the next month or so. We had an extra cameraman and better lighting and angles this year, so the videos should be even better than last year.

How about halfway happy. Which is more happy then I'd be with nothing. I enjoy a community that shares code. Sharing is caring. I'm agree that stuff on VIPM.IO should have a bit more polish. But a random forum post doesn't require the test and rigor of a commercial product.

With a slightly snarky tone, I want to ask if this is part of the 100 year business plan NI has. On a personal level I just hope LabVIEW can stay relevant until retirement. I do still have a perpetual license to 2022 Q3, which supports Windows 11. So even if NI goes away I'll be able to be in my language of choice until 11 is no longer supported. LabVIEW has changed the way I think about programming in such a way that I think it is hard to go to other languages. My brain thinks in parallel paths, and data dependence, not lines of code and single instructions. Whenever I develop in C++ I can't help but feel how linear it is. I'm sure higher level languages are better, but at the same time I don't really want to change. As long as I can work at a place that needs test applications, and doesn't care how they are developed, I'll be happy pushing LabVIEW. The fog of the future is hard to see though. The next year or two looks very uncertain in my career. But looking at the past, working in LabVIEW has felt like winning the lottery. Thinking about this helps me stay positive.

Hello! For a company conference I'm arranging a LabVIEW quiz like the TV-show Family Feud and I would very much appreciate your help to gather response material. If you haven't seen the show, this is how it works in short: Before the show, 100 people are asked a bunch of questions, like "Name a fruit" The 100 people might then have answered: Apple: 43 Orange: 22 Pineapple: 21 Banana: 14 On the show the team then have to guess what people answered. If they guess "Apple", they get 43 points etc. I'm now looking for 100 people (or as many as I can find ) and have made a Google forms with 12 questions. The idea is not to think long and hard about the answers but write the first thing you think of and it might take about 3-5 minutes to answer all of them. If you would take some time to answer the questions I would very much appreciate it! https://forms.gle/QAnjTETdGGoXkyA79 If anyone is interested I can share the results later on. Thank you in advance!

As if there were no such personalities on NI forums...

Found the issue. The cRIO and PC were connected via a router which was blocking the port used for firmware updates. NI MAX should display a message where the "Updated Firmware" button should be indicating that the port (with port number) is being blocked.

I don't have a use case for this but I love that the API uses plymorphic VI's-a vastly underused feature IMO. If you want to organise the functions instead of having a huge linear list, you can group them by separating the menu item with a colon ":".

Good Read here, a bit depressing https://nihistory.com/nis-commitment-to-labview/

Test Stand is a test sequencer so what you have now isn't even in the same paradigm. In terms of LabVIEW, you have some limited block functionality that could be compared to Express VI's (which we don't use). From what I can tell, It seems to be the Python version of Node Red (Javascript). It has a place but people are very quickly going to be dropped into text coding for anything more than hobbyist applications. Many people on this forum (not me) are also adept Python Developers already and I expect they will weigh in sooner or later. If you are going to target the LabVIEW community, I would suggest you work on your videos. From what I can tell, they are pretty much: Plug in some wires Magic happens Trust me bro, the pretty pictures are because of the magic".

@Rolf Kalbermatter I know you did not mean this, but I love it!

As a workaround, what about using the .NET control's own events? Mouse Event over .NET Controls.vi MouseDown CB.vi MouseMove CB.vi

I think there were 182. Everything was video recorded and after editing will be posted on YouTube. Expect something in about six weeks.

(Disclaimer: I am not an NI insider, and I have no inside knowledge of the pending Emerson acquisition) I think we're all sort of in a holding pattern waiting to see how the Emerson acquisition plays out. Emerson's outward messaging seems very positive towards LabVIEW, which I find encouraging.

This video may not look like it, but for us it represents an enormous amount of effort, difficulty, sacrifice and financial means. It is with special emotion that we proudly unveil the upcoming major update for HAIBAL, the LabVIEW deep learning toolkit by Graiphic. In a few weeks, we will introduce a significant enhancement to our deep learning toolkit for LabVIEW. This update takes our tool to a new dimension by integrating a range of reinforcement learning algorithms: 𝐃𝐐𝐍, 𝐃𝐃𝐐𝐍, 𝐃𝐮𝐚𝐥 𝐃𝐐𝐍, 𝐃𝐮𝐚𝐥 𝐃𝐃𝐐𝐍, 𝐃𝐏𝐆, 𝐏𝐏𝐎, 𝐀𝟐𝐂, 𝐀𝟑𝐂, 𝐒𝐀𝐂, 𝐃𝐃𝐏𝐆 𝐚𝐧𝐝 𝐓𝐃𝟑. Naturally, this update will include practical, easy-to-use examples such as DOOM, MARIO, Ataris games and many more surprises will come along. (starcraft or not starcraft?) 👉🏼 Visit us now www.graiphic.io 👉🏼 Get started with TIGR vision toolkit https://lnkd.in/dssB-MS4 👉🏼 Get started with HAIBAL deep learning toolkit https://lnkd.in/e6cPn4Fq

Well, the whole NI=>Emerson transaction seems to go as follows: 1) Shareholders from Emerson have approved the deal 2) Emerson created a wholly owned subsidiary in Deleware called Emersub CXIV, Inc for the whole purpose of merging with NI 3) Shareholders from NI approved the merger on June 29, 2023 4) After all the legalities have been dealt with National Instruments and Emersub CXIV, Inc will merge into a new company under the name of National Instruments, and Emersub CXIV, Inc will cease to exist. The end result is that National Instruments for a large part will most likely simply operate as is and be a fully owned subsidiary of Emerson Electric but for a lot of things simply keep operating as it did so far. If and what technical cross contamination will eventually happen will have to be seen. You could probably compare it to how National Instruments dealt with Digilent and MCC when they took them over. They both still operate under their own name and serve their specific target audience and for a large part were unaffected by the actual change in ownership. There were of course optimizations such as that most of the MCC boards where eventually actually manufactured and shipped from the same factory that also produces NI hardware. Digilent also has eventually taken over some of the products from NI that were mainly meant for the educational market such as myDAQ but also the Virtual Bench device which they sell under a different name but it is 100% the NI Virtual Bench device and also works with the same drivers.

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

I exclusively use the bundle/unbundle, unless I am not able to for example if accessing a field in a parent class. Accessors should be, in my opinion, only for when you want to get access to the data from outside the class, and even then you should really think about if this is strictly necessary. Often you can get rid of accessors by having a better designed API (methods). Lots of sets/gets is a code smell to me.

They introduced a token for smooth lines: SmoothLineDrawing=False

They are trying their best to snap NI at a bargain price, knowing full well that the picture will completely change when LabVIEW 2023 Q4 will be released, instantly doubling the value of NI share price.

Today I told NI, that I am not willing to join a subcription program, in which NI can increase the pices as they want or to shutdown my software and that LabVIEW 2022 will be my last version. I just can encourage all other guys to do the same and to not accept such a pricing model.

It's probably my limited command of the English language, but for me this sounds about as intelligible as a dissertation about the n-th dimensional entanglement of virtual particles between different universes.

I don't know about you guys but I hate writing strings. There's just too many ways to mess it up and, in this case, it might just be to tedious. So, I wanted to create a way to make SQLite create and insert statements based on a cluster. The type infrencing code was based on JDP Science's SQLite Library. Thanks! create and insert from cluster.vi

I work for NI now!

The Russian Reversal

Change the limit to 65535 instead of 10000 in the Windows Registry I have a file named: Max GDI Objects.reg With this content: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows] "GDIProcessHandleQuota"=dword:0000ffff

The issue was reported to LV R&D as Bug 2317159. It was introduced in LabVIEW 2022 Q3 and fixed in LabVIEW 2023 Q3. The Error 13 occurs when the LabVIEW Class private data includes certain types of .NET references, or a reference to a .chm help file. More details: LabVIEW 2022 Q3 included a "fix" to how linkages to .NET assemblies are adjusted in a build output. Unfortunately this "fix" caused the issue you're seeing. LabVIEW 2023 Q3 uses a new mechanism for app builder caching under the hood, which removed the codepath that was causing the Error 13 altogether.

If it was hard to write, it should be hard to read.

It should also automagically install Visual Studio, write the callback wrapper, compile it into a DLL and connect it to the VI with a CLFN. Moreover it would be nice to have a .NET translator from textual code to G code, as the current way of calling .NET assemblies is too awkward. It may take 10 minutes to find a good combination of Assembly -> Constructor -> Method/Property, especially when dealing with the OS native API.

Took some time to find this old thread in the Wayback Engine, but here it is: http://web.archive.org/web/20080315135806/http://forums.lavag.org/Comments-in-Configuration-Files-t9183.html&mode=linear You want the "read_configuration_data.vi ( 78.66K )" attachment.

TDF team is proud to propose for free download the scikit-learn library adapted for LabVIEW in open source. LabVIEW developer can now use our library for free as simple and efficient tools for predictive data analysis, accessible to everybody, and reusable in various contexts. It features various classification, regression and clustering algorithms including support vector machines, random forests, gradient boosting, k-means and DBSCAN, and is designed to interoperate with the Python numerical and scientific libraries NumPy and SciPy from the famous scikit-learn Python library. Coming soon, our team is working on the « HAIBAL Project », deep learning library written in native LabVIEW, full compatible CUDA and NI FPGA. But why deprive ourselves of the power of ALL the FPGA boards ? No reason, that's why we are working on our own compilator to make HAIBAL full compatible with all Xilinx and Intel Altera FPGA boards. HAIBAL will propose more than 100 different layers, 22 initialisators, 15 activation type, 7 optimizors, 17 looses. As we like AI Facebook and Google products, we will of course make HAIBAL natively full compatible with PyTorch and Keras. Sources are available now on our GitHub for free : https://www.technologies-france.com/?page_id=487

Realized I never closed the loop on this. It turns out it was a combination of things: intermittent faults in the fiber<->ethernet adapter due to a bad power supply intermittent latency caused by some heavy/spurious network traffic through a switch that was slowing down the TCP traffic throughput After fixing issue number 1, we eventually tracked down number 2 and unfortunately were unable to address as it was related to a separate critical system. Eventually I made some network changes to the cRIO found on this random page from 2009 regarding increasing the TCP buffer size. We've had zero issues in the last 5 months of operation. It feels like a hollow victory though because the LabVIEW TCP calls never threw any errors and my poor attempt at trying to use the system exec VI to monitor the socket memory for increases didn't show anything out of the ordinary, nor did any of the Linux system log/event files. Oh well, at least I sleep better at night now.

LabVIEW never has been a money maker for NI directly. They were able to develop LabVIEW because of what they earned with their hardware sales. And LabVIEW was used to drive those hardware sales. A very successful model that drove others like HP Vee and such out of the market in the not very long term. Maybe HP/Agilent also was simply already to big for that market segment that they could possibly target with a product like this. The entire T&M component market isn't that huge. For HP it was what they had been starting with, but the big money was earned (and sometimes biggly lost) already in other areas. T&M was good for a steady revenue, but nothing that would stand out on the yearly shareholders report. It was unsexy for non-technicals and rather boring. That was one of the big reasons to separate HP into multiple companies. An attempt to create smaller entities that target a specific market segment and could be fine tuned in the sales and marketing efforts to the needs of that market. About 10 years ago NI reached the size where they started to feel the limitations of the T&M component market themselves. There simply was not a big enough market left that they could capture, to continue their standard double digits yearly sales grow for much longer. Some analysts were hired to look into this and their recommendations were pretty clear. Don't try to be the wholesale everything for all little parts manufacturer in T&M, but concentrate on specific areas where big corporations with huge production lines invest their test and measurement money. Their choice fell on semiconductor testing and more recently the EV market. It has a huge potential and rather than selling ten-thousends of DAQ boxes to hundreds of integrators, they now sell and deliver hundreds of fully assembled turnkey testers to those corporate users and earn with each of them more than they could ever earn with several 1000 DAQ boxes. What used to be NI's core business is nowadays a side line, at best a means to deliver some parts for those testers. But more and more a burden that costs a lot of money in comparison to the revenue it could even under ideal conditions generate. If you can understand this you also can guess where NI is heading. They won't die and their shares will likely not falter. But what they will be has little to do with what they used to be. If LabVIEW still has a place in this I do not know. Personally I think it would be better if it was under the parapluie of a completely separate entity than the new NI but I also have my doubts that that would have long term surviving chances. Earning enough money with a development environments itself is a feat that almost nobody has successfully managed for a longer period. But the sometimes heard request to Open Source LabVIEW has also not a lot of chances. It would likely cause a few people to take a peek at it and then quickly loose interest, since its code base is simply to complex. And there is also the problem that the current LabVIEW source code never could be open sourced as is. There are so many patent encumbered parts in it and 3rd party license dependencies, that nobody would be legally allowed to distribute even a single build of it without first hiring an entire law firm to settle those issues. While NI owns the rights for them or acquired a license to use them, many of these licenses do not give NI the right to simply let others use them as they wish. So open sourcing LabVIEW would be a fairly big investment in time and effort before it could be done. And who is willing to foot that bill?

I don't know much about CINs, CLN, or DLL calling in LabVIEW. But don't be discouraged. Our history makes us what we are. There's several projects I started and spent a lot of time on just to do nothing with, but I feel like I learned stuff or grew as a developer and a person just because of the journey. Maybe that time could be better spent elsewhere. But with that mentality I'd never do anything for entertainment.

I have been a community admin for another Stack Exchange site, and the difference in tone between the various sites astounds me. I didn't understand how much rides on the tone the admins take. Stack Overflow, the main Exchange, is really bad to the point that I have shadow accounts to ask questions there because once you ask what is seen by some as a dumb question, they follow you to your next question with "you're still an idiot" type comments. It's massively helpful when it is helpful and deeply insulting when it is not. But it doesn't have to be that way -- it's the choice of the admins for that particular Exchange site. There's a difference between one or two obnoxious persons shining a flashlight in your eyes versus a group of people with laser pointers and magnesium flares. In my experience, Stack Overflow is the latter form of hell.

Noting down this mainly for self reference since it occurred to me time and again, in case it helps others too. I have several recent versions of LV installed on Ubuntu 20.04 (with alien). The nice thing is that somehow a NI deb package stream became known to the system, and some package upgrades are found automatically. However there is one caveat: each time the kernel is upgraded, several NI dkms kernel modules need to be recompiled. Usually that is automatically done, but sometimes stumbles on a missing config/modversions.h file. It seems that not every kernel headers package includes it. Missing that, LV crashes as soon as anything needing one such modules is loaded. E.g., as an easy test occurrence, when putting a new VISA control on an empty FP. The solution is trivial: if the (usually empty) file is missing, create it with sudo touch /usr/src/linux-headers-XX.YY.ZZ-generic/include/config/modversions.h where XX.YY.ZZ is the kernel du jour version (e.g. 5.13.0-28 as of today). sudo apt reinstall ni-kal and a reboot then fix the crash.

It's not directed at us (engineers). It's a sales pitch to internal profit centers with the hope that external LabVIEW engineers will use the arguments to their upper management. In essence it is "this is good for both of us, but mainly us, and means we will listen more, maybe". You will notice there are no concrete or tangible benefits to anyone other than NI. However I don't think this brain-wave coming directly after NXG being killed is coincidence. What is clear is that their mind is made up and now it's just a case of managing the PR. "The beatings will continue until morale improves" - Captain Bligh in Mutiny on the Bounty

I skirted the edge of what I'm allowed to say in my last statement. I'm obviously not at liberty to share any numbers, nor can I speak officially for NI on that front, but I personally had no qualms about returning to the LV team based on the data I've seen, at least for now. The future is not as bright as I'd like, but it's good enough for me to keep working. The decline on LAVA is worrisome. I've also noticed the reduction. It might be indicative that all of our new user growth is in experienced groups buying more seats for legacy systems without onboarding more new hires. I worry about that. But there's several other factors that could explain it also: The annual refresh of users from NIWeek/NIConnect has not happened for two years. The forums on ni.com are significantly improved (not as nice as LAVA in my opinion, but good enough to not drive people away like they used to). User groups went virtual during pandemic, which means there are now many more places to go for expert input regardless of geography. The number of other support venues has blossomed -- Stack Overflow is now available to LV in a way that it wasn't just a couple years ago; internal support groups exist at far more large companies than in the past. And the LV population has diversified into non-English countries. So am I worried about the future? Yes. But do I think we are currently in a bad spot? No.