Common way people write programs.

Maintenance Man · Aug 4, 2009

I have written a machine program and the company wants me to keep making changes to it as they see fit. I have no problem doing this and get it to do what they want. My question is if it is normal when a person keeps making changes to a program that it becomes a kind of hacking effect where a little is added hear and taken away there where rungs are added above and below where changes are needed ? Or do most people just start over and rewrite the whole program? I use descriptions for inputs and outputs along with rung descriptions which makes my programs easy to understand. If I had time I would take a second look at the program to see if there was a better way to write it , but all they care about is if the program works or not. I am just asking for the common way people write programs or am I doing the common thing? Thank you all for your help.

Sincerely:
Maintenance Man

:site:

OkiePC · Aug 4, 2009

That is a very common situation. I try to structure the program to allow for changes. I rarely ever start over.

There is no wrong way to write the program ... if it works, then it is correct ... (I say that with a smirk...of course we all know there are programs that are a complete mess to work with...but they still work...)

There is always a better way to write the program, but at some point, it is "good enough".

Paul

JSPLC · Aug 4, 2009

I agree, this is a normal process with PLC systems. I have been programming PLC's for a number of years and I found that if I start with a well structured program then it is easy to modify with in the structure to maintain consistancy. Adding or modifing lines in the appropriate locations to so that the structure is not disturbed.

Maintenance Man · Aug 4, 2009

Thank you very much OkiePC for your reply. I guess it is true that a program becomes good enough at a certain point; as long as the company is happy I am happy.
Sincerely:
Maintenance Man

ojz0r · Aug 4, 2009

I only have one little tipp, make it easy. My ambition is that anyone (with the right knowlage ofcours) should be able to sit down and understand the program right away since every minute of trouble shooting costs money.

Greg Dake · Aug 4, 2009

Think ahead

Don't paint yourself in a corner in terms of things like tagnaming conventions. Think how the system may grow.

Greg

Maintenance Man · Aug 4, 2009

Thank You all.

Thank you all for the help;I appreciate it a lot. I will keep it simple and write programs where they can be added on to if need be. I will alway go by the saying of KISS.

Thank you all

Maintenance Man.

aswilson · Aug 4, 2009

I will rewrite some sections of code if it gets really ugly, but usually it is make it work. This does mean code that isn't always the prettiest.

Sergei Troizky · Aug 6, 2009

I always try to follow certain rules when forced to "patch" programs:
- Fix one issue at a time and test the changes.
- Try to test in real mode and environment (not simulator).
- Sometimes it worth to not delete unsuccessful code modification, but disable it and write proper comment. This may save lots of time if another day the same "insight" comes into mind.
- Comment generously and usefully. You are doing it for future yourself, not for somebody else.

Colossalnut · Aug 7, 2009

I must disagree with Sergei... NEVER do anything just for yourself! I'm sure that you've endured your share of headaches trying to figure out what someone else did before you came along. I know I have. I've also run into strangers who have recognized my name from notes I left in various machines from years past! They thank me for detailing the why and how I did what I did. I always try to think about the next guy....

Colossalnut · Aug 7, 2009

P.S.
I totally agree with Sergei's other "rules"...

mordred · Aug 7, 2009

I agree with everything said here one situation I had was they anted different timing on a conveyer merge on an accumulation conveyer I told management that it was unnecessary due to the photoeyes detecting how full the conveyers are. They did not believe me so I said OK I'll change it each shift. Instead what I did was hook up the laptop, played a quick game of solitaire when it looked like I was done the Managers would say thanks it works great!! 6 months later I finally told them the truth. Since then I never had to make those ghostly changes LOL. Now back to this thread Are the changes the same each time? If so You may be able to activate a different sub routine for the different programs that you can activate via an input

Maintenance Man · Aug 7, 2009

Thank you all for some more good information. What I have learned from your posts, is that some of the code can be rewrote if it has to be but usually it can get ugly as long as it works. Comment generously for my future use and the use of others to make the program easy to understand the why and how I did what I did. And last but not least; because management wants a change and it does not need or it will not help the process at all; tell them you made the change and see what they say. If management is happy, I am happy. mordred, the changes I have been making is mostly timing issues where they want the product to move through the machine a certain way at a certain time. They are now happy with my program in which it does not look bad at all. Again thank you all for your help.
Sincerely:
Maintenance Man

godfrey · Aug 7, 2009

How do you do rev control? Do you rename the program each time? Is the naming convention logical? I like to put the date in the filename. It has been useful to me to look back at past revs of code to find that something that used to work, no longer works.

Sergei Troizky · Aug 8, 2009

Colossalnut said:
I must disagree with Sergei... NEVER do anything just for yourself!

I never said JUST for yourself.
I meant do it as for yourself, meaning as well as possible and not relying on own memory.

Forgot to mention another rule:
There is no such thing as "minor change", assuming certain level of program complexity.
Whatever minor and obvious it looks, expect unexpected.
The subrule is, never make "minor changes" if you cannot perform reasonable test run.

Common way people write programs.

Maintenance Man

Member

OkiePC

Lifetime Supporting Member

JSPLC

Member

Maintenance Man

Member

ojz0r

Member

Greg Dake

Member

Maintenance Man

Member

aswilson

Member

Sergei Troizky

Member

Colossalnut

Member

Colossalnut

Member

mordred

Member

Maintenance Man

Member

godfrey

Member

Sergei Troizky

Member

Similar Topics