Posts

It computes the Fibonacci sequence!

Image
 I finally got my prototype to do a real calculation: computing the Fibonacci sequence F(n) = F(n-1) + F(n-2). Started with 1 and 1, the sequence is 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377,... Here's a still image after it just computed 233, and here's a video of it computing all the numbers from 2 to 377. (The resolution is poor because Blogger has a 100MB limit on videos.) It's running at the full "Babbage speed" of 157 milliseconds per digit. I consider this my first real milestone! There are three phases to the computation, assuming F(n) is on digit wheel A1, F(n-1) is on anticipating carriage wheel F, and digit wheel A2 is zero. add A1 to F, while simultaneously preserving A1 by copying it to A2. move F to A1 move A2 to F Repeating that generates the Fibonacci sequence on A1. Here's the detailed microcode: //**cycle 1: add A1 to F while simultaneously copying it to A2    "finger A1; mesh FC; mesh MPC A1; mesh FPC A2; keepers up; unlock F del...

On not compounding 3D printing sloppiness

Image
Part of the motivation for using 3D printed parts to to explore the limits of what can be done to implement Babbage-like mechanisms with parts that have poor dimensional accuracy. My Lulzbot Taz 6 printer has a nozzle diameter of 0.5mm, which is 0.02", or 20 mils. The feature accuracy is probably twice that, or 40 mils. Standard machinist tolerance for metal fabrication is 5 mils, so we're about 8 times worse. There are many places where the inaccuracy doesn't matter, or where a little hand-finishing with sandpaper can improve the fitness. But there are some cases, especially where two printed parts interact with each other, that are unfixable. One example was the scheme I had devised for digit wheels that allows them to stack without resting on each other even though there are no framing plates like Babbage used for many of his designs. When built entirely with 3D-printed parts, it required two concentric cylinders to fit closely together. It's a bit of a challenge to...

anticipating carriage success

Image
I finally rebuilt the entire mechanism using the fixes that worked in the partial test jigs, as described in the September 30th and October 30th posts. Success! Here's a video that shows it correctly adding 5678 from the digit wheels to 0322 on the carriage, which produces 6000 by executing one direct carry and a two-level chain of anticipated carries. It's running at 500 milliseconds per time unit. Well, I shouldn't call it a success yet, since it's not reliable. There are marginal clearances and motion stutters that have to be tracked down and fixed before it meets that bar. It will get a passing grade only when I can reliably compute an arbitrarily long sequence of Fibonacci numbers.  Addition takes 18 time units. Here is the microprogram for it, which currently runs in a microprocessor and controls stepper motors, but eventually would run from the Babbage-style program barrel and control cams and rods to create the same lifting and rotating motions. {"add"...

detents

Image
Babbage was not a fan of springs, which at the time were not uniform and were prone to failure. One of his 1837 "Principles of the Engine" was "to have no springs to do work, only retaining springs". But he certainly made liberal use of spring for detents, which impose one or more preferred locations for an otherwise continuous movement. It is, as Tim Robinson observes, a "soft" version of the locking that he uses when parts should not be moving at all. Here are examples, some of which include the option of a hard lock. So how to easily implement detents, with fewer parts -- and in particular fewer vertical shafts? My first attempt was to use a "spring plunger" from McMaster-Carr, which is an acetal plastic nose in a steel 8-32 threaded case, with an embedded spring that provides 1 to 3 pounds of force. I used it screwed into a 3/8" vertical shaft and had it engage with notches of the kind Babbage showed. It works, but the small 1.7mm tip si...

fixing problems with subtraction

Image
Solving the interference problem describe in the last blog post was fun and gratifying, but ultimately pointless because there was a more fundamental design problem that was revealed by hand-operating the mechanism for subtraction.  Using the carry sector lifters for four different functions was clever, but one of them failed: forcing a "warn" on carry warning arms that were raised by movable wires (so that the raised sector lifters could be forced down) allowed the wire to fall before it should if it had been in the "detect 0" position for subtraction. So there needed to be a different way to return the sector lifters. I thought that would require an additional articulated mechanism: another stepper motor in the prototype, or another cam follower in the eventual all-mechanical version. But it turns out that all it takes is a scythe-like keeper above the carry warning arm that moves vertically with the arm but is fixed in rotational position.  This is a great simpli...

debugging the anticipating carriage

Image
In playing with the manual test jig for the anticipating carriage, there was one configuration that caused interference between two parts. It became clear that I needed to do a systematic analysis of all combinations of vertical motions. There are four basic vertical configurations which have to accommodate various part motion:  the rest case where all warning arms and sector lifters are down the non-carry case, where the arm is "not warned" and is raised, and the sector lifter is not raised the direct carry case, where the arm is "warned" and raised, and it raised the sector lifter the propagated carry case, where the arm is "not warned" and raised, but the sector lifter has been raised with the movable wire The analysis showed that it was case 2 that caused interference, when the sector lifters were rotated to the position which forced the arms to "warned", which is needed so that case 4 sectors will be engaged and positively lowered when the w...

the "Anticipating Carriage"

Image
Of the many clever mechanisms in the Analytic Engine, the one of which Babbage was most proud was his "Anticipating Carriage", which accomplished the ripple carries during addition through an arbitrary long string of 9's (or borrows during subtraction through a string of 0's) in a single time unit. He spoke of it in almost mystical terms as "teaching the Engine to forsee". From "Passages from the Life of a Philosopher", 1864 But Babbage didn't invent it just once. In  his draft monumental book-length technical history of the development of the AE, Tim Robinson catalogs 88 different versions created over 35 years, most of them incompletely described, and of course none of them proven to work by having been built.  The underlying principle is the creation of a chain of fixed and movable "wires" (which are actually stiff rods) that link together consecutive 9's that must be turned into 0's during addition. For a simplified explan...

