What can i do to get better at coding controls logics?

Over 25 years ago, I wanted to learn this complicated PLC thingy.
More and more machines were coming to my factory with them in.

My boss would not pay for software or schooling preferring to get the 'experts' in when they went wrong or needed changes.
I paid for a quick course myself and it was a complete waste of money and time.
I was no wiser when the course had finished
(looking back and knowing what I know now - the tutor was useless.)
He concentrated on 'scan times' and scan which meant nothing to me and nothing practical.
So I bought a PLC and the software and leads and set them up in my shed.
I spent 2 years after work in that shed teaching my self with books and trial and error.

There is no quick route to understanding PLC's and being competent - but getting an actual plc and software etc is far far better for understanding what is happening.

true talk. been doing this for over 20 years, and still don't know enough.
 
and it doesn't pay that bad. but i'm pretty sure the chemical engineer that makes the car wash chemicals makes more than i do.
 
The issue thought that i am having is that I cant find the "small steps."

I finished PLC 1 on Udemy by paul lynn. now i am working on PLC 2. PLC 2 just literally throws you onto an island and expects you to build a boat with a paperclip and papers (paperclip and papers referring to the small basics I learned in PLC 1).

it would be nice to see a "in between" where I can do small programming problems before jumping into a full big one.
 
you are correct. I am NOT 100% understanding scan cycle. the PLC 1 mentions it briefly by simply saying something along the lines of "it'll read this instruction on the left, and if logic passes, do the output on the right before going to the next rung"

however, when the scan gets more complicated by adding rungs with branches using the same output bit on a previous rung, or if there are branches on the logic side of the program (left side) I get confused on why the right side doesnt/does get energized most times.

Can you post a screenshot of this, maybe we can help
 
back in Post #21, member Doug-P provided a link to a set of eleven YouTube videos ... have you watched these? ... most (if not all) of the "scan cycle" type questions that you've asked so far are answered in that series ...

if you're interested, be sure to watch all of the videos in NUMBER ORDER ... then if you have questions about anything that you see there, feel free to bring those up on the forum ... (note that each "slide" is numbered - so it shouldn't be too hard to ask specific questions) ...

from your Post #28 ...

you are correct. I am NOT 100% understanding scan cycle. the PLC 1 mentions it briefly by simply saying something along the lines of "it'll read this instruction on the left, and if logic passes, do the output on the right before going to the next rung"

one specific part of that statement that you're misunderstanding is the phrase "if logic passes" ... many people believe that if TRUE logic doesn't "pass" through the rung, then the instruction located at the end of the rung will be totally ignored (and so the instruction will do NOTHING) ... that belief is quite often INCORRECT ...

good luck with it ...
 
Last edited:
back in Post #21, member Doug-P provided a link to a set of eleven YouTube videos ... have you watched these? ... most (if not all) of the "scan cycle" type questions that you've asked so far are answered in that series ...

Definitely, watch these videos. I thought I knew several things that I now understand differently because of them.

Thanks for making them available Ron!
 
Way late into this, but if someone hasn't already suggested, you should learn some real programming languages for free online, learn more about what is happening inside the hardware, then go back to ladder logic and conquer it.
 
Learning the basics is like learning nouns, verbs, adjectives. You know what punctuation marks are and what they do. You know how to make a sentence. How do you take this knowledge and write a paragraph? How do you write an article? How do you write a book?

There’s a fair amount of information about PLC programming basics, be it books or courses. I would say 70-80% of the information out there cover the basics. There is information on intermediate and advance programming, heck I have a 900-page advanced PLC programming book. It’s sitting on my bookshelf collecting dust. I remember being so excited when I received it, now I’m going to really learn to program! I flipped through the chapters, read a little here and there, and put it on my bookshelf. It’s a good book, lots of information, it would have to be right? It’s 900-pages long! But it didn’t teach me to be a programmer or an advanced one at that. The book taught more about the basics, more in-depth information. The basics taught me how to write sentences, the advanced taught me how to write paragraphs, I wanted to write articles and books, best sellers even.:)

