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 🤣

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!

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.

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

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.

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!

And the saga continues... https://www.reuters.com/markets/deals/national-instruments-picks-fortive-keysight-challengers-emersons-bid-sources-2023-03-03/

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.

I can't right now work on that. But I have plans to do that in the coming months. The story behind it is that I did a little more than just to make it 64-bits. - The file IO operations where all rewritten to be part of the library itself rather than relying on LabVIEW file IO. While LabVIEW 8.0 and newer supports reading and writing files that are bigger than 2GB, it still has the awful habit to use internally old OS file IOs that are naturally limited to only supporting characters in file names that are part of your current local and they also normally are limited to 260 character long path names. If your drive is formatted in FAT32, that is all the drive can do for you anyhow, but except for USB thumb drives, you would be hard pressured to find any FAT formatted drives anymore. So having these limitations in the library feels very bad. These two things are specially a problem on Windows. Mac is slightly less problematic and Linux has long ago pretty much solved it all internally in the kernel and surrounding system libraries. - Modern ZIP files support things like symbolic links and I wanted a way to support them. For Linux and Mac that is a piece of cake. For Windows I may for now not be able to seamlessly support that as creating symlinks under Windows is a privileged action, so the user has to either be elevated or you have to set an obscure Developer flag in Windows that allows all users to create symlinks. So in summary there was a lot of work to be done, most of it actually for Windows. Most of that is done but testing all that is a very frustrating job. And the non-Windows targets will then also take some more time for additional testing and making things that were modified for Windows compile again properly. So yes, it's still on my to-do list and I'm planning to work on it again, but right now I have another project that requires my attention. Because of the significant changes in the underlying shared library and internal organization of the VIs it will be almost certainly version 5.0. The official library API (those nice VIs with a green gift box in them) should remain compatible but if you want to make use of the new path name feature to fully support long path names with full character support, you may have to change to the new API, with the library specific path type, although if you use high level library functions, internal long path names will be ok, you just won't be able to access them with the normal LabVIEW file functions if they contain non local ANSI characters or are to long! It's the best I could come up with without the ability to actually changing the LabVIEW source code itself to add that feature into the internal Path Manager in LabVIEW. 😀 The according File Utilities Manager functions in the library will also be available for the user in a separate palette.

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

Kawaii?

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.

sounds like they were too busy updating NI Logo and colors to implement VISA. Oh well.

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.

As daddreamer pointed out, quite a bit of those functions are actually documented and always have been. The first multiplatform version of LabVIEW shipped with about 15 cm of printed manuals and reached at its top probably 25 cm. One of the many manuals was called the Code Interface Reference Manual. And while the name might have seemed to only be useful in Code Interface Nodes, those functions were always also available in shared libraries too since LabVIEW added official support for calling them. The information in that manual is for most of it also contained in daddreamers link, without the CIN specifics, which are nowadays useless and really have no advantage to shared libraries since about LabVIEW 7.1 but many disadvantages (and the 64-bit versions of LabVIEW do not support them anymore. Yes I'm aware that someone tried to hack them anyways into LabVIEW 64-bit and was partially successful. But it's an exercise in vain as it really has no advantages whatsoever to shared libraries). This is the Code Interface Reference Manual from around LabVIEW 3.1 (Release September 1994). It is 16mm thick and there were about 6 or 7 other manuals like that, some of them more than double as thick than this one. Lot's and lots of trees being cut down for all those LabVIEW manuals! It's for the most part the same as is also in daddreamers link, but there the CIN part is removed and few extra functions are documented that were added since then Some of the undocumented functions could be useful sometimes but being undocumented, it is a bit of a problem as they could change at anytime or completely disappear, which has happened to many of them over the course of LabVIEW development. Some were exported in the past for the compiler to be able to create code to access them directly but are useless to be called from your own external code as you lack access to internal data that needs to be passed to those functions to be useful. Some are still there as a placeholder but simply return a notImplemented error as they were moved to other parts of LabVIEW and only the export remained to make external code that depended on them in the past not load up broken but instead return a runtime error. CINs that didn't load really could throw LabVIEW into a fit. There are various additional managers to the documented Memory, File and Support manager functions in that manual but most are not really helpful. Things I have experimented with in that past and I would have liked to have more official access too, were the MagicCookie handler (all LabVIEW refnums are under the hood MagicCookies), UserDataSession (a more functional wrapper around MagicCookies), (which with the help of something called ObjectManager allows to add special crafted shared libraries through a descriptive text file, directly into the LabVIEW refnum system and access the shared library functions through property and method nodes), Thread, Mutex and Event manager (which basically offers a common interface to the underlying platform threads, mutexes and events), and it even has a Window manager, which abstracts the underlying OS windows into its own window API. But that Window manager is for modern requirements with multi monitor virtual desktops a bit arcane and one of the reasons that LabVIEW isn't that great on such setups. But it is very involved and hairy in some parts to make the various windowing systems such as Mac Quickdraw, Mac Cocoa, Windows GDI and Unix XWindows all map into the same common API. That makes any attempt to change something on one platform a really taunting exercise as it has a great chance to break one of the other platforms. There are also things like a Text manager (a VERY arcane attempt to abstract fonts and text handling into a set of functions), a Dialog manager, which allows to create dialogs in C code that use a LabVIEW VI front panel as resource for the user facing GUI but the entire handling is done in a compiled function from C(++). A Resource manager handles all the binary file formats in LabVIEW that are very much modeled around the old Macintosh resource file format. These are all things that were mostly present in LabVIEW 3 or 4 already, with the exception of the Thread, Mutex and Event manager, which was added in LabVIEW 5 when LabVIEW got true OS supported multithreading, and the UserDataRefnums which were around LabVIEW 7. I have very little knowledge about the interna of things that were added after around LabVIEW 7.1, as that was when I stopped to really dig into the LabVIEW internals. There is an extensive LVVariant interface that gets also exported since around LabVIEW 8.0 and which would allow to also work with Variants in external code, if it was documented. There was some header file downloadable in the past as part of the CUDA toolkit that contained some of these declarations and with it it would be possible to do some experimentation, but without real documentation it is rather cumbersome. Now before you start and scream that NI has kept all these nice cookies from you, consider that most users even struggle with the documented functions already and that are the more simple APIs. Much of what I described above would require several centimeters of printed manuals for each of them! It would also mean that these APIs are absolutely carved in stone and never ever can be changed again, which is something NI has kept to in all this time, unless there was an obvious bug in one of the documented functions. The undocumented functions allowed a much more lenient handling when something needed to be changed. The only people going to scream and show up with a rocket launcher because something broke, were either NI internal people or someone bold enough to hack around undocumented functions, where the LabVIEW developers simply could say: Bad luck! You were not supposed to play with those rusty nails!

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.

