topic Re: After next year will LabVIEW be part of FIRST? in General

After next year will LabVIEW be part of FIRST?

aeastet — Wed, 12 Feb 2025 14:30:12 GMT

I have been part of FIRST since 2010. When I started LabVIEW was a primary programing language for robotics. Today LabVIEW is a sad ghost of what it used to be. There is no support for LabVIEW, No examples, virtually no support. Anytime someone post on the LabVIEW part of the Chief Delphi website the are ridiculed and made to feel bad that they are using a dead language. I think this reflects what I have seen using LabVIEW for the last 25 years. NI is a ghost of itself. Nothing new, nothing innovative, nothing to be proud of.

Is there anyone on this forum that can explain the intentions of NI as it pertains to FIRST after 2027? I have started learning JAVA so I can stay relevant in FIRST and maybe my real job too. I do find it hard to show students LabVIEW when even I feel that it will not be around for much longer except as a language that only older guys know. Like Fortran or pascal.

NI, why are you giving up all of these new engineers of the future that could be using your software and keeping it alive? Please tell us what the plan is moving forward with FIRST so I know if I should spend any more time or effort with anything LabVIEW in FIRST.

Re: After next year will LabVIEW be part of FIRST?

oscarfonseca — Thu, 13 Feb 2025 03:12:00 GMT

Hi Tim,

Thank you for your question and for being such a dedicated user of LabVIEW and FIRST Robotics mentor. While I can't share specifics about 2027+ yet, I want to assure you that LabVIEW remains a crucial product for NI and continues to be highly relevant in the industry. As you know, LabVIEW is extensively used in various fields, from automated manufacturing to industrial equipment monitoring and control. Its graphical programming environment empowers engineers and scientists to develop sophisticated applications without needing traditional coding.

I truly appreciate your commitment to using LabVIEW and your involvement in FIRST Robotics over the years. Your feedback and support are invaluable to us at NI. If you have any additional thoughts on what has been good or could be improved with LabVIEW in FRC over the past 15 years, please feel free to reply here or contact me through the Forums messages.

Thank you again for your dedication and support!

Re: After next year will LabVIEW be part of FIRST?

aeastet — Fri, 14 Feb 2025 16:46:34 GMT

Where would I even start.

2010 LabVIEW was on 60% of the robots in FIRST

2025 LabVIEW is on less that 6% of the robots in FIRST

2010 I could get help from NI about LabVIEW issues in FIRST, Software and examples were available. New projects for path planning and vision were being developed and we available to LabVIEW users.

2025 There is nothing left to ask questions about. No LabVIEW code unless someone complies a DLL for Python or C++ that someone else made converted Python or C++ code to LabVIEW.

How could you make improvements? How about just being part of FIRST again. No software that is provided today for teams to use even has a LabVIEW example. The only reason any of the code is available to teams is because one guy, who doesn't even program with LabVIEW, is doing his best to make sure that teams have an option if they are the unfortunate ones still using LabVIEW.

LabVIEW is becoming less and less relevant every day. Just because you say it is relevant does not make it true. Just look at the numbers above. I work in the industry. I see how hard it is to find new LabVIEW programmers when I am trying to hire someone new. The pipelines for new programmers (FIRST, Colleges, etc..) are all gone. How can you stay relevant if the new generation never sees your software? I do not even try to show the students in FIRST LabVIEW any more. They are think it is obsolete and for old people. There is not support in FIRST so why would you use it. It is hard to argue with that.

Re: After next year will LabVIEW be part of FIRST?

aeastet — Mon, 06 Oct 2025 19:14:10 GMT

Any ideas on if NI is going to be part of FRIST after 2027? I just released a vision package for teams to use in Chief Delphi. I really don't expect that teams will use it because of the feelings about LabVIEW in FIRST. It would be nice to know if I am going to need to release an exe with in installer or I can keep the git repository for team to use.

Are teams going to have to download the community version of LabVIEW to use it in the future in FIRST? You guy cannot wait too much longer if you hope to have any part of NI in FIRST moving forward. Teams are already celebrating the demise of LabVIEW in FIRST. That is a big miss for NI and Emerson.

Re: After next year will LabVIEW be part of FIRST?

oscarfonseca — Wed, 08 Oct 2025 03:28:34 GMT

Hello Tim,

Our latest news announced in the FIRST Blog: 2027 Control System Testing Reminder

Emerson is excited to continue its support of FIRST through the exploration of enabling NI LabVIEW on the next-generation control system for both the FIRST Robotics Competition and FIRST Tech Challenge.

