C or LabVIEW: CompactRIO
 

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.

Re: C or LabVIEW: CompactRIO
 

generally lab view isn't bad, there really isn't any thing wrong with it, it makes programming sensors easier. But it feels like i'm programming in photoshop. And when you can type 100 wpm (words per minute), the click and drag feels slow.

Re: C or LabVIEW: CompactRIO
 

1). well we used WPILib this year so there woulnt be a problem with use codeing in C/C++ next year. with that said we are already looking in to how to use labview because we think that we will be able to do alot more with labview than with C/C++ ( well in 6 weeks that is)

2). I think labview will become the new standard

3). rookies will pick what every has the better how too videos, or the best "getting started with _____" documentation. on that I see them using labview

4). no idea on what first will use . . but for specializations sake it will be standard labview with some custom first functions.

5). I think programing any thing for real is better than programing for "fake". so if you've got some NXTs go a head and use labe view to try some things out.



6). I think the only limitations to labview till be the learning curve, and with the exception of maybe some very easy "push button - raise arm" code every thing will be "more difficult" with C/C++

Re: C or LabVIEW: CompactRIO
 

1) What is your team planning to use?
Not sure at this point. I know LabVIEW pretty well, and C very well, but I'm graduating after next year and I don't really want the C knowledge to die off.

2) What do you think will become the new standard?
LabVIEW. It's a very robust system and it'll be picked up.

3) What will most rookie teams pick next year?
LabVIEW. There will be a lot of documentation (more than previous) on how to use it. Plug fancy videos and everything. It's also easier to look at and trace. These things will prevail when it comes to a rookie team choosing.

4) Do you think FIRST will give us the standard LabVIEW, or will we have a customized interface for the CompactRIO?
They already give teams LabVIEW, I'm going to guess it'll be some addon for it so we can use FIRST functions in it. At least I hope. I don't want a dumbed down version of LabVIEW =(

5) We have some NXTs. Would programming them using LabVIEW be a good way to get some experience before next year's kickoff?
YES. What kind of a question is that? =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?

Can't say. LabVIEW can seriously do pretty much anything C can. I've made really complicated things in LabVIEW because I couldn't think of an easy way to do it (and it'd have been easy in C), only to find later an easier way, or the function already existed. (I made a function to convert a unsigned to a signed.. I still don't know if such a function exists. When you use LabVIEW functions it truncates the number instead of making it negative, I think).

Re: C or LabVIEW: CompactRIO
 

I will be using C. I will also modify whichever WPILIB's we use to work the way WE program.

Generally speaking, if you know how to program, any time you add an additional layer of abstraction between you and your robot it is a bad thing. It creates issues (look up the disable to auton switchover that created issues because it went through teleop using an additional layer of abstraction).

In addition, Labview is not a common environment. I understand that it's used - but C is MUCH more widely used and will serve the students better in the future. I'd rather they have a good grasp of programming so they can actually fix problems they run into later rather than having someone else write them a new labview library that functions.

Both have their uses. As far as I'm concerned, Labview is very nice for data acquisition - because as someone said you can grab your sensor module library and plug it in and read your thermocouple temperature, etc. That's not something that's as easy in C. However, it is not for programming complex robotics, no matter how much playing you do with it. Even in industrial applications (we have a large number of test stations in our plant) they use C and underlying ladder logic and rely on Labview for data acquistion. Not control.

Re: C or LabVIEW: CompactRIO
 

1) What is your team planning to use?
I am planning on coding in C++, as it is what I'm most comfortable in. However, our coach may "strongly suggest" us to use LabVIEW... which would be unfortunate... When I'm faced with graphical programming, I just can't do it. It's not how I work.

2) What do you think will become the new standard?
I think, with nothing to base this off, most teams will stick with programming in C/C++, since most already have an established programming team which knows how to do everything in C, and so, there would be little to no advantage of using LabVIEW.

3) What will most rookie teams pick next year?
I think most will use LabVIEW because, as mentioned before, they have great support and many videos to help out. However, this year, many rookie teams, like mine, chose C over EasyC.