Antoine's new profile pic is enough to scare anyone off of the forums-including search engines. He's really let himself go.

Here are a bunch of other web resources for colors & UI Design: Data Visualization Since LabVIEW tends to get used a lot in industrial, scientific, and academic settings, it's pretty common that we need to display data in a clear & understandable way. There are a bunch of resources for picking color schemes to represent data to improve contrast, readability, and accessibility (such as colorblind safe palette). Color Brewer: A useful website with a variety of color schemes for displaying data. Has options for sequential datasets, diverging, and qualitative. As well, it shows whether the selected color set is colorblind friendly, print friendly, or photocopy friendly. matplotlib colourmaps: Technically a python resource, but colors are colors. matplotlib is one of the most widely used python libraries for data visualization in python, and they've put a ton of effort into designing good color schemes. There's another library called seaborn that is based on matplotlib that has some more color palettes. Tristen's HCL Picker: A color palette picker which lets you choose colors that are evenly spaced in hue, chroma, or in lightness. This tool is really useful for generating palettes with good contrast. Fundamentals of Data Visualization: A book with lots of useful information on data visualization, from colors to plot styles and more. Design Palettes Making data readable isn't the only thing that matters, sometimes you want to have pretty UIs too. Some handy resources are: Adobe Color Tools: Has a color wheel for designing your own palettes. A tool to extract color themes & gradients from an image (drag/drop a clients logo in there to get a palette based on their company colors), and a tool for checking color contrast for readability. coolors.co: A website with a ton of color palettes to pick from. Material Design Color System: Material Design is primarily meant for mobile & web apps, but the design principles can apply to any application really. The Material Design guidelines have good tips on making intuitive UIs, and provides a palette of nice looking colors. Material Design Palette: To go along with the above. Select your primary & accent colors, and this website returns a palette. colormind.io: A neat website that procedurally generates color palettes. Lock in one or two colors and let the website pick the rest of the palette. mycolor.space: Similar to colormind.io, this auto-generates a palette. ColorSpace takes in a single color and returns several matching palettes. Icons Lastly, good icons can be a great finishing touch. Maybe it's just because I've been using LabVIEW for so long, but I find LabVIEWs icons to be a bit dated. Material Design Icons: A website with a ton of free icons, able to be downloaded as pngs. Adds a nice touch to UI elements. FontAwesome: Has about 1700 free icons. With a subscription, has almost 15k. icons8: Has something like 875,000 icons. Free to use as long as you credit & link to icons8 in an 'About' page.

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.

