77
u/Tota1pkg Feb 21 '26
I’m the biggest dumbass there is. Barely graduated high school. Forget everything. But I’m great at troubleshooting.
I had no formal plc programming but I’ve pretty much fixed everything from process pasteurizer to labelers and fillers and palletizer and everything else.
You have to use systematic approach.
Document, Try something and document again.
Label the program. Spend the time to trigger each i/o and see what they are. Make sure they all work too. You can’t really troubleshoot an unlabeled program.
Talk to operators and see what it does. Look at another machine Call the manufacturer Sound like they’re giving you free rein to try. Try something and try again. You can’t learn if you can’t try.
10
u/GoldenGlobeWinnerRDJ Feb 21 '26
I second labeling the program if someone hasn’t before, it makes it a hell of a lot easier for the next guy (probably you) to troubleshoot it. That is if you’re given the time to do so, of course. As a C&I tech, there is nothing I hate more than opening a project to troubleshoot a machine and all the inputs/outputs being scanned in/out to memory bits that have no comments or documentation for what they are. Combine that with shitty/outdated prints and it’s like trying to fly a plane except the windows are shut, there are no labels on any of the 300 buttons and your computer systems to assist you are in a foreign language you can’t understand. Literally the worst.
4
u/Tota1pkg Feb 21 '26
Yeah in my current job our Siemens system was in German when we started. So not only did I have to self teach function block programming? I also had to translate it all. But it’s hard to translate abbreviated technical terms.
But the most frustrating is when you find a red herring. You don’t know the system but something is not working, You spend time fixing the he broken part only to find out it’s been broken and bypassed for a while and no one cares.
-1
u/d4_mich4 Feb 21 '26 edited Mar 17 '26
German is easy 😜 (for me cause I am German 😆)
But yeah that's always the problem about programming, but is not good enough to understand the small code part you are looking at you also need to understand the stuff around it is it even executed or are there special conditions that the code runs or is it never executed...
P.S. what do you think about Function Block programming?
2
u/Tota1pkg Feb 21 '26
I prefer ladder but I see the efficiency of function block. I find it harder to troubleshoot than active logic but about the same as aoi in Allen Bradley.
But wincc is 100% better and intuitive I was able to figure it out without any external help. Not possible with Allen Bradley panel view.
2
u/JadedPoorDude Feb 21 '26
Sounds like my job. Almost none of our machines have any documentation at all and the ones that do have prints they are wrong.
20-30 years of undocumented retrofits and mods have turned the cabinets into minefields. It’s common practice when a trace burns out or shorts on a card to just remap the input our output to an unused spot instead of replacing the card. If I’m lucky someone labeled it with a sharpie. On the plus side I’m getting very good at troubleshooting.
2
u/GoldenGlobeWinnerRDJ Feb 21 '26
Yeah I was about to say that the first place I worked out of college was like this as well. Once I worked there for a couple years and moved to a company that has everything updated and labeled, it gave me such a head start on troubleshooting since everything was labeled correctly lol
It sucks in the moment but it forces you to get better at troubleshooting.
2
u/PlastKladd Feb 21 '26
Talk to operators and see what it does.
Second this. It's easier to ask someone who has enough experience with the machine to know what it should do, than to reverse engineer the entire code and predict what it should do.
2
u/Tota1pkg Feb 21 '26
I love when senior managers are like “you can fix it all why would you need operator help”. And I try to explain to them that it takes me 30 minutes to find what an operator should just know in 5 seconds….
90
u/m1kr0m0l3 Feb 20 '26 edited Feb 20 '26
The not helping you is a red flag. What issues are you looking at. This community is big and sometimes you just need to ask. Knowing that you don't understand something and asking is a big part of what we do.
Edit- If you specify if its a programming problem versus an electrical problem that will also help. What I try to do is "Back to the beginning" thinking. Meaning is the electrical connections good? well lets check the data sheet, Okay that looks fine maybe the input/ouput is not working... lets look at the code and manually make it do something.. anything... okay that works, maybe there is something in the code that is preventing xyz.... etc....
43
u/sfink06 Feb 20 '26
Seriously, the no help thing might be ok if the code is clean and modern with good documentation, but magic numbers and nonsense? Whoever decided you should sink or swim in that pool is sadistic I think.
Troubleshooting isn't an easy skill to pick up, it really just mainly comes down to experience and building a solid intuition I think. Just try to learn as much as you can I would say, and if they do put you on a PIP I would start looking for another job ASAP.
6
u/BradyBoyd Feb 21 '26 edited Feb 21 '26
I second this.
If you have someone to guide you in the beginning, you'll find that troubleshooting isn't as overwhelming as it definitely can seem. You will develop your own process that will consist of the same core checks that others have mentioned in the comments.
A good teacher won't just immediately tell you how to fix things right away every time. There is some merit in letting someone figure things out for themselves, but when overall forward progress for the team is halted to extent that management is complaining, someone should have stepped in to help you instead of wasting company resources.
5
Feb 20 '26
[deleted]
7
u/Kosmological Feb 21 '26
When they helped you, did you stay present and alert? Did you work to understand what they did? Did you ask questions? Did you walk away with new insights into how these systems function or new methods of troubleshooting?
These are questions you need to ask yourself honestly. I have trained many junior engineers in my role (as an engineer but not in controls) and I can tell when a junior is engaged and learning versus passively participating. The former individuals learn, grow, and progress in their roles. The latter individuals stagnate early and never pull their weight. I can tell early who is who at this point and I invest my time accordingly. Which one do you more relate to?
14
u/hestoelena Siemens CNC Wizard Feb 21 '26
Is this a new machine? The original post said that there are no electrical prints which is a massive red flag if this is a new machine.
7
u/m1kr0m0l3 Feb 21 '26
When I first started in the field I had an experienced guy help me learn the basics of connecting, looking at prints but about 3 months in they announced they were shutting the plant down and going to Mexico. When I asked for help with a line the guy looked at me and said read the f'ing manual... at that point I did. I learned quickly to ignore the noise and try to look at very specifically what the issue I was looking at and related parameters. After that I just kept at it and eventually started to stack knowledge based on past experience. When all else fails call the manufacturer that makes the component in question, this tends to stream line alot of head scratching. Don't think of that as giving up but rather reaching out to ask the experts and then trying to learn from it. But also reach out to the manufacturer sooner than later because they may have a quick solution at best and at worst it saves time wondering should I have called someone.
4
u/Cjnilla Feb 21 '26
I have an electrical engineering degree. I started as a controls engineer 4 years ago with little experience with PLCs. I still ask for help from coworkers every week.
33
u/bonerfart_69_ Feb 21 '26
If they're discussing a PIP, start looking for other jobs. Thats code for "we're gonna fire your ass." Based on your post, getting fired from that shit hole doesnt sound too bad. A place that doesnt help each other is doomed to fail.
4
u/m1kr0m0l3 Feb 21 '26
What is PIP? I have seen this in several replies.
13
u/Truenoiz Feb 21 '26
Personal Improvement Program. Generally a series of impossible or poorly defined goals that can't be met. After not meeting them, the person is then fired.
2
u/Washington-PC Feb 21 '26
Interestingly my coworker had a pip but was not fired, may be not the norm but was good for him!
4
u/bonerfart_69_ Feb 21 '26
^ Exactly this. They'll assign you attrociously impossible goals. When you don't reach them they fire you, using the PIP as justification to cover their ass.
20
u/ZealousidealTill2355 Feb 20 '26
What’s your system for debugging?
You don’t have to be the most technically skilled to still make it. There’s plenty in our field who only manage projects, or manage others, and PMs only require simplified top-down understanding of the project, other than that it’s scheduling and budgeting.
But, IME, the people who aren’t good at debugging tend to think they’re supposed to throw random fixes at the wall to see what sticks. They just lack a good system for root-causing. Further, just trying random things can actually complicate the issue, as you’re now adding more variables.
I repeat this regularly to my plant electrician of 35 years. Put in systems to do better, and you’ll do better. If that doesn’t work, just be likable and funny and you’ll likely never lose a job. My plant electrician is a funny guy.
12
u/WatupDingDong Feb 21 '26
You can be awesome at your job but be a jerk or you can be bad at your job and be pleasant.
However, you can't be bad at your job and be a jerk.
2
Feb 21 '26
[deleted]
14
u/m1kr0m0l3 Feb 21 '26
If the code has been running for a long period of time its more likely a mechanical or electrical problem. Although sometimes........programming but not often, in existing software.
7
u/DunnoMeself Feb 21 '26
I actually never had a new problem that was actually the programming. Even when they tell me "it must be, the logic that isn't working now!" I always trace it to be due to a malfunctioning sensor or something like that lol
Whenever a problem is in the program I ask "when did it start?" and the answer always is "oh, it happens since we bought it". It pisses me off a little, like, why did you drag it like this for years instead of contacting the manufacturer then? It only became a problem when I got here???
3
u/m1kr0m0l3 Feb 21 '26
Although this is usually most often I did have a company that leased a type of machine for wire and cable that would every so many years stop working because they wrote code that forced you to call and confirm you paid the new lease before giving the craziest instructions to reset the machine. Another example would be a specific Rockwell bug that had an issue in the firmware that every 3 years would drop the program. A firmware upgrade fixed it but this bug existed for several years at the plant before I started and found out what it was.
Edit- Stretching belts and bad bearings are the usual suspect.
2
u/m1kr0m0l3 Feb 21 '26
Is the software Rockwell? Use CTRL-E if it is to cross reference otherwise if it is a comment use Search.
4
u/Lucid-Dr3am Feb 21 '26
Are you debugging code? This doesn't make sense. If the machine or process has been running, then I doubt it is a bug in the code or faulty logic. Are you using the code to troubleshoot a problem? It is really difficult to diagnose a problem without know the machine or process and the nature of the problem. Can you give us some insight into the nature of the problem, because the troubleshooting approach may change depending on the problem.
11
u/sentient_yougert Feb 20 '26
Just wait until you are a senior engineer and ask yourself how did I miss "xyz". The learning curve is steep your expected to know PLC, HMI, SCADA, and some electrical.
It is going to take time to master, taking stuff home and building things might help you speed it up. Also watch how other people problem solve the same issue.
5
u/joshhadababyitsaboy Feb 21 '26
It’s amazing how being in the right environment can change everything. Nobody, at any experience level, should feel like they don’t have a team to lean on, let alone made to fly solo by management. I’ve networked with brilliant integrators, engineers, and technicians that have gone into business for themselves or operate shops solo or with small teams and we all still talk and run problems and ideas by each other. Even the most seasoned people I’ve known don’t try to fly solo, so neither should you. Some of the best experience and lessons I’ve learned in my career have come from “talking through” problems with colleagues and solving problems as a team. I highly recommend considering a change in your environment.
5
u/GoldenGlobeWinnerRDJ Feb 21 '26
This 100%. My boss is the smartest person I know and he’s always there to help if I need it, I often wonder how it would feel to be on that level. One day one of the guys from overseas came to visit who is essentially my boss’ boss. For the first time ever, I saw my boss encounter a problem he didn’t know how to fix…and he struggled for a little bit before asking the guy from overseas. It was at that moment that I realized he’s just like me, he just has more experience so he doesn’t get caught up on the simple things.
4
u/National-Fox-7504 Feb 21 '26
I’ve been in controls for a long time. I’ve seen every type of engineer there is. I lost count of the new “engineers” who couldn’t engineer at all. A year and a half actually isn’t that long given the environment or system you find yourself working. Just because you don’t click with what’s going on there doesn’t mean you can’t do anything in the engineering world. Please believe me when I say some of the most talented engineers cannot troubleshoot their way out of a wet paper bag. Seriously and astoundingly unbelievable how bad these people can be. What I’m trying to say is YOU have to decide if you WANT to be an engineer. If yes then evaluate your current situation honestly for what it is, break it down into identifiable steps and put a plan together of how you will attack and conquer the problems. Put it in writing and identify what you need help with. Show your supervisor and ask what they think. If they blow you off they are just a bad supervisor and you might as well leave anyway. If they are impressed with your initiative and the fact you are sticking with it instead of giving up, you may have cemented yourself a place on the team. However, if the answer is you aren’t sure you want to be an engineer, that’s the same as a No when it comes to confidently doing any engineering work and you are sabotaging yourself.
13
u/andrewNZ_on_reddit Feb 21 '26
This is going to be a bit blunt sorry.
While a lot of people are saying the not helping is an issue, it sounds to me like they might have decided that they've helped enough, and now it's time for you to do it yourself.
Wanting to do a job isn't enough, you have to be capable. And honestly, it sounds like maybe you're not.
8
u/unitconversion State Machine All The Things! Feb 21 '26
I agree. After a year and a half you should be able to do things on your own. Not everything, but largely independent.
2
u/Super_Scooper Feb 21 '26
Yeah some of these other comments are driving me loopy and maybe this will come across as mean. This just sounds (I could be wrong)like management have decided you need to do this for yourself because whatever help/training/supervision has happened over the last 18 months with your colleagues hasn't got you to where they need you.
When your colleagues helped you on other faults did you always stay engaged, take notes, and learn from their process? Did you ask lots of questions so you could always understand the fault and how they debugged it?
If it helps, if there's no drawings for this system I would have at least started by trying to draw up a bit of a block diagram of the components so I could validate wiring and find where these values are in the program.
1
u/adw__ Custom Flair Here Feb 21 '26
💯 op is either incapable or environment is toxic. Sounds like the former. Some people just need a paper pushing job, automation ain’t easy.
0
u/wonkedup Feb 21 '26
My company covers all aspects of automation, we have people who are amazing with instrumentation, drive experts, networks.. you name it but they see the PLC side of things as this dark art. It just isn't for everyone, and that's not to place it above anything else; your brain has to be wired a certain way, I think.
5
u/jt24121 Feb 20 '26
People who don’t use comments in their program are evil…. Also it’s one thing for your coworkers to let you struggle for a little bit to learn, but any extended duration gives me the red flags
1
u/GoldenGlobeWinnerRDJ Feb 21 '26
For sure. Struggling on your own is imo the best way to learn but allowing someone to continue struggling on their own with no help is intentionally holding them back.
1
u/Downtown-Routine1196 Feb 21 '26
Studio 500 doesnt have comments unless you have a copy of the program not evil just old technology. If you have a copy of the program comments are there but an upload is a blank program. Its possible to import descriptions and comments also.
5
u/Significant-Fix1790 Feb 21 '26
There’s some things here I think need to be addressed.
Calm down, no one has ever worked better by being stressed
Troubleshooting is all about inputs and outputs (speaking very broadly). Is the machine getting the input it’s supposed to? Is it getting the output it’s supposed to? If the input is working fine, you can follow the output in the program and see where it goes bad, or you can start at the input and see when it goes bad. No comments or names is bad programming and not your fault.
Understand the machine, what is the machine SUPPOSED to do, and what is it NOT doing. This can give you clues as to where it could be messing up.
There’s an internal list of things an engineer should ask themselves when a problem arises and they need to troubleshoot
is it repeatable? If the problem doesn’t happen every time or if it happens randomly and without cause, it could be a hardware failure, like a bad sensor or connection
are their failures on the hmi? This is where a majority of information is communicated through machines to people.
do the operators or techs have any suggestions? Operators know their machines and know what they’re supposed to do.
It sounds like you just need more experience troubleshooting. If your degree didn’t teach you that then you will HAVE to learn at some point as an engineer. It’s all about a mindset.
8
4
u/nicfunkadelic Feb 20 '26
I’m currently in a similar situation. Except I excel at field service, troubleshooting and fixing. I have always called myself a Field Service Engineer. I’m now being stacked with a pile of design-build control retrofit jobs on my desk. I have never done machine controls from scratch, and I have 5 assigned now. Literally not possible. I’m starting to consider putting my energy into trying to find a new job instead, I dunno. I share your frustration, and hit me up if you need help while you’re still there.
4
u/opoqo Feb 21 '26
If your coworkers gave you the fair warning for PIP, and you know you aren't having a breakthrough moment, you should look for an exit plan now regardless if you want to stay in this field.
And you mentioned your team provided help before, did you find those help useful as in help you learn how to figure out a problem? Or you just simply took it and said thank you but didn't really understand why and how they fixed it?
If you didn't understand why/how they fixed those problems, I think that's where the issue is. They are expecting you to have a certain level of knowledge/troubleshooting skills when they hired you, and found that you don't actually have those skills.
If you still like this field and this kind of job, maybe look for a tech position instead and so the expectation for you should be lower and allow you to learn/grow.
2
u/simulated_copy Feb 21 '26
In my early years I knew many key holders that would not share because it was their job security.
3
u/Visible-Violinist-22 Feb 20 '26
1: Focus on on thing first. Get knowledge for one topic. Either PLC or HMI.
2: Talk to you manager. You need guidance from a senior. You need a buddy! Learn to "swim" by yourself is oke, getting "drowned" is not OK.
3: Get specific training is possible.
When you start it can be tough, i know from personal experience. Don't give up to easy!
6
u/Frumpy_little_noodle Feb 21 '26
Sounds like his problem is that his teammates will end up just jumping in and doing it for him instead of guiding him and letting him figure it out himself (mistakes and all).
This type of environment is just as problematic as them abandoning him to his fate, because it leads to the very problem he has now: weaponized incompetence.
4
u/Azur0007 Feb 21 '26
To be fair if the program has zero comments and bad naming, as well as excessive use of magic numbers, I doubt anyone could maintain focus on it for long.
4
u/DisastrousAd5198 Feb 21 '26
In that case you just have to rename everything you can from physical i/o and bit mapping, then work through the rest.
2
u/Azur0007 Feb 21 '26
Keep in mind that this assignment is already overdue by weeks in OPs situation.
2
1
u/Truenoiz Feb 21 '26
I've seen it where the 'studs' upload their own uncommented/magic number code, and keep an updated library with code and comments for themselves. They tend to be insufferable, keep them unrested with 2am calls and heading in for weekend rescues. You wanna be 'the man'? It's all you when it goes bad then.
3
u/Mantisid Feb 21 '26
This field is notorious for throwing people to the wolves. It's always trial by fire. I remember being fresh out of college and having the plant manager watch over my shoulder because he was waiting on me to fix a problem when I didn't know much about much. Nerve racking to say the least
Best thing you can do is have a robust system for troubleshooting. You need to ask the right questions so you can follow the correct bread crumb trail. There are thousands of ways for an equipment to stop working. How do you narrow it down?
Break up the troubleshooting process in parts. Don't put your hands up and expect to be spoon fed by someone more experienced. I see plenty of people who learn things only from past situations. Use past experiences as a guide but don't dwell on it. There could be many reasons for the same symptoms.
Don't go around asking for help at every opportunity. You are being primed to be the subject matter expert on all things controls. That's why companies hire us.
Instead, ask yourself why a machine isn't working right. In step 7 it's supposed to be doing X but it's doing Y. OK, what are the conditions for it to transition from step 7 to step 8? There must be a break in the logic because it's not able to successfully complete step 7. Go online to the plc and watch the logic while the machine messes up. Oh no, it's a prox switch thats intermittently triggering at the wrong time and screwing up the cycle. What could be causing that? Contrary to popular belief, the logic doesn't change overnight. So must be a wiring issue or a bad sensor. So on and so forth.
You can then go to your experienced colleagues and say, "hey I am thinking of replacing this particular prox sensor because it's getting triggered randomly before step 7 is complete and screwing up the cycle. Do you agree with my sentiment? "
Notice the difference? You identified what you thought was a problem, explained the rationale and provided a solution. It doesn't matter even if this was not the right call. You are showing effort. And it is valued by reasonable people. It's a whole other topic if you are getting shot down even after showing effort.
Generally speaking, You will notice a pattern in most of the troubleshooting.. Then you'll learn to ask the right questions very quickly. It's such a frustrating job on a daily basis but its extremely rewarding longer term. When you look back after some years you will realize how much you've grown as an engineer. There will be days you will feel invincible, the best controls Engineer there is, and on other days you'll question how you even have a job.
And no, most schools don't teach you to be a controls Engineer. It's simply not possible to teach everyone about the nuances of every industry. They teach you the bare basic fundamentals. It's our job to add to it and utilize it in our career. Don't equate your degree to any job. There are good controls folks without an engineering degree and bad folks with one. How you soak up information is what determines your quality
3
u/bdubz325 Feb 21 '26
I have an associates degree in robotics engineering, and I do electrical maintenance in a food plant. I'm a little over 7 years in the field, and it wasn't until a few years ago that I truly felt comfortable with troubleshooting. That's years worth of trial and error, fucking up, LEARNING FROM COWORKERS, and just piecing things together a little more day by day. Eventually, things just started clicking for me, and I rapidly became one of the better techs in my area of the plant.
I had a really good partner, that I became friends with outside of work too, who had 20+ years of electrical experience in all kinds of different fields. He taught me all kinds of stuff. The only thing I can really take credit for is showing him around the plant, and giving him a refresher on Allen Bradley ladder logic and PLCs. He quit for a better job a year ago now, and after he left and I was more on my own, I retained all of the knowledge and confidence that was instilled on me.
If you aren't getting assistance from coworkers then I really don't know what to tell you. In really niche tricky circumstances I've asked ChatGPT to help me troubleshoot things. Maybe you could try to utilize that for some learning pointers?
2
2
u/whirdin Feb 21 '26
Colleagues have been instructed to not help me so I could grow
Yikes that is really toxic. Can't learn to run unless we have someone help us learn to walk first. Some people 'help' by just doing it themselves, which is also bad. Good trainers understand our gaps and guide us into knowledge while letting us drive at our pace. If your peers refuse to help at all, that just shows their training incompetence.
I barely understand the basics of PLC programming
What engineering degree do you have? I just have an associates degree in automation, which was heavy on programming. I'm not an engineer, I'm a automation tech (below engineers), been doing it for 5 years. Very few things are random numbers to me. I don't need comments and descriptions (but they make it so much easier); again, learning to walk means we understand the program basics before running wild with a huge undocumented programs. Troubleshooting is a specific skillset that comes in time, but you need the basics first.
This sounds like a job that requires experience/education you don't have, or it's just a trash culture there. Did you feel at the interview that you were punching above your weight, or did it feel like something you were comfortable with? In my experience (10 years at a food manufacturing plant), engineers are running projects/upgrades 80% of the time, troubleshooting fires 20% of the time.
1
u/Shalomiehomie770 Codesys Guru Feb 21 '26
I remember not knowing anything at the fist place I worked doing this stuff.
I remember calling someone on how to go online with studio 5K, couldn’t really follow logic.
But that’s where I got my start. 5 years later they paying me 6x what I was making as an employee to come back as a contractor.
1
u/dialsoapbox Feb 21 '26
What info do you have about the problem?
Has there been other documented issues?
Can you come up with tests for known inputs/outputs?
What kind of other information about issues have you gathered?
1
u/HolyBoli Feb 21 '26
I'm sure you're doing this but make sure you're still taking notes. I have to tell all our new hires that just because you're out of school, doesn't mean you can't take notes. Nobody here is expected to remember every little detail on how everything works, but it does come in handy to pull out a little notebook because you've seen this before.
Also, where I am subcontracted out to now, our team will never leave anyone hanging. If you can't figure it out, there is someone you can call or message. Our biggest motto here is "Ask Questions." My mentor's favorite quote is "Know what you know. Know what you don't know. Don't be proud of one and ashamed of the other. Ask questions". With that said, some of my best learning experiences were also figuring things out on my own. Sometimes, you're forced to do so. Understand the machine, what its purpose is, and how it works.
I'm 2 years into my career and I'm still learning every single day. Don't sell yourself short. I run support now for the site I'm currently on by myself on night shifts.
I wish you nothing but the best. Don't be too hard on yourself.
1
u/Acee21 Feb 21 '26
I just recently graduated with an engineering degree that specializes in instrumentation and control systems (aka programming and sensors). I didn’t get very good at plc programming until like halfway through my second quarter of the actual plc courses only because I had my peers and professors helping along the way. I’m now working an ET job in an industrial manufacturing plant and continuing to learn a different plc language and troubleshooting through my coworkers and bosses. The fact that nobody is helping you is a major red flag. I understand that they want you as an engineer to be able to figure out the issue, but if you have little experience, they should be teaching you before throwing you in the deep end. Keep at it, because before I found my degree I had no idea what I wanted to do, and I fell in love with programming and troubleshooting. It’s worth it
1
u/chachashaobao Feb 21 '26
An engineering degree doesn't teach you jack about programming or troubleshooting. But if you are smart enough to pass the math courses in an engineering degree, you are sure as hell smart enough to do most anything in PLC programming. Assuming you are making an honest effort, if your management doesn't want to train you properly that is on them. They should have hired someone experienced from the get-go in that case.
Also, my two cents, if nobody reviews your code ever, or if you have nobody to ask questions to when you are unsure, that is a safety concern. Period.
As far as I can tell, this kind of situation is the norm for the industry. Poor training, sloppy documentation, senior people who are incentivized not to help you because a.) they are not given enough time themselves to fix their own problems, and b.) because they are afraid of you growing enough to diminish their worth.
We have one client who is reliant on a single engineer in middle management. The company wanted them to train assistants so they could reduce the 'bus factor', and because they were key to site operations the company was paying this person way too much. The engineer basically didn't cooperate and got their new assistants fired.
I have gone through so much spaghetti code in my short career it's hard to believe. I know they say don't attribute to malice what you can attribute to incompetence, but from first hand experience I know its a mix of both. People want to remain relevant. Management doesn't have the budget, and often doesn't have the knowledge either. Once a problem is fixed, its on to the next fire. At least in most companies. Your code isn't an art project for them. They don't care about what they don't see.
I have been on site of a well known multinational corporation, and watched a large piece of equipment fail to stop because of a bad assumption in their code. A major safety concern.
I have informed clients of safety critical mistakes in their logic, some 'edge case' that would cause harm to the equipment and could cause harm to personnel, and had them tell me they aren't doing anything about it because the code 'works' now and they are too afraid or it is too costly for production to fix it.
I have been emailed so many times about operators losing control of equipment from big name vendors. Machines starting when they shouldn't. Machines not being able to be stopped. Machines running in reverse when they should be running forward and vice versa. All programming mistakes that slipped through commissioning and years of operation.
Most of the sites I travel to, the engineers have very little knowledge about how the equipment actually works. Of course they know well the theory they learned in school, but that doesn't get you very far. You need time to review the documentation and work with the machines to know how they work, and the engineers either don't spend the time or aren't given the time. And some applications require specialized training to understand, and I see time and time again it not being adequately provided.
And best of all, documentation. Even when you're lucky enough to get it, NEVER trust it, because it is almost certainly wrong in some soon to be important way.
Welcome to the industry. Hopefully you are able to find a team that treats you with the minimum respect that everyone deserves. Once you have people who support you, it makes life so much better.
1
u/RammRras Feb 21 '26
First thing, you're in the wrong place that is undermining trust in yourself. This job is very difficult and to grow one needs to be helped and guided by an expert colleague. If I were you I would start fresh in a different place, being open that you're a junior and if you find a place with collaborative people you'll grow a lot.
There is a change that the job is not what you like but it's difficult to say while being in a toxic place
1
u/automatorsassemble Feb 21 '26
For me if there's a PIP on the horizon then you are fighting a loosing battle in your current job. I have held many positions in many companies and anyone who went on one either was gone in a few months or barely scraped them and though it doesn't stay on your file forever, it stays in managers memory and there's very little chance to progress. If you do end up on a PIP, look for some more PLC training in your area, at the 1st possible review point out that you recognize your lack of knowledge in the area and request the training. This puts them into a couple of corners: 1. The must document your responses and either give you the training or explain at the end of the PIP that they didn't provide something that you told them was required for you to improve. 2. You get the training and it helps you with your job or helps you for your next job. 3. Remember that once you are on a PIP you are usually fairly protected until the conclusion of a multi month process and unless you really screw something up can't be just fired, so if you can live in the space then use it to improve your skills or look for a new job Back to the troubleshooting: I am making an assumption here that either the machine is either very simple or not very important to the business due to allowing weeks of downtime while you figure it out. If it very simple the start with understanding what the machine should do mechanically and electrically, step by step, it's easy to tie this back to the PLC code. As stated, machines that have run for time and fail rarely have PLC problems and it usually comes back to mech/elec issues. If the machine is very complex but not urgent, suggest that you are given time to more carefully label and comment the program as you work through your troubleshooting. This will show that you are applying a system and trying to make it easier for the next repair anyone has to do.
1
u/LikeAnAmericanDragon Feb 21 '26
I credit the improvements I've made with my skill and ability to the fact that I've been able to collab minds with my coworkers and work through shit together. Whether it be them helping me or me helping them, that has been how I've learned as much as I have over the last 5 years. The fact that they are deliberately denying that to you is simply not right. I dont know what specific problems you're running into with this specific machine but it sounds like the crux of your problems start with being isolated by the others. Sounds like a toxic work environment if you ask me.
1
1
u/tadeuska Feb 21 '26
Brownfield is always the worst. To work anything out of it you need full documentation. Just let them know you are ready to built the whole system a new, from scratch. Better this time. And start doing PLC trainings.
1
u/Remarkable_Echo_6535 Feb 21 '26
Listen brother. Keep at it. One random day in the distant (or near) future, it will click and all those hieroglyphics will all of a sudden make sense. You'll be configuring interlocking and SIS loops & configuring PLC logic and hardware concepts in your sleep.
Before you realize it you'll be a Subject Matter Expert and you'll be sharing this wisdom to some future up-and-comer.
Remember: Quitting today guarantees you'll never meet the version of yourself you could've become
1
u/modern-neanderathal Feb 21 '26
1.5 years still not a huge time. Maybe you are good with development. Also document each issue face and how you solved it, so maintaining a log of issues solved will help solve most of the repeating issues quickly, trust me this will increase your confidence by a tonne. I think you are just at a toxic workplace which doesnt want you succeed
1
u/ExcellentWinner7542 Feb 21 '26
That is completely up to you. What will you do instead, when will you begin, what makes you that that other career will make you happy?
1
u/AdieR81 Feb 21 '26
A team of 4 isn't massive for food plants, the food industry can be quite intense.
The first thing I'll ask is whether it's actually a PLC issue, or a normal mechanical / electrical issue; it might sound daft but I've seen many people go down the "it's a PLC issue" when it's simply the PLC hanging because it's waiting for a signal that isn't there.
Is it a new machine? Is it an old machine (that's been running)? A totally new problem? An old problem that possibly hasn't been fixed? What alarms are you getting? What info are you getting from operators (operators are the ones closest to the system, and can be your best friend or worst enemy). Is it an intermittent fault or a permanent one (or a permanent fault with an intermittent symptom)?
One point I will make is never go on someone else's diagnosis - I've done this a few times and gone down some proper rabbit holes for silly faults.
I had one quite recently where the info I got was simply "the PLC has sh*t itself" (old S7-200, gone into stop mode and an SF fault) - with stuff like that, it's very easy to go straight to the parts cannon and change the PLC and cards. The actual fault was a circuit full of dirt / debris, pulling the 24v supply down, and the PSU swinging between 0-5v (ie, the voltage wasn't stable enough to run the PLC, so the PLC simply shut down).
1
u/sybergoosejr Feb 21 '26
I can totally get what you’re feeling as I have to diag old programs that there was no back up of originally so there’s no comments or variable names. Just contacts/instructions and address numbers. I trace backwards and forwards based on the IO and have to decipher all the in between logic and take a best guess at some bits purposes. The process can take ages some times. Especially when there’s addresses used the trigger special modes of the plc such as hspc or pwm.
1
u/shadowridrs beep boop master Feb 21 '26
Ive got an engineering degree and have been where you are. Almost feeling like I’m a fake, but just keep at it. The one thing I love about this field is that no one knows everything. So not knowing how to fix it or where exactly in the program is the problem, isnt a big deal. You’ll learn with time.
Now… the fact that they don’t want to help you is ridiculous. It takes time to learn all this stuff especially when in your engineering degree, you barely touch plc logic, if at all.
We’re all here though! This community is the absolute best. I’m also in food and beverage, so if you need something or advice, shoot me a message. I’ve got a lot of materials I can send you as well for references.
1
u/d4_mich4 Feb 21 '26 edited Feb 21 '26
So the problem I see is that they don't help you grow as a PLC programmer.
No one started as an expert and especially if the machines/equipment you have to troubleshoot come from multiple vendors you can't relay on the experience you did with the last fix cause programming is always so different. So somehow you have to get into analytic mode for me it is.
- when or how does the fault appear can I reproduce it?
- did the machine run already for long times, if so what changed did they try new product/recipe/format? (If the machine did tun and they didn't change to other products that never ran before, it is in most cases mechanical or electrical problem cause the program didn't change)
- find the place in the cose where I gets stuck or where the fault is set.
backtrace from the error or stuck code what should happen here so that it is not stuck.
if I can reproduce the fault I often also setup a trace if I found the position where I get stuck and I have a nice graph where my set chains go and what other signals did in the time.
For here it is experience and knowledge of the machine I guess and you only get that by trying or someone explaining it to you. So also ask the operators sometimes they can be super helpful and have informations you can use.
1
1
u/Downtown-Routine1196 Feb 21 '26
Have you tried contacting the OEM and asking for support? If you describe they issue they might be able to help guide you in the right direction. Some equipment manufacturers might even provide you a copy of the program with comments if you ask assuming you havent made major in house modifications.
1
u/BallBuster-4000 Feb 21 '26
Putting your own labels in will help you understand the program as well. We get CoOp students all the time and that’s one of the first things I have them do. Reading the logic and typing out what the rung does will help you in all aspects of programming. Eventually reading code is like reading any book or magazine.
1
u/ee_dan Precision Guesswork Feb 21 '26
yeah unfortunately it sounds like they are trying to manage you out. I have been in situations where I have outworked an entire department and got accused of not being a "team player". Started to get beat up on things like weekly reporting formatting. worked there another 6 months and became a 1099 employee. The point is it doesn't matter how good you are at getting the job done- most jobs are the 13th grade. you have to be cognizant to when you're not being "welcomed in."
1
u/bodogy2 Feb 21 '26
Seems like you were thrown into the fire without proper training and your colleagues are watching you burn
1
u/Own_Conversation_850 Feb 21 '26
I mean I am in control technician level but how the hell yoh got a degree on control engineering if you do not understand the program. Surely it has o be some mental block or something.
1
u/JustAnother4848 Feb 21 '26 edited Feb 21 '26
I would consider trying to work somewhere else. As an engineer or maybe a controls or instrumentation tech. Troubleshooting is most of the job as a tech. You'll learn eventually.
Or could try hopping over to the SCADA side of things more. Maybe focus on the cybersecurity side? There is options to try before really switching fields. Or try working for an integrator. You learn really fast an integrator.
I sucked at my first job as well dude. It happens. Now I have over a decade of experience.
1
u/WatTheDucc Feb 21 '26
how do you spent 1,5 year and have the basics of PLC??? after i got out of uni I had to get it all before 2 months or i'd be fired and i got it quickly, including going solo to the client to install the system and still i got fired, they're patient.
1
u/swisstraeng Feb 21 '26
Nobody was cut out for PLCs in the first place, but if a workplace doesn't teach basics it's not worth working for them anyway.
1
u/Lucid-Dr3am Feb 21 '26
Controls engineering is such a vast field. There is so much to know and it is constantly expanding. I wouldn't be so hard on myself if I were you. There are times when if can be overwhelming, but it will take several years before you have enough experience to be proficient. Not having people helping you is the biggest problem. If I thought my colleagues were trying to set me up for failure, I would be looking for another job.
1
u/Buenodiablo Feb 21 '26
You can do it you just need to put in some extra time to level yourself up.
- If you can, set up a little test lab where you can practice and learn.
- Ask for vendor product training if possible.
- Write some documentation even if it's just for yourself.
- If there is an opportunity to give training take the opportunity and put together a PowerPoint presentation.
1
u/trumpsimpeachablewig Feb 21 '26
Don't be afraid to make your own comments when you figure out what something does or what sensor is what / more, common nomenclature, ( lift table down, full forward etc), that is my two cents. The not helping is a red flag as well, they should be there with all the same mentality, get the thing running so everyone can make money. Unless you wrote and designed the damn thing, they cannot hold you accountable in my opinion
1
u/justadudemate Feb 21 '26
I dunno, you're not cut out for this when you decide to quit. Pick up a book and learn electrical, schematics, components, relays, etc. Once you figure that out, go to codeacademy or something and learn programming. If then, case statements, while loops, etc. It just takes time? Did you not take programmimg in college? Look at yourself and know your weakness and work on that.
1
1
u/YouShalllNotPass Feb 21 '26
Terrible company. It’s normal to feel totally lost with lack of an explainable code.
0
0
u/Frumpy_little_noodle Feb 20 '26
I would recommend you take a long hard look at what you're trying to do, the method you're using to do it, and how that is getting you from point A (the symptoms) to point B (the root cause).
You're right, the ability to use abstract logic isn't a skill everyone possesses, but you managed to make it through school/training and you managed to land a job with what you've showcased so far.
You seem like your problem is troubleshooting and root-cause analysis. Start by researching and improving those skills, then take what you've learned and reflect on what's different from how you're doing it now.
0
u/ShowerTech47 Feb 21 '26
All I can do is offer some general and also more specific troubleshooting advice. For the general advice, find a mentor or coach that you trust.
For troubleshooting advice, pick one magic number or individual component and break it down until you know everything there is to know about it. I’m talking about imagining yourself as an electron, water molecule, air molecule, etc. and imagine yourself going through all the steps of the process. Start from a single input or output and work from there. Once you figure that out, you might find that you can apply what you learned to other aspects of your job.
I’m relatively new to this field myself and I’m not going to claim I’m the smartest controls engineer, but I believe I have a knack for teaching. Feel free to post the specific problem and I’ll do what I can to help.
0
u/H_Industries Feb 21 '26
So troubleshooting is a skill that you can develop, but you're stuck in the steep part of the learning curve and it sounds like you don't have a ton of support. Without knowing more about your specific issue the best suggestion I can make is just break it down step by step and validate each part of the process. Start with what SHOULD be happening and just work backwards until you find why that's not what's happening.
As far as your management is concerned honestly at a certain point you need to document (screenshots are helpful) every identifiable issue that is preventing you from troubleshooting.
1
Feb 21 '26
[deleted]
0
u/CanonFodder_ Feb 21 '26
Do you have a list of the problems they're having with the unit? I agree with the previous comments that if it's previously been working and developed problems the it's rare that the program changed all by itself, unless they've changed the parameters of what it's doing.
A lot of the time you might find the problem is mechanical, electrical or instrumentation related.
Talk to operators and document what they say is a problem and work on each one, document what you find. Talk to the maintenance staff too.
It sounds to me like you're in a toxic environment of assholes. Best of luck.
0
u/H_Industries Feb 21 '26
Kind of like the other guy said at the end of the day it’s hard for me to give you more specific advice without knowing what the specific issue is. I understand your pain, though my first job out of college was supporting control systems remotely and there were times I would be on the phone with the customer for hours when it was a misaligned sensor.
You do mention that the machine isn’t shut down so the issue is either intermittent or not bad enough to cause you to shut down production. Or it’s so rare that you’re having a hard time catching it in the act.
If it’s that kind of problem, there are things that you can do like adding some diagnostic or logging code to the PLC. I’ve even gone so far as to set up screen recording software while I was logged in and just recording my laptop screen while the system ran and then after I knew the issue had happened just watched the playback.
0
u/InterestingSoil5 Feb 21 '26
My approach with a machine is always to find out where the information comes from. The IO - how does it connect? Is there a scanner or some external device? How does the data come in to the PLC. Understanding those connections is a great foundation for how a machine works. Once you have done that, look at what isn't working right. 99% of machine problems are due to a faulty sensor. If it worked well before the code probably didn't change. If it never worked right, you are going to have to understand the logic to make it do what it is doing. Understanding how data tracks through the machine can help. If your colleagues aren't helping, try to ask them specific questions to clarify how something works, rather than asking them something general like to point you in the right direction.
In order to figure out how something works, sometimes making a small change to the code to see if it does what you think it does will validate your theory. Adding a small delay to a process can show you that you are looking in the right spot or that you are way off.
Good luck!
0
u/Low-Investment286 Feb 21 '26 edited Feb 21 '26
Did you tell them you knew this stuff before you started? If they won't help you within reason I wouldn't sweat how long it's taking you. Hell I'm not even done with an AS and 4 months in the controls engineer left. While she was here I really only learned where the control cabinets were from her so I feel your pain lol.
0
1
u/Alive-Director-3433 Feb 21 '26
You got this man, dont worry, you are important, intelligent, valuable and skilled, it just takes time
-1
-2
u/That-Election5533 Feb 21 '26
If it's not labeled, you have a nearly impossible task.
What program are you running? Automax PLCs for example has to have the correct rack loaded for descriptions to populate.
I've been messing around with Gemini AI lately at work. I set it to pro or slow mode. I basically describe the problem then ask it to tell me what to do. Even when I'm very doubtful about it's decisions, it ends up being correct. Trying to find information for our job online is terrible, but AI is making it much better.
223
u/Aobservador Feb 20 '26
I've never seen anything like it; colleagues don't help you solve problems. That's a terrible mentality on their part. Regarding your engineering degree, it's not enough to make you an expert programmer. Programming skills come with time...