Programming Machinery From Scratch

[jeffellis1 0]

I want to learn how to program machinery in PLC Logic from scratch, I have a firm foundation with AB RSLogix supporting engineers in the field, but how do I learn how to write a complete programs from scratch? Is there courses you took? What was the name of the course? Name of the text book and author? Is there standard checklist you follow which guides you in programming? What essential things do I need to learn? My goal here is to make myself marketable so I can find a job in programming. Any tips or hints on that is much appreciated too. Thanks Jeff jfls40@yahoo.com Edited 15 Mar 2006 by jfls41

[Bob O 8]

Hi Jeff, I am no expert but look at this thread; http://forums.mrplc.com/?showtopic=6433 It may give you a place to start until others have had a chance to reply. Good Luck! Bob O

[TimWilborne 108]

I here a lot of people refering to THESE books Also, Bob's link is broke. THIS is it

[Chris Elston 78]

Look at other peoples source code. Learn by example, look at their layout and organization. Download PLC samples here.

[Guest]

Greetings Jeff, I just wanted to say that the "career objectives" listed by the original poster in that link given above seemed to be quite a bit different from the ones that you've mentioned ... I'd suggest that you read through this thread and see if it sounds more along the lines of what you're looking for ... preview of major ideas: (1) get your hands on SOME TYPE of hardware and software ... (2) pick a project to work on ... (3) post your efforts OFTEN ... right-or-wrong ... for-better-or-for-worse ... POST EVERYTHING ... we'll be glad to help you along - but you've got to give us something to work with ... after you've made a start along this path (a week or two - maybe a month) then we'll help you decide where to go from there ... also ... if you don't have any hardware and software to play (correction: WORK) with, then start with the free programming examples at www.thelearningpit.com ... as for hardware, personally, I'd recommend that little Allen-Bradley 10-point MicroLogix1000 setup with the free software - just as a coffee-table-type starting point ... on the other hand, if you're already working around this type of stuff, you probably have access to some type of software ... how about a spare PLC system? ... give us a list of what you can lay your hands on ... be specific ... we need model numbers, etc. in order to give you detailed answers ... and as others have suggested, look at as many existing programs that you can ... the best way to learn how to WRITE is to spend a lot of time READING ... if you have trouble understanding certain parts of your sample programs, think about posting the files and asking for help ... just be SURE that you're not posting someone's proprietary or trade-secret type information ... Edited 16 Mar 2006 by Ron Beaufort

[Beuwolf_1 0]

I guess since I'm more of a do-er then the follower type, my suggestion may differ from many others in here on how to start out from scratch. My method of self taught was begin with a few examples, yes, but don't assume by using someone else's program, that its the only way things can be done. I go by the rule of know what is expected to be accomplished. Either in process or motion control, you should understand completely what it is the machine is SUPPOSED to do. Then break it down in to smaller pieces and even flow chart if that helps. One thing some more expereinced programmers forget with success, is a PLC only does what you TELL it to do, but that doesn't really mean its going to do what you WANT it to do. I have to remind myself of this every now and then when something doesn't quite look right. Hope this helps a lil bit

[flopro 0]

First and foremost-as painful as reality may be-you have to honestly determine if you have the mind/common sense when it comes to "logical thinking and "switchology"." Some of my technicians want to be set up with all the programming applications on their desktop/laptop PC. Usually I give them a reality check by asking them what makes them think they can write ladder codes for the equivalent of a pushbutton, relay, timer and lamp if they can't wire the hardware on the bench? No amount of formal education or training can teach common sense-methods, practices, procedures-maybe. But you either have it or you don't. Remember in coding, "Whoever does the most with the least is the best." I'm not a pessimist-just a realist. Edited 16 Mar 2006 by flopro

[Sleepy Wombat 27]

Firstly I agree with a lot of the above responses but on the same hand I am going to be a little bit cynical (mainly because you indicate that you have a "firm" foundation with AB RSLogix...) secondly because i am tired. Why don't you simply go out with them in the field for cying out loud and mabey you might get an appreciation for a process and the thought pattern that might be used as to how to program the dang thing, spend time to ask them the field engineers questions on how, why etc, DO NOT THINK THAT YOU WILL GET ALL YOUR ANSWERS FROM BOOKS.....

[jstolaruk 9]

You have to walk before you run. A lot of time, sweat, scars, and blood learning from your mistakes while you're installing/nursing a new machine in a production environment will get you the experience. Its only since I got a touch of gray on my temples and exceeded the age of 40 that new customers/employers believe I have the experience under my belt to take on the controls on a new machine. Be patient, and don't turn down anything new; it'll come eventually. Edited 17 Mar 2006 by jstolaruk

[panic mode 246]

