Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

Trying to Learn PLC Programming 4

Status
Not open for further replies.

sinueus

Electrical
Feb 4, 2010
6
0
0
US
Hi,
I always fall short on job applications because I can't program PLCs and the classes cost a fortune. I have the LogixPro sample diskette but that only allows ladder logic programming and working with that does not qualify me as a PLC programmer. I am thinking about buying a used PLC and learn to do it myself. There is one for sale in ebay that includes the following modules:

ALLEN BRADLEY 1746-A10 SLC 500 10-SLOT RACK W/ MODULES
1746-P4 SLC 500 POWER SUPPLY
(3) 1746-IA16 SLC 500 INPUT MODULE
(2) 1746-OW16 SLC 500 OUTPUT MODULE
(1) 1747-SN SLC 500 REMOTE I/O SCANNER

I think the numbers in parenthesis mean the number of modules included but I am not sure.

My question is: How much would I have to spend to get a system running so I can learn to program it? I am laid off so I can't afford to go overboard with this project.
Thanks for the replies.
 
Replies continue below

Recommended for you

I do not see a processor in the list. Obviously, you need a processor such as a 1747-L541 (SLC5/04 with 16K memory). It looks like the ebay parts are from a remote I/O rack.

Further, you will still need RSLogix 500 programming software that is quite expensive (plus, at a minimum, a serial port to connect your computer to the SLC500 CPU). Further, the SLC500 can only be programmed in ladder logic, so the "advanced" programming languages such as Function Block or Structured Text will not be available.

Simulators and emulators such as LogixPro 500 are a great way to learn to program. Here is a link to a free IEC 61131 programming system that you can download (along with a Soft PLC) for free. The system is called CoDe Sys and can be programmed in any of the programming languages specified by the 61131-3 specification.

 
Thanks amptramp. I suspected that It was going to be too expensive. It is so good to have help of this type. I appreciate it. I'll try the programs that you mentioned.
 
Buying a PLC is good first step. There is a lot to using a PLC which isn't covered by LogixPro. For one, if you are new, just getting the darn thing to communicate can be more work than writing your program. But if you are worried about costs, I would steer away from Allen Bradley. IDEC and Siemens both make good controllers and the software is reasonable, especially if you buy a starter package. I would recommend the Siemens 224XP - it has digital in, digital out, analog in(2) and analog out (1). I have done a lot of programming with Allen Bradley, and they make good stuff, I only use Allen Bradley only when a client requests it. For hardware, AB costs 2x what Siemens or IDEC cost. Software will cost you a fortune, over and over again. Tech support will cost you, documentation will cost you, tech support will cost you. They even charge you to log onto their user forum. Software upgrades aren't free either. They make Apple seem like open source software. Do yourself a favor, get a Siemens or an IDEC.
 
Thanks eeprom.

If I learn to program, say, a Siemens, would I be able to program an IDEC or AB? I've only been able to see that AB can be programmed in ladder, block, text, and I think you can also use C.

I am still trying to get the software that amptramp recommended to run. I'll come back later and post another question if can't get it to work.

Right now there is a great job opening but it requires plc programming (as usual) so I can't apply to it even though I am qualified to do everything else. I need to learn to program fast!

Thanks again
 
Try some of your local distributors, explain your situation. The Siemens house near me has comped the Basic PLC course for some electricians just to get a "friend" in a facility that knows their products. The local AB house did it a few years ago, just depends on how much the sales folks are willing to help to get someone in that remembers them in a nice way. Remember, the worst the distributor can say is no, and you are a potential customer.

Also, if you don't mind a bit of advice, go talk to whoever is in charge of the opening you're looking at. Sometimes a eager and willing candidate is a better choice than someone who may or may not already be fully qualified.

PLC programming covers a lot of area, different hardwares and softwares, interfaces and communication networks. Hard to be an instant expert at all of it. Go find out what hardware, soft and HMI they're using, and how it all talks, you might find you are a better candidate.

Good Luck!
 
catserveng,
You read my mind. I tried some of the local distribuitors to see If I could get a deal on some software but I had no lock. I ended up buying one of the Logix 5000 trainers for $370. It hurts but I needed to take immediate action. Right after doing that, I sent an application for the job I had in mind explaining that I have everything they need except the PLC and that I am getting that now.
I hope this gets me through the hoop.

Thanks everyone
 
Was looking the the MrPLCs site after I made the post.

They have a link to a free limited use version of RSLogix 500. A quick check on eBay shows a few MicroLogix 1000's around $150, some switches, lamps and a power supply and you can get a basic start, then go from there.
 
Ladder logic is ladder logic, regardless of whose platform you are using. Yes, there are differences between Siemens, IDEC, and Rockwell. And it is a pain to learn them all. But there are basic concepts common to all: communications, controlling I/O, dealing with analog signals, logic, timers, counters, data-logging, and PID loops. Once you understand how to incorporate these concepts in any platform, you will have the skills to create a program. Once you have that skill, applying it to another platform will be relatively easy. But...if you are using this as job-finding tool? I would get online with a couple outfits you are thinking about working for and then take a look at what platforms they advertise. If you find a place where you want to work and they use Rockwell exclusively, then you should start with Rockwell.
 
