Programming with the 2009 controller

[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

[Guy Davidson]

Originally Posted by Danny Diaz

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

Danny,

How would you combine LabVIEW and C? What functions, for example, would you use C rather than LabVIEW for? Could you give a few examples or links to see how this all comes together?

Thanks.

[Danny Diaz]

Originally Posted by Guy Davidson

How would you combine LabVIEW and C?

Through the Code Interface Nodes and the Call Library Nodes, but after thinking about it a little more I think I would not use the Code Interface Nodes since the Call Library Nodes are the easiest to work with.

You can build .out files for VxWorks (the equivalent of .dll files for Windows/ETS) and call into them using the Call Library Node - this allows you to have a C-compiled library that you can use. It's incredibly easy to build libraries with WorkBench, the VxWorks IDE you should be getting, we even have a step-by-step instruction set to help you build your own libraries under VxWorks.

Originally Posted by Guy Davidson

What functions, for example, would you use C rather than LabVIEW for?

There are multiple reasons why it would be beneficial to have a hybrid system.

First, I'm what I call a "realist" - I don't think you should be forced to take algorithms you've already written in C and convert them to LabVIEW just for the sake of having them in LabVIEW. I know there are a lot of great algorithms for performing lots of different kinds of advanced calculations floating around, and a good number of them are in C. Sometimes you want to break them apart and study them in-depth in order to become a master of the algorithm, and sometimes you realize you have 2 weeks before ship and you just want to plug-and-chug. Being able to build/access C-based libraries are beneficial in this case.

Second, having a c-based library gives you the power to change out modules on a filesystem level, or access modules on a given filesystem. This makes a lot more sense on NI controllers with USB Mass Storage support, you could have different program code on different USB flash drives, and change them out at will. You can do the same thing with the FTP server on the controller, it would allow you to update specific portions of your code without recompiling everything (and it can also be done through an automated script).

Code sharing. If you have the .out files, you can share code with teams using the LabVIEW interface as well as the C/C++ interface. This would be especially useful for autonomous algorithms and sharing them with rookie teams without autonomous.

Lastly, using C instead of LabVIEW can be a valuable crutch. Depending on when the controller gets in your hands and how much time you have to learn how to use it, having an out can make you more comfortable with the whole 6 week deadline thing. I would hope that teams would pick up the LabVIEW software we provided in the KOP, maybe even pick up an NXT robot and the LabVIEW NXT Toolkit, and learn how to use LabVIEW in the off season. However, that's not going to be possible for all teams. Giving a way to experiment with LabVIEW but being able to use some C code if necessary can help facilitate teams moving to using LabVIEW without being cornered into an all LabVIEW or all C/C++ situation.

Originally Posted by Guy Davidson

Could you give a few examples or links to see how this all comes together?

LabVIEW itself is chock full of examples. Just use the example finder found in the lower right-hand corner of the LabVIEW 8.5 opening splash screen. Look up "Call Library Node" and you'll find tons of examples of how to use this feature.

I hope I answered your question adequately.
-Danny

[jwr134]

Can someone give a list of the programs that teams will be able to program with in 2009 and following years?

[yoyodyne]

Originally Posted by Danny Diaz

I would hope that teams would pick up the LabVIEW software we provided in the KOP, maybe even pick up an NXT robot and the LabVIEW NXT Toolkit, and learn how to use LabVIEW in the off season.

Danny, I am doing just that and the examples work great with the NXT but I don't know why or how. For instance in the getting started guide there is the NXT microphone example. I am trying to figure out where the sample rate is set. There is a lot more detail shown in the VI hierachy dispaly but I haven't been able to drill down to the basic configuration info. Is it worth trying to figure out how the VI's work at a lower layer (at least for the NXT) VIs or are the configurations kind of hard coded and not accessable? Now that I think of it I don't even know how the system figured out what sensor input I pluged the microphone into. I need to spend more time reading the generic help info but searches on "sample rate" did not turn up anything that looked fruitful.

[esquared]

There are a few key ideas that I believe have been missed so far in this thread, but picked up on in other similarly-themed threads.

1.) Labview VS. C/C++ - A hybrid approach is completely reasonable and could be equally efficient as a pure LV or C project. LV has the capability to call C-esque libraries on this real-time target, so your team’s C programmers can still code their PID controls for an end effector, but have the top level LV code simply provide the position target to that block. It remains to be seen whether there is any significant overhead in a LV->C library call when in a real-time situation. It was made clear in the mentor’s meeting in Atlanta that the reverse would NOT be possible, wherein a C project could call Labview libraries/functions.
2.) This is not your momma’s Labview – LV for the cRIO becomes code that can run in real time. It is more like VHDL where you describe how you would like signals to be manipulated, where you would like them to go, and let the compiler/synthesizer take care of the details. A similar approach is used by Matlab’s Simulink program, where there are tools for going directly from a discrete-time simulation of an algorithm to object code for a DSP or microprocessor. Is Matlab/LV higher level programming? Yes. Do you want to write an application to provide a testbench for your code, graph/filter/FFT your results, etc. for your C program? Probably not. LV will DEFINITELY help in testing stability/response time of your various control loops, something that was difficult before or only achievable by physically trying it on your robot.
3.) There is a strong commitment by FIRST/NI/WPI to keep library development equal between the C and LV branches. This was specifically asked and addressed at the mentors meeting. Assuming they live up to this commitment, I do not expect teams using C to get stomped by Labview teams, even for vision processing.
4.) Accessibility – Some of the LV capabilities demonstrated on the practice field were fantastic. Draw a line on the screen, your robot will follow it. What gets lost when you have this sort of accessibility is the details of how something like this works. The two girls on our programming team spent their whole 6 weeks learning how to interface with a gyro, how PID works, how to tune PID constants to achieve a stable response, how to write a basic state machine to accomplish a series of motions, and then combining it all to knock trackballs off in any position and drive our robot around the track in hybrid mode. They know how all of this works because they spent the time and effort to understand it, and they put blood (well, I did), sweat, and tears into it. Scoring 12-20 points in hybrid mode was a lot of work, and when we’d get out on the field and do it they were excited because they made every motion out there happen. Drawing the robot path with a mouse on the field, and having it follow it automagically… what did they learn? THIS is what FIRST is all about – not making robots work, but learning and teaching HOW robots work.

