Let me start by saying congrats on completing you first program. I’m assuming this thread is about the conveyor you posted about in the My first PLC project finished! thread.
The way I would have tackled the program will take more lines of code than the 5 you are showing. Your code does take a part placed on the conveyor and moves it to the first open spot on the conveyor. But in watching the YouTube video you posted I see some problems. As you are eluding to in this post, the part movement is inefficient. With your code the part stops at each conveyor or what I would call a station before it moves to the next station even though there is no part at the next station. What I think you’re looking to accomplish is when the conveyor is empty and you place a part on it, the part should be moved to the front of the conveyor without stopping. There are some other issues as well, what happens if a motor fails to run (tripped overload), what happens if a part is taken off the conveyor, what happens if a motor is running but a part doesn’t move? What if the conveyor had 6 stations instead of the 3? If you start adding to your program to account for these what if’s, you might end up with a mess. The issue I see is that your program isn’t broken down into logical blocks, it lacks structure or architecture.
First, I would change your naming convention. The entire piece of equipment is the ‘conveyor’, so I wouldn’t have named the parts of the ‘conveyor’ (like the motors and sensors) conveyor[1], conveyor[2], conveyor[3]. This causes some confusion, does this program run more than one ‘conveyor’? Your comment for rung 4 denotes a better name for these parts of the ‘conveyor’, that being Section. Personally I would call these parts of the ‘conveyor’ Station1, Station2, Station3, but even Section1, Section2, and Section3 is better name than conveyor[1], conveyor[2], and conveyor[3], plus it’s easier to read. You might also consider using Camel Case when naming your symbols, some designers limit the amount of characters you can use for a name and using Camel Case will allow you to get rid of the dashes and still allow your names to be readable, i.e. Station1MotorControl. Also, don’t put the word ‘bit’ in your names (line_2_running_bit), we already know it’s a bit
. When you name symbols, determine if the symbol is a command or status and name it accordingly. I’m thinking Line2Running is a command, so it should be called Line2Run. Your Motor_control would be called Run because it’s a command, a signal back from the motor would be called Running. You have a Start_sensor and Stop_sensor, but is that what they really are? Are they the InfeedSensor and OutfeedSensor? Your Start_timer, we already know it’s a timer, what’s its purpose? Would a better name be StartDelay or RunDelay?
Order of the logic. When I look at the five rungs you posted I see one thing common between all of them, that being line_2_running_bit. But where that bit is placed on each of the rungs it’s hard to see that it is common. If you place the line_2_running_bit bit (that sounds redundant now doesn’t it
) first in the five rungs it makes it easier to see why an entire section of code isn’t running. This will make it easier to troubleshoot.
For the logical blocks, the program structure, I would have done this. There is a Conveyor object and Station objects. The Conveyor object controls the state of the conveyor. It knows the push-button states, controls the indicators, e-stop logic is probably done there as well. It determines if the conveyor should run or not. The Conveyor object tells the Station objects to run. The Station objects tell the Conveyor object if they are in alarm. The Station objects convey information to one another, am I Ok, can I receive a part, am I sending a part. The code for Station 1, 2, and 3 is the same except for mapping of information between the stations, this gives you code reuse. How a station determines how they run their motor, whether there is a part present or not, doesn’t matter to the other stations. The other stations only care about, can I send you a part, are you Ok, and here comes a part. So the logic for Station1 shouldn’t have Station2’s senor or motor status in it, it should only have Station2’s StatusOk and InfeedAvailable status in it. Coding to logical blocks lets you focus on smaller pieces for the program instead of the entire program at once. Notice your original post is concerned with how to control all three motors. What you need to think about is how to control each individual motor. A Station is only concerned with the station before it and after it. So in actuality you only need to think about how to control and individual station. From there you organize your data into logical blocks of memory, so you might use one word for the status of the station and another word for the alarms of the station.