Industrial Controls Curriculum

[TimWilborne 108]

OK so I titled it an Industrial Controls Curriculum, but it is just a PLC class to start with. I may have been persuaded to teach a PLC class But I refuse to have the traditional textbook class. They don't work, it's been proven again and again. You typical graduate can't even figure out what PLC cable they need to connect to a processor, much less how to configure their PC to communicate with the PLC. So think about the green programmers and techs you've ran into. What does everyone lack that keeps them from succeeding? Also, what horror stories to you hear from the "talented" people who didn't finish? For example some of the best techs got lost in the first grueling weeks of principles and data types of PLCs. This would be more of a technical class. Any help is appreciated. Thanks TW

[Leitmotif 0]

I think I am qualified to comment, graduate of US Navy Nuclear Power, AA, BS MS and two quarters of PLC and a dash of VFD therein. SO I have been thru a few schools and have seen my share of dropouts and completers. I think your class title "Industrial Controls" is dead on. The PLC cannot do anything without sensors and output devices. Those are most of the trouble calls anyway. I think a quality program is 25% material, 30% instructor and balance student. Good (motivated?) student can overcome bad instructor. When I took PLC it was because I was trying to learn at home. I decided I had a lousy instructor (me) and I had better find a qualified one. So I did. As it worked out I "wrote" my curriculum and decided what to learn and when or in what step I should do it. Instructor approved or modified as needed. Started out with how to configure NO and NC switches and what happened with each configuration, at the end (after several projects) I had a stepper motor and VFD setup controlled by PLC (that project was a simulated automated drill press). It was alll AB PLCs. Am now teaching also - class oriented to Electric Vehicle teaching principles of AC 3 phase motor and VFD to drive a car. After 5 sessions I have a 90% satisfaction grade from students. Next session Sat 10/23. Dan Bentler

[Guest]

be careful what you ask for - but give me a call if you're serious ... (or just give me a call anyway ... it's always good to hear from a friend) ... key points: people don't learn when they're bored – and people don't learn when they're frustrated ... somewhere between boredom and frustration is a "sweet spot" where optimum learning takes place ... hint: for most students, the sweet spot lies a lot closer to frustration than it does to boredom ... a well-known rule of thumb says that the average student has a "learning" attention span of about 20 minutes ... BUT ... that rule only holds true when the "learning" is based on PASSIVELY listening to a lecture - or PASSIVELY watching PowerPoint slides ... on the other hand ... when you keep the students "learning" by ACTIVELY thinking through a problem, then their attention span can LAST ALL DAY LONG ... so ... present a PROBLEM – and then "coach" the students through a systematic approach to finding a SOLUTION to the problem ... "coaching" isn't the same as just assigning the problem – and then waiting around until the students are finished solving it ... a little league baseball coach doesn't just let Johnnie swing away for an hour of batting practice ... instead the coach identifies what's "right" about Johnnie's swing and reinforces that part ... and he identifies what's "wrong" with Johnnie's swing and corrects that part ... once you get the hang of it, your "motivated" students will LOVE the approach ... and you can cover a LOT more material – and have it "stick" better – than with any other method available ... Edited 18 Oct 2010 by Ron Beaufort

[JeffKiper 9]

Are you going to be teaching programming or brand name troubleshooting? If it is teaching general programming I probably wouldn't use that text book stuff either. I still have my 4th year book from what I remeber it was OK. I would make it as real world as possible. If brand labeled troubleshooting than I would hit comms, some basic logic, and heavy real world I/O. It seems that 90% of my service calls are real world problems. very few of them are logic based problems. I went through a 4 year electrical apprentiship. When I turned out I could write some logic, bend conduit, wire and troubleshoot Relay logic. We did 1 year of PLC programming. We only used Logix Pro. I didn't know anything about connecting a cable to a PLC.

[drforsythe 15]

