ganutenator
Lifetime Supporting Member
post a rung of logic that you are having trouble w/ and we will try and help.
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.
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.
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"
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 ...
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.
Epy, which languages would you consider the top 3 to learn to support an understanding of ladder?