[Lua][Redpower Frame] Elevator is missing floors.

So here's the setup. The elevator has the computer console on it. A single bundled cable out the right sends the motor signals and receives input both from the call floor buttons, the colored cables denoting the floors, and the alternating gray/light gray encoder. The frame motors are spaced 4 blocks apart so there is only ever 2 (1 up and 1 down) in contact with the frame at any one time (in theory). It's gotten a lot more complicated as I've tried to solve this. The elevator pretty much goes from the top of a volcano to bedrock so a traditional long shaft twin motor style isn't feasible.

Here's my routine for going to a particular floor:

nextCol = colors.gray

function toFloor(targetFloor, direction)
while rs.testBundledInput("right", targetFloor) == false do
	 rs.setBundledOutput("right", direction)
	    sleep(0.2)
	    rs.setBundledOutput("right", 0)
	    sleep(0.2)
	    while rs.testBundledInput("right", nextCol) == false and rs.testBundledInput("right", targetFloor) == false do
		 sleep(0.1)
	    end
	    if nextCol == colors.lightGray then
		 nextCol = colors.gray
	    else
		 nextCol = colors.lightGray
	    end
	    sleep(0.2)
    end
end

If I mess with the sleep code at the end I can get it to stop missing floors but it takes a very long time to travel. I've tried tuning it to the point where it doesn't miss and 0.3 is still causing a miss though not as often. What's happening is for some reason the frame motors every so often are moving 2 spaces instead of 1 as if the frame motor wire had a noisy signal. With the shaft encoder technique I've caused it to stop plummeting to the center of the world but of course it's getting stuck on lightGray waiting for Gray to show up.

Originally it just pulsed the direction control colored wire on and off until it detected the input for the target floor but even that was behaving screwy without causing it to wait 1 second for each floor (0.5 on 0.5 off). I'd rather not solve this with a second computer or pistons or anything like that, it's honestly complicated enough as it is.

Now that I think about it, the issue might come down to the delay sometimes seen in redpower wires. Say the elevator is moving down. While in transit, there is a period of time where the elevator is in contact with 2 frame motors going in the same direction as it moves off 1 motor onto another. If there was a redpower delay between the motors (the bottom one starting late), that might cause it to move two blocks in 1 pulse like I'm seeing. In which case I have no freaking clue how to solve this lol.

I've done something like this some time ago, frame elevators are really slow and hard to setup, because a single block can prevent the elevator from moving.
I think your problem is related to the hardware, not the code.

Last time I tried this, CC computers on a frame were rebooted by frame movement.
That, or variants, would lead to this sequence of events:
Your program raises the rs signal.
The frame moves your computer.
The computer is shut off or deactivated until it arrives.
The frame arrives, and the computer is reactivated.
The computer may still be transmitting a redstone signal. Since there was no "active" computer transmitting during transit, this is seen as a new pulse.

If your computers aren't rebooted entirely (what versions are you using?), that would explain how different sleep values affect the outcome. Even more so because it would explain the intermittency of your results.

The "shaft encoder" is nifty. Somewhat more advanced than the wires I used for detecting when a frame reached the end of its movement. (Counting pulses is unreliable, what if it had run out of power?)

It's not as if CC computers are expensive, so I'd probably go with a CC computer at each floor, to control each pair of engines, prompted by the destination floor the on-elevator comp puts onto the cable (rather than it reading its current floor) - add a cable for "at the exact position for a floor" which it can use to know when to stop, and you'd be set.
Then again, before talking maybe i should actually load up a 1.2.5 world and actually try building something like that? :)/>/>