Leaderboard

So first I want to acknowledge some areas we could have done better. I have been involved in a number of discussions around what our migration strategy looks like, and the biggest gap we immediately identified is a lack of clear external messaging, so that is something we are looking to address. I have talked to all different kinds of users, and in a relatively short discussion we are able to align on whether or not NXG is ready for their use case. That is great, but you should be able to make that determination yourself by looking at public documentation, it should not require a call with me or a frustrating session of attempting to migrate an application. NI has tried to provide this in the past with the LabVIEW roadmap, but it doesn't have enough detail for you to make a high confidence decision. For example, it is not possible to differentiate between functionality that is not complete yet versus functionality which was intentionally omitted or intentionally changed. We have also not done a very good job of explaining the background of specific decisions - which leads to some of the feedback in this thread where it seems like we have changed everything for no reason. Certainly I can point to some changes which were mistakes, and generally speaking we have the flexibility to undo those changes, but many of the bigger changes were intentional, designed, tested changes which we believe are an improvement. We intend to do a better job of publicly documenting those decisions. It is hard to overstate the reorganization efforts that have happened within NI over the last couple of years. Last NIWeek Eric Starkloff talked about how we were organizing the company around business units instead of around products, and that has had broad reaching impact, but we were making major shifts in the way we built products in the last couple of years anyway. Like many of the large software companies we have been shifting to a user-centric development model where we actively try to bring the user into the development process instead of thinking we know what they need and developing in secret. A good example of this shift is the introduction of the product owner role in NI R&D, a role focused on ensuring we are delivering the right value to our users. Both the product owners and product planners have long histories of working with LabVIEW, so you should not feel like the decision makers working on LabVIEW NXG are completely detached from LabVIEW - in many cases the decision makers for the two products are the same. There have definitely been teething pains with this shift, but we are getting better at it. I saw several comments about feeling left out of the decision process, and there are certainly some valid concerns, but I would also point to the level of engagement over the last few years where the product owners and product planners have attended and solicited input at the CLA summits, GDevCon and NIWeek. We also have quite a few targeted user engagements when we are working on defining features and workflows. We can absolutely do more, and we plan to, but many significant product decisions have been made as a result of those engagements. Remember that there are a lot of LabVIEW users out there, and we can't talk to all of them. A light-hearted analogy would be to seeing the results of a national poll and saying - 'well nobody asked me!' That being said, I do want to increase my engagement with this community, and there is clearly a lot of passion about making LabVIEW NXG the best it can be. I would love to set up some 1x1 interviews with those of you who are interested so I can better understand how you are using LabVIEW today. I will start a different thread about that. Back to the main point - it is important to understand what LabVIEW NXG is today versus what it will become. LabVIEW NXG today is not ready for most of the applications of this community. You are some of the most advanced LabVIEW users around, and are collectively using nearly every feature in the product. As Stephen said early in this thread - NXG has many nice things, it just isn't ready for him (or most of you) yet. We are trying hard to get there and have made substantial progress, but there are still functionality gaps. We expect that you will continue to use LabVIEW for at least a few more years until NXG is more complete for your workflows. I saw a comment about not wanting to develop an application of thousands of files in NXG, and I agree that I don't consider NXG ready for that either. Similarly - converting a large project from LabVIEW to LabVIEW NXG is not something I would recommend yet either. The Conversion Utility and associated tooling is more effective for converting instrument drivers and libraries. To be honest I was surprised that no one in this thread pointed out that there is currently no way to probe classes, and no way to make custom probes. Yes we are already at version 5.0 and we still haven't built a full replacement for LabVIEW. That is a reflection of the incredible array of features in LabVIEW and the diversity of users and user cases that this community contains. However version 1.0 was not intended as a full replacement for LabVIEW and neither is version 5.0. For a subset of our user base who are building less complex applications NXG is ready for them and they are using it. For example a lot of work went into the workflow of helping a simple user take and process their first measurement, and we are building out from that foundation. When I talked about our reorganization and change in philosophy - that also translates into how we prioritize features and workflows. We are not just racing to recreate every last piece of LabVIEW in LabVIEW NXG. We are trying to understand the problems you were using those features to solve so we can determine if that same solution is the best choice for NXG. I plan on also addressing some of the specific points of feedback in this thread, but this post turned out much longer than I had intended! Hopefully that provides a bit of framing around the current state of LabVIEW NXG. Thanks, Jeff

As I did not find any implementation for CRC 8 SAE J1850, so here is mine. Suitable also for FPGA. BR TS CRC.vi

There's an Idea Exchange entry about this for LabVIEW CG, but it really should extend to NXG too: https://forums.ni.com/t5/NI-Package-Management-Idea/Install-the-same-package-to-multiple-versions-of-LabVIEW/idi-p/3965419

As someone that sometimes publishes open source code, I generally choose the most permissive license I can because I basically only want the code to be shared and I don't mind the rest. I had started using the Unlicense for all my work but realized that it's not OSI-approved (and apparently some countries don't recognize Public Domain as a thing), so I fell back on Zero-clause BSD. https://opensource.org/licenses/0BSD You know, if someone wants to use my name to advertise their stuff, I am not sure I would mind. I guess if they misuse my name in some way, I could sue them for that anyhow. But it's not like they'd build a rocket launcher and say that my code powers it, therefore it's bound to work correctly, right? As for the copyright notice on every front panel, block diagram or VI descriptions: please don't do that. 🙂 It just multiplies by 2 the time it takes to compile your packages. Useless, unproductive, annoying and of no legal value. (IMO anyway)

As a user collaborating on an idea for un-created code, I want to be able to see what other users are thinking about as well. For example, let's say, in the back of my mind, I have this idea for an open source barbecue thermometer that runs on a Raspberry Pi using LabVIEW. That said, I have several open source project ideas, all of which I find equally interesting, so I randomly pick one of them to start working on. But, maybe there's another community member that wants such a BBQ thermometer as well. If I knew that, I might choose to prioritize the project that someone else is interested in vs. another project that nobody (but me) cares about. Similarly, let's say I have the idea, but don't have the bandwidth to really pull it off in any reasonable timeframe. Someone else sees the idea, however, and wants to help. Knowing that I'm not alone, I might choose to begin work on the idea. Finally, let's say that I have this really cool idea, but I'm a software guy and it would probably require a custom Pi HAT. That's way outside my comfort zone, but maybe someone else is willing to help with that, and make the project a reality. This could even allow for voting, similar to the kudos system on the NI Idea Exchange. Of course, there's no obligation to do anything if your idea gets a bunch of kudos, but it could be incentive and/or drive innovation by others.