My friend and I were wondering which was more used, windriver or labview. We’ve also heard of teams using both together. We’re wondering how many people are using which, and potentially reasons for this decision. Thanks.
The reason why I/we choose to go with Lab View is simply for its “advanced” debugging capabilities. The whole concept of a front panel/dashboard is completely going to help us this year rather than having to stare at a terminal, seeing only one piece of data at one time. The dashboard rocks. The other debugging stuff in LabView makes it very easy to see exactly what is going on (little function to literally follow the flow of the program & see what has what value…etc).
Mostly why we/I chose it.
-Tanner
What our team decided to do (which was the least, although still so, controversial) was to focus on using LabView and perhaps secondarily use C or C++ if really get the fire under us going.
My opinion is that LabView is more pragmatic in a sense. There are mistakes that you can make in C that LabView simply won’t let you do. There are also many more plug-in style bits in LabView that make things easier.
Also, probably the biggest factor in the decision was that many mentors (especially those outside of the main programming mentors) had experience with LabView. Many people also wanted to learn LabView.
Any other opinions?
Our programming team students chose C++ primarily because:
- The returning students have C background from previous years.
- Our mentors were more versed in C/C++.
- The students saw C/C++ as a more widely applicable language/environment to learn be familiar with – they saw utility for it in a wider range of post-educational fields.
- The students liked that they could edit C/C++ code without need for a specialized environment (to do Labview well, you need Labview - you can edit C/C++ with something as simple as a text editor).
We made our choice back in September to allow time for pre-season training. We’ve been working with Windriver since the pre-ship in late November and so far, our team seems to be happy with the C++ choice.
Team 694 uses Windriver C++ exclusively.
The only NI Software we have played with so far is the “Vision Assistant.” All of our senior members have experience in C++, and we all think that Labview’s visual programming is just as tricky to master as text based C++. On top of that, C is much more of a standard in the programming world, so we all feel its more beneficial for our newbies to learn for their futures.
We do hope, however, to learn Labview after build season so we can be helpful to labview based teams in the future.
From my experience, people who are not familiar with programming will love LabView. Anyone who already knows how to program will like WindRiver better. Maybe that will help you decide.
Although it’s a bit strange at first when you’re used to text programming, I’m for LabVIEW all the way. I love the ability to change constants with the front panel w/o redownloading and using probes, it makes debugging so much easier.
C/C++ is certainly more efficient but when we’re using a controller as powerful as the cRIO and only have six weeks I think LabVIEW is the way to go. Graphical programming languages are becoming more and more common as hardware becomes more powerful.
Team 1318 is using LabVIEW. Though we have three veterans, all seasoned C programmers, we are all seniors and must pass on our knowledge. The new programmers have a range of programming experience and we thought it easier to teach them LabVIEW. In addition, LabVIEW is a little too attractive. Its debugging capabilities are impressive, with the ability to “probe wires” or look at/manipulate values on our front panel or whatnot. (though I have heard that C++ is now capable of working with the Dashboard…) Under other circumstances, I would have used C++, but we will use LabVIEW and see how it goes…
define both\hybrid
You can use C++ on the cRIO but still have a LabView dashboard running on your computer.
makes sense now:yikes:
Team 1111 is using C and C++ to program our robot simply because LabView is a proprietary software and C/C++ are standards. Anyone can write a compiler or IDE for C or C++. Labview seems like NI’s way of trying to pull FIRST off course from it’s goals and train students not to work towards an understanding of science and technology, but to stumble through it without having to know anything useful later in life. People using Labview can no more call themselves programmers than people using VB or Alice[/End Minirant]
There have been 2 programming challenges that have shone the value of LABVEIW this year. First, we decided to try filtering the joystick values to limit acceleration with out any sensor input. After, thrashing about trying to write a VI to do this, our programmer and mentor found several built in VI’s that could be used to do this. Being able to graphical see the out put of the filters really helped to zoom in on the best candidates. The speed with witch changes can be made is outstanding. It would take a seasoned C++ veteran to have gone thru all the options we did in about 3 hours. The built in VI filters are tunable. This past Saturday the robot was ready to drive and it’s amazing how fast changes can be made. The second task that made me become a LABVEIW believer was our testing of a Sharp ID distance senor to try and get better ranging on the PVC pipe trailer pipe than the camera. Our programmer whipped up a VI for testing in minutes. Once again the graphical feed back is very important. Our team has chronically had problems tackling any thing the least bit complicated in programming. This year is different. Things are happening. Labview is a great big tool box. I don’t care about proprietary software. Does it get the job done?