There are different methods. You need to organize your work and you need to organize your program.
RESEARCH
My basic approach is to find out everything there is to know about the process / machine before I even write one line of code. I do research and I do most of it in the field, not in the office. I can spend a lot of time on this because I know this is what could ruin the entire project otherwise. Rockie programmers don't do this enough IMHO.
If I get handed a program specification then I know I have a lot of work ahead of me trying to figure out what they really need and what they didn't think of when they wrote the specification.
SOLVE PROBLEMS / PROTOTYPING
Then I identify any potential problem areas. Things that I am not sure about or haven't done before. I start by testing things and doing small prototype programs just working on these specific things. So basically I start with what I anticipate being the hardest things to accomplish. Starting with details is called bottom-up design, but I do it only for "unknowns".
PROGRAM STRUCTURE
Then it's time to find an overall structure for the program. This is called top-down design. Basically I structure my program after logical section of a process or machine. I don't structure it after what the programming is going to do.
So everything that has to do with one part of a system is together in one place. All data and all functions and processing related to that logical section. This is called encapsulation and is a fundamental principle of object-oriented programming. PLC's don't have an object-oriented programming language but you can use the principles anyway.
ELECTRICAL / MECHANICAL / SAFETY ISSUES
Then I start to by going through all I/O and look at the electrical schematics and pneumatics. Maybe something has to be changed. I think about safety functions as well in this stage. And where all sensors are to be placed. Mechanical drawings as well.
PROGRAMMING AND TESTING, PROGRAMMING AND TESTING, PROGRAMMING...
Then I to program making decisions along the way to find a good solution for each problem. Not just one solution, but the solution that will work best considering what the system is and how it can be implemented as well as a number of different considerations. While programming I also test it and I think about how to test the program while I do it. Testing that can be done on a machine or process in the field I'll start with as soon as I've done something worthwhile testing.
KEEPING EVERYBODY UPDATED
As the project is coming along I keep my clients updated and discuss solutions and problems if they are of interest to them. Any technical/process/machine question I prefer to discuss directly with the people that knows the most about it.
Sorry about the long rant guys!
.
