How do you write a PLC program?
How do they know what to code, and when and where to do it in a program and how can they remember so many different algorithms?
Inside the Mind of a Professional Programmer
If you’re working hard to become a programmer you’re probably like every other newbie. You’re probably looking at programming through a narrow prism. Instead let’s look over the shoulder of a professional programmer and discover exactly how they create their magic.
If you’re learning to write ladder logic in a PLC you’re likely focusing only on learning a new instruction or to get a couple of outputs to twinkle green at you.
While that is important, it’s also important to step back from the in-depth studying you’re doing now and start taking a look at the big picture.
Just so you know, it’s this big picture that separates the pros from the newbies.
To get some insight as to how a pro writes a program, let’s peek inside a pros notebook to understand how they think.
Let’s say a senior engineer went to a meeting and was informed that a machine he’s working on needs to have a part sensor added.
Well, that’s pretty easy, you might think
So, the pro PLC programmer makes a note in his notebook to add a sensor to a machine to detect a part before the machine cycles. Ok, then, easy enough.
Now let’s say he is making notes so a junior engineer can tackle this task with no errors. To begin with he makes a few additional notes, because he wants to remind the junior engineer of the steps involved with this simple task.
After he notes the brand and model of the sensor he wants him to use. He also makes some shorthand notes of a few other items as well:
- Wire in Sensor – brown is power, use black for your signal, it’s a 24VDC circuit
- Add Input to the PLC program – use the next sequential address for inputs.
- Add in sensor & backcheck status
- Add in a multi-indicator on the HMI – grey – deenergized/green – energized
- Add in bypass button on HMI & bypass active bit (pilot light)
- Add in bypass in bypass routine
- Add in HMI process messaging – part missing & part never cleared
- Add in HMI faults messaging
- Add to the proper HMI nest group – (let’s assume there are 2 parts nests in our project)
- Add the sensor to the faults routine – trigger to remind the operator to remove parts from nest, for missing & parts never cleared after the last cycle
- Update the PLC program file – add the file to the network or backup PC drive
- AutoCAD – add the sensor to the inputs page and add a description
- Test HMI messaging
- Test your code – test the manual bypass, bypass code, indicator lights and test your program in auto cycle.
- Test – that the faults trigger when the part is missing and when it hasn’t cleared the nest before the next cycle.
Wow, you might be saying.
That’s a lot to do just to add a sensor.
Well, let’s, think about this from a high-level perspective.
While a beginner is only focused on adding an input for the sensor, and an output for an indicator light.
A pro thinks about the entire process, every condition that could arise where that sensor could be used. In the manual mode, in auto mode, before the cycle, during the cycle and after the cycle.
He thinks about the need to prompt the operator with process and fault messaging. He’s thinking about being able to monitor the sensor throughout the program and during the cycle as well with status bits.
If you think about it, all he’s asking the junior engineer to do is to have a physical sensor added. Then to add in a bypass option, then to add in the faults for those times when the sensor doesn’t see the part when the autocycle start buttons are pushed and if the sensor hasn’t cleared before re-pushing the autocycle start buttons again to start the next cycle.
He’s also asking to add an indicator light added to the HMI, to visually identify the sensor and then to have the indicator added to the proper nest group.
Next, he’s asking, to have the AutoCAD print updated, so that anyone who needs them like electricians, customers and fellow engineers they would have the most current updates. Next he’s asking to have the network updated (most companies setu-p a network dive, or file to store master PLC programs in) with the new PLC program and he wants to ensure the junior engineer’s updates his work.
Now, take a minute to think through his logic. It’s simple to follow. Even if you’re not sure exactly how to write the code yet, can you see the logic, the big picture of his thinking?
All he’s doing is asking to add a sensor to a PLC program, then add in the status, backchecks, pushbuttons, push buttons active bits, parts missing, parts never cleared, faults, and messaging. Then TEST, TEST and TEST the updates…
Actually, if you use this procedure every time your programming (and or build your own procedure based on likely conditions) then you’re starting to program a PLC program like a pro.
Let me know what you think or if you have any questions.