"So think about the green programmers and techs you've ran into. What does everyone lack that keeps them from succeeding?" The biggest thing I learned from green techs is that we as controls engineers, need to pay attention to our customer(s). Whether our customer is someone who directly pays for our services, or the person running, supporting, selling or purchasing the machine, the customer needs to be listened to. I have seen many new techs come and go (usually into sales) and the biggest thing they lack is humility. Without humility, we do not listen. Without listening, how can we possibly find out what our customers really want? It usually takes a while for a new tech to realize that they are not as good as they think they are. So, the long and short of my response is: Teach your students that they have two ears and one mouth and to use them in that proportion. To be successful, listen to the customer. Don't be too cocky and deliver what you say you are going to deliver. Chances are that you may be able to program a plc better than them, or design a control system better than them, but they almost assuredly know their machines or processes better than you.

[robh 12]

One of the problems I run into with some of my "greener" co workers is that they expect everything to work exactly the same every time, regardless of what they are doing. They seem to get very one track minded about the communications and software. I would have to say that the communications side of things seems to be the biggest hurdle especially when you have multiple protocols.

[TimWilborne 108]

All great points so far, just getting done for the night so can't reply to each, but keep it coming please What a great statement! Of course I think this should be included in Attitude 101, not sure it can be integrated into Controls 101

[Ken Moore 23]

I work with some very smart techs, they THINK, they know what is wrong, but do not have the confidence to proceed. I keep telling them: " if it isn't working, you can't break it". Hard to instill confidence. But trouble shooters need to act and not be afraid. Bare in mind, we always consider safety, lock out, tag out etc.... Not short cutting any of that stuff.

[TimWilborne 108]

I completely agree with you there Ken, but is there anything besides experience...and the occasional solution going wrong and realize the world didn't come to the end...that really builds this confidence?

[Crossbow 295]

I've been teaching for 8 years, and I write all my own curriculum. There are no good books out there I have found for the methods I use to teach with. So I write my own. Start with some basics, then mix in a basic exercise, like establishing communication. Then do some more basics, and perhaps an exercise to erase the PLC data (return to out of the box condition). And so on... You need to mix hands on in as frequently as possible. Don't lecture for more than 15-20 minutes without exercises, demonstrations, or something. And for the first couple programming exercises, give them a written program and have them type it in just to learn their way around the software, without having to apply programming techniques. Then once they are using the editor, throw them a quick mod to the program, or another exercise they write from scratch. My first 1 or 2 exercises are usually entering example code, then one where I build mistakes into the program for them to locate and repair. Then I hit them with 'here's the application, write it'.

[Guest]

