C or LabVIEW: CompactRIO

[Loubear]

I prefer C++ myself, but I'm going to have to learn labview either way because I'll pretty much be the only programmer on my team next year ( subteam leader graduating...) I'd like to give the choice to new programmers about which one they want to use, and I'll be learning both to help them with whichever one they choose. Also, the simplicity of probing and analyzing video data is very tempting... The best option for me at least, is to hope that NI finalizes their compatibility stuff, so that we get to use vis with dlls interchangeably and vice versa instead of choosing one and sticking with it..

[Turing]

ComradeNikolai made a comment about commenting above, and I thought I should comment on it.

1) Comments should be used for . . . comments. Aside from debugging during development, commented-out code is likely a bad thing. If you find yourself looking at code with large sections commented out, it may be time to consider cleaning up unused, broken, or out-dated code.

2) One of the structures in LabVIEW is a "diagram disable block" which acts like commenting out code in a text-based language. You can still see the underlying code, but a transparent block is above it and the code will not run.

[Uberbots]

I think what some people are going to label LabVIEW as is the rookie standard... which really isn't true at all. LV is powerful; extremely powerful. The 'flowgraph' portion of LV is very high level, yet based on modifiable low-level code. Anyone who makes their robot in C will quickly realize how un-needed it is at the level the FRC competition is going to. you only have 6 weeks to program, and lets say the challenge is to autonomously pick out 15 red colored balls from a pile of 150 multicolored balls. Anyone using C programming from scratch will be in the pit because no easy-to-use library really exists for the task at hand. in LV, however, the vision and manipulation libraries are extensive, and the ability to add new libraries further adds to the power.

true, labview's libraries probably could be ported to work with a standard C compiler, and probably already have.
but isn't it easier to maintain the code when you can see it all at once, while it is natively written in a followable flowchart form?

[random_guy7531]

Originally Posted by markulrich

As a team that hasn't developed a very strong programming base yet, we are considering switching from C/MPLAB to LabVIEW next year. I think that it would be much easier for inexperienced students.

1) What is your team planning to use?
2) What do you think will become the new standard?
3) What will most rookie teams pick next year?
4) Do you think FIRST will give us the standard LabVIEW, or will we have a customized interface for the CompactRIO?
5) We have some NXTs. Would programming them using LabVIEW be a good way to get some experience before next year's kickoff?
6) Will there be any limitations to using LabVIEW? Will there be any features that are easily accessibly throught LabVIEW but require complex C? What are the main advantages/disadvantages?

Thanks so much, any advice is greatly appreciated.

1) we will most likely (about 95-99% sure) be useing c/C++ considering that the students already know the lanuage from previous years, and the newer students have been shown to learn from them rather well (by osmosis ). As well, c/c++ gives the programmer a finer amount of control over their control system, and also provides a HUGE library of code that has already been developed (just think of all the c++ libraries in existance. Although many wont be applicable (like, say, the directX library), others could be very useful, such as a sockets library for sending datagram packets across the wifi connection to the oi to display sensor info, etc). Also, it is one of the primary languages used by the mentors for their robots.

2)Personally, although i see labview doing very well among younger or rookie teams, I thinks that c/c++ will the language of choice for the older (>2 years) teams simply on the basis that c/c++ can carry over to much more in the programming world (try programming a windows app in labview). I guess you could look at the c/c++ vs labview in the same way $@#$@#$@# the current c vs easyC decision many teams have. easyC is good for a starting team without a knowledgable programming mentor who needs to get through a season, but for total control over a program, c/c++ is preferred.

3)As I explained above, i think labview will be the choice of most rookie teams. LAbview will enable teams to get off the ground quickly, and they can switch to c/c+ when they feel that they need greater control over their control system.

4)Im really not sure on this one. I think that FIRST will likely provide a standard labview, but with first elements, like the WPI lib, installed with it. Basically, i think it will be a standard version for all intents and purposes, but optomized for first. Then again, im not really sure here, so quoting me would probably be a bad idea.

5)I think that doing so would be a great way to try out the labview side of things before getting the full system. People learn by actually coding (well, dragging in this case), not just by reading or watching a tutorial. The more hands on experience you can get, the more prepared you will be for next season. However, be cautious about what may change between the NXT and cRio. The addition of the OI will change several things, so be prepared for things to not be the exact same as they were with the NXT as they are with the Rio.

