Fish outta' water

[Paullys50]

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

While I can see the benefits on small systems, coming from the process world I feel that this would be difficult on larger and on complex processes. On one hand, making things read like a sentence seems logical but on the other there are times when this seems like it would be extremely tedious to program. From a system integrator perspective, tedious = inefficient = $$.

Writing logic for each device that reads like this seems more difficult:
"If the current step is 10, 20 or 30, and the system is in 'Supply Mode' and 'Route 1 Supply' is selected AND 'Route 1 Proximity Switch Confirmed' activate timer for 'Route 1 Supply Pump' for 3 seconds, then turn on 'Route 1 Supply Pump'. BUT if the 'Route 1 Supply valve' is not opened, interlock 'Route Supply Pump' or if the 'Route 1 Supply Tank Level' is lower than a 'Low Low Setpoint' interlock 'Route 1 Supply Pump."

Note that I used a 'BUT' to try and differentiate equipment interlock conditions versus typical operation. Then of course if you have a bunch of additional outputs that have to be controlled with a variety of steps, conditions, time delays and interlocks, I feel like it gets harder to read.

I like to see patterns in logic, patterns in logic form my base 'sentence' and the tags I see in the logic fill in the blanks. Patterns tell me what to expect before I look at the detail.

- "Ok, I'm in the logic are where we activate outputs based on step number".
- "Now I am in the logic area where we interlock outputs to protect equipment."
- "This is the logic that maps my software command signal, to the physical IO."
- "This is the logic where the programmer began to lose their mind."

 

[geniusintraining]

At 54 yrs old,

Your still a young kid

We sell lessons that may help, they were wrote by me (also a former mechanic) and Ron wrote one, send me a PM with your email address and I will send you a link for them (no charge) there are also a few videos

Do you have a PLC? if not by a used one on ebay and go "hands on"

Also keep a open mind... since you brought up Harley, PLC's are like bikes there are MANY brands and they all will get you from A to B, some better then others and some are a blast to ride, others are a nightmare and they will ride you but they all do the same thing in the end

 

[FactoryTalktotheHand]

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 can understand that. Ron's terms are not commonly-used in the industry, but they should be because they are the most accurate as to what is actually happening in the processor. GE is the worst by calling their instructions "Contacts" and "Coils." Sure, it's more user-friendly to people unfamiliar with programming but familiar with hard-wired electrical panels, but it's not accurate and can cause a lot of confusion and headache down the road when you're looking at a rung that is all lit up green but the OTE instruction is not.

In that case, the first thing an untrained person might think is "this is a bad processor!" After all, if you have voltage on a relay coil and the relay isn't changing state, you know there's a bad component. But someone who understands how the processor actually works will say "There must be another instruction writing to this address somewhere, I need to find it." It can make the difference between needlessly spending thousand of dollars and multiple days of downtime for a processor replacement, or having it fixed in five minutes.

 

[motosman1]

I TRULY appreciate all the direction and support, you guys are great! As I said in the original post, in defense of my mentor...he is not a teacher. He is not PAID to teach, he never took this job to teach and he has not previously been a teacher. He was actually the welder when I worked here, with him, ten years ago. We are a small company of 21 employees. He has cemented himself in his current position and has no reason to fear for his job. He actually WANTS me to learn and be able to relieve him of some of the workload. Problem is, as I am trying to learn he, is making electrical drawings AND writing/modifying programs AND researching and procuring components AND he is our IT guy AND dealing with issues in-the-field. He IS overloaded, hence my reluctance to "bother" him with questions I feel I may be able to answer on my own. That's why I am here. Believe it, or not, this simple bit of input from Paully's5.0 really turned on one of the "lightbulbs" in my brain to help me see more clearly...

"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.

__________________
"Comments should be like a mini-skirt... long enough to cover the essentials but short enough to keep your interest." - Uptown47

 

[KalleOlsen]

Here's good, compact reading:
http://www.contactandcoil.com/patterns-of-ladder-logic-programming/

Kalle

 

[dwoodlock]

Computer basics can be a hamper at first, but I think a mechanical background will be more helpful when starting out.

General experience is always helpful!

I guess one recommendation I would make is that you keep frequenting this site.

Tons of great information here, and as you've seen from this thread; a huge amount of people willing to help. Sometimes you strike out, but more often than not somebody has seen it before, or can at least offer an idea.

best of luck

 

[jamesau]

Kalle's link in post #20 is an excellent one. I'd recommend you print out each pattern for study and use as future reference.

