Ken is absolutely right!
Start from the end, the outputs, and work your way back to the "causes".
RUN IN
AUTO E-STOP
---| |---+---| |---( ) MOTOR
|
RUN IN |
MANUAL |
---| |---+
Then develop your code for the Manual Control, using Start/Stop Buttons, and the Auto Control, using whatever conditions are necessary.
The E-Stop shouldn't be used until the last rung where the actual output is controlled. That makes it very easy to determine right away if you have an E-Stop issue.
When you need to troubleshoot a particular output, go to the output, check the status of the conditions that should be driving the output.
If you don't have an E-Stop issue, then, knowing which condition should be driving the output, if that condition doesn't exist, go to that Control Relay Output and examine the code there.
You have to "think-out" the general concept before laying a single rung!
And, as has been mentioned, the best way to "think-out" the process is to write a general, verbal description of what you want to happen. This will help you to create a general description of the various modules within the process.
You can then move on to fill in the details in each of the modules.
It all boils down to the scheme that you were taught in grade-school on how to develop an Outline. Before you can even start the Outline you need to know what you are trying to accomplish. Then you fill in the general ideas that are necessary to reach that goal. Then you "flesh-out" the general ideas, and thus, the entire project, into functioning code.
What are you trying to accomplish?
Generally, what are the things necessary to support that goal?
What does it take to make those "things" happen so that you can reach that goal?
You go forward by moving backward... from the desired effects back to the required causes.