4) Do you think FIRST will give us the standard LabVIEW, or will we have a customized interface for the CompactRIO?
I thought I read somewhere that they ARE doing this, but it was about midnight when I was reading the thread...

5) We have some NXTs. Would programming them using LabVIEW be a good way to get some experience before next year's kickoff?
Yes.

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?
One /*dis*/advantage: no commenting out a huge block of code that doesn't work and consequently confuse everyone reading it. See? I need comments!
FIRST / National Instruments stated that there will be parity between the libraries for C and those for LabVIEW, so I think that with an equal understanding of LabVIEW and C, there will be no difference in difficulty.

Re: C or LabVIEW: CompactRIO
 

Our team is going to be using C++. The code team is already fluent in C, and we're going to be able to do some amazing stuff with Object-Oriented Programming.

2. I have no clue what will be the standard. It will be interesting to see which way teams swing.

3. I think rookie teams will be using LabView more.

4. I think some sort of customized interface would be released. This will make things interesting.

5. Familiarizing yourself with a language or IDE is always good, regardless of the project. That way when you actually start programming the robot, you know what to do and how to approach it.

6. I personally will always prefer C++ over LabVIEW. While I admit I have no experience with LabVIEW, I like to deal with hard code so I can program line by line, command by command.

Re: C or LabVIEW: CompactRIO
 

Hmm... I'm considering buying an NXT to practice working with LabView between now and next year's season.

Re: C or LabVIEW: CompactRIO
 

What do you think is the "best" way to have students learn LabVIEW during the offseason? Is there something better than the lego NXT, something more similar to what FIRST will use? Is there a good simulator (built into LabVIEW??) that students could use at home?

Re: C or LabVIEW: CompactRIO
 

I think you can make a user interface that you can play around with.

A basic instructional video can be found here.

Re: C or LabVIEW: CompactRIO
 

1) What is your team planning to use?
I'll let the new programmers pick that. We are starting fresh next year, Our programming "staff" graduates this year.
For my money? I think LabView is amazing


2) What do you think will become the new standard?

I hope it is LabView, but C and C++ has a installed base

3) What will most rookie teams pick next year?

Great question, not sure. Someone stated it will be whoever has the best "How to..."
I tend to agree

4) Do you think FIRST will give us the standard LabVIEW, or will we have a customized interface for the CompactRIO?

I hope it is a full on dev pakage with specialized libraries. That way I will have all of the tools I am used to

5) We have some NXTs. Would programming them using LabVIEW be a good way to get some experience before next year's kickoff?

Yes and No.
Yes because you will learn the drag and drop method.
No because a Full Dev Package of LabView is SO much cooler, with more capability

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?

Some one once told me that "LabView allows scientists to act like programmers. It makes the easy things hard but it makes the hard things easy"

I have programmed in LabView and in C (and Pascal and Fortran and...ok enough) and I prefer LabView. I don't even see the difference anymore between C and LV. But I can get up and running fast with LV

I am excited about this. I have always wondered if LabView is a good way to train a programmer.

Re: C or LabVIEW: CompactRIO
 

1. We will continue to use C, or C++ if OO is really useful for this (think driver control and complex modular end effector systems)

2. C is the industry standard, and frankly, I think that C will continue, at least with veteran teams, just because things like dealing with packet data and interfacing new systems are easier to handle with a text-based language. All experimentation, and complex robot code will probably be done in C. Debugging, though, is where Labview will begin to dominate, since building GUIs is so much easier, and teams can make really nice dashboards.

3. Rookie teams will probably use Labview, just because it doesn't look as intimidating as a C environment with all the functions and brackets, and everything. Things like functions, arguments, parameters, and variable types are all nicely obscured.

4. Was a new version of LabVIEW created specifically for this competition?
A: NI is creating a custom build of LabVIEW made specifically to meet the needs of the FRC
competition. The graphical programming environment, though, is the same one used by hundreds
of thousands of students and engineers worldwide.