6)I dont think that the limitations on labview will be that great. That being said, C/c++'s vast number of already written libraries can give it an advantage (if they are applicable). Think about having an single board computer (like a via motherboard with a small hdd and like 128 mb of ram) running windows xp sitting on your robot which the cRio talks to using its ethernet port. The cRio would communicate all of its sensor data, which the computer would process and return all of the motor/relay commands. THis would give the advantage of allowing more complex calculations, as well as the ability to program in the language of almost anyones choice, as all the cRio would have to do would be to read sensors, send them out in a TCP or UDP packet, and then receive a TCP or UDP packet and assign motor commands. The computer would be doing all of the processing of the actual values, which could be done in c#, java, or vb.net (any language that supports sockets). While i dont know if labview can do this, I think that it would be much more difficult than in c++. One thing labview has going for it that I personally liked was its data filters. Many sensors we have tried in the past have been very noisy, and labview has its own filters incorporated with it that actually make the data readable.

pros/cons:

c++:
pro-lots of flexibility. already developed libraries. known from previous years.
Object orientation (YAY! )

cons- difficult to pick up for a first timer, requires more knowledge of coding and algorithm development

labview:
pros- visual coding allows quick pickup by less experienced students. Allows for more complex control systems by younger teams

cons-less flexible, less applicable in larger context of programming

Hope this helps!

[Greg McKaskle]

I've inserted comments with >>s.

... just think of all the c++ libraries in existance. Although many wont be applicable (like, say, the directX library), others could be very useful, such as a sockets library for sending datagram packets across the wifi connection to the oi to display sensor info, etc). Also, it is one of the primary languages used by the mentors for their robots.

>> Both C and LV have enormous libraries available, but of course these will be subset to those portable enough to run on VxWorks. It isn't windows, and it isn't linux. Also, FIRST may not allow arbitrary wifi traffic, at least not within a competition.

2)Personally, ... (try programming a windows app in labview).

>> Actually, it isn't hard. The OI shown in Atlanta was written in LV, as was the Mindstorms NXT environment. Some things are easier, some harder.

4)
>> It will be standard LV, but with a simplified palette option. Over the last few decades, LV has grown to include tons of functionality, and this is an attempt to filter it to the needs of very bright high school teams. The full set will still be installed and available when desired. Additionally, some of the toolkits for LV will be included, such as vision. Most importantly, the FRC or WPI libraries will be integrated.

5)
>> A good way, but it may be just as valuable to go through some PC examples for LV. LV is cross-platform and the code written for the PC is the quickest to develop, and can later be targeted to the cRIO, NXT, etc. The biggest limit you will find on the NXT is the limited data types and programming palette. The subset of LV that NXT supports is very basic. Cool, but basic.

6)...running windows xp sitting on your robot which the cRio talks to using its ethernet port.

>> One reason XP and an SBC weren't the primary computer is the boot time, size requirements, etc. Also, the latency of going over TCP or UDP is large compared to internal busses, so this data path would need to be used wisely. I'm also not sure if FIRST will consider the multi-computer approach legal.

... While i dont know if labview can do this, I think that it would be much more difficult than in c++.

>> The TCP and UDP stuff in LV is quite nice. The data parsing isn't as nice as in some rapid prototyping languages, but it works fine once you get used to it.

pros/cons:

>> Your list was a pretty good one in my opinion, but I'll list what I've experienced as the major differences between these languages.

C/C++ are expected to have the flexibility to write a complete OS such as unix. They plug into every nook and cranny of the HW, no matter how icky or low-level. You can cast pointers, for good and evil, and build amazingly efficient data structures and algorithms provided you can debug them. Summary: the ultimate in flexibility, but one line of code can contain so many bugs, it boggles the mind. Thus one of the more expensive and time-consuming languages to use for development.

LabVIEW is a higher level language. It puts more emphasis on the problem domain, and less on the syntax or logistics of your program. Because you don't have pointers and the like, it is simultaneously easier to get the code working, and harder to get the same control or efficiency as C. This is the same tradeoff as most other higher order rapid prototyping languages. Graphical is the first element people notice, but the data flow approach is really the more fundamental difference. It makes parallel code so easy that whole new approaches are now feasible, and a C/C++ developer scared of threads may need to reconsider their approach to fully use LV. LV is also good for unit testing and modular development.

Other distinct differences are the debugging tools. LV has some nice ones. C/C++ has some different nice ones. I use and really enjoy using both languages.

