Best way to design a program

[Matchu04]

Evening all...

I have got to the stage at work where I am taking on more code writing then, fault finding. My problem is, my current approach is trial and error to some degree and would like to try and be a bit more professional in my approach.

Im basically looking after a old kegging line that is S7 but converted from S5 about 10 years ago. A lot of changes have been done, and there not all for the good... What approaches do you guys use to get the correct logic.

The part I am working on the minute is a dual fed infeed (T junction style), that allows kegs to be conveyed to a racker. There is escapements on both legs that restricts the kegs going in, and various PEC's to detect keg transitions around the escapements.

I know its not the biggest task to hand but I wanted to try and go about it with a more planned approach. How do you guys / gals get it done..??

Matty

 

[Patfu!]

It sounds like you know how it works so I would start with a sequence of operation. If I don't have something very similar to start my program with I write on paper what I expect the equipment to do. Step by Step write out the sequence and try and think of the "what if's" while you write it out. You may also find out why the "not so good" changes don't work as well as they should . That's my two cents.....

 

[RussB]

It sounds like you know how it works so I would start with a sequence of operation. If I don't have something very similar to start my program with I write on paper what I expect the equipment to do. Step by Step write out the sequence and try and think of the "what if's" while you write it out. You may also find out why the "not so good" changes don't work as well as they should . That's my two cents.....

Good advice there. ^

I also try to keep the 'control' and the 'diagnostics' separated in logic, usually with subroutines or blocks.
A lot of basic diagnostic information is "IF" this does not happen "Before" that or within "this amount of time" something went wrong. By keeping that type of logic out of the actual "Control" it simplifies the "Control" and speeds troubleshooting.

I like to promote getting the "Control" written first and as "basic" as possible. Once it is proven, then write the diagnostics and do all of the "What if's" in another part of logic, keeping "Control" clean, mean & fast.
YMMV.

 

[Matchu04]

Thank you for your input guys, I have not had chance to revisit this again but, I have started to plan it on paper, managed to find a video that I found quite helpful. I will post the what I have done so far, this week when get the chance so you can see what you think...