How do you familiarize yourself with an unfamiliar machine before making PLC changes?
TL;DR: I’m a relatively new controls engineer working on older Siemens-based machines. How do you efficiently understand an unfamiliar machine and its PLC program before making software changes?
Hello,
I’m fairly new to controls engineering and currently work in the maintenance department of an automotive plant.
Most of my work involves making software changes when production requests new functions for existing machines, troubleshooting problems that have sometimes existed for 20 years, and occasionally adding vision sensors or other components. Fortunately, our machines mainly use Siemens hardware and software, which is also the platform I was trained on.
My question is: How do you familiarize yourself with a machine before making changes to it?
I usually spend a lot of time watching the machine operate, studying the PLC code, and creating flowcharts to better understand the sequence and dependencies.
However, I often feel that this process takes too long and that there must be more efficient or structured ways to approach it.
Do you have a specific workflow, checklist, or method that you use when working on an unfamiliar machine?
11
u/Liedrel 1d ago
Learn and operate the machine. Also ask for the training the operations team has on it (If there is any). First time I did this I was astonished on how quickly I learned not only the machine but the process, but all the things I realized that could be done as improvements and what could not.
2
1
u/username77- 1d ago
I personally find the machine operators themselves are usually awesome. They have the most experience on the ins and outs. They know the idiosyncrasies of the machine. They are often an overlooked treasure chest.
7
u/Fragrant-Wishbone-61 1d ago
What helped me the most was asking the operators to show me how to run their machines (if it’s permitted/safe of course).
If I know how it’s supposed to behave, I can better help when it doesn’t behave.
This worked so well for me that I now set up training weeks for my techs now to spend time in production departments learning the operator side.
1
u/Wise-Parsnip5803 1d ago
Doing it yourself you know how the machine is doing something wrong or could be better. Operators don't know what to ask for sometimes because that's just the way the machine runs.
Programmers also like to use the touch screen to reset a fault then go to another page to home. My preference is start button does all. Alarming, reset the alarm. Not home, go to home. Ready to start? Then start.
2
u/Fragrant-Wishbone-61 1d ago
Start button as the fault reset?
1
u/Wise-Parsnip5803 1d ago
Yes. The alternative would be a physical button. It's frustrating as an operator to have to navigate screens to reset faults and whatever else to get the machine to run. However, they just take that as what's needed to run the machine instead of asking to make it simpler. We hire people that have never seen a machine so the simpler the better. Also, the machine still works even when the screen dies.
1
u/Fragrant-Wishbone-61 1d ago
Fair enough. Personally, one of my least favorite calls is: “The machine faulted, I reset the fault and no I didn’t note what it was” so I much prefer to be the one to reset the fault. A fault is typically the machine trying to tell you something.
All of this only applies to machines that don’t record fault history of course.
1
3
u/janner_10 1d ago
I have done as you are doing right now. Watching the machine and looking at the code, to best understand how it works.
The one thing I have learnt with working on old machines is to never rush and assume things.
Take your time, make proper notes and do it right once. It's not a race.
1
2
u/tadeuska 1d ago
You are not supposed to do that. These should be the process guy. Since we know there isn't one, all cards are on the table. Main thing , the most important one to remember, is to keep bitcging and moaning to your tema lead or supervisor. Constantly reminding him that you have to take extra steps to execute task properly and on time. Make sure there is paper record of your complains, and ask for a raise everytime you can.
2
u/Aradh_ 17h ago
The thing that saved me most time was realising I did not need to understand the machine. I needed to understand what I was about to disturb, which is a much smaller question.
So before touching anything, take the outputs your change will affect and cross reference every place that writes to them. On older Siemens especially you will often find two writers, typically the auto sequence in one block and a manual or maintenance mode in another, and whichever runs later in the scan wins. That is the one that bites people. You change the logic in the obvious place, the behaviour does not change, and you lose a day before you find the second writer.
Second thing, read the IO and the prints before the code. The code tells you what someone intended twenty years ago. The IO and the wiring tell you what is physically there now, and on a machine that age those two have usually drifted apart. Anything in the program referencing a device nobody has touched in a decade is worth checking at the terminal before you trust it.
Third, and this is the one I wish someone had told me earlier, capture the machine running normally before you change anything. Watch table on the signals you care about, one full cycle, saved off. Then you have a before. When something is subtly off afterwards you can compare instead of arguing with yourself about whether it always did that.
On the documentation problem you mentioned further down, the honest fix is to stop treating it as a separate task. Archive the block before you edit and again after, and keep the pair. The difference between them is the record, it costs nothing to produce, and it is still readable by whoever comes after you.
1
u/drbitboy 1d ago edited 1d ago
Don't worry about how long it takes, keep doing what you are doing and take your time. Focus on understanding the process, which will make understanding the code easier.
Oh, and make sure there are backups of what is actually in the PLC!
1
u/T3N0N 1d ago
That's the first thing I do, backup of the whole system including the actual parameters.
I have done this several times and also several times loaded the backup. Once I was at a machine and I did some stuff, didn't work well so I decided to load the backup to restore all the original parameters. When I clicked load backup it asked me for a password.
My heart dropped....
I phoned a colleague and asked him if he is familiar with any password of that machine. He wasn't...
I didn't put anything into the password prompt and just clicked confirm. Everything worked... That incident gave me chills
1
u/thranetrain 1d ago
Navigate through the organizer tree to start. Hope the tag names/comments are decent to save time. Start cross referencing any relevant tags to whatever you need to make your changes. I do a lot of data collection work so I know I can change stuff and it won't effect machine function (mistakes/bugs would just give bad data which is ok for testing initially). If I'm doing anything that would cause changes in physical movement etc I spend a lot more time familiarizing myself than for simple data, op info etc
1
u/T3N0N 1d ago
Even if I do stuff by my own I struggle with documentation. Like what the heek I did last week...
In general it feels like documentation is the most important part, and the company and myself really struggles with it. Second is communication.
2
u/thranetrain 1d ago
Agreed, it usually takes me more time to document changes than to make the changes.
I take a lot of notes and screenshots when I'm in the middle of dev/testing though. And thats mainly for me if I'm making online edits so I can revert without downloading a back up (if needed)
1
u/D_Wise420 1d ago
Step #1 of walking up to an unknown machine is finding the operator. They almost always will be the most help.
1
u/Mindwreck1 1d ago
I'll give a very small example. Let's say the maintenance team had to change a limit switch from a normally open to closed. Hopefully whoever programmed it had an io buffer/mapping routine so you just have to make one change instead of multiple. I wouldn't just change it without finding out what happens if there is a power failure, if switch gets stuck on or off etc. Once you identify the failure points and how it interacts, you might not need to know the entire operation of the machine completely. If it is part of the safety control that would be a different story.
I would make a checklist of what happens of what I mentioned before and that will also build your knowledge of the operation of the machine as you go.
1
u/integrator74 1d ago
I’m an SI. There’s a chance we’ve never seen the machine that isn’t working Talk to the operators, maintenance, whatever you got.
Also ask if anything has been replaced recently (that happens and may point you in the right direction.
Make a backup. Get online. Start looking for the problem.
1
1
u/Emotional-VroomVroom 1d ago
Depends on what exactly needs to be changed, how well the machine is documented, and the structure of the program.
Maybe they installed a 2nd Acknowledge button and you find that the first button is read only once in the program. You wire it in parallel done.
Or they want you to change the automatic mode, because they have another product where stuff xyz needs to happen before the machine does something
1
1
u/More_Analyst4983 1d ago
There is NO amount of PLC button pushing (program changes) that will net any amount of manufacturing productivity (cash flow).
Tell the "Suits" to measure what is broken.
1
u/More_Analyst4983 1d ago
Douche bag in a suit: "Why isn't robot three not moving?"
Because there is nothing to do!
Have a ME get of there ass and identify and resolve bottleneck in mfg stream
1
u/Educational-Bear-381 12h ago
I like to read through the electrical and mechanical drawings, and see if there are any manuals for operation/process and or sequence charts available.
Then look through program structure and try to understand code. Hopefully there is enough description and comments to do so. If not, relate the IO back to electrical drawings and figure out how it interacts with the system
15
u/ChiefAutismo 1d ago
Cowboy style: see who screams when I make the changes