this is something everyone goes through. good idea is to try using what is considered good programming practice regardless what language it came from. i see lots of programs that make me wonder if programmer had chance to sit down and think about it before writing hundreds of lines of code. the fact is that things get messy after making changes and the more unplaned changes, the worse the outcome. read as many programs as you can because you will learn from all of them (bad ones too). if you don't like it, chances are you will try to make something that is either better or worse. either way you win, just think about it: - if you make something better, benefit is obvious - if not, you gained experience and you can use the other solution until you find a way to beat it with something even better. i try to organize as much as possible before writing any code, (remember, i try...). for example, i use excel to make lists of I/Os, alarms, HMI buttons and indicators, program stages, sometimes with alternative sequence(s), hmi screen arrangements and their content, handshaking signals, recipe formats, code blocks etc. it's just so much easier to manipulate or group than in ladder editing software. i can pass this to someone else for review (maybe more than one person) in case something was missed etc. and in case I'm not available and someone else has to take over project, it takes no time to explain what was the big idea behind that job. and once this is acceptable, rest is pretty much plain code entry without much thinking involved (it could serve as a training for new guy learning programming enviroment for particular plc). i find it is much more efficient to do this than to simply go nuts and produce some code and later look back and forth 100 times through files and datatables looking for good place for next free bit or register. after only few jobs using things like this, i was able to copy large portions of existing 'plans' when making new ones, noticably reducing time spent on programming, used memory was packed tighter making more room for future expansion or logging. so one of the first things is to produce i/o list (comments are so much easier to enter in excel and just export to plc), define program blocks (alarms, indicators, sequence, mode selection, or whatever). later on you just have to follow the list and do one thing at a time.

[brucechase 1]

Jeff, I was in the same boat as you about 10 years ago . I had only seen 2 plcs and actually changed only 1 line of code. Now I'm the "expert" here. I really didn't find much in books, most of what I learned was troubleshooting and deciferring other's code. To try to help explain what you want, I also had a huge problem with writing code from scratch. That was only because I've never done it before. What I think you are looking for (and what I really needed) were all the little "tricks" and "standard code" that makes a plc so unique. How do you initialize all the things you are controlling. Most anyone can program motors to start and stop but what should be included in every program with a motor is a section of code that says if you tell the motor to start and you don't get a run contact in 2 seconds, then alarm. There are all kinds of stuff like this that should be in a program to make it easier to work with - and I think that is what you are asking for. I spent a lot of time looking for information on "how" to program but I never really found what I was looking for. As you write more, you will have certain sections that remain the same for many different programs (alarms, HMI, faults, etc). This is really the meat of programming, not getting the machine to do exactly what you want, but what to do when it doesn't. I hope this helps.

[darrenj 0]

Last year i did a complete overhaul on a carton filling machine..I chose RS5000 and control logix as my platform. The existing controller was an old PIC409 controller..made obsolete, The manufacture of the machine sat on the fence for a while about sharing the program then decided against it..So i grabbed the maintinance manual and read it about 100times..I then spent about 3 weeks on the floor watching the machine,talking to the mechanics and operators..asking..what does this do..what happens if.. After that i hid myself in a corner of the plant and started to write my code..Then the big day came!!..The machine was sceduled out for 2 weeks for my retrofit..on the first day i had removed the old controller and all the old cableing..This was my first do or die programming project and it was a big one..so after that first day i sat down and stared at the big hole where the "guts" used to be and asked myself just what the hell did i get myself into!!! after 3 days of mounting,grunting and mild panic attacks it was power up time!!..All went well!!! There was a couple of minor glitches but we were testing on day 5 and ready for production on day 7..then the mechanics did some overhaul and were back up and running in the 2 week time period..The amount of pride i felt the day i went home after a full days production with no problem was undescribable..Even better was to find out the manufacture of the machine was doing the same thing at another plant and it took them 3 weeks!!! and they had major problem for about 2 weeks after that!! All being said i guess my point is research..as panic mode said..writing the code is the easy part.. After all was running well the operators and mechanics came to me for "extra's" to make there life easier..and again as Panic mode has said without thaught the program turned into a bit of a mess..I am now looking at another machine almost the same whoever i plan on a complete re write of the code..something easier to follow and more stuctured,no kind of pieced together like the other one looks now.. I am not to hard on myself now..i know it comes with experiance..at least i can look at it and say "I did this wrong then..how can i fix that on another" This was probibly a little easier for me than most becouse i write the program and do the install and trouble shooting.. Also to repeat what Sleepy wombat said..get out in the field and get your hands dirty..reading about how to do something is not the same as doing it..as we always say when we look at some desighns.."it looks good on paper..however..." Good luck and hope you feel the rush the first time you push the start (Just make sure you have one hand over the stop button!!!!) D

[coolhand 0]

I would sugest taking a class at the local Vo-Tech in "Motor Controls". This would consist of instruction in motor starters, relay logic, and wiring controls the "old way". After re-wiring a stop light lab a half dozen times you start to think a bit more logical. The next class should follow that one with the same labs. This time you get to hook the outputs to the PLC and do it the easy way. I feel that building on this foundation will be benificial. I also agree with looking at other peoples code as being a benifit. I am one of the techs in a large manufacturing plant and am responsible for making edits, updating, etc. There are at least 100 procesors in the plant and some of the code reads like a good book and some reads like spagheti with tiimer after timer to control an event -one adjustment can effect the timing and function of the whole machine. Luke

[Sleepy Wombat 27]

One final point. Be respectful and thankful to those who offer advice and guidance.