Over the coming months, the NI team at Emerson will be working closely with FIRST control system developers to evaluate and test the new Systemcore controller for full support with the LabVIEW Community Edition. This will simplify licensing, installation, and allow teams to develop LabVIEW code across major operating systems.

For decades, NI LabVIEW has empowered engineers, scientists, and students around the world to solve complex problems and accelerate innovation, from groundbreaking research at CERN and NASA’s rocket propulsion testing, to life-saving medical advancements at Stryker.

Looking forward to the results of the testing from our R&D team.

Cheers,

Re: After next year will LabVIEW be part of FIRST?

JimASim — Tue, 11 Nov 2025 21:36:47 GMT

This is really nice to hear.

If there is some way I can help this effort, let me know. I'd be happy to contribute any way I'm able. You may already have my contact, but just in case it is jim_simpson@windstream.net

Over the years, I've created a number of LabVIEW libraries and documentation, that I'd want to ensure work with any new FRC things. These include:

WPILIB math library (includes examples and sample robots) - https://github.com/jsimpso81/WPIlibMathLabVIEW
Extra examples (some of these may be old) - https://github.com/jsimpso81/WPIlibMathLabVIEW_Examples
PhotonVision LabVIEW - https://github.com/jsimpso81/PhotonVisionLabVIEW
PathPlanner LabView implementation (not 100% up to date, but works well) - https://github.com/jsimpso81/PathPlannerLabVIEW
Choreo LabVIEW implementation (not up to date) - https://github.com/jsimpso81/ChoreoLibLabVIEW
Secret Book of LabVIEW ver 2 and training - https://github.com/jsimpso81/FRC_Secret_Book_Of_FRC_LabVIEW_2

Some LabVIEW things that might make it easier for teams to use LabVIEW.

Faster compile - I know this is quite a job... It is the most complained about thing I've heard. It seems the compiler is single threaded. It also appears that it compiles everything even if it isn't a dependency of something changed or something changed. Generally I teach my team to make modules, test them completely before integrating into robot code. This way full robot compiles are minimized.
Better quality assurance - The next complained about thing is LabVIEW is buggy. This was primarily the WPILIB library stuff. This has been much better lately, but impressions once made are hard to change.
Dashboard template with larger resolutions - Re-sizing the dashboard template to use larger screen resolutions is fairly hard. As such I created some templates of different fixed sizes. This has worked well. I made a post a couple of years ago asking for these to be incorporated into the standard, but that didn't happen. Larger sizes would still be nice. Also non 4x3 video size choices in that drop down menu.
Better visibility, documentation, marketing - Not a technical thing, but something to promote that robot control system can be build faster and just as good with LabVIEW.
Easier integration with 3rd party libraries - I ported or made interfaces for PhotonVision and PathPlanner, but this has been hard to keep up with. It has been hard enough to keep up with the WPILIB math library changes so they remain compatible. I don't have a good suggestion here.

For my own coding somethings that I'm uncertain of include:

Documentation on making the most cpu efficient code: For example is the Formula Node or Expression node faster than implementing multiple blocks to perform calculations?
An easier way to edit palettes. Maybe create palettes from a spreadsheet template.
An easier way to create documentation. The documentation inside each VI is great. None of the built-in documentation tools seemed to work for what I was doing. I ended up creating a documentation tool that allowed me to create html files. These were then used to create web pages and PDF documentation for the libraries mentioned above.
Documentation on configuring github desktop or other git repositories / tools to use the visual VI compare tool.

Thanks

Jim Simpson

Re: After next year will LabVIEW be part of FIRST?

aeastet — Thu, 13 Nov 2025 14:31:10 GMT

@JimASim wrote:

This is really nice to hear.

If there is some way I can help this effort, let me know. I'd be happy to contribute any way I'm able. You may already have my contact, but just in case it is jim_simpson@windstream.net

Hi Jim I have talked to you on Chief Delphi a few times now. I appreciate all of your work to bring some of the open libraries to LabVIEW. It would be nice to have NI open the support to members that want to own and upkeep this code. I have another open question in this forum that asked that exact question.

Over the years, I've created a number of LabVIEW libraries and documentation,

Some LabVIEW things that might make it easier for teams to use LabVIEW.

Faster compile -

The newer versions of LabVIEW are supposed to make this better. I haven't done much new realtime stuff at work lately so I am not sure if this is faster. You can push the run button on your code and it will temporarly run on the roboRIO. After the first time you deploy your code it is really fast. Not sure if you knew that.

Better quality assurance -

NI does not take care of the WPI library. This is another area where they need to let member take over support for that. I am accredited and approved by the WPI board to add code to the WPI system. There is currently no LabVIEW code in the GIT repository. I would love to see this change.

