I concur with Bernie. This is perfect for a "state engine" type of program, but I would pad that out with a dwell time for each of the stopped states to minimize short cycling.
Your door would have the following obvious states:
0) reset position unknown?
1) fully opened stopped
2) travelling downward
3) fully closed
4) travelling upward
5) stopped during travel (dwell)
and perhaps:
6) Fault! overtravel
7) Fault! Motor fault
8) something I forgot or want to add later...
etc.
These states are mutually exclusive, only one of them can be active during any scan.
Draw those out in a circular pattern of blocks like numbers on a dial clock, then draw lines between the states as you need to allow them to occur.
On those lines, write down the conditions for the transition. How would you allow the door to go from one state to the next?
Example1: To go from Fully opened to travelling downward I need the E-stop monitor and the rising edge of PB1...
Example2: To go from "reset, unknown position", if LS1 is on and LS2 is off then transition to "fully closed", if LS1 is off and LS2 is on then transition to "fully opened".
This chart can be studied and perfected (use pencil) and then directly translated into solid ladder logic. I can find a link to an example using my preferred style for the structure and data types, just ask.
The logic just uses the transition instructions in series with commands to clear a group of bits and then latches the bit for the presently selected state. One of those bits are reserved (the most significant bit) as a marker to restrict multiple state changes per scan of the transition or stepping code. This allows the logic controlling the states to be compact and orderly, only one rung per state covering them in order.
After that logic, the outputs are mapped on OTE rungs in series with any mode control bits to the left of them, and preceding those would be the Step Bit examine instructions in parallel.
So it is obvious that, for example, motor X1 coil is turned on when in states 2 and 4 with simple ladder code, and a search or cross reference for the step bit turns up the OTL showing the transition that got you to that step, and the other state transition rungs around it along with your paper chart, or searching the results for the XIC of that bit will help you find all the states that it can lead to.
It is also obvious when looking at the state changing section of the code, that if there are three branches, then there should be three lines on the paper chart pointing to that step, and those steps should be easy to identify looking at the addresses of straightforward bit examine logic.