Programming with the 2009 controller

[slavik262]

Hooray for anti-M$ sentiment...

My main goal is to get away from MPLab and it's fun casting issues. I'm hoping for Visual C++ because I've used it extensively for school projects and had great success with it.

Regardless of IDE, I can't wait to program the robot in C++. Object-oriented programming combined with 1,000 times the memory of this year's RC and a much faster processor will let teams do things we've been dreaming of for years.

[lingomaniac88]

I'm thinking of trying LabView for 2009. Looking at some videos on the NI website, it looks pretty cool. Anyone know how easy/hard is it to learn and use LabView?

[Alan Anderson]

Originally Posted by lingomaniac88

Anyone know how easy/hard is it to learn and use LabView?

The learning process for LabView takes wildly different paths for different people. I've watched complete novices pick it up in basically no time.

On the other hand, it was very difficult for me. I think that's probably because I was learning it from someone who knew it inside and out and thus could do everything quickly, but who was very poor at transferring that knowledge to someone who couldn't follow it that quickly. Most of my time was spent doing two things: unlearning a lot of what I learned about procedural programming, and getting used to the multilayered view of programs that LabView provides.

I still am not at all comfortable with it, and I still cannot "read" a LabView program written by an expert.

[Nikhil Bajaj]

Originally Posted by Alan Anderson

The learning process for LabView takes wildly different paths for different people. I've watched complete novices pick it up in basically no time.

On the other hand, it was very difficult for me. I think that's probably because I was learning it from someone who knew it inside and out and thus could do everything quickly, but who was very poor at transferring that knowledge to someone who couldn't follow it that quickly. Most of my time was spent doing two things: unlearning a lot of what I learned about procedural programming, and getting used to the multilayered view of programs that LabView provides.

I still am not at all comfortable with it, and I still cannot "read" a LabView program written by an expert.

I definitely agree with you on this, Alan. I've used both LabView and Simulink in various project to program embedded targets, and it has nearly always been easier for me to understand and conceptualize what is going on when I write my own C code. That said, I do have a lot of friends and know many people who swear by Simulink and LabView for doing their programming for various types of things. They are extremely versatile products. I would imagine though that they might be easier to pick up for someone without any programming background than C or C++, although I personally feel that there are a lot of insights into controls and programming that you can't gain by using such high level, abstracted ways of programming.

[neutrino15]

I think it's great that FIRST has expanded our variety of IDEs.. I read on the 2009 PDF that Windriver is basically Eclipse.. Can somebody please explain? Is Windriver some comerical spinoff of a perfectly good Open Source project? Or is it just a set of plugins for the standard Eclipse IDE?

Q) What IDE(s) will be available for use with the new controller/programming language?
A) Both WindRiver Workbench (Eclipse) for C/C++ and LabVIEW.

Either way, Eclipse is a great program (widely used in the industry).. Labview also shows promise as a learning tool, though I am a big fan of starting newbies off with writing real C code..

On another note, does anyone have any idea as to what libraries will be onboard the cRIO? Also, what libraries will FIRST or WPI be supplying? I assume they will write some of the very low level (pwm generation/timer interface) for us.. If you know, do tell!

The most exciting thing for me.. Floating points and Objects!!! Woohoo!!

[prograid]

Originally Posted by neutrino15

I think it's great that FIRST has expanded our variety of IDEs.. I read on the 2009 PDF that Windriver is basically Eclipse.. Can somebody please explain? Is Windriver some comerical spinoff of a perfectly good Open Source project? Or is it just a set of plugins for the standard Eclipse IDE?

Eclipse as a whole is a set of plugins for a very small core platform. The open source components include that core platform and various development tools that can turn Eclipse into and IDE. One of these open source development tools is the CDT (C/C++ Development Tooling). However, the open source product only integrates with variants of GCC (and I think possibly Visual C++ in the latest version). So WindRiver basically added support for their compilers, debuggers, etc. to the CDT (which does require a good deal of effort) and repackaged it and sells it to you as WindRiver Workbench. Their website for it is here.

[neutrino15]

Thanks for clearing that up.. I watched a bit of their video demo and found "We support many host OSs, including Windows, linux, and Solaris!" a bit disappointing (no love for the mac!)

Could Eclipse be used on the mac? (for purposes beyond text editing/versioning, for the cRIO?)

[neutrino15]

Thanks for clearing that up.. I watched a bit of their video demo and found "We support many host OSs, including Windows, linux, and solaris!" a bit disappointing (no love for the mac! [which, btw, has some 8-12% of the market now])

Could Eclipse be used on the mac? (for purposes beyond text editing/versioning, for the cRIO?)


Also,

the open source product only integrates with variants of GCC (and I think possibly Visual C++ in the latest version).

I am quite certain the cRIO supports GCC. Not so sure about the visual c++

[DtD]

Eclipse would work on a Mac, since it is Java based. (Plus, Wikipedia says it is cross-platform)

~DtD
Blue Valley Robotics

[Chris_Elston]

Does any one in this thread know if the 2009 controller can be programmed with the traditional industrial languages?

such as:

Ladder Logic
State Logic
Flow Chart Diagram
Structured Text (yup...C++ is Structured Text)

Are these optional? Or is labview only function block programming only?

National Instruments for YEARS has been bugging me to try a controller to replace the PLC (programmable logic controllers) I use in machine designs, and have said we can program in ladder logic, STL, flow chart, ST, when we switch over to this controller. That's where I am coming from with this question.

Or is C++ and function block (labview) the only options? And those other few mentioned in this thread....

[jtdowney]

The only supported ways they mentioned were WindRiver C/C++ (Using WPILib), Intelitek easyC, and National Instruments LabView. However the WPILib for this RC will be open source so the options are not set in stone. Also I was told we will not have access to program the FPGA next year but it is something they are evaluating for future years.

[Qbranch]

Originally Posted by Chris_Elston

Ladder Logic

Eeek!

Sorry, I have an allergic reaction to Ladder Logic.

Anyhow, I think the reason your NI rep said you could program in all those methods was that if you arrange your icons right on the screen in Lab View, it runs just like ladder logic. Similarly, with a clever use of the filmstrip control you could make it act like a flow chart too. I know they have C boxes that work in there somehow too.

If I were the programmer for our team next year, I'd go the C route if they give you cVI libraries. The labview system has a lot of oddities to it, like (this is a dusty memory) you can do everything to an array except one critical function like writing or reading a specific element or something of the sort, can't remember quite. Also, LabView pictures are REALLY hard to document and get jumbled really fast. The pictures aren't too portable really either.

And finally... this won't seem like a big issue till you're using it... LabView has no zoom. The little one or two pixel wide terminals you have to hook wires to don't get any bigger.

It'll be interesting, any which way it goes...

-q

[Chris_Elston]

Originally Posted by Qbranch

Eeek!
Sorry, I have an allergic reaction to Ladder Logic
-q

I've been programming and designing PLC based controls for years...10+ years… Of course, I am partial to ladder logic. My job title: Sr. Controls Engineer. I have my own website dedicated to PLC based controls: www.mrplc.com written a few papers on it. I have several example codes to download.

When I say "robotics" to a FIRST student, they are thinking MARS rover or first robotics, or even animatronics type robotics. Like Disney based characters, etc.

When I say "robotics" to my co-workers or anyone I contact in my everyday life, they are thinking, ABB, Fanuc, Motoman, industrial six axis robots. Robots that to do repetitive tasks.

I've declared a difference to my students and I figured out it's best to explain it like this:

If you're going to be an electronic engineer, a person that designs circuit boards, you'll more likely be apt and need to learn C++ so you can program micro processors. You'll be working for someone like United Technologies, they make thermostat controllers, or BAE, Raytheon, any automotive ECU's and such or any type of electronics that require a micro processor. Could even be a toy company too, like Tyco Electronics. Tickle Me Elmo stuff.