Over the years I’ve learned high-level languages as well, Basic, C++, Visual Basic, C#, Java, Python. I found the same patterns with the information that was available. 70-80% of the information cover the basics. They teach you about variables, conditional statements, loops, functions, classes. Intermediate and advance information teach you more about functions, classes, and go more in-depth with things like polymorphism and inheritance. I could write scripts, classes and such, but they didn’t teach me to be a programmer. How do I write a program, how do I become a programmer??? And then I started learning about design patterns, object oriented design, use cases, UML, refactoring. This wasn’t information in my intermediate or advanced books on C++ or Java. These were books that showed examples in a certain language, but they weren’t about the language, they were about the concepts. These concepts took me from being able to write sentences and paragraphs to being able to write articles and books. The more I learned about these concepts the more I realized I actually practice many of these concepts when I program PLCs.

So what? Can you get a book on Java Design Patterns and directly apply that information to PLC programming? Nope. But you might learn concepts that you can apply to PLC programming. There’s a lot more information out there about high-level program design than there is about PLC programming design. You can learn concepts that will help you to approach PLC programming in a different way. You won’t find these ‘concepts’ in PLC programming books, these are concepts that we (PLC programmers) have learned or figured out over time. That’s why you’ll often seen programmers tell beginners to “practice”. With practice you’ll learn to see these concepts on your own. But, if you have a basic overview of these concepts from a high-level language you might see the same type of concepts in PLC programming sooner.

How about an example? Refactoring is the process of taking existing code and altering it without changing its behavior. How does this apply to PLC programming? If I’m asked to write code for something I haven’t done before, I obtain the requirements and I just start writing the logic. Once the logic works as desired, then I refactor. I look at the logic and determine how can I make it do what it does but only better? Maybe the logic uses a counter, but I don’t need a counter I could use and increment statement instead. Maybe it’s hard to understand the logic I wrote, but if I change it around some it’ll be easier to understand for someone else (or myself in the future). Maybe I’ll change the structure of the data, where it’s stored in memory. All of this is called refactoring, a concept from high-level languages, that we use in PLC programming. Sure, maybe it’s just giving a name to something we already do. But giving the concept a name might make you more conscious of applying the concept. The concept is something you would figure out from “practice”.

How about another example. There is a high-level design pattern called the Observer pattern. Basically, it’s where one object tells another object to please inform me when you change your state. So, in a PC program you might have a button, and you have a class that does something when that button is pushed, so your class becomes an observer of the button. When the button is pressed, the button tells your class it’s been pressed and your class does what it needs to do. Can you directly apply the Observer pattern to a PLC program? Nahh, but the concept of observer can. I have a distributed radio network consisting of 40+ PLCs. Data must be exchanged between PLCs and also collected by the SCADA. One way to do this is to have a Master PLC that talks to every PLC. The Master PLC maps data from the PLCs and sends mapped data to the PLCs. So, if PLC-A needs to send data to PLC-B, the Master PLC collects the data from PLC-A and sends it to PLC-B. Hmm…I don’t like that idea because it creates a single point of failure. If the Master PLC goes down, all the PLCs are in the dark. There should be a better way, how about if I have the PLCs talk to one another directly, I’ve done that before, just have the PLCs communicate with one another using timers. Hmm…40+ PLCs talking to one another one a regular timed basis, creates a lot of traffic and a lot of unnecessary traffic because their states don’t change very often. That’s where the Observer pattern’s concept comes into play - “please inform me when you change your state”. I didn’t apply the Observer pattern to my PLC program, I applied its concept. I wrote a generic communication logic that is used by all the PLCs. The only thing different in all the PLCs is the IP addresses it must send data to, and what information determines that PLC’s state. So basically, the PLC sits there quietly until something changes its state, then it’ll send its new state to all the PLCs interested. There’s some handshaking going on as well, or ‘Hey, I’m still alive here’, stuff. But all in all, it’s a quite network that’s very responsive. Did I figure this out from just knowing the Observer pattern? Hard to say, I’ve known about other similar concepts like report by exception, time to live, and others. Point is, it didn’t come from any PLC programming book I read. I also used refactoring during the process as well, the production logic is much better than the logic I started with :)