That's from the FAQs on the WPI FRC Resources site.

5. YES, NXT would be a great way to prep for LabView (it familiarizes you with wires and stuff like that.) Data flow programming is a slightly different paradigm, and NXT would be good practice.

6. GUIs are very easy with Labview. I've tried Python, C, Java, and VB, and for GUIs related to I/O processing, nothing is easier than LabView. On the other hand, we did have problems with VIs crashing, i.e., CMU2Cam, but hopefully this has been fixed. It just works, and there is amazing documentation if you need it. On the other hand, it will be harder to do a lot of the low-level stuff hard-core embedded systems programmers love to do. Interfacing a custom router, or a PS3 would be a lot harder to code. The capabilities of the C libraries will be easier to modify, and existing C code can be easily ported over, so a lot more code exists. And innovative systems, like the Autoflex 2.0 might take more effort to code.

Personally, I'm planning on having the new programmers on our team write the debuggers and dashboards with LabView, so they learn programming concepts at least, and don't get overwhelmed by the power and complexity of C. But slowly, we will move them from debuggers and dashboards to real robot code, which we will continue to write in C.

Re: C or LabVIEW: CompactRIO
 

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..

Re: C or LabVIEW: CompactRIO
 

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.

Re: C or LabVIEW: CompactRIO
 

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?

Re: C or LabVIEW: CompactRIO
 

Same here.

I see LabView dominating most certainly the rookie teams, as well as the more advanced veteran teams. I think a lot of veteran teams will be at a disadvantage this year, when they just touch LabView for the time in January, while others have been practicing on their NXTs for months. I have a feeling that next year's game will heavily weight a team's ability to use some higher-end sensors, and I think that LabView is really going to help out in this regard.

My 2 cents.
Jacob

Re: C or LabVIEW: CompactRIO
 

The Lego NXT is probably a good option for learning LabVIEW right now. However, I believe that NI is going to try and get the new controllers to the teams prior to kickoff so that they can start learning a little bit early. The last thing they want is for build season to start and have everyone struggle to learn LabVIEW in 6 weeks. Nothing is definite yet, but they said something might be ready at the end of summer/early fall time period.

Re: C or LabVIEW: CompactRIO
 

I agree. Anything that will allow a team to become more familiar with LabVIEW will give them a head start, and the NXT is a great platform for doing so.

That's the plan, inasmuch as I am aware. However, plans are contingent of a lot of things going right and are subject to change - everybody will be apprised of the situation as it draws closer, I promise.

-Danny

Re: C or LabVIEW: CompactRIO
 

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...).

Re: C or LabVIEW: CompactRIO
 

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 :P). 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! :P)

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!

Re: C or LabVIEW: CompactRIO
 

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.

Re: C or LabVIEW: CompactRIO
 

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):


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++.

Re: C or LabVIEW: CompactRIO
 

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.

Re: C or LabVIEW: CompactRIO
 

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

Re: C or LabVIEW: CompactRIO
 

I absolutely agree with this statement. Most all safety critical applications already use this approach as code generation can be controlled and qualified.

In these cases the efficiency (execution time) isn't quite as good as something hand crafted and optimized, but with processing power on the cheap and labor costs rising, efficiency in development time seems much more appetizing to me.

Re: C or LabVIEW: CompactRIO
 

This is correct from my perspective, and also the very reason why I think it's most valuable that we're teaching C and low-level stuff to the kids interested in software on our team. When you make the bulk of the code easier to write (as graphical tools are starting to do), it becomes a commodity. For these jobs, you no longer need a software engineer to implement them - anyone with a logical mind has a decent chance at being able to do it. Of course, that means that the 10% of programmers out there who know how to get down and dirty with C and/or assembly coding and debugging become more valuable, and the value of the rest decreases. I think it's important that the kids on our team who show real interest in software be steered towards this 10%.

