Amongst teams using WRWB (C or C++) for development, are there any that have no regrets about the choice?
If your team is pleased with WRWB, could you please provide some comment as to why your team chose WRWB over labview?
Also did you have a team member (mentor or otherwise) with previous vxWorks experience?
we chose windriver becuase our experience on c/c++ … and the last year we use c and have more success.
if u don’t have any experience you should use labview
I have tons of experience with eclipse (Java and C++), what WR is built on. I also have experience in C, C++, C#, and the OOP style.
None of my team’s students had experience in either labview or C/C++, but we had me (full-time C/C++ programmer) and a few other mentors who had dabbled in C++. With this in mind, we decided that:
- We were bound to hit roadblocks in either environment. Think bizarre compile errors, or “why is it doing THAT?!” kind of events.
- People with lots of experience in a given environment tend to know how to get around roadblocks in that environment
- Thus, choosing the environment that we had background in would be the most prudent choice.
Another way to look at it is that labview probably has a higher “top speed of development”, but accelerating our team to that rate would take long, because not only would the students be learning, but so would the mentors. With C/C++, we can hit the ground running, programming wise. Our plan is to compete this year with C/C++, then re-do the robot’s program in labview so that next year we’re ready to do it all in LabView. See attached image for a pictorial version of this paragraph.
I am very happy with Wind River Work Bench. I am a co-mentor on our programming team, and both of us mentors have experience with C/C++. We used eclipse with WPILib last year and were fairly successful.
We are in the same situation with Bongle: I and other mentors have a lot of experience using C/C++, and no experience using LabView at all.
However, eclipse and WindRiver annoy me quite a deal. I’ve done a lot of work with visual studio in the past, and despite looking similar, the environments are both rather different (in particular: shortcut keystrokes, eclipse’s millions of tabs, autocomplete, and the whole ‘workspace’ paradigm to name a few). The WindRiver-specific stuff seems to be mostly semi-intuitive, except there are a few places where at first it seemed like to do particular actions a particular option seemed like the way to do it – but then it turns out it does it, but in a totally different way.
Despite those annoyances, as I am learning to deal with them I’m becoming more productive.
One thing we really love however is the ability to setup our laptops on a table in the gym, and sit there and do just about everything we need to do wirelessly without having to constantly walk over to the bot. 
Also, I am 85% happy with WPILib – I think they did a great job abstracting a lot of the common functionality away, and it makes really simple things really simple. There are a few places where I think I would rather have some of the objects setup a bit differently, but thats ok. Just waiting for them to open it up so we can submit patches… 
I’m growing increasingly frustrated with the WRWB package. We have spent most of our time setting up the workspace and fixing little bugs that pop up. It seems every time we are about to get a nice piece of code to run, Workbench (or something in the cRIO) breaks. We are currently having an issue where the cRIO keeps switching between system and user mode. Any ideas how to stop that?
Does anyone know if there is a definitive guide to setting up Workbench? It seems the new LV 2 update and cRIO image v7 broke our existing settings.
I do agree – getting the workbench setup properly is a pain. However, once you get it setup correctly the first time I have personally found there is very little that needs to be changed (except for minor idiosyncrasies ).
Go to C:\WindRiver\docs\extensions\FRC … theres a bunch of magic in there… updated versions of the documents that are only posted online in their old forms (which is really annoying, IMHO). “C Programming Guide for FRC.pdf” has the information you want.
We are loving it, we are programming up a storm here in it, with the only thing slowing us down being the incomplete manual. Someone posted a new doxygen output which in addition to the source fills in any of the wholes. The examples are ok, but they do do some things that are kind of frowned upon in terms of clean code (i.e. put things in a cpp file that really should be in a header). I spent the time from Atlanta announcement on testing labview, and even attended a training, and really did not like it, I spent way to much time just trying to figure out the most basic things in c in labview. On the otherside NI has made some great processing libs and tools for Labview.
On another not, I was speaking to a relative who is a lead engineer for a major consumer and avionics electronics company, and what he told me is that they are having a hard time finding people in the United States that have the skills to do the programming, they will never be using labview in there products they will be using C. Right now there solution has been to hire people from India for SKILL not COST. From that persepective which is better to prepare you for the workforce?
We chose WindRiver over lab view because most of our programmers know c/c++. Most of us felt that me might as well work with something we can code in instead of learning something else.
599 is the same situation most of you - we went with Wind River because our programmers and mentors have lots of C experience and little to no LabView experience. I’m fairly happy with Workbench since it’s basically Eclipse and I’ve been using that for most of my own coding for a bit now. It’s got a few quirks that really annoy me but there are enough nice features to balance out.
Our team 1382 started to learn and test both. We always were programming on c/c++, but on this year we chose Labview because it’s very useful, not only on FRC.
On Labview we can make graphs and others indicators with sensors signals. We think with it, the code problems can be solve fast and better.
Our team is having trouble with the WindRiver compiler. Can you please post the location of the header files for the C++? I need to verify we installed the product correctly.
Thanks
Have you tried to compile one of the examples? A practice we’ve adopted is any project we create is derived directly from the SimpleTemplate example… its easier for debugging multiple different programs at once, since it makes it easier to find in the module list for things to unload…
Yes we have, we even tried a simple hello world. The compiler can not find cstdio.h and the only one we could find is under a jre directory. Where are your system .h files?
Thanks in advance for answering.
cstdio.h? Which example are you compiling… have you tried the FRC examples (the other ones won’t work, AFAIK).
I’ll give it a try. Can you do a search on your machine for iostream.h and tell me where the file is located? That would be a really tell me alot.
Thanks
There is no iostream.h , thats the old style header and should not be used. iostream is what you’re looking for.
There are 6 include directories on the project.
- C:\WindRiver\vxworks-6.3 arget\h
- C:\WindRiver\vxworks-6.3 arget\h\WPILib
- C:\WindRiver\vxworks-6.3 arget\h\coreip
- C:\WindRiver\gnu\3.4.4-vxworks-6.3\x86-win32\lib\gcc\powerpc-wrs-vxworks\3.4.4\include
- C:\WindRiver\gnu\3.4.4-vxworks-6.3\x86-win32\include\c++\3.4.4
- C:\WindRiver\gnu\3.4.4-vxworks-6.3\x86-win32\include\c++\3.4.4\powerpc-wrs-vxworks
If you’re just starting out with a new project (especially without any prior C/C++ experience) – if you need to include anything other than WPILib.h you’re probably doing something wrong.
I’m one of the mentors. It looks like the group did not install the WindRiver product correctly. The WPILib.h file includes IOStream, IO, and many others. We get compilation errors when trying to build the samples but, given the information you just gave us, the issues we are having are obvious. I’ll have them reinstall so we can get off LabView.
Thanks for all your help.