Apologies in advance for making everyone’s scrollbars that much tinier.

--Eric

[Danny Diaz]

Originally Posted by esquared

THIS is what FIRST is all about – not making robots work, but learning and teaching HOW robots work.

I was with you up until right there. Even Dean Kamen has come out and publicly said that FIRST is not about teaching engineering, it's about inspiration. I figured I'd throw that out there since it gets thrown in my face enough as it is.

-Danny

[Jon236]

Originally Posted by Danny Diaz

I was with you up until right there. Even Dean Kamen has come out and publicly said that FIRST is not about teaching engineering, it's about inspiration. I figured I'd throw that out there since it gets thrown in my face enough as it is.

-Danny

Danny,

That's true....but what I find inspires these kids is getting them to the point of competency with the programming. I expect them to write the VI's to perform autonomous, control the drives and other actuators and implement feedback control, as well as being able to debug.

I don't expect them to become LabView experts....but I DO want to leave them with that taste of wanting more. THAT's what I call inspiration.

BTW, will the FRC Toolkit VI's that I have be of any use?

[Gdeaver]

On the LEGO NXT web site there is a link to some downloads for the schematics and some low level docs on the interface.

I believe that a graphical programming environment is an excellent way to bring a larger population of students in to programming. My experience over the years has led me to believe that only 10 to 20 percent of the general population have brains wired that allow them to be natural programmers. A larger percent can learn to program, but they really struggle to master the basic abilities. I've noticed that the more visual and graphical the programming environment the easier it is to get the "programming challenged" going. This is especially true when the graphical objects refer to real world objects. The NI cRio and Labview system at the low level are much more complex than our previous controller. I worry that if you EE and professional programmers attack the programming of our new system in c-c++ you will alienate a large percentage of our students. I submit that First and our society in general would be better served if you elite programmers focus your immense skill base on abstracting our new system to a high level graphical object system where we concentrate on robot behavior and algorithms instead of low level constructs. If it is done right there will be layers that that students can peel back and expose the complexity as they become more proficient. Automation and connectivity are rapidly permeating our society. In the future we will need a very large work force to service all the automation. This will never happen unless you professionals start designing system the Rest of society can deal with.