Nice set up you got there gaxx, just one question:
Why is this necessary? From the looks of things, you're activating the movement with redstone, so why not just add an appropriate delay based on how long you know it takes to move and wire that out. Also what's the pulse even for?
it's for synchronizing with the walls. the outer walls will be a quarry like door, looking kinda like this prototype (rotate by 90°, i messed this up the direction while monotonously placing lots of blocks)
when a wall and a drive direction is activated together, it will do this: open, move, close, move, open, move,..... and breaking everything in front of the wall while opening/closing. activating both is slower since the drive can't move while the walls are active but i don't want to move slowly when the walls are offline. that's why i needed a system capable of the modi: drive only, wall only, drive-wall synchronization.
everything in my ship does something in 1s ticks regulated by Timer. in theory a wall needs 3s to open/close and 2s to move, so my first design was by regulating everything with a counter configured as 6/2/3.
in practice this absolutely doesn't work!!!! the reason is bluetricity. the ship is big. it's normal that a motor needs to completely recharge once it moved. so the case that you have to wait 3-4 ticks before it actually moves is common. the same could happen to the walls.
another reason was a malfunction that could be caused by deactivating the walls while the drive is still active. in wall-drive mode the 3ticks of wall switch to drive, 2ticks of drive switch to wall. if you deactivate the wall while the drive is active it switches to "drive only". so while the wall is in the middle of an unknown state the drive completly resets the Counter, setting the unknown state of the wall as default. to correct that you had to manually move to the logic section where that is managed and repair it.
that's not user friendly!
in case it was hard to understand, the old system had two problems
first: the wall had several states: wall open<->wall1<->wall2<->wall closed where only "wall open" and "wall closed" are of interest but you could crash it so it would think wall1 or wall2 are important which needed manual repair
second: the drive could switch back to wall mode without having moved
the new system defines states only by actual physical states of wall or drive (redstone torches that disconnect when moved and reconnect at interesting state)
that way for the wall has only the states "wall open" and "wall closed" which prevents breaking. you can still temporary break the mechanism by deactivating the wall while it opens but that will repair itself by going into "wall only" mode and pressing the "reset button" i'll need anyway for "wall only". i don't want to explain that right here, would go away from the topic for some time ^ ^
for the drive it prevents switching to wall when ship hasn't moved without slowing down the drive below it's capable speed
the switch between both is managed by a Counter with 1/1/1
i know all that because i've build a prototype testing side simulation everything, so all that is the result of heavy testing with redstone logic.
that's a newest prototype. left is the wall logic, right the drive logic. the chicken is not part of the circuit 
the wires that leave the system at the bottom of the picture are part of the wall-lock mechanism, preventing the activation of a wall while another wall is not closed.
PS: a wall in a bad state with the old system would have also malfunctioned all other walls since it occupies the space the other wall wants to expand into. i think that will be obvious once i can show you a picture of the complete ship 
PSS: the vast majority of all logic involved in this ship is for managing the walls. quite extensive for a feature that's not even demanded 
PSSS: sry for the wall of text as answer 
