modifiying an existing plc program

i have a machine in our shop that is designed to put groves in pipeing to fit belts on the pipe sections to turn them into conveyor rollers.

the system is run with a micrologix 1200 series plc, right now the machine has 2 modes. mode 1 is it just cuts the pipe to length but doesnt add the grooves. Mode two is where it adds a double groove to the one end and then cuts the pipe to length.

my boss wants me to add additional functionality to the machine where by you can also select two additional modes - 1 where it adds a single groove the other where it adds the double groove at the front end and then stops, waits for the operator to swap the pipe around then grooves the other end of the pipe segment.

My problem is this, i was able to contact the orginal machine builder and get the electrical drawings and copys of the plc program (of which there are 5 different ones?) but whoever programed it did so in a method im not overly familar with (tons of subroutines) so im wondering - would it be easier for me to start from scratch and build a new program with the added functionality - using the existing program as my guild, or would i be better off trying to modifiy the existing code?

If you know the machine really really well, then starting from scratch might be easier, but I would still get familiar with the style in use and study it while in action to make sure you don't miss anything being done by the OEM that you had not noticed before.

Paul

Your company has already paid for the program once already, there is no reason for them to pay for it twice because you can't modify the existing program "easily".

Using subroutines cleans up programs quite nicely, and chances are there is a subroutine that is specific to the groove operation. If you can find this subroutine and understand it, 75% of your programming is done. Copy/paste and modify as needed to get the desired affects.

Of course, copy and paste into new subroutines to differentiate the new modes you have added!

Or, you could just contract the original company to do the mods...

IMHO - Starting from scratch means commissioning from scratch. Unless the program is horribly written, I'd go and modify it. Subroutines shouldn't make things more difficult to work with really.

I have modified and rewritten many programs over the years, and it is almost always easier to change one than to start over. If you think that starting over is easier, then probably you do not understand how the old program is working. If you cannot figure out how it is working, then your chances of successfuly writing a new one with added features are slim to none.

A subroutine is not some exotic device. It is simply a way to divide the program up into smaller blocks. Smaller blocks are easier to study, print, change, and copy.

What you have to do is identify the Outputs in the program that cause the double-groove cut. Then figure out how to stop it after only 1 groove. Then figure out where to Pause (temporarily stop) the groove-cutting output when an input switch is pressed, so that the pipe can be reversed manually.

If you post your program (PDF print-out), I might can figure it out for you if I have time. I might not, because I have gone back to work after being off 6 months due to disease.

Ok I will be the one dissenting voice. I have run into programs over the years where (usually in hindsight) the program should have been just redone. If the OEM is using subroutines to do operations other than program organization, it can get hairy to modify the program. I have seen programs in the past with subroutines called for certain actions that created problems for the programmer and they ended up solving it with lots of unlatches and other Yucky stuff (and yes yucky is a technical term). There have been times I have modified a program and afterwards thought it would have been easier to just rewrite it.

Most times changing the existing program is best. However CE79 you are the only one looking at the program to determine whether modifying the program would be a good course or a nightmare. You may want to post examples of the code you have problems with and the people here may change their tone or still suggest the modification route.

the main problem i have with the program is that whoever designed it - - - used many many many Bit files mapped to all of the plc inputs and outputs - even those that are spares and not currently in use and the orginal programmer seemed to pick his timer and bit and status numbering completely at random instead of following sequencial logic.

for example you'd expect bit files in use to go from B12:0/0-B13:0/0 ect where as he appears to have picked B3: to indicate program status (running/not running/paused/faulted ect) B14 to B16 appears to be his movement and grooving logic B40 appears to be his bits mapped to his inputs and so on..... its just when i look at the program -its not that complex - -theres only 14 inputs and 9 outputs on the machine - but when i try and look at his logic because the Bit numbering jumps around so much im finding it hard to figure out the existing sequences. Add to that the orginal programmer mapped alllll of the inputs and outputs on the micrologic 1200 to bits which seems to have made the program 2x as big as it needs to be.

I had the machine operator sit down with me and explain the machines sequence.

This is what he told me:

Machines collet opens
Pipe is fed into the machine
Pipe reaches back stop
Collet closes
based on a selector switch on the machine the machine eather simply cuts the pipe to length, or it places 2 grooves on one end then cuts it to length