Dashboard template with larger resolutions -

You can customize the dashboard to do what ever you want. The template is just to get you started. I am not sure if NI should own this but having more templates is a good idea. Again this would benefit from open sourcing this effort.

Better visibility, documentation, marketing

I have been around long enough to remember when LabVIEW was on 70% or more of the robots. I is sad to see how far down LabVIEW has fallen. I believe this is mostly do to the poor view of LabVIEW by the users. I do not believe that this was because of poor performance by LabVIEW, but more because teams never learned the proper way to use LabVIEW. It would also help to have video s os the do's and don't's of using LabVIEW. Again open sourcing this would be the best way to get this done.

Easier integration with 3rd party libraries

I agree here. If LabVIEW is going to see a revival in FIRST there needs to be code that gives the team the same access as Java. We have to lower to point of entery to the same level as Java to get teams to switch back.

For my own coding somethings that I'm uncertain of include:

Documentation on making the most cpu efficient code:

This is a complicated subject. There are many things that can be done to make code work better and faster. This would probably be part of the training that would need to be generated. Open source again!!!!

An easier way to edit palettes.

You need to look into the JKI package manager. It allows you to build and distribute code. It allows you to build packages that include the palette development. This is always included in the LabVIEW install. Look into it. It is easy to use and it provides versioning of the releases and package installs. We use this at work to manage all of our modules.

An easier way to create documentation.

Documentation is usually the thing that is hard to get people to do. Also we have found that building an example code that you include with the palette is better than documentation. For each module we develop we always include an example that shows how to use the code:

Documentation on configuring github desktop or other git repositories / tools to use the visual VI compare tool.

I'm not sure this is an NI issue. Teams may use a different software management tool than GIT or github. This is something that would also be good for the open source FIRST project.

Thanks

Jim Simpson

Re: After next year will LabVIEW be part of FIRST?

JimASim — Thu, 13 Nov 2025 16:26:09 GMT

Thank you for responding... Here are a couple of thoughts on your comments.

Better quality assurance -

NI does not take care of the WPI library. This is another area where they need to let member take over support for that. I am accredited and approved by the WPI board to add code to the WPI system. There is currently no LabVIEW code in the GIT repository. I would love to see this change.

Lately the quality assurance has been pretty good. However I think some of the original LabVIEW library code had issues. I wonder if it was written by college students from WPI? It doesn't matter, just that the impression lingered...

I guess I thought that NI took care of the LabVIEW WPI lib (or their FRC pallete). I tried a couple of years ago to get WPILIB to incorporate my library with theirs, or at least add documentation. It didn't go very far. I started to update the documentation myself to add a LabVIEW tab to the examples, but I never got far enough to submit it.

Dashboard template with larger resolutions -

You can customize the dashboard to do what ever you want. The template is just to get you started. I am not sure if NI should own this but having more templates is a good idea. Again this would benefit from open sourcing this effort.

Resizing the dashboard is fairly hard. I have a spreadsheet that calculates the size that all the things need to be set to. Also some of the code has to be changed. That is why I created a number of dashboard main VIs with different sizes. Also the dashboard project has some issues. Some of the files that are referenced aren't part of the project.

An easier way to create documentation.

Documentation is usually the thing that is hard to get people to do. Also we have found that building an example code that you include with the palette is better than documentation. For each module we develop we always include an example that shows how to use the code:

Documentation in each VI is easy. What I wanted was to create something like javadoc. I ended up creating my own application. It makes html files for each "group" of VIs. (This is based on file name. PID_*, MotorSim_* would be different groups.) The web pages were crude, so I just make a PDF file instead. This seems to work okay. (Not as nice as javadoc, but still one file and searchable.) I use the same app to make documentation for all the libraries I've published.

Documentation on configuring github desktop or other git repositories / tools to use the visual VI compare tool.

I'm not sure this is an NI issue. Teams may use a different software management tool than GIT or github. This is something that would also be good for the open source FIRST project.

We have used github with great success. (I've had more trouble with students stomping on java files...) We use the github desktop app. Its biggest drawback is the lack of a compare tool. I've not discovered how to make the LV compare tool work with it yet. (I realize that there are other git tools that can be used.)

I was hoping to hear back from NI on the how can I help question, or at least how to test my libraries with what they are doing.

Jim

Re: After next year will LabVIEW be part of FIRST?

aeastet — Thu, 13 Nov 2025 18:03:13 GMT

NI does have a compare tool available. It is built into LabVIEW. It will show you the difference between two vi's. It is not built into git though.