How many times have you

reprogrammed the original copy of your program, to either simplify or improve, or just the challenge of redoing a program to a completely different style, or do you say to yourself, that it works and thats good enough? I haven't written very many programs, but I always like to see different ideas that would improve efficiency and simplicity. One of my pet peeves, when I look at other programs is the overuse of timers to reset timers, under-usage of comments, and programs that don't have a nice logical flow. What is your biggest pet peeve, when reviewing other programs?

It's sometimes diffucult to leave well-enough alone.

I know this can be different for folks maintaining equipment in their own plant verses OEMs that are programming stuff that will be delivered to a customer.

I'm one of the latter, so I try to do the best job I can on our site before the machine is delivered. If, during the installation phase, I see something that I believe the customer's support people may struggle with, I'll clean it up and document it the best I can. Usually the code as been tested for the most part in order for us to ship so I won't make any big changes. Last thing I want to do is make some big changes, leave, and find out I created another bug that rears its head later.

Never Reprogrammed,

But when do similar logic, at a later date, sometimes have a thought of "Isn't it better if I do it the other way". Then something which give more satisfaction will come up.

But there are times when you abort the thought and stick to the so called 'proven method'.

In the lab I program the PLC once then when i go on site the customer ask many other requests and modifications.
Also for optimizing and tests,
so i reprogram many times

I like highly structured code as opposed to 'clever' and 'tricky' code. After maintaining the equipment for 20 years and through maybe 50 or more modifications on each machine, I would love to sit down and rewrite some of these programs. If they started out structured they become a maze of interlocks and sub programs, unused sections of code etc. But the brass look at the equipment as running and tested and you want to redo it and then work out the bugs? Unfortunately it doesn't happen. So when you build the structure for the original program, leave room for modifications within the structure. Leave spare tags and inputs and outputs already configured. The next generation of maintenance electricians will thank you!

Ahh.... how many times have you wished you could start again.

It's nice to think you have the chance to do it again & this time make your code neater, slicker & generally well documented.
Well in the real world you don't have many chances but when you get them it's really satisfying as you know what to do this time without having to patch it up.

I have a set way of programming, and don't vary from it. Changes are changes.

Every so often, I come up with something I like a little different, and will change from there out. Sometimes these are something I figured out, other times tips or observations from others.

Just change from there out. If it were a safety concern or something major, then yes, a change would be in order.

A change just to change, doesn't make sense to me. Specially when I would have to change 5 or more hard copies!!!

regards.....kc

parky said:

Ahh.... how many times have you wished you could start again

Click to expand...

I read an interesting book the other day that gave a wonderful piece of advice - Plan to throw away your first implementation and then do it again. You can start again if you decide to plan it that way.