Learning how to "code" in high level/graphical languages is great, and is a valuable skill for now, but in short time it probably won't be much more important than saying that you know how to write a paper in Microsoft Word. The valuable people will be the ones who know how to find the problem when the high-level language blows up because of a hardware problem, or a device driver or HLL interpreter bug, or whatever. And don't be fooled into thinking that these aren't still an issue. I recently had to spend a good deal of time tracking down a bug in Java that ended up being an issue with the way the JVM handled a hardware timer on the processor, and nothing we could have done from the Java side would have found the problem or been able to fix it.

Re: C or LabVIEW: CompactRIO
 

This is my second year in FIRST and i have been working on the electrical system the past two years. I have finally grasped all the physical stuff that deal with electronics know i am trying to understand the software side. When i talked to the mentors on the team they gave me a copy of labview and i have just stared using it. I am finding that is essay to pick up and understand and i like looking at the pictures in labview instead of lines of code that you will see in C.

Matthew Simpson
Team 75 driver

Re: C or LabVIEW: CompactRIO
 

I may be biased because it irritates me to have to learn what picture mean in GUI's, but I believe that the argument here goes back to the very core of why we have language. You can only explain so much in flash cards with images, even adaptable ones. We need words for more precision. However, time pressures will most likely lead to the majority using graphics.

Re: C or LabVIEW: CompactRIO
 

Agreed (not that it matters). In my view this is the difference between an applications programmer/coder and a systems programmer/engineer.

Although I believe there will be parity between LabView and C programming environments for the FIRST added value in the new platform - specifically in terms of the standard sensor suite included in the KOP. I cannot see how real parity will exist in the 2-3 year short term between the two environments. My reasoning is based upon what the customer base for cRIO has been using - only LabView. So the body of art in terms of VI blocks, knowledge, etc. exist only in LabView within the current customer community. That plus the fact that LabView can be used to model a system and provide the simulation of most of the sensor inputs for testing/simulation makes that environment have benefits that the C environment cannot match from a whole program standpoint in the near term.

I don't even like LabView but my opinion is it would be irresponsible for me to not push LabView as the main programming environment for the robot going forward given the functionality and current art associated with the new platform. I could easily envision that 10-20% of the code would still be in done in C just because it fits better, but that the majority of the software team would be using LabView. So this would reflect the typical 80-90% applications programmers and 10-20% of systems programming mentioned by Dave above.

For me, LabView promotes being a user of black box technology pieces rather than promoting understanding how to be a creator of useful technology. There is nothing wrong with being a technology user, but where's the fun in that?

Re: C or LabVIEW: CompactRIO
 

As a computer science teacher, I am actually strongly leaning toward "encouraging" our programmers to use Lab View, because it is better at forcing them to design good code. It is fairly easy to take a bright kid with any inclination to write workable code. It is quite another thing to design good code. Lab View's module oriented design, with testing of the modules, promotes good design and good practice. And Lab View is not a fluffy tool. It has been around for a long time and can be used for very intricate, high level programming.

I liken this to a debate that occasionally rages among HS and college computer science teachers: Should students start learning to program by learning assembly? My opinion is absolutely not! It teaches most students bad habits. The counter argument is "Would teach someone to drive a race car without teaching them how the engine actually works?" There are two counters to this argument. The first is simple. Sure you want your race car driver to understand how the engine works. But that is not the first thing you teach them. The second is that assembly is not really "how the engine (your computer) works." It is a less abstract interface than C, but still an abstraction.

I will say that I don't know if my opinion would change if my students did not already know some programming languages. On the whole, I don't think that it matters what language you learn first, as long as you learn good practices and skills. In a general sense (not computer science specific) this is actually an area of pedagogical research that is pretty well studied.

Re: C or LabVIEW: CompactRIO
 

I see learning lower level languages (such as assembly) as the CompE equivalent of taking a Design for Manufacture course.

DFM teaches MechEs how to design things so it is easier for the manufacturing engineers. Learning assembly teaches CompEs how to write things so it is more efficient once it is compiled.

