Finding bugs

Problem: when running the Fibonacci calculation at "Babbage speed" of 157 milliseconds per digit, it sometimes jammed.

Of course, the root cause is something that happens earlier. One tool for finding such problems is a high-speed video capture that can look back in time, like a logic analyzer.  

Doing that showed the bug: in my implementation of the anticipating carriage, the carry sector keepers started to move to the "restore" configuration before the figure wheels had been locked. That caused an additional half-digit motion of the carry sector and the digit wheels. The lock wasn't able to correct that much error, so in the next cycle the linking pinion was not able to mesh.

Here's the annotated video at 1/5th speed.

Diagnosing the problem was tricky, but fixing it was not, because until the control gets implemented as cams in hardware, it's all in the temporary microprocessor "nanocode".  All that was needed was to change

"carry add; ",
"keepers top; lock F; setcarry nowarn time 50 199;", // do nowarn only if F is locked
"keepers down; ",

to

"carry add ",
"lock F; keepers top delay; setcarry nowarn time 50 199;", // do keepers and nowarn only after F is locked
"keepers down; ",

Since a "lock" operation only takes a half time unit, delaying the "keepers top" to the second half of the time unit ensures that its motion won't affect the carry sector or the digit wheel. 

It's now pretty reliable, but I have no illusion that this is the last bug. I'll keep testing.