darwil93 said:
So to start with, I’m pretty new to the field.
I work as an E&I tech (one of four techs) at a food manufacturing plant. For the most part, we are moderately automated with a pretty good variety of different controllers and other automation.
I work second shift maintenance and my job is not to do any engineering or programming work but to merely maintain what’s already there. I am okay with that. It suits me perfectly. But there are times where I want to do more than just wait on the machine to break down of course.
I get the urge sometimes to go to different machines—ideally frequent problem machines—and just watch them run while looking at the program. I’d like to think I’m doing some sort of practice. Until this point, I have just been moseying around in the program with no rhyme or reason in order to get familiar with it. Although, with my personality, I don’t like becoming familiar that way. I like to be more systematic and planned.
So my concern is that if I come across a machine that’s new or one whose program I haven’t looked at yet, is there some sort of SOP or standard guideline that I could go by, and use to navigate the program with a better sense of “start to finish” quality. Most of the programs we use seem to be very well structured ladder logic, with the exception of a few. If there is such a system I feel like it would work perfectly for me. I’d like to think I would use it in the form of doing “drills” regularly and just applying it to different machines.
Naturally I understand, this type of question is going to open a can of worms in the way of add-on questions due to the incredible vagueness of it. I’ll be glad to take the heat. Like I said, I’m new. I need all the feedback I can get.
Thanks in advance everyone
This approach is almost exactly how I got into the field. Whenever my shift was quiet and nothing much needed doing, I'd get online with a PLC and poke around until I found something I didn't understand. Then I'd work through it until I understood.
If your plant is anything like the one I worked at, you'll have 50 PLC's programmed by probably 30 different people. That gives you a terrific opportunity to see 30 different approaches to programming. Look through each PLC and see how each programmer handles a simple DOL motor. What about VSD? VSD with fieldbus (ethernet, devicenet)? Look for a simple solenoid. What about a valve with open/closed feedback? What about a double acting valve? What about an analog control valve? Each programmer will do it slightly differently, and as you compare them you'll start to get a feel for which ones are intuitive and straightforward, and which ones are unnecessarily complicated or just flat out badly programmed.
Look at sequences. There are a hundred different ways to achieve a sequence, some great, some good, some f***ing terrible. If you come in "cold" and within half an hour are more or less across how the sequence is structured, it's the former. If you poke around for half an hour and still can't make head or tail of it, it's the latter.
Are any machines communicating with one another? Look into how that's done. Again, several different methods, each with their own advantages and disadvantages.
Moving forward, if you *want* to get a little more into programming, your idea of finding a problem machine is a good one. Spend plenty of time with it until you completely understand the issue. If you feel that you could make an improvement, ask yourself:
1. If things go wrong, what are the consequences? Could I live with that/would my employment here survive that mistake? e.g. if you make a mistake and shut down a process, have you just caused $50,000 of product to be scrapped and necessitated a two-hour restart process? If so: it's probably not worth the risk. But if your mistake/shutdown just causes a machine to stop, and just means you to have to very quickly revert your changes and restart the machine, the stakes are much lower.
2. Is it your role to be trying to make such improvements? If not, what might be the repercussions for you should you make a mistake and e.g. shut down a machine while operating outside your expected role? Would it be a case of "sorry, I thought I could fix that issue we've been having" and your boss tells you to be more careful in future? Or would it be a case of "this is not your role, that's why we have engineers on staff, don't touch the code without our permission again"?
Then repeat those two questions assuming things go
right.
1. If your modification results in an improvement, what is the potential benefit? Might you be fixing a problem that causes dozens of machine stoppages a day, and constant operator headaches? Or is it just a case of "oh hey, that nuisance alarm hasn't come up in a while", guess someone fixed it!
2. If you make an improvement/fix a problem, are you likely to be praised for your efforts and going the extra mile, or criticised for getting too big for your boots and trying to do the engineers' jobs?
Weigh it up from both sides. If you stand to make a huge improvement, and nobody will care too much if you make a mistake or are "outside your job description", then why not give it a go? If you're just looking to fix a minor nuisance problem, and know that you're not really supposed to do this sort of work but it's such a small issue that it's not going to ruffle any feathers, maybe it's worth taking the chance? If a mistake could have reasonably significant consequences, but the potential reward for getting it right is sufficiently high, maybe it's worth a shot if you're confident your reputation/job security can handle the worst case scenario?
The only other tip I'd give you, if you
do end up making a change is: code it in such a way it can be quickly and immediately reverted. e.g. put a bit in the code that you can toggle on or off to switch between the original code and your new code, or to bypass/disable your changes.
Document this extensively. Before you leave site, make sure that everyone who might have cause to be looking at this PLC/code is aware of what changes you made, why you made them, where the relevant modifications are, and how to revert back should it not work as intended. As an engineer, a maintenance electrician messing about with your code and not telling anyone is the bane of your existence. But a maintenance electrician who makes considered, well documented changes, and makes sure that all the relevant stakeholders are fully informed of the changes at all times, tends to make friends with the engineers fast.
If you modification results in a positive outcome, make sure to circle back and tidy up after yourself. i.e. remove the "toggle to reinstate old code" bits, update rung comments to explain what changes where made, why, when and by whom. e.g.
Code:
2020-01-13 Initials
Added 100ms debounce to sensor to ensure widget fully engaged before indexing to next station, to reduce incidence of label mis-application
If you do have engineers that usually look after the code, you may be well served by involving them in this process. i.e. just duck in and say "hey, I made this temporary change two weeks ago to address the label mis-application, and since then the issue seems to have completely disappeared. Seems like it's working well, do you want me to tidy it up and make it permanent? Or leave it to you to review and finalise? Are you happy with how I solved the problem, or should it be done a different way?" Again, if you work with the engineers you'll likely make a lot of friends there.
Good luck!