Re: Programming with the 2009 controller
 

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

Re: Programming with the 2009 controller
 

Yeah, that was a pretty long post... :cool:

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

Re: Programming with the 2009 controller
 

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

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.

Re: Programming with the 2009 controller
 

Sadly the cRio will be Windows only based on what an NI employee said at one of the sessions. Windriver (I think) is only a windows app and their license won't let them port to OS X. However this is only true for sending to the robot. So using a different OS for debugging and stuff is an option.

<conjecture>Also, my hunch is that the Windows thing only applies if you use their libraries. It is possible to program the robot using currently existing tools so we might be able to, with some extra work, do most everything on a Mac. I would appreciate if someone more familar with NI could comment on this thought. </conjecture>

Also for anyone who missed the championships and wants to see some info about the new controller the link to the NI community is http://decibel.ni.com/content/community/first.

Also, who thinks it would be a good idea if NI released pre-release libraries so that teams could get their feet wet over the summer? This is a massive change for everyone involved. The controller is bigger and heavier (2.5 lbs w/o modules) And the wiring to and from it will be different. Perhaps FRC should allow us to get our hands on stuff ahead of time to help us overcome some of these obstacles.

Re: Programming with the 2009 controller
 

Agreed. A look at the code would be rather nice. I don't want to have to figure out an entire new system and program a robot at the same time. We all have plenty to do during build season as it is :D

Re: Programming with the 2009 controller
 

I was explicitly told Windows and Linux and that the compiler is based on the GCC toolkit by more then one representative (one from NI and the other from WPI).

Re: Programming with the 2009 controller
 

If you are right you will have made my day... (Im a Mac user) Anyone have any official releases from companies answering this?

Re: Programming with the 2009 controller
 

Sorry about that. That's what I meant. Thanks for correcting me.

Re: Programming with the 2009 controller
 

You don't need an OO language to program in OO. We did OO in C this year (well, mostly). It's just way easier with an OO language :P.

Well I guess you can't exactly practice polymorphism in C. But the whole encapsulation thing, easy.

Re: Programming with the 2009 controller
 

The evaluation download page for the WindRiver compiler (http://www.windriver.com/portal/serv..._OpenerMode=2&) lists the following system requirements:

Now that means you'll be downloading an RPM but it will be trivial for a semi-experienced Linux user to install it on any number of distros.

Re: Programming with the 2009 controller
 

um.. isn't C an object oriented language already.

Re: Programming with the 2009 controller
 

No, C is a procedural language.

Re: Programming with the 2009 controller
 

You're right, I was getting them mixed up, but if this isn't getting too off topic, what kind of
languages are there and what is the difference? Anytime I run into a different style I just adjust and then go with it.

Re: Programming with the 2009 controller
 

LABView, while I have no experience with it, is a graphical interface you use to code.

C++ is a subset of C, meaning that it follows the same syntax. C++ is basically C with added features such as classes (allowing for object-oriented programming) and templates. If you're already comfortable with C the jump to C++ should be fairly easy. Online tutorials such as learncpp.com have helped me a good deal.

While you can "fake" OOP with C, actually having classes to work with brings a whole new world o' fun into programming.

Re: Programming with the 2009 controller
 

If it will run it Linux, it shouldn't be that hard to get it to run on a Mac given the unix core. In addition, os x already runs many linux services such as apache and gcc. I am going to try and get the compiler to run ASAP.