Re the main issue, this seems to be my misunderstanding about how Savepoints work (as distinct from BEGIN and ROLLBACK). Here is a relevant discussion. From that discussion, I see I should, instead of "ROLLBACK TO <Savepoint>" I should do "ROLLBACK TO <Savepoint>; RELEASE <Savepoint>;" Issue 22

I don't think anyone is saying that, so much, with respect to NI as a whole. But the effort and investment in NXG made LabVIEW (Classic?) the withered limb of NI, Now they have lots of C# devs who can't do jack with LabVIEW. From this seminar, it looks like this is a solution (lots of C# devs) looking for a problem (Cloudy stuff) and they see LabVIEW as a stagnant technology instead of the axiomatic driver behind their hardware it actually is. Don't get me wrong. They can very easily move into this space and do all the cloudy stuff. But their view of how this will fit together is flawed (IMO). They are viewing it purely like an IT system rolling out images (think AWS Compute-IAAS) when, in fact, those images will be highly specialised LabVIEW installations for very specific and usually custom hardware configurations. They lost Test and Measurement to Python a while ago-arguably the mainstay for LabVIEW.

This appears to be a known issue in LabVIEW 2021 SP1. https://www.ni.com/de-de/support/documentation/bugs/22/labview-2021-sp1-known-issues.html

Right click on the tunnel and select "Linked Input Tunnel>Create and Wire Unused cases"

Hello, LAVA. My team at SpaceX is looking for LabVIEW developers. We have two job reqs open, one for entry-level developer and one for senior. Ground Software is the mission control software for all Falcon and Dragon flights. Every screen you see in the image below is running LabVIEW. Our G code takes signals off of the vehicles, correlates it for displays across all our mission control centers and remote viewers at our customer sites and NASA. It's the software used for flight controllers to issue commands to the vehicles. This is the software that flies the most profitable rockets in the world, and we're going to be flying a lot next year and in the years to come. If you'd like to get involved with a massively distributed application with some serious network requirements, please apply. You can help us build a global communications platform, support science research, and be one of the stairsteps to Mars. Entry level: https://boards.greenhouse.io/spacex/jobs/6436532002?gh_jid=6436532002 Senior level: https://boards.greenhouse.io/spacex/jobs/6488107002?gh_jid=6488107002

Dear community and network, at HSE, we are big believers in Inner Source (https://en.wikipedia.org/wiki/Inner_source) and apply it to our customer projects. By opening up our code as open source to the public and sharing it for free we make sure we stay on top of the tools and processes needed for that, and we pay back to the awesome LabVIEW community. You can browse our Open Source offerings at https://code.hampel-soft.com. We constantly work to give back to the community and widen our offerings. But we need your help! Please let us know how you use our open source LabVIEW and DQMH code, by taking this quick (promise!) survey: https://bit.ly/HSE-OS-Survey-2022 This survey is targeted at those of you who use our tools. But even if you don't use any HSE offerings, we have some questions for you. We want to hear your feedback so we can keep improving our offerings and our logistics. Thank you in advance!! Joerg PS: This has been posted on the dark side, too.

This utility VI is helpful for filtering out only contained controls in a right-click Affected Items array. [LabVIEW 20xx]\resource\plugins\PopupMenus\support\Filter For Contained Controls Only.vi Many of the shipping right-click plugins use this VI for the exact purpose you describe... for example, check out the source code for the Change To Array Or Element plugin: [LabVIEW 20xx]\resource\plugins\PopupMenus\edit time panel and diagram\Change To Array Or Element.llb\Change To Array Or Element.vi

Shaun is right. Some exports from kernel32 seem to be not supported but we can't see the list of bad functions in your screenshot. Also the msvcr90.dll sounds weird if you run the DLL checker on the same machine that you verified the DLL to work in LabVIEW. MSVC9.0 is the version of the MS C Compiler used in Visual Studio 2008. You need the MS Visual Studio 2008 32-bit C Runtime installed on every system that you want to execute this DLL on. But the standard MS C Runtime can't be installed on the Pharlap ETS system since it depends on newer Windows APIs that Pharlap ETS doesn't support. NI has created certain versions of the MS C Runtime that can be installed on Pharlap ETS. You need to install the according support on each realtime target in NI Max. There are installable packages for following MS C Runtimes: MSC 7.1 (Visual Studio 2003) MSC 9.0 (Visual Studio 2008) MSC 10.0 (Visual Studio 2010) If you managed to compile your project in MSVC 6.0 then it will also work since that only uses the standard MSVCRT.DLL that is provided with every Windows installation since about Windows 95. Only DLLs compiled with Visual Studio 6, 2003, 2008 or 2010 can be possibly made to work on NI Pharlap ETS systems. Any newer Visual Studio version or alternative C compilers are not really an option unless you are prepared to dig into linker script customization, but that is something I haven't really bothered with ever, so it is unlikely you should even try.

For a regular library (.lvlib), opening a reference to it (via the 'Library.Open' method) will not bring member VIs into memory. For a class (.lvclass), opening a reference to it (via the Library.Open method) will bring all member VIs into memory. There's no way around this behavior that I know of.

Love the language but it is hard to disagree with this, I am a synesthetic and dyslexic human who finds it much easier to deal with and faster to program in(except for the amount that it crashes and the multi-hour build times) I have 10-15 years left in my career (hopefully, no climate change depression 🤞) and I fully expect to spend the last 5-10 doing legacy support and converting old LabVIEW apps to something else. I am starting to learn skills that will facilitate this. Closed source will never compete with open souce. Just look at how dotnet has expanded since Microsoft open sourced it and moved it to cross platform.

Dear Santa NI I am now in my 40s with youngish kids, so despite the fact that all I got for Christmas this year was a Pickle Rick cushion I am not actually complaining. However, I would like to get my order in to the Elves as early as possible. This is my wishlist, in no particular order. I expect this list will not be to everyone's taste, this is ok, this is just my opinion. Make LabVIEW free forever. The war is over, Python has won. If you want to be relevant in 5 to 10 years you need to embrace this. The community edition is a great start but is is probably not enough. Note: I accept it might be necessary to charge for FPGA stuff where I presume you license Xilinx tools. NI is and has always been a hardware company. Make all toolkits free. See the above point. Remove all third party licensing stuff. Nobody makes any money from this anyway. Encourage completely open sharing of code and lead by example. Take all the software engineering knowledge gained during the NXG experiment and start a deep refactor of the current gen IDE. Small changes here please though... we should not have to wait 10 years. Listen to the feedback of your most passionate users during this refactor. NXG failed because you ignored us and just assumed we would consume whatever was placed in front of us. I am talking about the people like those reading this post on Christmas day and their spare time because they are so deeply committed to LabVIEW My eyes are not what they used to be, so please bring in the NXG style vector graphic support so I can adjust the zoom of my block diagram and front panel to suit accordingly As part of the deep refactor, the run-time GUI needs to be modernised. We need proper support for resizable GUIs that react sensible to high DPI environments. Bring the best bits of NXG over to current gen. For example the dockable properties pane. (Sorry not much else comes to mind) Remove support for Linux and Mac and start to prune this cross compatibility from the codebase. I know this is going to get me flamed for eternity from 0.1 % of the users. (You pretty much made this decision for NXG already). Windows 10 is a great OS and has won the war here. Get rid of the 32-bit version and make RT 64-bit compatible. You are a decade overdue here. Add unicode support. I have only needed this a few times, but it is mandatory for a multicultural language in 2021 and going forward Port the Web Module to Current Gen. All the news I have heard is that the Web Module is going to become a standalone product. Please bring this into Current Gen. This has so much potential. Stop adding features for a few years. Spend the engineering effort polishing. Fix the random weirdness we get when deploying to RT Open source as many toolkits as you can. Move the Vision toolkit over to OpenCV and make it open source Sell your hardware a bit cheaper. We love your hardware and the integration with LabVIEW but when you are a big multiple more expensive than a competitor it is very hard to justify the cost. Allow people to source NI hardware through whatever channel makes most sense to them. Currently the rules on hardware purchasing across regions are ridiculous. Bring ni.com into the 21st century. The website is a dinosaur and makes me sad whenever I have to use it Re-engage with universities to inspire the next generation of young engineers and makers. This will be much easier if the price is zero Re-engage with the community of your most passionate supporters. Lately it has felt like there is a black hole when communicating with you Engineer ambitiously? What does this even mean? The people using your products are doing their best, please don't patronise us with this slogan. Take the hard work done in NXG and make VIs into a non-binary format human readable so that we can diff and merge with our choice of SCC tools Remove all hurdles to hand-editing of these files (no more pointless hashes for "protection" of .lvlibs and VIs etc) Openly publish the file formats to allow advanced users to make toolkits. We have some seriously skilled users here who already know how to edit the binary versions! Embrace this, it can only help you. Introduce some kind of virtualenv ala Python. i.e. allow libraries and toolkits to be installed on a per-project basis. (I think this is something JKI are investigating with their new Project Dragon thing) For the love of all that is holy do not integrate Git deeply into LabVIEW. Nobody wants to be locked into someone else's choice of SCC. (That said, I do think everyone should use Git anyway, this is another war that has been won). That is about it for now. All I want is for you guys to succeed so my career of nearly 20 years does not need to be flushed down the toilet like 2020. Love you Neil (Edited: added a few more bullets)