personally I've had a lot of success by using the "evil instructor" method ... during the very first few minutes of the class, I tell my students that they are REQUIRED to immediately "correct the instructor" anytime I make a mistake ... so ... AFTER the material has been covered CORRECTLY, then the "evil instructor" is free to restate the material INCORRECTLY and the students are REQUIRED to catch his "mistakes" and immediately point them out ... this approach might sound "frustrating" but try it and you'll find that the students LOVE it and it keeps them on their toes trying to be the first to nail the instructor ... just a few quick examples: (1) this routine IS being scanned because the "rails" are green ... (2) this instruction must be TRUE since it's highlighted in green ... (3) this OTE must be the ONLY thing in the program CONTROLLING the motor's output because a "Find All" search only finds the address O:001/3 in this ONE place ... (4) in a DOUBLE-COIL situation, the last rung always wins ... (5) and so on ... the basic idea is to toss in some of the same common misconceptions that the students have been hearing around the shop and to make sure that they can point out the fallacies when they hear these mistakes from their co-workers in the future ... secret handshake: if you don't do this, there's a very good chance that the "big dogs" are going to DE-TRAIN Little Johnnie once he gets back to the plant ... another way to build confidence ... a lot of my lab equipment has been "tricked out" to introduce real-world problems into the students' hands-on exercises ... for example: I've installed miniature toggle switches into some of my output modules ... I can flip these when the students aren't watching so that a specific output will: a) operate normally ... or ... b) not come ON regardless of the logic ... or ... c) not turn OFF regardless of the logic ... another simple example: I also have some special "tricked out" wires that I've purposely flexed back and forth enough to break the conductors while leaving the insulation in place ... naturally inserting these into the students' wiring projects leads to some realistic troubleshooting and problem-solving exercises ... and so on ... another way to build confidence ... as the class progresses, my students spend almost as much time at the whiteboard as I do ... they're expected to be able to trace out the systems that we're exploring and to lead their classmates through a step-by-step solution to the problems we're troubleshooting ... NOTE ON THIS: when I talk to my "corporate customers" these types of "teamwork communication" skills are some of the most important topics they're interested in having their employees learn ... just being able to explain technical concepts in a straight-forward and coherent manner isn't something that comes naturally to a lot of people ... but ... once you channel the students into a step-by-step left-to-right approach to tracing the signals through a PLC-controlled system, then most of them will gain a LOT of self-confidence in their abilities ... CAUTION: this requires a careful approach and some time to get to know each student's personality ... once you can make a "game" out of the exercise, the students will enjoy the challenge of correcting each others mistakes ... BUT ... some people need more "coaching" than others before you can put them on the spot in front of a classroom ... another way to build confidence ... break the various hands-on exercises down into "bite-sized" sections ... that way if you have to coach a student through PART of the exercise, there will still be other parts that he can work on for himself ... another way to build confidence ... don't OVER TEACH material that the student should be able to "figure out" on his own ... for one simple example: early in my classes the students are shown how to add a new LADDER FILE to their programs ... later in the class, the need will arise to add in a new INTEGER FILE ... we've never really "covered" that ... but ... most students will intuitively Right-Click the proper icon and then add the New File without being specifically told how to proceed ... that's a "magic moment" ... make sure that you point out to the students how much they're able to PROGRESS ON THEIR OWN once they've learned the underlying ideas ... another way to build confidence ... be sure to point out PATTERNS in how the course material all "fits together" ... the human brain is designed to learn NEW knowledge - by referencing it to EXISTING knowledge ... you can channel that natural tendency by first making absolutely certain that the EXISTING knowledge is correct and by then pointing out how any NEW material is SIMILAR to or is DIFFERENT from - things that the student already knows ... once you've coached your students through recognizing these PATTERNS for themselves, they'll gain confidence in knowing that they can continue to "learn on their own" even after they've left the classroom ... Edited 20 Oct 2010 by Ron Beaufort

[BobLfoot 301]

Tim - you've got a lot of good advice as usual for a well asked question on this forum. I may be repeating some of the above, but back when I had to break in fresh apprentices to PLC troubleshooting I always started with a battery, a switch, a relay and a lamp. If they could wire this circuit and then "grow" it by adding a second switch for a basic motor start/stop with seal in relay {lamp representing motor} then they were ready for basic plc. Otherwise we went to electronics 101 first before plc.

[JeffKiper 9]

I have been to Ron's class. He helped me make mistakes over and over. Those are the ones I remember the best. Ron I still draw a wheel running around and around when doing scan stuff that doesn't just jump out at me. He set me up on a RIO problem. Block I/O would runn just fine for a while the start flaking out. The code ran fine on a PLC5 but not a CLX. .Hardware issues is all I can say until Ron says it is OK.

[Guest]

remember that the 1756-DHRIO module is VERY "picky" about having the terminating resistors in place ... the older PLC-5 and SLC-500 hardware usually runs OK even without the resistors ... once we installed the resistors, the Remote I/O link worked OK with the ControlLogix hardware ... Edited 20 Oct 2010 by Ron Beaufort

[JeffKiper 9]

I am talking about step 1, step 2, & step 3. I wasn't sure if tha resistor was a setup or not.