If you're interested in automation, or stuff you see on the TV program "How It's Made" like machine automation, you'll need to learn ladder logic. If you want to play with six axis industrial robots, learn ladder logic. Though most six axis robots are not programmed in ladder logic, you'll need a PLC to interface with. The PLC is the master controller of most all automation processes. Why? It's robust, been around for years, easy to program. One of the BEST FEATURES of the PLC is the ability to programming and make code changes on the fly. Or in the PLC world it's called "online changes". I can go online with a PLC while the production line is running, and make code changes on the fly and not disrupt the production line, hence no downtime. Places like GM, Ford, assembly plants charge their suppliers $10,000 a minute for each downtime caused. There is no compile process in PLCs. PLCs are designed around robust wiring hardware as well. Most use standard hookup wire, 16 AWG or smaller. PLC don’t crash or blue screen. Most roller coasters are controlled by two PLC’s. Each PLC ladder logic must match before it tells an output to turn on in a roller coaster ride. The Raptor roller coaster in Cedar Point is controlled by 4 PLCs. Two PLCs control the trains on the track and make sure that no train enters each other’s “zone”. The other two PLCs monitor safety. Each seat belt has a digital input and each PLC must agree logically before any output is processed. The PLCs that control the Raptor are Allen Bradley PLC5 type PLCs. PLC5 type PLCs are octal based processors however have been a standard in automotive production for decades. I think all of FORD plants still use PLC5 type PLCs, most are now switching over to Control Logix based PLC platforms. Learning to programming a PLC is like programming in assembly. (only thing I can think of to compare it to). Your working in “bits” and “bytes” and need to move “words” of data around logically. It’s as basic as you get. Most PLCs have built in functions like a “timer” which make it easy to program.

In my experience so far with working with National Instruments, they excel in data acquisition. Traditionally in the past, it's been quite cumbersome to do data acquisition in a PLC. In the OLD days, the PLC had one RS-232 port, channel 0 they call it…. and quite often even to get a bar code reader into a PLC to sort a package on a conveyor line was a chore. Or even a standard weigh scale running the weight through the RS-232 port of a PLC was not fun. No fun, but I've become an expert ASCII parser learning to do it this way. Quite often the thought process of reading a weigh scale “string” through an RS-232 port, then parsing the data you want say the weight of the box, then converting the parsed data into a integer based number so you can make a logical decision on this was quite tricky.

Then not long ago, National Instruments really started to catch on in the automation industrial world, and wow...the data acquisition and test data you can get is amazing. So my gut feeling of most places that deal with automation or manufacturing still use PLCs to control the automation, and have a National Instrument controller for data collection. Before National Instruments I used a product called WinWedge and other products similar. Where National Instruments has my attention is their ability to create VI's for just about everything, like standard off the shelf vision systems. National Instruments can talk on a multitude of protocols. Ethernet, Controlnet, Devicenet, Profibus, RS-232. Back in the old days products like WinWedge took the cumbersome ASCII parsing out of play, but was only good to interface with RS-232 devices such as scales, bar code readers, etc. This is where I see National Instruments really start to shine. Recently though, they are starting to try and take and replace PLC’s with their controllers….in my opinion right now, I dunno.. I am not sold. I need more convincing along with a lot of other Control Engineers I know. I have never heard of National Instruments using C++ until now from FIRST. From a control point of view, I think that would be better to write and control a process in C++ than function blocks of Labview. If I was using a National Instruments controller to replace a PLC.

I've talked to several industrial based control engineers and right now, we are still mostly sticking with PLCs for our main process controls. Every factory out there will "generally" have a PLCs at the heart, then other types of controls like a National Instruments test stand that will collect data and store it away into a database. Something that would take a long time to do in ladder logic, A.K.A. a PLC, a National Instruments ability to data collection and analyze test data takes the cake. Those engineering peers of mine that have tried to use National Instruments for control have suffered and found it really hard to make use of process control in labview function block. Simple multi-task state logic, or digital input debounce logic, that a PLC can do with a couple rungs of ladder.