mechanical clearances: good or bad?

Image
To investigate why the lock on the fixed long pinion was so important in making number transfers reliable, I slowed down and single-stepped the copy operation, and watched carefully. What I discovered was that in "giving off" the first non-zero digit, the source digit wheel was not turning a full digit position -- it was only moving about 80% of the way.  Why? Because there was too much free play between the finger on the axis and the nib on the digit wheel. It turns out to have been intentional, because the design provided clearance to allow for the elevation of the finger to the level of the nib without any possibility of interference. The digits are spaced on the wheel by 18 o . The finger width was 8 o and the nib width 8 o , for a total of 16 o , which provided 2 o of clearance. In this case clearance is a bad thing because it produces a dead zone of movement. I changed it to instead have negative clearance of 0.5 o by increasing the finger width to 10.5 o , and usin...

the virtues of locking

Image
I implemented Tim's suggestion to do Babbage-style consecutive locking from source to destination, instead of engaging all the locks at the same time.  Each locking takes half a time unit, so doing all three locks takes1.5 time units. That conforms to what Babbage seems to have indicated in his timing diagrams. Nothing changed in the operation, though, so it's not clear under what circumstances it makes a difference. Maybe it allows more misalignment to be corrected. My new little tester continues to copy numbers with 100% reliability. I decided to do an experiment to see if the new lock on the fixed long pinion had anything to do with it, so I pulled the plug to its stepper motor. The machine failed immediately. The problem was a jam when the small pinions tried to mesh with the digit wheels. I think the issue is not that the new lock corrects small misalignments after the operation, but that it prevents derangement when the four-gear pinion train (small to fixed long to mov...

gear design success

Image
Finally, I have a scheme for the gear design that seems to work. To cut right to the chase, here is a video showing a 4-digit number being flawlessly copied back and forth ten times between the two numbers on a digit stack, through both fixed and movable pinions  The "unit of time" is 0.157 seconds/digit, which is the speed Babbage proposed for Plans 16 through 28. The movable pinion also allows for shifting: multiplication or division by 10.  the mini-tester for digit wheels and long pinions How did I get here? At the time of my July 11th posting about gears, I was still plagued with excessive backlash, among other problems. Tim Robinson came over for the day, and we brainstormed ideas. We decided that the change to two teeth per digit had been a bad idea, and that we should go back to one. That simplifies the design because the gear teeth can again be used for locking, rather than having a separate locking wheel. But, critically, we would stay with two cycles of 0-9, which ...

An aside: Piers Plummer's Difference Engine

Image
An absolutely extraordinary partial model of Charles Babbage's Difference Engine #2 was built in 2017 by Piers Plummer at Royal Holloway, University of London. You can see it in action here: Amazing! It is a simplified version of the DE with 4 columns of 6 digits each, opened out more than the original design for better visibility. It is made of 3D-printed and painted nylon, laser-cut steel, and other standard modern parts. "And of course, it had to be powered by steam!" In order to learn from their detailed design, and to see that it gets the public exposure and preservation that it deserves, I asked for and received permission to make the CAD files available. They are now on GitHub here: https://github.com/LenShustek/AnalyticalEngine/tree/main/Piers_Plummer_DE The design files were made with Solidworks. For those of without access to that CAD software, I created and included JPG images of each of the parts and assemblies. This was a project with the Centre for Software ...

rethinking gear teeth

Image
The prototype mechanism has been reinstalled using the new framing plates made on an NC milling machine, and there is clearly an improvement. The gears move more smoothly and, unlike before, perform the same on top as on bottom, thanks to the now precise and vertical axle positioning. But the crippling backlash problem remains, despite the fact that the center-to-center spacing is now nominal for the gear diameters, not expanded. The problem, I've concluded, is in the gear tooth design. I've been naively using the Solidworks "Toolkbox" to design what I expected to be gears with standard 20-degree pressure angle involute teeth. Now I discover this disclaimer in the fine print of their documentation: "Toolbox gears are representations for machine design purposes. They are not true involute gears that you can use for manufacturing."   Nice . What's more, there doesn't seem to be a backlash adjustment in their complicated set of equations, which are anyw...

making the next set of parts

Image
My 3D printer (a Lulzbot TAZ 6) is operational again after replacing the controller board because of a bad stepper motor driver.  In the meantime I found a generous machinist with a big CNC mill who is making the framing plates. While I wait for those, I'm printing and stockpiling the assortment of odd-looking pieces that will be needed for version 2 of the prototype assembly. The most complicated of the framing plates is the one to which the 18 stepper motors are attached. Half are for rotational motion and half are for lifting motion. This prototype has one digit wheel stack holding two 4-digit numbers, a set of fixed and movable long pinions that can shift up or down to effect multiplication or division by 10, and one anticipating carriage mechanism that can add or subtract. That will be enough to do simple repetitive calculations, like of the Fibonacci Series. It is not enough to do multiplication or division. I've worked out a scheme to do that, in the next version, with o...

new gear parameter trials

Image
 I've been experimenting with new gear parameters using two teeth per digit -- see the previous post -- that should be more tolerant of backlash. The results so far are encouraging. For the prototype driven by stepper motors I'm looking for access to a CNC mill capable of making precisely-located holes in 12" x 18" acrylic plates that are 3/8" thick, and I have two good leads. In the meantime I have made a couple of small manual test jigs using my 8" x 10" Genmitsu CNC router to make the holes in the smaller framing plates for those. long pinion manual testbed anticipating carriage manual testbed Both seem to operate pretty smoothly even though the axle-to-axle spacing is at the spec for the gears, unlike the extra-wide spacing I had to use before that made the backlash worse. In the process of playing with the anticipating carriage mechanism I found and fixed several bugs in my original design: The reset pin on the carry sector lifter could interfere w...

gear backlash woes

Image
 Changing the long pinion meshing to be to the inner gear solved the problem of bogus multiplication by 1.35. But now there is another problem:  random subtraction of 1. The root cause is excessive gear backlash. When configured for addition there are four gears between the digit wheel that is "giving off" a source digit and the digit wheel in the adder ("anticipating carriage") that receives it.  If I hold the destination carriage wheel I can wiggle the source wheel almost a complete tooth -- which is a full digit -- without it trying to move the destination.  In doing a transfer I can get it to work correctly by "preloading" the gear train. But if I don't do that, then the first digit being given off might be absorbed by the slop in the gear train. This is clearly a major problem. There are three contributors to the backlash: The center-to-center spacing of the shafts is slightly larger than the gears were designed for, which had to be done to make m...

fixing a gear ratio problem

Image
 After various mechanical tweaks to allow too-tight gears to turn, the prototype is starting to come to life. But even just moving a number from one digit stack to another disclosed a bug: in the process it multiplies by 1.35! Sort of. Here's the deal... Changing a number wheel by one digit up or down means rotating it about the axis by 360/(3*10) = 12 degrees, because there are three repetitions of the digits 0 through 9 around the circumference. Since there are 30 teeth on a digit wheel, each full tooth movement represents a change of one digit. When a chain of gears is linked together, a movement by exactly one tooth is propagated unchanged through all the gears -- regardless of the diameter and number of teeth of the intermediate gears -- as long as all the gears have the same tooth pitch. That is a parameter called the Diametral Pitch (DP), which is the number of teeth per inch of diameter of the contact circle of the gears. Following Babbage's Plans from 13 through 28, I ...

"programming" the prototype

Image
  Now that the prototype shows signs of coming to life, it is time to consider how to animate it. The axles are rotated and lifted from the "21st century" section on the bottom that is filled with stepper motors controlled with a PJRC "Teensy 3.5" microcomputer. Here are comments from the source file of a motion script interpreter I have written for it:    The following axles are implemented in this first prototype:           C    carry sectors for adding 1       F    the anticipating carriage digit wheels       FC   the connector pinion for above to FP       FP   the fixed long pinions       FPC  the connector pinion for above to either A1 or A2       MP   the movable long pinions       MPC  the connector pinion for above to either A1 or A2       A1   the upper number i...

ditching the lifter springs

Image
The initial version of the prototype had all the axles fixed. Vertical motion was effected by moving sleeves surrounding the axles that the components to be lifted (digit fingers, pinions, carry levers, etc.) would be trapped between. When the lifter was lowered, a spring on the top would push the components back down. There were two problems with this approach: The sleeves were long and introduced too much friction sliding against the axles. The spring force was often inadequate to move the components down. Besides, Tim Robinson says that Babbage never wanted to depend on either springs or gravity for positive motion. Consequently I redesigned the lifters so that the components are fixed permanently to the axle, and the axle is driven positively to move both up and down. The components are still spaced and trapped by concentric sleeves, but they are fixed in position and don't slide on the axle. Here's what the drive mechanism on the bottom looks like for a rotating shaft that...

a better locking mechanism

Image
Tim Robinson came by to see my prototype and had a number of excellent suggestions. One of the problem areas we discussed was my locking mechanism, which is based on a rotating wedge. It doesn't work well in moving the digit wheel away from the wedge pivot point. We mused about whether a different wedge shape would help, but I thought about it later and couldn't find one that worked. Babbage sometimes got around this problem by using different and oddly-shaped locking teeth that weren't simultaneously functioning as gear teeth for meshing. To fix the problem I redesigned the lock to use a wedge that drives along a line through the digit wheel axis, and I pointed the wedge. This works much better. The downside is three parts instead of one, and a second supporting rod.  I may eventually investigate a bar lock moving in an oblique slot like in Difference Engine #2. That presents its own challenges, but it would use far fewer parts.