What about just thinking in an object-oriented way? When I first started PLC programming I didn’t think in the terms of objects, I thought in terms of parts of objects. Say what? I thought in the terms of – this high-pressure switch needs to turn off this pump if it is on, so I would put that switch directly in the logic for that pump. It works, but maybe there’s a better way. Maybe I should think of the high-pressure switch as an object and the pump as another object. Maybe the pressure switch object should have a high-alarm bit and maybe the pump object should have a remote-shutdown bit. Now I can write my logic for my pressure switch object, some logic will determine that the pressure switch is in high-alarm, so it turns on its high-alarm bit. What does it do when it turns on its high-alarm bit? Nothing, the pressure switch object doesn’t care, it’s just saying if anyone is interested I’m in a high-alarm state. Now I write my pump object logic. Ok, we have an HOA, a request-to-run, and a remote-shutdown, now I can write my pump logic. But what tells it to run, what tells it to shutdown? It doesn’t matter right now, that comes later, I’m just writing the logic to run the pump. Ok, pump logic is done, HOA works with the request-to-run bit to turn on the pump and the remote-shutdown bit works to prevent the pump from running no matter what. Now I take this pump logic and copy it, because I have three pumps. Nowwww we take that high-alarm bit from the pressure switch object and tie it to the remote-shutdown bit for each of the pumps. But wait, the pump can’t run if there isn’t enough product in the tank that its sucking from, no problem I tie the tank object’s low-level alarm bit to each of the pumps' remote-shutdown bit. You knew there was a tank object right? Ok, what turns on the pumps, the tank its pumping too? Nope, the alternator object :) How many posts have been requests for help making pumps run based on this or that requirement? The logic for the pump objects are the same, it’s the alternator object’s logic that needs to change based on the requirements.

Ok, so what’s the real point? Don’t rely strictly on PLC programming information. Learn other concepts that you can apply to your PLC programs. PLC programming is more than just knowing the instructions, it’s about gathering requirements, use cases, patterns, structure, knowing the process, etc.

Here are some things to help you progress beyond the basics –
1. Learn about the PLC scan cycle.
2. Learn about high-level language. Python is probably the easiest to learn. Java and C# are similar to one another but are more structured.
3. Think in terms of objects, this helps break the program down into small parts.
4. Think about data structures, how you organize your data within your program, what is the data your objects require.
6. Know the process you’re programming for.
7. Think about your program’s structure. That’s one of the things that separates sentences and paragraphs from articles and books, structure.
8. Practice, practice, practice.
 
"The basics taught me how to write sentences, the advanced taught me how to write paragraphs, I wanted to write articles and books, best sellers even."

After that great answer, l think you have written a chapter or 2 for your best seller.
 
I personally have taken Paul Lynn's courses. His PLC3 courses on HMIs are awesome just as well. My advice? Don't give up. If you need, don't PLAY the video of his solution. Pause it and glance through it to get an idea. Most others have stated the basics. KISS principle. Break your code into sections. Etc. As a disclaimer though, Paul did say at the beginning that this course would be very frustrating as a beginner :p.
 
Learning the basics is like learning nouns, verbs, adjectives. You know what punctuation marks are and what they do. You know how to make a sentence. How do you take this knowledge and write a paragraph? How do you write an article? How do you write a book?

There’s a fair amount of information about PLC programming basics, be it books or courses. I would say 70-80% of the information out there cover the basics. There is information on intermediate and advance programming, heck I have a 900-page advanced PLC programming book. It’s sitting on my bookshelf collecting dust. I remember being so excited when I received it, now I’m going to really learn to program! I flipped through the chapters, read a little here and there, and put it on my bookshelf. It’s a good book, lots of information, it would have to be right? It’s 900-pages long! But it didn’t teach me to be a programmer or an advanced one at that. The book taught more about the basics, more in-depth information. The basics taught me how to write sentences, the advanced taught me how to write paragraphs, I wanted to write articles and books, best sellers even.:)