it seems to be a fairly simple operation - even with the addition of 2 more sequence options. im leaning more towards re-writing the program from scratch then trying to decode the sequences in this existing program

the options that the machine is supposed to have are:

1) simply cut pipe to length (does this already)
2) add single groove to one end and cut to length
3) add double groove to one end and cut to length (does this already)
4) add double groove to one end and then release pipe wait for operator to switch pipe around then groove opposite end. (the double ended pieces will be [precut to length because otherwise the operator would have to remove the rest of the pipe from the machine to get it to fit into the collet.)

Mapping I/O to internal bits is a very common practice and has several advantages:

You can write your program without having to know exactly how everything is going to be wired. And then it can be adapted to a variety of different processors or I/O configurations.

You can change an input or output point in one place very easily. (Example: you find out that a normally closed pressure switch is actually a normally open. Invert the contact in your input map and you're done)

You can write simulation routines that tests your logic without having to wire up all the real I/O.

A good way to help you follow those mapped bits is to use symbol names based on the device names.

I usually map the I/O for the reasons above, but with so few I/O I could see why you might want to do away with that on your machine.

Sounds like you have a pretty good understanding of the machine now, and you can always test the new code and if you hit bugs (...bugs that don't destroy anything...) you can dump the old code back in and keep them running while you fix yours...

Good Luck!
Paul

Paul - - -usally i program the same way - -esply when dealing with a bunch of tooling that needs to move in sequences. Of for mapping inputs to timmers for debounceing of photoeyes and proxies

what is mostly confusing to me in the random way in which the orginal programmer picked his Bit-numbers they just seem like he pulled them out of his azz rather then any logical method i can see (such as Using B13: To B14: for sequence one - B23 to B24 for sequence two, B30 for inputs, B40 for outputs B3 for machine status. Also what is causeing me problems is that he mapped all 24 input points on the plc even though only the first 12 are in use, that seems to have cluttered up the Bit memory table with bits that are mapped to inputs that will never be used - as well as using up the corrisponding timers in his debounce circuit.....

it seems like whoever wrote the program was trying to make a simple machine process as long as complex as possible (maybe he was getting paid by the hour for his programing? hahaha)

Controls_Engineer79 said:

....
it seems like whoever wrote the program was trying to make a simple machine process as long as complex as possible (maybe he was getting paid by the hour for his programing? hahaha)

Click to expand...

In my experience comments like this come from 2 view points. The first is from an experienced engineer who is legitimate when he/she says that the program was written in a poor fashion.

The second is from inexperienced engineers/technicians that don't understand that 95% of the time there is a valid reason for the "madness" that exists in the program. Programs are not always obvious to the Lehman, I'd love to see how you would react to the sequential programming my company uses. It is extremely efficient for us (so we can quote the job competitively), logic is clean and simple to understand once you grasp the overall concept, however the consequence is that you can't just look at the code and understand how the sequence is working unless we comment the hell out of it.

I used to think the KISS method should be applied for everything when I was supporting equipment, but now that I am a system integrator there is a much bigger picture, and KISS for an OEM/SI is not the same for an end user.

Many factors besides machine specific operation can affect program structure such as: project cost, internal programming standards, programming preferences, and of course experience.

My thoughts:
They mapped ALL inputs to reserve the bits for future additions. Do the bits line up with the Inputs?

Bits used in various locations within a file are usually done to provide space for any "expansion" that may be needed which is related to that group of memory, so gaps were put in place. As for the inputs being in B30, outputs in B40...is there an expansion input card in slot 3 by chance? Output card in slot 4? Probably not in your case, but I hope you see the potential relationship between the memory bits and IO. Just trying to make you think on a lager scale.

I don't understand why the bit memory locations are a hinder, after all it could use B100:0 for sequence 1, B200:0 for sequence 2, N7:0 for Inputs, N8:0 for Outputs, B43 for system status....in the end memory is memory.

If its less than 500 rungs and RS logix 500 send me a copy of it with descriptions and I will help you with it. I rewrote a few hundred, sub- routines make it easy just sometimes to write your own subroutine and with a selector switch just cutt-off there JSR instruction and your routine is the only one that runs when you select it. Remember the offer is no good without descriptions. [email protected]

Why not post the program for us to see?

Sounds like you got another offer for help. Take advantage of it while you can. Some of the old guys get tired sometimes and don't offer to help very often.

Im not old