What’s the best way to learn a new program for a new piece of equipment?

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

In my opinion, you've already started by pretty much answering your own question;

I get the urge sometimes to go to different machines—ideally frequent problem machines—and just watch them run while looking at the program.

Click to expand...

The next step I would suggest is using the tools of the software package. Watching "is it green on the screen" won't always be reliable. So this is where trends etc. come in.

Using the help files for each instruction being used in that rung of logic, will help you.

I would then go a step further, and if there is an HMI with no diagnostic information, start learning how to add that to it. A good HMI means you should be able to fault find e.g. a faulty proximity sensor or temperature transmitter, without getting your laptop out.

I started out the same by the way, in the dairy industry making cheese. By the end of my 2 year apprenticeship, I was replacing the obsolete PLCs installed since the 80's with something we could actually modify/have control of with modern day tools.

Standing and watching is good. If you don't know what it should be doing, how are you to know when you are called to it, that what it is reported to be doing is abnormal.

If you can get hold of some spare hardware i.e. a PLC & HMI you could start by doing simple projects i.e. a simple pick & place, you do not need any I/O just use internal bits. you can simulate the I/O. One way is to create a separate block of code to do this for example: when a solenoid (pneumatic cyl) is triggered, start a timer and when time up make it equal or set the cylinder out prox and when it is turned off reset the out prox & after a time set the cyl back prox. do this for all functions and there you go simulation. This is often how people do it without a real life machine.
If you are going to write an actual program then first of all map all inputs to internal memories in a program block. do the same for outputs but do not call the blocks. write your code using the input/output mapped bits and create a simulation block. there are many things you can do like increment mapped analogs up & down using timers to simulate real world times etc.
Debug the program & when ready put the call into the I/O map blocks & either disable or remove the simulation block. this way you only need the plc and not the I/O or use the simulator if availlable. (note: some PLC's you may have to leave the mapping out & when ready to drop them back in configure the real I/O cards in the PLC parameters.
This way you can really get to grips with the functions of PLC programming without causing any disruption to existing plant.

I would get out of the PLC and try to work out how the machine is being controlled by watching it physically. Find the prox's that trigger things, watch what happens when it faults, starts up, stops, etc. Then start to piece together a bit of a control narrative on how it looks like the machine works.

After you have a rough idea then open the plc and try to find the parts that correspond to your narrative. The infeed prox that triggers the screw feed after two seconds is actually called JAR_DETECT and turns out it's 2.5s and won't actually fire off if the machine isn't in auto. Do this until you have a good idea on all of the machines main states.

I find even at least writing anything down and trying to find them in the code helps stop my brain from tricking me into thinking I knew what was happening when I was totally off.

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

Click to expand...

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.
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!