Over the years I’ve learned high-level languages as well, Basic, C++, Visual Basic, C#, Java, Python. I found the same patterns with the information that was available. 70-80% of the information cover the basics. They teach you about variables, conditional statements, loops, functions, classes. Intermediate and advance information teach you more about functions, classes, and go more in-depth with things like polymorphism and inheritance. I could write scripts, classes and such, but they didn’t teach me to be a programmer. How do I write a program, how do I become a programmer??? And then I started learning about design patterns, object oriented design, use cases, UML, refactoring. This wasn’t information in my intermediate or advanced books on C++ or Java. These were books that showed examples in a certain language, but they weren’t about the language, they were about the concepts. These concepts took me from being able to write sentences and paragraphs to being able to write articles and books. The more I learned about these concepts the more I realized I actually practice many of these concepts when I program PLCs.

So what? Can you get a book on Java Design Patterns and directly apply that information to PLC programming? Nope. But you might learn concepts that you can apply to PLC programming. There’s a lot more information out there about high-level program design than there is about PLC programming design. You can learn concepts that will help you to approach PLC programming in a different way. You won’t find these ‘concepts’ in PLC programming books, these are concepts that we (PLC programmers) have learned or figured out over time. That’s why you’ll often seen programmers tell beginners to “practice”. With practice you’ll learn to see these concepts on your own. But, if you have a basic overview of these concepts from a high-level language you might see the same type of concepts in PLC programming sooner.

How about an example? Refactoring is the process of taking existing code and altering it without changing its behavior. How does this apply to PLC programming? If I’m asked to write code for something I haven’t done before, I obtain the requirements and I just start writing the logic. Once the logic works as desired, then I refactor. I look at the logic and determine how can I make it do what it does but only better? Maybe the logic uses a counter, but I don’t need a counter I could use and increment statement instead. Maybe it’s hard to understand the logic I wrote, but if I change it around some it’ll be easier to understand for someone else (or myself in the future). Maybe I’ll change the structure of the data, where it’s stored in memory. All of this is called refactoring, a concept from high-level languages, that we use in PLC programming. Sure, maybe it’s just giving a name to something we already do. But giving the concept a name might make you more conscious of applying the concept. The concept is something you would figure out from “practice”.

How about another example. There is a high-level design pattern called the Observer pattern. Basically, it’s where one object tells another object to please inform me when you change your state. So, in a PC program you might have a button, and you have a class that does something when that button is pushed, so your class becomes an observer of the button. When the button is pressed, the button tells your class it’s been pressed and your class does what it needs to do. Can you directly apply the Observer pattern to a PLC program? Nahh, but the concept of observer can. I have a distributed radio network consisting of 40+ PLCs. Data must be exchanged between PLCs and also collected by the SCADA. One way to do this is to have a Master PLC that talks to every PLC. The Master PLC maps data from the PLCs and sends mapped data to the PLCs. So, if PLC-A needs to send data to PLC-B, the Master PLC collects the data from PLC-A and sends it to PLC-B. Hmm…I don’t like that idea because it creates a single point of failure. If the Master PLC goes down, all the PLCs are in the dark. There should be a better way, how about if I have the PLCs talk to one another directly, I’ve done that before, just have the PLCs communicate with one another using timers. Hmm…40+ PLCs talking to one another one a regular timed basis, creates a lot of traffic and a lot of unnecessary traffic because their states don’t change very often. That’s where the Observer pattern’s concept comes into play - “please inform me when you change your state”. I didn’t apply the Observer pattern to my PLC program, I applied its concept. I wrote a generic communication logic that is used by all the PLCs. The only thing different in all the PLCs is the IP addresses it must send data to, and what information determines that PLC’s state. So basically, the PLC sits there quietly until something changes its state, then it’ll send its new state to all the PLCs interested. There’s some handshaking going on as well, or ‘Hey, I’m still alive here’, stuff. But all in all, it’s a quite network that’s very responsive. Did I figure this out from just knowing the Observer pattern? Hard to say, I’ve known about other similar concepts like report by exception, time to live, and others. Point is, it didn’t come from any PLC programming book I read. I also used refactoring during the process as well, the production logic is much better than the logic I started with :)

What about just thinking in an object-oriented way? When I first started PLC programming I didn’t think in the terms of objects, I thought in terms of parts of objects. Say what? I thought in the terms of – this high-pressure switch needs to turn off this pump if it is on, so I would put that switch directly in the logic for that pump. It works, but maybe there’s a better way. Maybe I should think of the high-pressure switch as an object and the pump as another object. Maybe the pressure switch object should have a high-alarm bit and maybe the pump object should have a remote-shutdown bit. Now I can write my logic for my pressure switch object, some logic will determine that the pressure switch is in high-alarm, so it turns on its high-alarm bit. What does it do when it turns on its high-alarm bit? Nothing, the pressure switch object doesn’t care, it’s just saying if anyone is interested I’m in a high-alarm state. Now I write my pump object logic. Ok, we have an HOA, a request-to-run, and a remote-shutdown, now I can write my pump logic. But what tells it to run, what tells it to shutdown? It doesn’t matter right now, that comes later, I’m just writing the logic to run the pump. Ok, pump logic is done, HOA works with the request-to-run bit to turn on the pump and the remote-shutdown bit works to prevent the pump from running no matter what. Now I take this pump logic and copy it, because I have three pumps. Nowwww we take that high-alarm bit from the pressure switch object and tie it to the remote-shutdown bit for each of the pumps. But wait, the pump can’t run if there isn’t enough product in the tank that its sucking from, no problem I tie the tank object’s low-level alarm bit to each of the pumps' remote-shutdown bit. You knew there was a tank object right? Ok, what turns on the pumps, the tank its pumping too? Nope, the alternator object :) How many posts have been requests for help making pumps run based on this or that requirement? The logic for the pump objects are the same, it’s the alternator object’s logic that needs to change based on the requirements.

Ok, so what’s the real point? Don’t rely strictly on PLC programming information. Learn other concepts that you can apply to your PLC programs. PLC programming is more than just knowing the instructions, it’s about gathering requirements, use cases, patterns, structure, knowing the process, etc.

Here are some things to help you progress beyond the basics –
1. Learn about the PLC scan cycle.
2. Learn about high-level language. Python is probably the easiest to learn. Java and C# are similar to one another but are more structured.
3. Think in terms of objects, this helps break the program down into small parts.
4. Think about data structures, how you organize your data within your program, what is the data your objects require.
6. Know the process you’re programming for.
7. Think about your program’s structure. That’s one of the things that separates sentences and paragraphs from articles and books, structure.
8. Practice, practice, practice.

Well said, the paragraph analogy is a good one
 
Last edited:
Epy, which languages would you consider the top 3 to learn to support an understanding of ladder?

1. For ladder specifically: assembly language, so as to see ladder on bare hardware without the perks of ladder

2. C, for the future of PLC hardware/software, so as to see the basic operations of any kind of computer anywhere that have been standard since the 80s, that we don't $^#$ing have on PLCs still for some reason. o_O

3. Python, for the future of PLC hardware/software, so as to see what a few lines of concise brilliance can achieve in microseconds on the crappiest Android phone CPU.

Give me programmability or give me death.
 

Similar Topics

I am making massive headway into the PLC replacement i have mentioned in various threads, its all running and even the AB stepper drive was easy...
Replies
18
Views
8,505
Good Afternoon , It seems like we always have problems with using Type J Thermocouples with our slip rings . Would using a RTD at 10...
Replies
6
Views
1,622
I am beginner in B&R Automation Studio and TIA Portal. Have an experience in electrical part of PLC cabinets. Now its time to get a new skills...
Replies
8
Views
1,632
Bla Bla Bla, why doesn't it work, l need help and l don't understand PLC's. Or better they understand everything, but can't understand +1 -1 = 6...
Replies
22
Views
5,960
I rarely need to add a network card to the drives we install... very rarely. But my sales-guy said he needs to quote a network-connected ACH580...
Replies
6
Views
2,555
Back
Top Bottom