I am currently a second year student (out of 3) in a technical college program called "industrial electronics". The curriculum includes what you'd expect : programming PLCs, power, electricity and electronics, instrumentation and controls, math, physics, CAD, etc.
I am also employed in a coop fashion by a local systems integrator. I work about 25-30 hours during my studies, and 40-60 during breaks. On weekends, I provide support for a client (two day shifts) with the help of my boss (basically, I give a problem a shot, and if I am completely stumped, I can call my boss at any time during my shift for help. This way I am introduced to a whole slew of issues and tasks and I am developing my autonomy). The client, of course, knows about the details of this arrangement.
I have been doing this support for around a month, and while my autonomy has improved, I feel like I'm learning only through prior exposure; I can now do common tasks (change a valve and teach it, fix the random PLC/HMI comms problem, etc) but when I am exposed to situations I haven't seen before, I never know where to start. For instance, today, one process was stuck in a loop. I found the cause (temperature transmitter was reporting a value a few degrees below what it needed to clear the step), but because similar problems in the past had been caused by faulty valves (or closed valves that shouldn't be closed), I looked in the direction of the steam valves, up until an operator showed up and gave a knock on the transmitter itself (apparently this operator had had this problem before), which made it transmit the actual (correct) value (and obviously this means I am changing the probe and transmitter tomorrow, when the process is free). Given that there were other TTs farther down the line who showed the right temperature, in retrospect, maybe I should have clued in, but I was too attached to my prior experiences to do so.
Maybe this is normal, given that I am so fresh, but I'm a bit embarrassed at how bad I am at troubleshooting. I'm relatively handy with a laptop and a PLC so I can nearly always find out why the process isn't moving, but I struggle with finding the root cause and the solution. There was one time where I fixed a problem without any help and I walked away almost high from the pride. I guess I wanna chase that high.
Perhaps some of you would like to share your knowledge. I do well with methods and I think my problem is that I don't know the right questions to ask (a kind of quis, quid, ubi, quibus auxiliis situation I guess) when I come across a problem and that I have no method to apply beyond "look at what's causing the hold up on the PLC". So perhaps a push in that direction would help a lot. Troubleshooting is a skill and it gotta be able to be learned. If it makes any difference, I "get" electronics troubleshooting. I built a PI controller on a breadboard with a dozen op-amps and I had to troubleshoot my share of problems. But I know how op-amps work so it was just a matter of following each input and output from the beginning and poking around when a part didn't do its job correctly. I don't know the processes at the client's plant very well yet so I can't apply the same logic. But I don't think it's optimal to have to know every process like the back of your hand to troubleshoot well.
Another thing I am not so great at, and I found this out at school, is tuning a PID. I've had quite a few labs on the subject but my results seldom came out as what was expected. The tuning constants I get are always way too aggressive. Doing Ziegler-Nichols methods, even when choosing a Ku that isn't even ultimate (oscillations decay slightly over time) because I've had it with getting oscillatory processes and overworked valves, I still get like 2:1 decay. Maybe I take the textbook too literally, but I was expecting to come away with good tuning after applying the "recipe", not results I need to modify afterwards, else what use is the method when I could just go by feel (and in fact, that's how I've been most successful)?
Thanks for any help
I am also employed in a coop fashion by a local systems integrator. I work about 25-30 hours during my studies, and 40-60 during breaks. On weekends, I provide support for a client (two day shifts) with the help of my boss (basically, I give a problem a shot, and if I am completely stumped, I can call my boss at any time during my shift for help. This way I am introduced to a whole slew of issues and tasks and I am developing my autonomy). The client, of course, knows about the details of this arrangement.
I have been doing this support for around a month, and while my autonomy has improved, I feel like I'm learning only through prior exposure; I can now do common tasks (change a valve and teach it, fix the random PLC/HMI comms problem, etc) but when I am exposed to situations I haven't seen before, I never know where to start. For instance, today, one process was stuck in a loop. I found the cause (temperature transmitter was reporting a value a few degrees below what it needed to clear the step), but because similar problems in the past had been caused by faulty valves (or closed valves that shouldn't be closed), I looked in the direction of the steam valves, up until an operator showed up and gave a knock on the transmitter itself (apparently this operator had had this problem before), which made it transmit the actual (correct) value (and obviously this means I am changing the probe and transmitter tomorrow, when the process is free). Given that there were other TTs farther down the line who showed the right temperature, in retrospect, maybe I should have clued in, but I was too attached to my prior experiences to do so.
Maybe this is normal, given that I am so fresh, but I'm a bit embarrassed at how bad I am at troubleshooting. I'm relatively handy with a laptop and a PLC so I can nearly always find out why the process isn't moving, but I struggle with finding the root cause and the solution. There was one time where I fixed a problem without any help and I walked away almost high from the pride. I guess I wanna chase that high.
Perhaps some of you would like to share your knowledge. I do well with methods and I think my problem is that I don't know the right questions to ask (a kind of quis, quid, ubi, quibus auxiliis situation I guess) when I come across a problem and that I have no method to apply beyond "look at what's causing the hold up on the PLC". So perhaps a push in that direction would help a lot. Troubleshooting is a skill and it gotta be able to be learned. If it makes any difference, I "get" electronics troubleshooting. I built a PI controller on a breadboard with a dozen op-amps and I had to troubleshoot my share of problems. But I know how op-amps work so it was just a matter of following each input and output from the beginning and poking around when a part didn't do its job correctly. I don't know the processes at the client's plant very well yet so I can't apply the same logic. But I don't think it's optimal to have to know every process like the back of your hand to troubleshoot well.
Another thing I am not so great at, and I found this out at school, is tuning a PID. I've had quite a few labs on the subject but my results seldom came out as what was expected. The tuning constants I get are always way too aggressive. Doing Ziegler-Nichols methods, even when choosing a Ku that isn't even ultimate (oscillations decay slightly over time) because I've had it with getting oscillatory processes and overworked valves, I still get like 2:1 decay. Maybe I take the textbook too literally, but I was expecting to come away with good tuning after applying the "recipe", not results I need to modify afterwards, else what use is the method when I could just go by feel (and in fact, that's how I've been most successful)?
Thanks for any help
Last edited: