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