[jeffellis1 0]

This advice seems a little out of place, are you sure your posting to the right guy?

[TimWilborne 108]

I think what Sleeping Wombat is talking about is many come here, ask a question, and never come back, say thanks, or anything until they have another question. It wasn't directed to particularly. Just general for people wishing to learn Edited 27 Mar 2006 by TWControls

[jeffellis1 0]

Actually, I have been recovering from surgery, haven't had time to do much. I thank each and every person who has posted on here and am going to take their advice. Thanks alot everyone, Jeff

[Sleepy Wombat 27]

I hope that all went well, and I and others at Mr PLC wish you a speedy recovery.

[jeffellis1 0]

I just got back into reading this site today and want to thank everyone for taking the time and posting their comments for me.

[Been Around 0]

How did it go? Learn anything? best of luck in programming!

[OkiePC 14]

Writing your first program of any kind from scratch can be overwhelming. The thing that always helps me is often called a "top down" approach. Outline everything. Keep the overview outline simple. You can detail it later. Make lists of control requirements, I/O, get a copy of the electrical schematics. Divide and conquer the details. Take your basic outline of the machine and it's functions, and gradually expand it until, voila, you have a working algorithm in normal english language on paper. Then youre ready to start typing in code. I usually paste my outline into my PLC software in the form of rung comments first. You can import them if you're good with *.csv files. It will have structure, and you don't have to worry about the forest while you are working on one treebranch at a time. Just focus on what is said in the rung comment, and write the part of the program that does that. You can use symbols and worry about addresses later, or go to your address list and electrical drawings, and finish off each section completely as you go. There are advantages and dis-advantages to both methods. Keep your outline current. When the occasional oh-**it requires you to back up and add things or change something, make your documentation consistent. If you feel like your outline doesn't make any sense, or is getting out of control, don't be afraid to re-organize it. Know your PLC hardware well,. and keep that in mind as you write the outline. You will find that the items in your outline are most useful (re-usable) if they are broken down into generic functions. The 2nd program you write from scratch will be much easier, because your first one will give at least a couple of re-usable pieces. Most importantly, totally understand your hardware. Find out it's exact sequence of operations, and any programming quirks. Get familiar with it's instructions and variations. You don't have to use all of them, but some instructions may have slightly different actual functions from one platform to the next. By all means, look at other peoples code. There are as many different styles as there are programmers. We all mix and match what we've seen, what we've created, but mostly what we have debugged. Starting with borrowed pieces is a sure way to circumvent at least some debugging, but be sure you totally understand the code you are using, and don't step on copyrights! Forums like this are a good place for examples you should be able to legally copy. I don't share anything here I don't want globally published and used. Hope this helps!

[BobLfoot 301]

Let me wholeheartedly agree with Oike's comment that the first from scratch can be overwhelming. Just never forget every big program consist of tons of small ones. I'll also say that some of the "best" code I ever wrote was based on wheels borrowed from others. This forum has tons of sample code and I'd advise studying it for inspiration if not using it wholesale.

[gravitar 3]

I don't think that writing one's first program necessarily has to be overwhelming... Just start with something small! Do something first with just the relay symbols, maybe add a timer or counter. Leave PID, sequencers, and block transfer for later days :) Have the instruction set reference guide for your PLC with you while you're learning. It'll be a lot of help to you. It has been my observation that most people begin their first attempt at programming with a good beginning knowledge of electricity and ladder logic, but get stuck on the software-specific details like "How do I download to it?!" So make sure you get familiar with the layout and structure of RSLogix (And RSLinx, which you must have running and configured to do any sort of communication) and you'll do fine.

[jeffellis1 0]

Im working on my first program from scratch and when I look at other ladder logic files for automated machinery, like index tables for example, I get overwhelmed with so many instructions to sift through. Specifically the back and forth, go to this rung, go to that rung, to find out why a particular input isnt' true. Is there any tips or hints you could give me in how you are able to look at rungs, especially the ones with hundreds of inputs and not feel like your overwhelmed? thanks a bunch

[darrenj 0]

Dont look at other's!!! Sounds simple but it is effective... Everyone has there own style..Just go with what is comfortable with you.. Dint think of the whole program to start..think of lots of small programs..(I am sure someone else said this)..Start at the begining..how does the machine start..Look at that and only that...then whats that is done look at what happens next..then do that...etc..etc.. you will find its not that bad if you break it down..if you look at the whole thing in one shot it becomes overwhelming.. i am lucky..i have a plant that will let me "test" in.. I did a machine last year (The project i spoke of in my first post in this thread" and, on my own time, i re write parts of the logic, just to make it better or take advantage of some of the things i have learned since then..They don't mind if i show up on Saturday and download them and test them..heck if it doesn't work i reload the program and they are away come Monday morning..if i leave the "test" program in then i make sure i am there on Monday to make sure everything goes smothly..(Not hard seeing as i spend about 2/3 of my week there anyway.. anyway..as i said don't look at the whole project to begin with..look at parts of it..If there is a part that you cannot figure out how to do..ask here but go on to the rest..I am sure many people here will help you thru the tough spots..