Boy!
I am learning at a fast pace! All the responses have been extremely helpful. I am now working almost 100% on this and there is more to come. The videos that arj3090 recommended were great! I had done that type of thing with computer hardware and the videos opened my mind to doing it with PLCs. That's what I am talking about. I need to get out of the basics and into the advanced. I am checking all the responses and I am working in all of them.
Thanks
 
PLCs programs are basically the same at a simple level, but even then they can have significant differences, such as how one-shots or state machines are implemented. As you get more complex, some allow you to mix other programming languages and other things that are very machine specific.

However I find that the software can be completely different from different vendors and that's where I find most of the difficulty programming new machine. Some vendors even have different software for different models so it can be almost as confusing changing models as brands.

In some areas AB PLCs are the norm and it is good to be familiar with their software. However it is costly. (A friend says AB's motto is "You can get better but you can't pay more.")

Having said that I think that if you're just trying to get familiar with PLCs you could start with a simple and less expensive system. If you spend your money on an AB PLC and software and your new job uses Siemens PLCs you have wasted some time and money.

I used over a half dozen different PLCs but for most applications I like Automation Direct PLCs. They're not fancy, but their software is inexpensive and one package programs all the PLCs. They have a small PLC, the DL100, for about $100. I think the DL100 can even take some add on modules like analog I/O. They have inexpensive software, and may even have free software for the DL100.

Then you could learn simple ladder logic programming and say you are a programmer just like the big boys.

I think I have a simple program for a DL100 I could send you, if I can find it. It might be easier to start with a completed program and both see how it can be done and learn to modify it, rather than start from scratch. I like to structure the program, as much as you can with ladder logic, and write lots of comments so maybe it'd help. For me, even things that seem obvious when you're writing the program can be a complete mystery a few years later. Of course it's often that I'm not sure whether I'm afoot or horseback anyway so maybe it's just me.

StephenTheObdurate@Gmail.com
 
I think the best advice you have had here is to find out what companies in your area are using. Most companies in the us use AB. That's why AB will compromise less on price, training, software, etc than other companies. Some of the comments on programming are true but may be misleading to someone that knows nothing about PLC programming. Ladder between platforms is similar. the small differences; however, can really throw off a new programmer. Addressing schemes are different, communication, and the different programming packages. Hey its a big difference just going between the SLC/Micro AB lines to the Logix lines.

that all said, get a PLC. Simulators may give you a sample of how a PLC works, but there is soooo much more to PLC programming. Find out what brand/type you will be likely to come across, and get that one. Make sure you can get software to work with it. It's been mentioned before that even AB has a demo package of their software for the Micros. Do your research. That package only works on some of the micros. If you need to ask here or on other forums. For example, the 'plc' you first posted about was just a remote rack. No PLC included. That would have been a shock I'm sure. I would suggest finding a Micro 1100 if you can (availability is poor right now). You can use the free package with one and it is able to do online programming which the 1000 cannot do. You also need some type of instruction. There are lots of programmers out there. There are few that actually structure, comment, program correctly.

Russell White, P.E.
Automation Technologies, Inc.

Automation Help
 
My experience has been mostly in the West but I've heard that there are application and regional differences. I heard that the Auto industry does not favor AB so in the midwest AB is not that common. I also heard that NC sheet metal machines and the like have different PLCs and software, so AB and AutoCAD aren't the norm.

I have worked for people that used AB, though my last three customers all had different model AB PLCs and different programming packages. I have also worked for people that used exclusively CH, Siemens and Automation Direct. There may be no way to pick the right software, but AB is more common in my limited experience.

The only problem is that AB is expensive and as noted, they have different lines, so even if you do get AB software you may not be familiar with what the plant is using. I have even seen software packages for AB from other vendors. Further, it is probably way beyond your budget to get too involved in some advanced things, like setting up networking between different machines, no matter what package you have, so some advanced device specific software may not be that useful.

Of course, most HR people, and many middle managers have no idea that there are even different AB packages, so any AB experience may get you the job.

If money is no object I'd probably get AB. If you don't have a clear idea which PLC you will use or you have a limited budget I wouldn't.
 
PLCMentor:

There are few that actually structure, comment, program correctly.

Would you elaborate on your comment, i.e., what is correct structure, correct commenting consists of what, and what defines programmed correctly. Also, would you state where you obtained the standards you adhere to during program development.
 
I can elaborate some as examples, but it would be impossible to give a good answer here. Let me start with the last first... I don't know of any standard that covers good PLC programming methods. We have internal standards here, but I know of no book or document that covers this. Possibly due to the fact that we regularly update and add to our standards. This field is one in which I constantly learn. I have been fortunate in having several very good mentors along my path.

Correct structure:
Some of the standard programming techniques that you would learn in any programming course do apply to PLC programming. Others will completely send you down the wrong path. Modular program organization is very necessary in a PLC program.

Correct programming:
Tight compact programming practices are not necessary and many times a hindrance. Im not saying sloppy programming is good - I'm saying that PLC programming needs to be written for those that will maintain it. Using indirect addressing, jumping around the program and other things that make the program harder to follow/troubleshoot should be avoided.

Correct commenting:
Any register, bit, etc used in a program should have a comment associated if allowed by the programming software. If not then some other means of commenting should be used.
Major sequences should be commented.
Changes made to a program should be commented.


Russell White, P.E.
Automation Technologies, Inc.

Automation Help
 
Don't get me started. I was trained as a computer programmer, assembler, C, PL1, PLM, Pascal, Cobol (the worst) ... and I believe in structured programming even with ladder where you create any structure on your own. I have been writing ladder for decades but consider my previous training essential.

Proper programming is a matter of personal choice, but some programs are purely awful from any standpoint.

I have seen programs with virtually no comments. I once worked with a man who deleted his comments after he wrote the code. He said it was to to make the programs smaller but I'm sure it was because it made him indespensible. I think the man who wrote Pascal that said if you ever have a programmer who's indespensible you should fire him before he does any more damage.

Comments that aren't updated after the ladder is changed are all too common. Some old PLC programs would move the comments when ladders were added so the comments had nothing to do with the ladders they were over.

One big problem with most comments is that they may say only what is done (turn output off - the obvious part) without saying why. Why is the big issue, especially when you're looking at code someone else wrote or some code that you wrote awhile ago. I often look at old code and I'm not even sure I wrote it - but maybe that's just me.

I consider it critical to have paragraphs before section that explain the purpose of each section, and explain the variables used, what and why, including the format - is a variable in in engineering units? If so what? It's also important to explain a variables scope, even for contacts scope - who affects it, what does it affect and why.

You can certainly write without this and most people do but its often not effective in the long run.

Run on programs are especially easy in ladder, where fairly independent functions are all mixed together. I consider this bad. I try to consider different sections as if they are different subroutines and mark then as such.

I once had to modify a program without comments. I spent quite awhile studying a section of 6 ladders and 10 rungs, with 5 contacts. It turned out that the result was a single contact that was used. It was a one-shot. This is the worst. Horrible code without explanation.

I developed my ideas over about forty years of programming, including over a decade of writing sophisticated motion control programs in assembler for an 8085. (I started before floppy disks were common. We used paper tape for the program and the assembler. A three pass compiler meant loading the assembler tape, then the program tape three times.)

The algorithims I developed for hydraulic servo control were ported to an 8086, by programmers I never met, after I left, and in use twenty years later. My structure and subroutine comments were unchanged. I think that this was one of my greatest accomplishments, and think it is an ideal all programmers, ladder or not, should strive for.
 
I been thinking about my previous post and have some other things to rant about:

Independent and dependent variables. Say you have a number of different operations in a process, such as energizing a solenoid, starting a motor and lighting an indicator. If you turn these on in each place where you need to, even if it's a couple of places, each output is independent. Then if you need to modify the operation, you have to find each place that this happens and modify it. If instead you have a single output, such as the solenoid and operate the motor and indicator based on the solenoid, then they are dependent and you only have to change the solenoid output and everything else follows.

This can be important where you enter a value and save the raw value, an engineering value and a bcd value for a display. If you make the raw value an independent variable and continuously calculate the engineering value and bcd value as dependent variables, you don't have to keep track of every routine that changes the variable: entry, restore default or load different configurations.

This brings up state machines. I commonly see state machines with too few states, possibly where operations have been added after the fact. A state machine should have a state defined for every step in an operation. If when you have a state to cut a sheet, the steps could be: 1)operate the clamp and if the clamp closed limit switch is closed, energize the cutter, delay, de-energize the cuter and clamp.

