Fish outta' water

Please bear with me. At 54 yrs old, I have made a huge career change. Life-long mechanic is now apprenticing for electrical and PLC programming in the industrial water purification business. I have always worked with my hands, instead of a keyboard/mouse, allowing me to see almost instantaneous results after the turn of a screw. Writing an entire program, in a language I've never seen, for equipment I didn't know existed, is very daunting and overwhelming. But, I refuse to give up! As an automotive and Harley-Davidson technician I excelled to the top of my peer set. I am as computer literate as need-be to get the job done, but unlike my kids I did not "grow up" with computers. In the first 60 days I have become more familiar with a computer than I ever imagined, but am still sorting out things like IP addresses, "pinging", etc...We use exclusively A-B products (don't know why). The guy I'm working under is a self-taught, highly motivated "wonder" (in my and my co-workers eyes, at least) with 7 yrs. experience. However, in his defense, he is not a "teacher". I have been getting bits and pieces of valuable training but on a need-to-know basis. Here's my issue: I know that there are a couple different XL spreadsheets (discrete and I/O addresses), a ladder logic program for the PLC and a Red Lion HMI that all need to be configured and work in conjunction with each other. I'm having a hard time seeing the big picture, as in what should be the first step and how it is used to configure the rest of the job. I have already purchased the "PLC TUTOR" book by Phil Melore, I am half-way through it and comprehending about 95% of what I'm reading. Most of the instruction and manuals from Red Lion and A-B are confusing and obviously written for someone with more experience and understanding than myself. Are there any resources out there that address and explain the "big picture" for a true beginner, like me? Thanks in advance for any and all help and direction.

Welcome...
Watch these in order and maybe it will help on the PLC side.
http://www.ronbeaufort.com/main_frame_page.htm

Yep... watched those, in order, and it did help with understanding ladder logic. Still somewhat confusing because he gives different definitions for symbols than what is most common in the industry. So when I go to other sources and they are referring to XIC as "examine if closed", I have to remember that according to Ron that means "go look for a 1". Just adds to my frustration, a little.

I feel part of my frustration comes from my lack of "basic computer skills" (as referred to by A-B as a prerequisite to their training) and most of the instruction assumes a certain level of these skills.

As you progress through PLCs from different companies you may come to my view that the make a point to call common things by different names. This is in addition to the different ways of numbering things.

Just concentrate on the idea of each item, like an input contact ---] [--- will be TRUE if the physical input circuit is activated.

Ron Beaufort's excellent series shows his more 'in depth' analysis descriptions. He repeatedly hits the ideas of the input data table and the output data table as totally separate things from the actual input electronic circuitry and the output circuitry.

The name XIC and XIO (and I think are more prevalent in AB systems) reflect back to the origin of ladder logic from physical relay control. (Actually, with physical relays we tend to use 'Normally Open' and 'Normally Closed' to emphasize the powered off state of relay contacts.)

Hopefully this doesn't further muddy the waters for you but when I think of a ---] [--- input contact, I imagine it being part of an imaginary relay called "Input x". If power is on the input then it will energize and pass power. If power is not on the input then it will not pass power. After awhile you don't have to think about it anymore.

Good Luck with your new endeavor. With your attitude, I'm sure you can get all the help here that you could possibly need. Don't be afraid to ask.

Another note - this regards nicknames (or whatever they call the limited unique description text assigned to an item)

Inputs should be named for the condition which exists which turns the input circuitry ON. I don't care if a switch (or whatever) is normally open or normally closed (this can be in the extended description (if available) if you think it is needed. Don't just give the name of the device.

Similarly an output should be named for the action which occurs when the output is turned ON. Again, don't just give the name of the output device.

As an example, suppose you have an air cylinder with sensors at both ends. The output should be named 'Extend Cylinder x' (assuming that's what it does). This could alternately be the name of what ever the cylinder moves but make sure to include the actual action which takes place. The input which senses the fully extended position of the cylinder could be named 'Cylinder x Is Extended' or a similar 'Part / Adjective'

Also similarly internal holding bits should be named for the state which turns them ON (or the continuous state they represent if they are latched).

The whole point is that rungs, when the items are properly named, reads like a sentence across the page. Start with "If" then continue on with the items, their state and any linking AND or OR connections. Of course XIO (or normally closed) contacts should have a "IS NOT" while reading. Just before the outputs say "Then" and continue with the output names.

If a rung 'sentence' is too complicated to say clearly (at least for me) it is a sign that it is too complex as a single rung and should be broken up, possibly with internal holding bits and the ends of the smaller rungs.

I commend you for the career change, I hope you learn quick.

As you have mentioned, the 'basics' are really about understanding how to use the tools required to do your job. Just like a your previous profession you had tools, you had to be proficient at using them to even begin to do the actual work required. Industrial Automation is no different, a computer is our biggest asset. Just so happens that the younger generation is already at an advantage because basic computer knowledge is simply a requirment in society today. So understanding how to navigate around Windows XP/7/8/10 is a must, understanding keyboard shortcuts for Windows and any software you use is a must, understanding command prompts, file types (zip, exe, xls, apa, mer, rss, lk5...) are a must. Unfortunately there isn't much of a 'class' for this stuff anymore, it's almost assumed knowledge.

Much of what you learn is simply from experience, perhaps you are lucky to work with a really good mentor. Most of the time, you have to just roll with it and figure it out. I'm not surprised your colleague is not teaching you, after all if he is self-taught chances are he only knows how to teach himself, or thinks if he figured it out, the next guy should be able to as well. Or he was is is annoyed or feels threatened.

I like to teach those who are willing to put in the effort, but not someone who just expects it. I also have a hard time teaching those who really need Computer 101 or PLC 101 classes. I don't have the time for it, ESPECIALLY if they have a minimum 2 year degree!! (former coworkers I'm ranting).

Books, Videos and Classes can teach you the how to use the basic tools, but hard to teach anyone how to apply the tools and CREATE something with them. In their basic forms I know how to use a hammer, saw, welder but don't know how to apply those tools to create a statue. The PLC world is similar. You can't easily teach someone how to apply and create automation software. Its a combination of natural ability and getting experience by trial and error. Maybe you will be lucky and have a mentor along the way, but not always. Hopefully you work with others who can tell you what needs to be accomplished and do some brain-storming, but then it's up to you to apply the knowledge.

In your example. The Excel worksheet is how he organized what devices he had for control, putting what he has available to work with on paper. There he is matching the field devices with PLC addresses, giving them names/descriptions that might be used in the program. Its a method to tie the physical with the software. If they are really good with excel, it could be very elaborate and perhaps automatically create different files to use in the PLC (comments, tags, logic).

The 'BIG' picture is this:

1 - Understand the process you are trying to control

2 - Understand the field devices you need to control the process.

3 - Engineer/Design on paper first.

4 - Create logic in the PLC to control the process

5 - Have a means for operators to interact with the process you are controlling.

It's difficult process, I see you are in Texas, if you happen to be in Houston maybe we could make an arrangement for some 1-1 tutoring.

To all, so far, thanks for the support. Honestly, I am accustomed to Harley and various other forums where dancing around egos and attitudes seem to take precedence over actually reaching out to help someone. You guys are a welcome change. My present employer is a long-time best friend and I worked for him for two years, about ten years ago. I worked primarily as a welder, pipe fitter and assembler and progressed into building/wiring the control panels. Ten years ago we were just in the infancy of using PLC's for controls. Before that it was all switches, relays and solenoids. Even the electrical drawings have changed, tremendously. SO...I already have a good understanding of the systems, field devices and process flow. I am now becoming educated on PLC's, PID loops and motor VFD's. For the past 25 yrs all I have known about electricity is 12vdc, and an occasional ceiling fan! Also, to Paully's5.0; thanks for helping to describe the relationship between XL and the PLC, and you are correct about learning how to use the tools of the trade. I can see a definite urgency in developing my computer 101 skills, as they ARE "assumed knowledge". Thanks also for the tutoring offer. BTW, if you are still in WI, I married a girl from Kenosha and trips "back home" to see the in-laws have resulted in me falling in love with the North Western region and daydreaming of taking my PLC career up there to retire, someday. I know I have a long way to go.

Love the "mini skirt" quote, by the way!!

motosman1 said:

Yep... watched those, in order, and it did help with understanding ladder logic. Still somewhat confusing because he gives different definitions for symbols than what is most common in the industry. So when I go to other sources and they are referring to XIC as "examine if closed", I have to remember that according to Ron that means "go look for a 1". Just adds to my frustration, a little.

Click to expand...

For now ignore all the other lingo and follow Ron's method until you have a good understanding. The other lingo is handy when you are trying to communicate with others who have been taught in a mix of ways.

Ron's method of XIC "Go look for a 1, Do we have a 1" and XIO Go look for a zero, Do we have a zero"

For OTE instructions if true logic comes in "Go write a 1" and if false logic comes in "Go write a zero"

Many of the other methods will confuse you or teach you to the point that you think you have a good understanding but anything above basics will eat your lunch. Ron's method is powerful but simple to learn, understand and apply.

nobody has mentioned Logixpro yet. I highly recommend it as it helped me at my.start as well. http://www.thelearningpit.com

OdinIII said:

Hopefully this doesn't further muddy the waters for you but when I think of a ---] [--- input contact, I imagine it being part of an imaginary relay called "Input x". If power is on the input then it will energize and pass power. If power is not on the input then it will not pass power. After awhile you don't have to think about it anymore.

Good Luck with your new endeavor. With your attitude, I'm sure you can get all the help here that you could possibly need. Don't be afraid to ask.

Click to expand...

Good call.
Better yet, start out thinking about what the program is really looking at....a BIT in the DATA TABLE.
The fact that it may (or may not) be ASSOCIATED with some hardware input, is, for the purpose of program analysis and troubleshooting, an abstraction.

THIS single point is where I see more students get tangled up.

And, generally, its been my experience that Mechanical folks tend to do better, initially, than do Electrical folks, mostly because the electrical folks keep trying to make "circuits", and thinking about electrical stuff while looking at the program....a crutch that Mechanicals don't bring to the table.

Just my experience with my students over the years.

Great to see an older bugger having a go! I started with my first computer (DOS of course) was i was 51. I had the great advantage of being thrown into the deep end and having to get out as an apprentice when servicing machinery with no drawings and no knowledge! Learning by falling on your bum is great - you never forget the times you fall on your bum.
All PLCs have different terminology - I learned on the old Hitachi D series and Omron step controllers and M1Rs - hand held programmer only.
Depends what you are doing but if temperature and the like see if a local college has a course on temperature measurement for example - learn about thermocouples, RTDs, triple point and on-off versus PID.
Understanding how a machine operates is crucial - if you do not understand that you are dead in the water despite the ruddy bits of paper most companies insist on these days! Recent job with a bit of paper bloke and he did not have a clue - I did all the work without the bit of paper!
I wish you well and it is great seeing you have a go.
There are many here like me who have fallen on their bums all their lives learning - best way in my view.
I am a bad teacher by the way - it has to happen NOW! And heaven help anyone who holds me up because they do not have their s**t together!
If I am teaching someone they have have the courage to stop me and go back and explain because I am gone about 3-4 steps in the future.
You must learn to stop your teacher and ask or you will not learn much because your teacher is already probably 5 miles away.
When teaching I have to control myself considerably as if it does not happen now my hands go in!
I do understand where the other guy is - he is like me I think - not a natural, patient teacher.

bernie_carlton said:

Another note - this regards nicknames (or whatever they call the limited unique description text assigned to an item)

Inputs should be named for the condition which exists which turns the input circuitry ON. I don't care if a switch (or whatever) is normally open or normally closed (this can be in the extended description (if available) if you think it is needed. Don't just give the name of the device.

Similarly an output should be named for the action which occurs when the output is turned ON. Again, don't just give the name of the output device.

As an example, suppose you have an air cylinder with sensors at both ends. The output should be named 'Extend Cylinder x' (assuming that's what it does). This could alternately be the name of what ever the cylinder moves but make sure to include the actual action which takes place. The input which senses the fully extended position of the cylinder could be named 'Cylinder x Is Extended' or a similar 'Part / Adjective'

Also similarly internal holding bits should be named for the state which turns them ON (or the continuous state they represent if they are latched).

The whole point is that rungs, when the items are properly named, reads like a sentence across the page. Start with "If" then continue on with the items, their state and any linking AND or OR connections. Of course XIO (or normally closed) contacts should have a "IS NOT" while reading. Just before the outputs say "Then" and continue with the output names.

If a rung 'sentence' is too complicated to say clearly (at least for me) it is a sign that it is too complex as a single rung and should be broken up, possibly with internal holding bits and the ends of the smaller rungs.

Click to expand...

This is excellent advise for naming conventions. I wish all programmers would follow it.