Basically what I am getting at is ladder logic is not for everyone, but in certain industries, you've got to learn it. It depends on what students choose to purse.

Students of mine in the past needed some guidance and I get asked all the time which is the best programming to learn. I sit them down and explain to them what I have explained here. It depends on what you think you might be interested in doing. I don't discourage either, even though I am partial to PLC.

However from the programming perspective, I still believe to this day, not everyone can program. You either have that "nak" to program or you don't. If you can think logically, learn the basics of logic flow, A.K.A IF THEN ELSE, you should be able to sit down in ANY ENVIRONMENT and program. I sit here and tell you I started mentoring for FIRST robotics in 2004, the first year the C++ controller was introduced. I had NO CLUE how to program in C++. But I had the fundamentals of programming and understood logic based thinking. Of course I was an expert in PLC ladder logic programming, but that didn't make me an expert in C++ nor did it scare me away from trying to learn this microprocessor stuff so I could continue on learned it myself so I could teach my students the best I could even though I didn't have one course in C++ programming.

In the automation world, it seems to me just about everything I touch has it's own "mnemonic" based language anyway. For example Fanuc robotics use a language called "teach pendant programming" TPP. Its mnemonic based, or you can program the Fanuc robot in KAREL as well.

My final advice to my students is to have them try and decide what kind of an engineer they think they'll want to be, then I can direct them on the best way to use your time as a FIRST student in high school. Each industry has their standards for what they use for hardware and programming languages. It's up to the students to decide which one fits them the best. I can see that alot of my past programming students will find electronics more their cup of tea because of being exposed to C++ and microprocessor based controls. PLCs and ladder logic have a purpose, C++ and MPLAB have a purpose. Each one could probably do each other’s job, but I can’t see using a PLC to control the fuel map on your injection system in your car, nor can I see PIC processor controlling a 1000+ I/O production line where it has to interface with vision systems, robotics, handle data collection request, and do all that while able to make online programming changes too.


Sorry for the long post.

Chris Elston
Sr. Control Engineer
www.mrplc.com

[Danny Diaz]

Yeah, that was a pretty long post...

Anyway, LabVIEW has a State-Chart, Ladder Logic, and other types of plug-in modules you can use to alter how you program LabVIEW. I don't believe we're going to be providing those modules to teams in 2009, however.

And to answer a previous question on this thread, WindRiver uses a home-modified variant of GCC to compile programs for use with their OS, VxWorks (which runs on the cRIO-9074 and FRC variant), and they also have a port that uses diab (though the cRIO-9074 and FRC variant cannot use). NI has modified the VxWorks OS a bit to work with the cRIO controller, but we've done nothing to the compiler - WindRiver is going out of our way to make sure we have the latest and greatest tools for FRC teams to use to program C/C++ within the eclipse-based IDE they have.

Of course, I'm going to be a little bit biased on the side of programming the FRC system with LabVIEW, though I will most certainly take advantage of the C Interface Node and the Call Library Node within LabVIEW to compliment our code, which allows for LabVIEW/C/C++ hybrids. Last time I heard this was still going to be supported, but it is all still preliminary.

-Danny

[slavik262]

Chris, I'd first like to thank you very much for that post. Despite its length, it really provided a great deal of insight. However,

Originally Posted by Chris_Elston

I sit here and tell you I started mentoring for FIRST robotics in 2004, the first year the C++ controller was introduced.

The current controller does not support C++ programming, but C. This year is the first year teams will be able to program in C++. This makes me very excited for several reasons:

1. I have grown to strongly dislike the current compiler. It misses time-costly errors such as interger promotion and overflow issues without producing so much as a warning, providing you the fun of manually searching your code (Oh! We had to cast the char to a short on line x!). A new compiler will make my day, or rather, my season.

2. C++ will finally allow us to use object-oriented programming, making code cleaner and more efficient to write and debug.

3. The new processor combined with RAM 1000 times greater than this year's processor will finally open doors to us using dynamic memory allocation. Combined with C++, this will let teams do some pretty awesome stuff.