You probably hope to develop the ability to collaborate on and tag-team with your mentor on projects as the need develops. For this reason, you should try to learn his style of programming/project execution first; there are many ways to skin the cat in this game! As you develop experience and knowledge, you can refine this style.

I'd ask your mentor for a copy of a project (PLC/HMI) for the purpose of learning his style and study it. Try to get a project where there is a well-written narrative of what the PLC/HMI does along with other supporting documentation.

AB has a bagillion documents which support their products. For the programming aspect of the PLC, you will want to refer initially and often to their 'instruction set' manual. This will help you understand not only the various programming instructions, but also the various data types that are used (variables and logic are two distinct programming elements).

Good luck and be kind/patient with yourself in this endeavor! Understand also that the machines you may be asked to control may pose dangers; you should insist on supervision/peer review when appropriate (you probably wouldn't let a completely green motorcyle mechanic overhaul a customer's suspension on his own)

 

[adisharr]

To add a bit to all this great advice, I think the other area beginners struggle with is understanding all the different data types and how they are used / represented in the PLC. Omron was always fun to deal with when some of their instructions / configurations used a mix of them in the same instruction.

Bits, bytes, Words, doublewords, Floating point, integers (wigned and unsigned), Hex, decimal, BCD, etc..

It might help to look at some of the tutorials on that as well as things progress.

P.S. Even after 23 years doing this, it's always humbling to come to this forum an realize everything that I don't know

 

[motosman1]

I keep saying "thank you" and probably can't say it enough. My mentor tries by giving me analogies that relate to real world situations. Seeing PID as a car on the road using "cruise control". These examples really do help. I suspect I may be too anal-retentive for my own good as every time I approach something that I should probably just accept and memorize, I catch myself asking why? Where? How? Then I feel overwhelmed. I'm getting a lot of good resources, though.

 

[JordanCClark]

I suspect I may be too anal-retentive for my own good as every time I approach something that I should probably just accept and memorize, I catch myself asking why? Where? How? Then I feel overwhelmed. I'm getting a lot of good resources, though.

I understand. Just don't get into the trap of overthinking it. There have been plenty of times that I've second/third/fourth-guessed myself, only to go back to my original thinking at the end!

In a similar vein, my daughter is the exact same way. I have to tell her it's sometimes good to slow down and know THAT things work first. The HOW things work will come soon enough when she gets the basics down.

 

[Bob O]

If you can, post a program and specific questions about the program. If you do, you need to zip it first.

 

[JordanCClark]

Maybe I should go back and say that I'm NOT comparing you to a 12-year-old girl!

She, is, however, a very smart young lady. She loves Star Trek and Doctor Who, so I must be doing something right.

 

[uptown47]

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

I thank you! Part of a best man's speech I did once. Can't claim to have written it myself but it tickled me

To OP,

I found knowledge around PLCs is like a muscle, the more you use it, the stronger it gets.

My advice would be to immerse yourself in it.

At first it will seem like an impenetrable mass of jargon, 1's and 0's and strange logic. But after a while little bits start falling into place and then you get 'eureka' moments.

Get a PLC simulator (or a real PLC to practise on). Don't try and understand it all at once. Break everything down into small manageable chunks and as soon you as come across something you don't understand, make a quick note of it, and then when you've got a small list post it on these forums for people to help you out with it.

Once you get some basic concepts then you'll find these gel together to form a step up to the next level of understanding.

Onwards and upwards. Time = experience.

You seem like you've got the right attitude to learn and I wish you the best of luck.

 

[motosman1]

To uptown47,
Thank you for the direction and encouragement. You are correct, sir! It does seem impenetrable. I have been at this for about 30 days now and feel like I should have a better handle on it. But I also reflect back at what I have done, so far, and considering that much of my energy has been devoted to learning basic computer navigation skills I find the motivation to move forward. I have also arrived at the fact that due to either age or the previous 25 yrs in the "mechanic" mode, my memorization skills are not up to par. I am not accustomed to just accepting that "something happens" and not FULLY understanding "why or how" it happens. But you are right in that already little bits (no pun intended) have fallen into place. It has helped immensely to join this forum, after buying Mr. Melore's book, for further direction and encouragement that maybe I have NOT bitten off more than I can chew. I am excited to learn more, DO more and come back here with real problems with which to pick your collective brains. Thank you, again!

 

[dwoodlock]

every time I approach something that I should probably just accept and memorize, I catch myself asking why? Where? How? Then I feel overwhelmed

If you dont ask why, you really aren't learning.

Fine example of why the education system today is a huge mess. Memorizing and learning are two different things.

Take the time, google is your friend!