[neutrino15]

I wrote to the WPIlib team concerning the features available to both Labview and C/C++. It seems as though they are fully committed to offering an almost identical layer of abstraction in Labview/C/C++. With windriver's supposed debugger, it seems as if the only advantage of using Labview would be the Graphcial programming (which is not that much of an advantage to some people):

LabVIEW has an extensive library of code included with it. We are trying to get all the relevant stuff ported to C/C++ so it will be accessible to both languages. For example, selected parts of the Image Processing library is being ported as we speak. That will give teams access to most of the vision code in either language.

C++ will be well supported with classes for each type of device, sensor, and robot abstraction (like driving). Each of those classes will also be on the LabVIEW palette.

The C/C++ default code will be through the library. Since most of the heavy lifting is being done by hardware, the library provides a pretty thin framework. Most of the complex stuff is around driver station – field - robot communications like support competitions, i.e. autonomous/teleop, enable/disable and Driver Station. So the philosophy is that you write programs “from scratch” for the most part, except that there is a rich set of classes (and functions in C) to handle device support.

Since the source code will be available, you’re free to modify it if you feel that is required. But we’re trying to make the programming interface pretty non-intrusive. The goal is for it to never get in your way from doing what you need to.

Between the Open Sourceness, Windriver Workbench, the chance to learn C++, and the ability to continue using Subversion (our versioning system of choice), It's fair to say we will be using C++.

[adman]

The question you have to ask yourself about the entire shift to the
CRIO Chassis and the NI Software ensemble is...

Do I want to teach my students a langauge that can be used in any
industry at any level ... C, C++

or

Do I want to teach my students a lanaguage that is much easier to
learn up front, can be adapted but will rarely be ported to things
like a mass consumed low cost consumer product... LabView

As with all things in life. Probably both is the correct answer.

[Russ Beavis]

I wouldn't sell NI + LabVIEW short with respect to programming lower-end microcontrollers.

http://www.ni.com/embedded/

The tools might be a bit pricey and still somewhat immature but I can envision a time when > 90% of programmers will be using graphical tools (eg LabVIEW, Simulink, UML, etc) and < 10% of programmers will be doing low-level work in a text-based language.

Anyone still using punch cards and assembly language out there? Those were great tools for their time and are still critical in a number of applications. However, I'm sure that C/C++ is WAY more common now even though assembly language dominated the embedded world until relatively recently.

Will the graphical tools create code that is as efficient as hand-crafted assembly or C? Never. Will continued time-to-market pressure force engineers to find faster ways to develop their code? You bet.

Russ

[JesseK]

1) What is your team planning to use?
I want to use LabView itself. I hate dealing with pointers. I'd rather work from an algorithmic level than a nit-picky tit-for-tat variable level. However, I'm not the programming mentor so I don't have final say for what the team will use.

2) What do you think will become the new standard?
In 2 years, LabView. Veterans who stuck to their guns in C/C++ will experience shock and awe when they're stomped by algorithms that would have been hard to program in C, namely things that have to do with the vision system.

3) What will most rookie teams pick next year?
No clue. It seems logical that the previous reply about "whichever has more documentation" is the best prediction.

4) Do you think FIRST will give us the standard LabVIEW, or will we have a customized interface for the CompactRIO?
The FIRST rep at the Q&A said there would be specific libraries for use with an FRC bot. These libraries are being developed by WPI. Other than that, no mention was made about a "custom interface" to the CompactRIO. So it's standard labview with a few bells and whistles that tell the RIO what ports map to what pwms, etc (I think).

5) We have some NXTs. Would programming them using LabVIEW be a good way to get some experience before next year's kickoff?
Let me consult my Magic 8 Ball... :-p

6) Will there be any limitations to using LabVIEW? Will there be any features that are easily accessibly throught LabVIEW but require complex C? What are the main advantages/disadvantages?
Supposedly we can use a laptop and communicate with the driver's station via the laptop. This will allow us to connect ANY USB joystick or device to the laptop and control the bot. This also implies (though it may later be throttled) that the laptop may serve as an offboard processor for other external scripts. So long as the interface exists and the software can communicate back to the Labview API, the limitations are only limited by your teams' minds. The LabView API can do many many things so long as you properly encode a way to receive the external data (e.g. file inputs...but don't count on real-time direct IP protocol communication...).