One way would be to have one state. In that state the clamp would be on and the cutter would be on if the limit switch was closed. Instead you should have two states. In the both states the clamp is on, the second state the cutter is on and you change from the first state when the limit switch is on. Then the operation is clearly defined.

In the first case if you stop you might have to check whether the cut has started. If you have two states you know whether the cut has started.

This may be a weak example but maybe you get the idea. I believe that every step in a process should have a state. That way you can have a simple single point for outputs: A solenoid is on in states 3 to 5 and state 7. The solenoid operation is clearly defined in a single rung and there are no surprises when you go back to modify the solenoid operation.

I have repaired complex programs with interlocking operations where one part of the process affects the others and the states weren't clearly defined. Then the operation was expanded, (interlocks, extra steps, etc) with some entertaining results.

In simple PLCs having a numeric state and repeated tests on each rung (STATE = 3) can be a bother and numeric claculations are slow. To speed operation I sometimes have a series of rungs before the state machine that set contacts:
If STATE = 0, contact STATE0 is ON
If STATE = 1, contact STATE1 is ON
and so on.

This takes lots of memory but if the operation is complex it may save time. Again STATE is an independent variagble and STATE0 and STATE 1 are dependent variables, set/reset in a single location.

You can do any6 old thing with a simple program but things have a habit of getting out of hand. I try to ALWAYS write ais if I have a complex protgram. It's something like always putting your seat belt on even if you plan only to drive a few blocks to the store.
 
Status
Not open for further replies.
Back
Top