DFM is a necessity for any ME who intends to mass produce her work. Learning a low level programming language is a necessity for any CE who intends to mas produce his work.

For research and one offs, it is completely superfluous to cost optimize. Cost optimization is a very important skill for a large fraction of engineers, but it is not necessary for 100 percent of engineers, and it is not necessary to start with it.

Re: C or LabVIEW: CompactRIO
 

As helpful as LabVIEW is, it isn't magic. Whether building a VI or writing C functions, the same programming concepts apply along with the same problem solving skills and methods. LabVIEW isn't alone in abstracting away some of the bits&bytes details to allow developers to focus their time on solving real-world problems instead of worrying about issues like memory management.

Understanding the low-level details is undeniably important for software engineers, but there is no reason to fear using high level languages like LabVIEW or Java. C++ has the standard template library to save time by reusing common data structures and algorithms. Code reuse, whether provided by a calling a LabVIEW VI or #including something into your C/C++ code, should help developers be creators of useful technology, not hinder them.

Re: C or LabVIEW: CompactRIO
 

I almost totally agree. But I think that a computer architecture course and an algorithms course are soooo much better than learning assembly.

Algorithms, to choose the simplest code with the simplest access patterns.

Architecture, because even at the assembly level, execution performance is hard to predict without considering cache lines, cache sizes, interrupt latencies, etc. Ideally, the architecture course uses an assembly language to illustrate some of the concepts.

And of course both of these will get you only so far, so familiarity with profiling techniques, profiling tools, and lots of experimentation are necessary too. The architectures just keep getting more comlex.

Greg McKaskle

Re: C or LabVIEW: CompactRIO
 

Agreed. I used ASM as an example for this audience. CompArch&Algs is much more relevant.

Note: I am not a programmer by trade, I am a SparkE. However, I really like hardware, so I've spent a little time there.

I learned a little x86 assembly, and a little PIC assembly. Relatively low return on investment, though it helped me understand C much better.

In CompArch/VLSI, we designed our own processor. Started with architecture, decided on components and interconnects, went to gates, laid out on silicon, and we even wrote our own assembly languages. I think one team even made an assembler in python. I probably won't design too many more processors, but it sure did help me better understand what is going on under the hood.

I got a lot out my Foundations of CS class. We learned a new programming language every other week, spanning most schools of thought. Scheme (LISP) taught me a surprising amount about algorithms, and prolog just proved that specific languages solve specific tasks orders and orders of magnitude better than any others can.

So... I hit a few lower levels, scraped my knees a bit and moved to the higher level languages. Now I write any code I need in English (in the form of a spec document) or python (which is essentially a dialect of English).

Re: C or LabVIEW: CompactRIO
 

Please correct me if I am wrong, but C++ can be just as "high level" as Java or LabVIEW. Assuming WPIlib has similar included functions and objects to LabVIEW's panels, and Java's libraries, isn't it relatively equal?

The way I have always seen it, you can make a language as high level as you want (as long as it supports things like functions and objects), but if you are working in an exclusively high level language (such as LabVIEW) it is hard to get down into the nitty gritty low level to debug and perform hacks.

To me, the difference between LabVIEW and C++ is like the difference between writing a paper and drawing a wordless comic strip. They both convey the same thing, but the paper can be written faster and allows for more subtle tweaking.

Again, if I am off track, correct me...

Re: C or LabVIEW: CompactRIO
 

LabVIEW has a number of tools to help with debugging, you can set breakpoints, probe wires to watch values at runtime, highlight the execution paths, etc so debugging should not be a concern.

As to which is faster, this probably depends on the problem being solved and the user, but the general notion would be the opposite of what you have suggested. Higher level languages tend to increase programmer productivity.

One of the best things you can do is to learn both.

Re: C or LabVIEW: CompactRIO
 

A pretty good report (IMHO) about the state of C and it's relation to C++ and LabView can be found here.

Re: C or LabVIEW: CompactRIO
 

In these sorts of conversations, it is useful to break these programming environments into elements such as (langauage, libraries, and tools).

The panels and UI objects, along with vision, signal processing, and file I/O, are library elements, and can be added to most any language. The level of library integration you can achieve with a given language will differ, and the tools are often key to getting the libraries well integrated -- think intellisense or whatever it is called.

The tools are things like the debugger, tracer, text or graphics editor, and source code control. These features, again, aren't unique to a langauge, but their level of integration can make a huge difference. When C is bundled into a package with a slow compiler, weak debugger, and primitive text editor, it feels like a bad visit to the dentist. Choose a package with better tools, and it is like going to the candy store. Same language, different tools.

Language differences come down to issues like expressiveness, control over (scoping and encapsulation, time of binding), etc. I don't have my favorite language book handy, so I can't be that complete. Anyway, independent of tools and packaging with libraries, some languages add additional syntax to give power for things like binding time. Other languages focus in simpler syntax and more expressive power through polymorphism or sophisticated dispatching mechanisms.

In the end, all three elements affect programmer effectiveness and happiness. Breaking them apart into topics like this allows us to be more precise about the tradeoffs, because words like high-level can be very misleading and imprecise.

High level languages tend to have no pointers or low level access built into the language. Just as low level languages can be made higher level with libraries, high level languages can gain low level features with libraries, and this is how LV does peeking and poking to memory.

Taking out pointer magic, of course seems like a major limitation at first, but the tradeoff is that you wind up with a more structured access, that gives you more certainty about what code is really doing versus the side effects that happened. If code is peeking and poking all over the place, where do you look when a piece of memory is getting corrupted? If the access is limited to a single function or object, the bug gets solved more quickly, and hopefully doesn't happen in the first place.

So, if you limit what you use in C++, it can become a high level language. Arguably, that is what Java and C# are, (((C++)--)--). They are variations of C++ with less of the low-level stuff available. But if the low-level isn't off-limits, I think the language is both high and low level -- not a bad thing in the hands of a trained user, but with the low-level stuff still there, it can still cause bad things as well as good.

While humorous to think about, I don't think your description is very accurate. LV was designed by some physics guys, not cartoonists. They wanted to break away from some of the limits of current languages. They noticed that when you asked a scientist, engineer, or student how something worked, or how they wanted it to work, they would walk to the chalk board (this was the 80s, so possibly a white board), and they would usually draw their system as pictures, not C code. One common picture involved shapes that represented processing and lines that represented the information or product flowing between the processing stations.

They thought this lent itself to being represented in a data flow language, and wanted to include the graphics too. When Fortran and other early languages were invented, they chose a stream of ANSI chars because that was all that computers could process -- stacks of cards with holes punched into them. The ways of representing the holes improved, and fancy computers could even support graphics and sound, but programming languages still consisted of ANSI chars that the compiler consumed one at a time.

The end result of this exploration was to define a structured data driven data flow language that used graphics to represent the functions, and lines or wires to represent the flow. They added in libraries for common engineering tasks and UI displays, and because they couldn't integrate graphics into VI or emacs, they wrote their own tools for editing, etc.

LV is by no means the only graphical language out there, and not all graphical languages are the same, just as not all textual languages are the same. While an obvious difference, the more important difference when actually writing code, is the data flow functional approach of LV versus the procedural approach of C.

While this analysis and analogy can be interesting, in the end, the important thing is that the language, libraries, and tools support the user to quickly accomplish what it is they are trying to do. Hopefully they also allow for others to understand, contribute, and extend it to their purposes as well. Both the C and LV languages have been around for decades. They work in different ways, and this gives the user a choice. I truly hope that most students become familiar with both of these languages, and others as well.

When I'm asked the question, "What is the most important computer language to learn to prepare me for a programming career?"; my answer is, "Your second one." You will learn way more from the differences and similarities than you gained from the initial language. It will also be far easier, as will the third, etc. It also tends to get lessen the zealotry a bit.

Greg McKaskle

Re: C or LabVIEW: CompactRIO
 

This is a great answer to the question.