Wednesday, October 13, 2021

Driver for an electromagnetic pendulum

In a previous post, I described some experiments with circuits for driving an electromagnetic pendulum. The results were not very satisfactory, and for the Thriecan clock, I ended up using a commercial module. I have since revisited this, and now have something I am happier with. To recap: the pendulum contains a magnet. As it approaches the center of its swing, a sensor detects its presence, and then energizes a driver coil to impart some momentum to the pendulum. Ideally, you use one coil as both the sensor and driver. The circuit I present here uses an Arduino and a small number of discrete components.

Some initial experiments

In the first attempt, I was unable to get a strong signal from a coil: only a few millivolts. This is probably because of the geometry of the coil, which had a narrow diameter but was quite long (about 25mm), based on the one in the instructions for the Toucan clock. It is better to have a shorter, fatter coil, so that more of the winding is close to the magnet as it passes by. I rewound the coil on a bobbin with a 6mm inner diameter and a length of 10mm. I did not count the number of turns or measure the length of wire. Based on its resistance (35 ohms) and the resistance per unit length for 32 AWG magnet wire, it is around 60m. The winding is about 30mm in diameter.

I wanted to know how much difference the specific magnet made, so I constructed a pendulum with the magnet on the end of a 300mm brass rod and measured the voltage when the pendulum was dropped from a known position. The magnets I had lying around were:

  • 20mm x 4mm N38
  • 12mm x 3mm N35 (I think)
  • 12mm x 3mm N42
  • 10mm x 3mm N52
All but the first gave about 0.3V. If you add a second or third one, this goes up by 0.1V per additional magnet. The 20mm one gave 0.5V or around 0.65V with two. I was a bit surprised that the grade of magnet didn't make a difference, as each unit of N rating is supposed to correspond to an extra 1% in magnetic field strength (or something like this).

The distance between the magnet and the coil also makes a difference. My test setup didn't allow me to change it much, but an increase of distance between the coil and the magnet from about 3mm to about 6mm dropped the voltage by half.

The circuit

Here is the circuit. I'll explain the ideas behind it in a moment.

(Diode: 1N4001. Transistor: PN2907.)

The voltages I measured aren't enough to register as a digital signal when connected to an Arduino and are maybe too low to switch a transistor which could be attached to a digital input. An alternative is to use an analog input of the Arduino and then set a threshold in code based on the analog reading. With a resolution of about 5mv per step, we should be able to do this. A reading of even 0.1V would be detected as a value change of 20 on the analog input.

If you search the web for advice on connecting a coil as a sensor to an Arduino, there is a lot of unclear (and possibly misleading) information. The main concern is that transients from the coil could exceed the input voltage range of the Arduino and so damage it. Various solutions involving voltage dividers or Zener diodes can be found. I don't think this is necessary. The Arduino inputs have protection diodes which limit the voltage to just above 5V and just below 0V. The issue with the protection diodes is that they can only handle a limited amount of current. 1mA might be OK, 100uA definitely is. More than that would likely burn them out. In the circuit above, the flyback diode on the coil should eliminate most of the risks, but to be sure, I designed the circuit to allow for a 10V swing. In this case, with a 100k resistor on the analog input, the current would be 100uA and we are OK. Relying on the protection diodes is something that people argue about on various forums, leading to some of the other solutions. An application note from Atmel has an example in which an analog pin is connected safely to mains at 110-240V AC. Also take a look at this.

There is one further issue with using the analog input. The Arduino datasheet recommends that the input impedance to analog pins should be 10k or less, and we want to use 100k. Looking into this in more detail, the reason appears to be that the analog to digital converter works by charging a capacitor internally and them sampling its voltage. The internal capacitor is 14pF and it should be charged in 6us or less at standard sampling rates. With a 100k external resistor, we have a time constant of 1.4us, so we should be OK.

The remaining input element is the 10uF capacitor. It largely gets rid of noise and ringing on the input without slowing down the signal too much. Looking at the signal on an oscilloscope, there is still a small and short duration spike at an acceptable level. With no capacitor at all, there are spikes for about ten milliseconds before the circuit settles down.

On the output side, we simply drive a transistor from a digital pin. When the pin is low, the transistor turns on and the coil is energized. The sensor can't be read at the same time, and that's OK as we don't need to. The flyback diode helps to protect the transistor when it turns off and the field in the coil collapses.

In previous experiments, I found that I needed external power to get enough drive in the coil, mainly due to use a coil with less good geometry. For this version, the 5V output of the Arduino worked fine. Its Vin can also be used if a higher voltage or current is needed. I experimented with an Arduino Uno, but will move to using a Nano soon.

The code is similar to the version I gave before, namely:
  • read the sensor
  • when it exceeds a threshold (20), wait (10ms)
  • turn on the coil (200ms)
  • turn off the coil, and wait a little longer (10ms)
  • keep going
I still have to tune the exact timings and the threshold. These values give a very strong swing to the pendulum. Currently I am not using a weight bob or tuning to 1s per cycle, and this may affect the timing and possibly the voltage needed to drive the coil.

I've not fitted this to the Thriecan clock. My intention is to use it for a possible future design.

Sunday, October 10, 2021

The Thriecan Clock

 The Thriecan Clock is a modified version of Clayton Boyer's Toucan clock, adapted for 3D printing. The key feature of this clock is a electromagnetic pendulum. There is a magnet attached to the end of the pendulum and a coil hidden in the base. As well as providing the timing, the pendulum also provides the energy to drive the clock. As the pendulum approaches the vertical position, the electronics attached to the coil senses the magnet and applies a pulse to the coil. This pushes the magnet and hence the pendulum away and the process continues. The top of the pendulum is attached to an arbor and this turns a cam with two pawls. One pawl, called the pick-up pawl, pushes on the escape wheel. The other pawl then holds the escape in place while the pick-up pawl moves back for the next cycle. The remainder of the clock is a standard gear train to divide the rotation of the escape wheel down to minutes and hours.

The version you see here is not quite final. I am going to replace the battery pack with power connector so I can connect it or a different power source. There is enough room to locate the battery pack in the base, but it disrupts the operation by attracting the pendulum. There's also a few screws sticking out while I make final adjustments and I will then replace them with shorter ones.

Adapting the design

The original design was intended to be made out of wood. You can see many examples on the Toucan clocks YouTube channel. I bought a copy of the plans in DXF format and loaded them up into Fusion 360 to provide a starting point for the sketches. For parts where the dimensions were critical, I used these sketches directly, and for others I either adapted them (for example, the cam) or replaced them entirely (for example the weight bob). The original design used 3/8 inch arbors, and I replaced these with 3mm ones. Instead of printing separate gears, connectors and pinions and then gluing them together, I merged them into a single part. This is something which works nicely for 3D printing, but it difficult or impossible in woodwork. I undersized many of the holes for the arbors and for the pendulum shaft and drilled them out to either a tight fit or a loose one. I've not always been successful in getting good tight fits and so where possible I also provided holes for set screws.

One of the hardest parts to adapt was the frame. It is much too big to fit on the printer bed. It's possible to split up large pieces like this and then glue or otherwise connect them. However, I didn't like where the splits ended up so I changed the shape of the frame. It still needs to be split into three pieces: the main part of it, the left foot, and the curve reaching down to the right foot. You lose the nice curve on the left hand side of the original design by doing this. The joins are hidden behind the dial on the left and where the arc on the right joins the vertical part. In each case, as well as gluing the parts, there are some metal pins joining them. These help keep the parts aligned while the glue sets and provide a little extra strength. The dial is also slightly smaller, and has a central bar to help support one arbor and the hour wheel. It's held on to the frame with two M3 screws. I didn't really think ahead here, so I ended up having to use 45mm screws with a bit of padding behind the frame to get the length just right.

One reason for wanting to try this specific design was to see how easy it is to start with a plan designed for woodworking and adapt it for 3D printing. It worked out somewhat well. The process was a bit hindered by the ways the plans are supplied: the DXF is a single gigantic file some parts of which are actual plans, and some parts of which are descriptive text, assembly diagrams and other auxiliary information. It seems an odd way of doing things. Fusion 360 gets a bit heated when you load all this in, and so a fair amount of initial pruning was needed. I'm also a novice with Fusion 360, so the way I did some things might not be best.

The pendulum

The pendulum is a 2mm brass rod with the magnet holder as the bottom and the weight bob around the 25cm mark. Adjusting the position of the weight is a bit fiddly as it involves loosening the screw underneath it, and sliding it up or down. The bob holds quite tightly to the shaft so adjustment can be down without tightening the screw until it is in its final position. The weight itself is a few M3 screws in the shiny little bucket.

The pendulum is connected to the cam with a 3mm brass shaft. This is a problematic part of the design, as the weight of the pendulum is greater than that of the cam and pawls, causing the shaft to tilt to the back. There are a few ways this could be fixed; perhaps a counterweight on the front, or a longer support glued to the back of the frame. Another option would be to move everything in front of the from forward and lengthen the shaft. For now, it works OK as it is.

One tooth or two?

Looking at the examples of the Toucan clock on YouTube, there are two different philosophies about the position of the pick-up pawl and the stop pawl at the point where the pick-up pawl starts to push on the escape wheel. They can either be on adjacent teeth like this, or separated by one tooth like this. The clock runs either way, and you can set the way it works by adjusting the angle between the pendulum and the cam. It may make some difference to the required swing of the pendulum. Looking at the first 10 videos on the YouTube list, I saw 8 were adjacent (the Toucan closes its beak) and 2 were separated (the Toucan eats with its mouth open). I went for adjacent, which sets the cam a bit anticlockwise from the pendulum.

Driving circuit

I experimented with various driving circuits. As mentioned in a previous post, I had no success with getting a 1 or 2 transistor circuit to work, and after fiddling around for a long time, I wasn't happy with any of the other options I tried. In the end, I decided to buy a ready made module from carveshop. It works well, but is a little pricy. I plan to spend some more time looking into this, in part because I have a second electromagnetic pendulum clock I would like to try.

Sunday, October 03, 2021

An electromagnetic pendulum

 For a future clock project, I would like to construct an electromagnetic pendulum. The pendulum has a magnet at its tip, and base contains a coil of thin wire. We aim to detect when the pendulum is approaching, and then turn on the coil for a short time to add extra energy. This can be done by turning on the coil to attract the magnet before the pendulum reaches the center (vertical), or waiting until it has passed the center and turning on the coil to repel it.

There are many different ways of doing this, and it was used in commercial clocks before electronic movements took over. The German-made Kundo clocks are one example. If you look on the web, you will find many articles about electronic pendulums, whether for clocks or just as toys, with a variety of different circuits. One of the best descriptions is Kundo battery clocks by Rod Elliot, with several possible circuits and a lucid explanation of how they each work. There is a 2 coil, 1 transistor design, used in Clayton Boyer's Toucan clock, and two variants of a 1 coil, 2 transistor design from the Kundo clocks themselves. In another article on the same site, Rod Elliot notes that there is some trial and error in getting these circuits going. After playing around for a few days without getting to anything reliable, I agree. I also found a site with a very similar circuit and a comment thread full on people saying how they never managed to get it to work. I'm not sure why I had so much difficulty. I know that for a few components (capacitors mainly), I didn't have the exact values and had to come up with a substitute. I tried out several different coils that I had around. Some didn't produce enough voltage to turn on the transistors. They would need more turns or more cross-sectional area, both of which affect the induce voltage. Others could clearly turn on the transistors but didn't impart enough energy the the pendulum.

There are other solutions, both analog or digital. One analog option is to replace the transistors with two or more stages of op-amps. You can then tune the sensitivity of the triggering better, and also add some delay before the pulse to the coil happens. Other solutions use a simple microprocessor like a PIC, or a TI chip.

I decided to go with a simple and highly controllable solution. I had some KY003 Hall effect sensor boards in my stock of parts, and so I just connected one to an input pin on an Arduino. The Arduino can't drive the coil directly, so I hooked up an output pin to a transistor, like this:

The transistor is a PN2222, and the Arduino output pin connects to the 22k resistor.

The code is quite simple:
  • wait until the Hall effect sensor turns on.
  • wait a while to allow the pendulum to reach the center.
  • energize the coil for a while.
  • check the Hall effect sensor has turned off (in case we are still within range).
The pendulum itself if a 30cm brass rod. I want a period of about 1 second, so there is a weight around 25cm from the pivot. The magnet is at the end. The delay after detecting the sensor should be long enough for the pendulum to reach or just pass the center. If the angle of the pendulum at its extreme is P, and the angle at which we detect the sensor is S, then the delay should be arccos(S/P)/6.28, to a first approximation. The 6.28 comes from the angular frequency being 6.28 radians/second for a 1 second pendulum. See here. None of this is exactly right, as it assumes a small angle for P, whereas I actually see around 20 degrees in each direction. It also does not allow for extra energy being added to the system. But it will do to get roughly the right values.

This is the prototype working. It needs a small nudge to get going:

Here's the code. Note this is a prototype and might change before the final version.

// Electromagnetic pendulum controller.
// Detect the magnet with hall effect sensor on this pin...
constexpr int hall_sensor = 3;

// ... then wait this many milliseconds ...
constexpr int detect_to_activate_delay = 23;

// ... then energise this output pin ...
constexpr int output = 7;

// ... for this many milliseconds ...
constexpr int activation_duration = 200;

// ... with this much slop in milliseconds when checking the sensor is out of range.
constexpr int sensor_cooldown = 10;

// Use this pin for LED.
constexpr int led = 13;

void setup()
  pinMode(led, OUTPUT);
  pinMode(output, OUTPUT);
  pinMode(hall_sensor, INPUT);
  digitalWrite(led, LOW);
  digitalWrite(output, LOW);

void loop()
  // Sensor reports LOW on detecting a magnetic field.
  if (digitalRead(hall_sensor) == LOW) {
    digitalWrite(output, HIGH);
    digitalWrite(led, HIGH);
    digitalWrite(output, LOW);
    digitalWrite(led, LOW);

    // Wait until the magnet is out of range of the hall effect sensor, and then allow a little longer.
    while (digitalRead(hall_sensor) == LOW) {}

Additional notes

After some experimenting with this form of drive, I think there are some good and bad points.

Good points: it is very easy to build as the circuit is so simple. It's convenient for tuning the timing. You can add a few extra lines to report the time between ticks. Note that the activation delay and duration make very little difference to the timing, so this is about adjusting the position of the bob on the pendulum.

Not so good: getting both the Hall effect sensor and the coil close enough to the magnet is a challenge. I mounted the sensor on top of the coil, but this then requires a large coil to supply enough impulse. The force on the magnet goes down (if I remember correctly) as the square of the distance from the coil. To make life easy, my coil was whatever was left on a 4oz could of 30AWG magnet wire, probably about 300 metres. Anything much less than this didn't work. This could be solved by more careful design, such as mounting the probe embedded in the top of the coil or in the hole in the middle.

Wednesday, September 22, 2021

Mending broken DXFs in Fusion 360

I recently downloaded some DXFs originally designed for use with a CNC machine, with a view to converting them into something suitable for 3D printing. Blender is my go-to for quick manipulations, but in this case I wanted some more advanced tooling and so I decided to use Fusion 360. I had multiple problems, and so I decided to document them here in case this helps others in the same situation. The root cause of most of the problems is disconnected segments. It seems that some programs which output DXFs will leave a small gap between segments. As a result Fusion 360 can't find closed curves and this prevents it doing many important operations such as extruding. The DXF file I am working with is about 4MB and contains around 30 separate items, some for parts such as gears, and a few to illustrate how the parts fit together. I'm only interested in the former. I also tried cutting one part from the sketch into a new sketch for some tests.

You can recognize when there are broken segments if extrude and similar operations are not available, or if you hover over what looks like a closed curve and it does not all highlight. Generally you have to zoom in a long way before you can find the segments that are not joined. If there were only a few of these, fixing them by hand would not be too much of a burden, but when you have each gear has two or four of these per tooth, it quickly becomes time consuming.

A first thing to note is that Fusion 360 has two ways of importing DXFs. In both cases, the result is one or more sketches. The options are:

  • From the Design > Insert menu, there is an Insert DXF function. It seems to be essential to set this to "One sketch per layer" to avoid it taking a very long time. In the file I was working with there were 9 layers.
  • Use the DXF Import Add-in, from the Fusion 360 App Store. I was hopeful about this, as it includes an option to fix the sketch by joining close elements, either on import or as a separate operation. The fixing stage appears to be extremely expensive. I tried importing the large file with the fix option turned on, and after several hours it was still going. I doubt that it would complete in a reasonable time, as by that point Fusion 360 was using around 7GB of RAM, forcing my PC to continually swap and so grind to a halt. With the smaller sketch, I didn't run up against the memory limit, but the fixing stage simply didn't do anything. Note that the Add-in does not allow you to set the units (DXF files don't specify what units they are in), a curious omission.
I then looked at other scripts and add-in designed to fix cases like this. I found three:
  • ConnectTheDots is a Python script. The example video shows it working on exactly the case I wanted. It operates on the selected part of sketch, which I though might allow me to concentrate on just the parts I was interested in. Unfortunately, the script does not work with current versions of Fusion 360. It raises a Python exception. It appears to be unmaintained.
  • ConnectTheDots (another one) is a fork of the original version. It does not raise an exception, but never seems to complete.
  • FillGaps is a paid add-in. It costs $10. There is a free preview version to try it out, though the preview is not very useful as you can't examine the resulting segments. It can join nearby disconnected points by either adding a new segment or merging them. It doesn't take a huge amount of memory, though it can be quite heavy on CPU. It works on the whole of a sketch. Unfortunately, on my large test file it got slower and slower. At the start, the progress bar (which shows percentages) advanced by 1% every 10-15 seconds. From 99% to 100% took multiple minutes, and it then stayed at 100% for an hour and a half until I cancelled it. On the small sketch (cut and paste of a single gear), it finished quickly and accurately. So this looks like a good option, with the inconvenience of having to do a lot of cutting and pasting.
One other option is to load the DXF into blender, select a part from it, convert it to a mesh and then use Blender's Edit Mode operation to combine vertices by distance. This works, but leaves the result as a mesh and in some cases seemed to add some distortion. You can also only export meshes as DXF from Blender and not curves: if you try to export as a curve, then it silently does nothing. However, if you want to continue doing all your modeling in Blender it might work.

A final possibility is to treat the DXF as not being part of the model at all, and just use it to guide creating new sketches with them a guidelines. This isn't great for complex geometry such as gears, but could be combined with the Fusion 360 gear generator add-in to generate gears matching the ones in the DXF.

Thursday, September 16, 2021

Steve Peterson's Stepper Clock

Steve Peterson has a design for a desk clock driven by a stepper motor. I am mostly interested in purely mechanical designs, but as I was impressed an earlier design of his, I decided to give it a go. As usual, here's some pictures and video:

The clock consists of a stepper motor driving a gear train to turn the seconds, minutes and hour hands. One of the arbors, called the "gear 5 arbor" and located at the top right, has two gears held together by friction. There is a spring clutch just behind the larger gear. This allows you to turn the knob at the back to adjust the time. The clock is driven by an Arduino Nano and a NEMA 17 motor. Normally a Nano would not have enough power to drive a NEMA 17, but in this case an uncommon type with a higher coil resistance and lower current requirements is used. There is an intermediate board designed and sold by Steve Peterson which simply connects five ports of the Nano to each coil of the motor. Each port is connected through a resistor, with values which are approximately in powers of two. The control program can then advance motor with 1/32 microstepping. The circuit has a passing resemblance to a resistor ladder DAC, though it is not quite the same. It's quiet and works well, with low power requirements and minimal circuitry.

A few places in the mechanical part of the clock rely on parts being a tight fit on their arbors. I'm not keen on this approach. With 3D printing, you have to undersize the hole and then hope to drill it out to a suitable diameter, then force the part into the right position. I found all of the parts were already too large for the arbors. The holes have a diameter of about 1.65mm and fit onto 1.5mm shafts. With some printers and filament, the hole might close up enough to make this work. For me it did not. I decided in the end to print the parts with a small transverse hole and hold them in place with M1.5x5 screws. One piece where I did this is the gear 5 insert that holds the spring for the clutch in place. It needed some care to avoid the screw interfering with the large gear at the back (gear 2, in the design). I also found that you have to be careful in attaching the knob on the back of arbor 5, used to adjust the time. If it drags on the back of the frame at all, this is enough to stop the minute and hours hands.

The stepper runs quite smoothly, but when it is attached to the gear train, there is noticeable judder. In testing, I started with just gear 2 and saw a lot of rebound on each step. It gets less as you put the rest of the gear train together. The following video illustrates:

I used Mika 3D silk PLA throughout. The gears are so-called rose gold, which is in fact a pale pink. The frame is silk black, which is more like a dark grey. I'm not all that pleased with the appearance. Either a darker black or a bright color would have made for better contrast on the numerals. Two of the parts (the stepper gear and the smaller gear on arbor 5) warped during printing, like this:

I was surprised by this. It used to happen a lot when I had a poor quality printer and used blue tape as the print surface. I have not had it happen at all since I got the Prusa MK3. The parts were OK on reprinting them.

With the code as downloaded the clock was accurate to within 2 seconds over an hour. I am tuning it further by tweaking the parameters in the code.

And a small update

The first clock in this series, also by Steve Peterson, had been working quite well and accurately for several weeks until recently. It now occasionally stops and the pendulum swing is less than it used to be. I am intending to add a bit more weight to the weight shell, but also think I probably need to take it apart and check for anything that might have slipped out of alignment, particularly on the pendulum arbor.

Wednesday, September 15, 2021

M5Stack Clock

With all that I've written recently about 3D printed clocks, I thought I should not neglect a purely electronic one. Some while back I bought a M5Stack. It's a packaged ESP32 with a screen and (in this model) some neopixel LEDs. I wrote code to use this as a clock. It periodically resyncs to a reference time if it has a wifi connection and otherwise tracks the time internally. This variant of the M5Stack doesn't have a real time clock, but there is a library for tracking the time without one. The colored LEDs on the side very gradually change color: a color encoded as HSV is picked at random and the color change until it reaches the target value. It can run off the internal battery or from USB power. Here's a few minutes of it, at 30x speed:

Not super interesting, but practical and useful.

Tuesday, September 07, 2021

Brian Law's Clock 27

Brian Law is a British designer of clocks. Most of his designs are intended to be made out of wood, and he sells plans for them on his site, He has also adapted a few of the designs for 3D printing. There is a simple beginner's design, and three designs which are more interesting mechanically. I decided to make his Clock 27 design. This is a weight driven clock with a pendulum, and the interesting feature of it is that is uses a novel escapement, designed to minimize friction. A blog post explains how the escapement works. I like the design and found it fairly easy to get it running, with only a few issues. I do think there are a few ways in which it can be improved to make it easier to print and assemble. I'll come back to these in a moment, but first some pictures and video:

The clock running:

And in slow-mo. Make sure you have the sound on for this.

When I first assembled the clock, it would run for a few seconds (20 was the longest) before stopping. The pendulum was not swinging enough to keep the clock going. I tracked this down to the gravity arm, the piece on the left shaped like a crescent moon. The blog post says that "The finger on the end of the Gravity arm needs to be adjusted so that it causes the trigger to release the Escapement wheel just before the fork in the fork in the Lifting lever [The L shaped piece] reaches the curved tooth", and this was not happening. As a test, I stuck a small piece of plastic on the tip of the gravity arm. The clock then ran, though a bit unevenly. I reprinted the gravity arm with the tip extended by 1mm, and took the chance to check over and clean up all of the remaining parts, and after that it ran smoothly.

Brian Law has several parts that are to be printed separately and glued together. For his version, he used ABS, and there are plenty of effective solvent glues for it. I used PLA, where the only glue that works well is gel cyanoacrylate. It requires the surfaces to be smooth and quite close fitting for the glue to hold. One case where it is suggested is to assemble parts like this:

There are two gears here, the big 60 tooth one and the smaller 15 tooth one. They are printed separately because of the overhang and then joined into a single piece. A single part this shape would otherwise need support to print. I found the parts did not glue well together as there is a fairly large gap around the mating piece (which is part of the upper gear). One way of improving this would be to make it a tighter fit. A better way would be to make the mating piece and the hole it goes into hexagonal. And best of all is to extend the teeth of the upper gear down and then merge the pieces into a one that can be printing as a single entity, like this:

This is the solution I adopted. I did glue some of the pieces as recommended, for example the wall spacers on the back of the frame, but also found a few more places where it was easy to modify and then merge the parts.

The clock relies on some of the gears being tight on their shafts, and the design undersizes some of the holes so they can be carefully drilled out to fit the arbors. In most cases, you could get away with a looser fit and extra spacers as an alternative. The one place where there has to be a tight fit is the 60T gear which mates which the ratchet. It directly drives the shaft it is on and thereby the minute hand. I found it was too loose at first, and so tightened the interior hole as well as adding a couple of hole for M2 set screws. This seemed to work; even without the set screws the fit was tight enough that I had to tap the rod with a small hammer until it was in place and the screws are only there in case it loosens up over time.

Note that there is an error in the bill of materials for the clock. Instead of needing three 100mm shafts and one 69mm one, it actually needs one 100mm and three 70.5mm; similarly, you need one 31mm shaft, not three. I used several different materials: stainless for the 100mm, carbon steel (McMaster Carr High Tolerance Rod) for two of the 70.5mm rods, and brass for the remaining one. This was based purely on what I had available. Brass is my preference as I can cut it with hand tools, unlike stainless, and it doesn't corrode. The carbon steel corrodes a little, and as I live near the ocean this can become a problem over time.

A few of the parts are on flying shafts (I mean ones which are only held at one end). Law suggests adding a magnet to keep them in place. I prefer a simpler solution: make the shafts slightly longer and print a tight fitting cap for them. Take a look at the second picture above for some examples.

One other issue I encountered is that once you have attached the dial to the frame, two of the screws which hold the front of the frame to the back are inaccessible.

Before I modified the gravity arm the beat was very patchy and I worried that this might be due to uneven teeth on the gears. However, once I made the slightly longer gravity arm, it ran evenly. It has met my basic test (running for 1 hour). I have yet to tune the timing and as you can see in the pictures it is still mounted on a test frame rather than on the wall.

Where next?

This is the fourth clock I've made recently, each based on a slightly different principle: hanging pendulum, seesaw pendulum, balance wheel, gravity escapement. It's not that I especially love clocks, more that I just find it interesting to make them and then get them working, and I enjoy finding complex printing projects. There's a few more designs I will probably try out. I don't leave most of them running: if I want to tell the time, there are plenty of much more accurate electronic devices within easy reach. The only one that I do leave going all the time is the Peterson clock, in part because it runs for 7 or so days without rewinding. It has stalled a couple of time in the last few days after a few weeks of working well, so some maintenance might be needed.

A footnote

A day after posting the above, I moved the clock from the testing frame to a permanent position on the side of a bookcase, and found it didn't run for more than about 45 seconds. I think this is just that it was not balanced. It took a while, but after slowly adjusting the angle it was hanging at and also adding a washer to the gravity arm to give it a bit more momentum, it seems to be running better - at least two hours without stopping.

Sunday, August 29, 2021

The problem with string

 It is, of course, well known that everybody loves string, except when you are 3D printing. In the clocks that I've made recently, there is often a lot of stringing between gear teeth which are close together. It doesn't take much to clean it up: a few gentle swipes with a piece of sandpaper generally does the trick. However, there's always some residue left behind. The common advice is to lower the printing temperature, so I did a quick check to see if this helps. I selected a gear with 18 teeth, printed it at different temperatures and counted how many of the gaps between the teeth had significant stringing. "Significant" is a bit subjective here; roughly, I mean I would feel obliged to clean it up. Here's the results:

You probably can't make out too much in this picture. The counts of stringy teeth were:

  • 210C: 10
  • 205C: 10 or 11
  • 200C: 4 to 6
  • 195C: 3
  • 190C: 3
So this validates that a lower temperature helps. 210C is the Prusa default for PLA and I think they use it to ensure a good flow. I'll certainly consider lower temperatures in future.

Saturday, August 28, 2021

TheGoofy's clock, and a digression on balance wheels

 One of the oldest clock designs on thingiverse is this model by user TheGoofy. It has many makes and several remixes. I made this once before several years ago, and never got it to run reliably. At the time, I had a printer which was much less accurate and well-tuned than my current one. TheGoofy notes in his description that it was designed for older, more inaccurate printers. I think that I couldn't make it work as a combination of what my printer was able to produce and my ability to figure out what was going wrong and fix it.

I recently had another go, with some success. Here are some pictures and video:

The video was taken while I was still tuning it, and it's quite obvious that the beat and timing are off. Here is a later version that is a bit better:

It worked pretty much straight off with only a few changes. Some of  the parts came out undersized. In most cases this does not matter, but in the pentagonal connector between the escapement spring and the balance wheel, it is important to get a good fit. The original spring is 1mm thick, and I found that the coils flopped around too much. I found a remix with a 1.3mm spring. The end of the spring has a triangular piece which fits into the frame, and this was also far too loose. At first I held it in place with some tape, and then adjusted the model to make a tighter fit. One other adaptation I needed was to drill out the holes for the arbors in all the gears and moving parts, as they were too tight. My preferred way of doing this is with a drill bit in a pin vise. It allows you to go slowly and carefully control the drill so that you don't end up skewing the hole.

I used the v1 ratchet and no planetary drum. This gives the shortest running time in the sense that the weight falls a greater distance for a given run time. As I was regarding this a more of a clock demonstrator rather than something I intend to use as a real timepiece, I didn't worry about this too much. I like the idea of the servo driven version, and may try it out later. I found that the clock ran quite reliably with 600g of weight. I think 500g is also OK, but less than that wasn't enough. Note that TheGoofy recommends 1.2kg, and that may be needed for a different ratchet/drum combination: for a higher gear ratio you need more weight, and also get greater run time. With the version I used the weight dropped about 5 cm in 10 minutes (measured very approximately).

One issue I had is that the clock would sometimes stop dead. It took only a slight touch on the balance wheel to get it going again. After a while I realized that this was because I had some screws for setting the time on the balance wheel, and they protruded just enough to occasionally catch on one of the gears. Countersinking the holes on the balance wheel so I could screw them in a tiny amount further was all that was needed to fix this.

I also tried a variant version of the anchor in response to getting an occasional stall. I'm fairly sure that something about this throws the beat out (that is, the ticks and tocks are uneven), and I switched back to the original one.

There are two features of this clock which make it different from the Peterson and A26 clocks. It has a seconds hand, with a little extra mechanical complexity as a result. More importantly, the timing element is a spring/balance wheel combination, with an anchor between this and the escapement. I think this is called a Swiss or lever escapement. It's a much more compact arrangement than using a pendulum. In a 3D printed version, it's less practical as the spring will wear out over time. It's also harder to tune the period. I haven't found any very good guide on this, so here is my understanding of the physics and some observations about the practical reality.

Some noodling about balance wheels

In theory, the balance wheel acts as a harmonic oscillator. Wikipedia gives an expression for the period. The important factors are:

  • it is inversely proportional to the square root of the spring stiffness. So a thicker spring makes the period shorter, resulting in less time between ticks. It speeds up the clock, making it run faster.
  • it is proportional to the square root of the moment of inertia of the balance wheel. If you imagine the balance wheel as being made up of lots of tiny masses, the moment of inertia is then the sum of each mass times the square of its distance from the axis (mr^2). So a heavier balance wheel or moving some of the mass outwards makes the period longer and the clock runs slower.
The balance wheel has its own intrinsic mass, and also has eight holes round it which you can insert screws into. The screws can be moved in or out to a small degree and you can choose how many to use provided they are kept in pairs. So by adding or removing screws or adjusting their position, you have some control over the timing.

Now this is all for an idealized system, and in a clock there are at least a couple of things that might make it different. I don't have the skill to analyze this in detail, but my thoughts are:
  • gravity is acting on the screws attached to the balance wheel. The direction of the gravitational force relative to the balance wheel changes as the balance wheel moves. So the resulting moment on the balance wheel is also different. This implies you get different effects depending on which of the balance screws you use.
  • when the nub on the spring hits the anchor, it loses some energy, and it then gains some energy back as the trailing edge of the anchor hits it. It also interrupts the smooth motion. I've no idea how this would affect the period, if at all.
Note that you will find some descriptions on the web of adjusting the position and setting of certain balance screws having a special effect. I think this information needs to be taken carefully as it is often referring to a bimetallic balance wheel, which behaves differently from the kind we are using.

I did a few experiments to see how changing the weights on the balance wheel affected the period, by adding and removing screws. There are eight holes for screws round the balance wheel. If you imagine it vertically, I'll call the top pair A, the next one down B, the ones just below the midpoint C, and the pair at the bottom D. Note that this depends on exactly the orientation you choose for the balance wheel relative to the spring. You can also position it so that there is a screw at the top and bottom, and there are other orientations which are unbalanced.

I initially used M2.5x4 screws. I timed how long one rotation of the seconds hand took. The spring for these experiment is 1.3mm thick, though I think as a result of the slicing parameters it is probably more like 1.25mm. I noticed that with weight higher up, the movement of the spring was less regular. It looked in some cases as if it was about to tangle (one loop catching on the next one). Also, I doubt that I was setting the screws to a consistent depth in the experiments, and as noted this affect r in the mr^2 computation of the moment of inertia.

Here are some results:
  • screws in A, B and C: 92 seconds per revolution of the seconds hand (and somewhat uneven).
  • screws in B and C: 77s.
  • screws in C only: 71s.
  • screws in D only: 56s. Note that this case has the same theoretical moment of inertia as the previous one, and so supports some of my speculation above.
  • no screws at all: 75s. On a second run I got 68s.
The last reading is a bit odd. I think what is happening here is that the mass of the balance wheel is now so low that it can't transfer enough momentum to the anchor and hence to the escapement wheel. Some of the beats were noticeably uneven. I think the other results are somewhat consistent, in that I reran the timing for a couple of the cases and got the same result to within a second.

I now changed the spring to a thicker one, 1.5mm deep, with these results:
  • D: 56s.
  • C: 61s.
Another little bit of physics here. For a spring with a circular cross section, the stiffness varies as the diameter of the wire to the 4th power. The spring in this clock has a rectangular cross-section and we are changing only one dimension of it, so it's a reasonable guess that the stiffness should change as the square of the depth. The period varies as the inverse square root of the spring thickness, so it should be linear (inversely, that is) in the thickness. We went from 1.25mm thick (nominally 1.3mm) to 1.5, so a factor of 1.25/1 = 0.833. And in the D test, the change in period is 56/66 = 0.848. So it looks like physics is working.

The answer

The main reason for the analysis above is that I haven't understood how to tune balance wheels in the past and I wanted to work through the logic. The short summary is:
  • stiffer spring means slower.
  • more weights means slower.
  • position of the weights matters.
The actual configuration I ended up with was a 1.5mm spring, balance wheel oriented with screw holes on the vertical axis (different to the A/B/C/D configuration I described above), and no weights at all. This gave me pretty close to 1 minute per rotation of the seconds hand. I saw some variation across measurements at different times. Also, the clock sometimes runs smoothly and sometime stutters a bit. I think this is probably when I hit spots on the gears which I hadn't finished well - I didn't clean everything up very carefully.

This is another nice design - thanks TheGoofy (aka Christoph Laimer). Looking over the last three clocks, you might be able to see there is a progression, from an easy hours+minutes pendulum design, to a slightly harder hours+minutes horizontal pendulum design, and now to hours+minutes+seconds balance wheel. I have a few ideas for what I would like to try next.

Sunday, August 22, 2021

Short notes on clock calibration

Here are some notes from calibrating and comparing the two clocks.

The A26 clock is supposed to run at 3600bph. I calibrated it to this value when I set it up. After leaving the clock without running it for a few days, I then set it going and found that it was gaining about 30 seconds in 5 hours (6 seconds per hour). Just before I stopped the run, I measured it 3640 bph. It's probably quite temperature sensitive due to the use of a brass rod for the pendulum.

The Peterson clock is intended to run at 5850bph. I set it that way originally and it has run continuously for around 10 days since then. On a test over 30 hours or so, it gained around 2 minutes (4 seconds per hour), and I measured it at 5870bph.

Both measurements of how fast the clocks ran could be very inaccurate as they rely on judging the time by eye.

Another data point. In one hour, the weight on the A26 clock fell 120mm. So you would need a lot of height or to double up the weight chain to get a good run time. The weight was about 300g with a 30g counterweight.

The weight for the Peterson fell about 5mm in one hour. So with a four foot drop, you should be able to get 10 days from it. The weight is 7 pounds 12 ounces, with a doubled weight cord.

Sunday, August 15, 2021

Printing and Remixing the A26 Clock

Several years ago, thingiverse user A26 published a model for a simple clock. I made one version of this in 2019, and was never very satisfied with it. Following from making Steve Peterson's clock recently, I decided to have another go at it, and to make some design changes to improve it. The first change I made was to adjust the tolerances on some of the parts. Several of them fitted together very loosely so that, for example, gears would slip on their shafts, and bearings come loose. I think this is likely due to variation between prints and slicers.

The most serious problem was in the design of the anchor. It uses a knife edge: basically a V-shaped pivot which rests in a groove. A gust of wind can make the pendulum swing about the vertical axis (if you see what I mean), and as I found with my original build, if you are clumsy as I am, you can easily knock it out of place entirely. I therefore redesigned the anchor somewhat along the lines of the Peterson clock, so that it is mounted on a 3mm shaft. This entailed extending the frame of the clock to allow extra room. The result is much more stable. I haven't yet tuned the timing of the clock or allowed it to run for a long time, but so far it seems to be working well.

Here's some pictures and video:

The filament is PLA throughout. Most of the parts are directly from the original design or my modifications of them (thingiverse remix), with the drum and ratchet from the self-winding version. (I started on adding the self winding mechanism, but got frustrated with it and gave up). The face also comes from this design, held on with some clips that I knocked together. I added a couple of small clips that slide tightly onto the pendulum shaft and help stop it from slipping. The main shaft and pendulum shaft are stainless steel, as I had pieces about the right length. All the other shafts are brass. I much prefer brass as I can cut it without power tools. I've been using this saw, which allows very clean and precise cuts with minimal effort.

To set the hour, the best approach is to hold the part called Wheel 4A stationary (see the original design for which this is), and turn Wheel 5. The shaft that connects Wheel 4A and 4B is snug but not so tight it can't turn. I glued the 4B end of the shaft in place. For the minutes hand, I hold Wheel 3 stationary and rotate the minutes hand on the shaft. The first time I did this, the hand broke, so I made a new version which is stronger. I am using about 200g weight.

Adjusting the beat (that is making the ticks and tocks of equal duration) and the timing (beats per hour) is difficult. For the beat you have to have the pendulum shaft exactly centered and the weights at exactly the same distance from each end. For the timing, you have to move the weights in or out on the shaft. Fine adjustment is tricky; the designer of the self winding version addressed this by threading the pendulum shaft and weights, but I am not able to do this.

Note that my change to the anchor means that you can't get the timing right. The clock needs to tick at 3600bph, and the slowest I could get was around 4400bph. This can be fixed by either using a longer pendulum shaft or modifying the pen weights so that they have a longer stem. I used both: the shaft is 250mm, and the longer stem pen weights allow for a bit more range of adjustment (not shown in the pictures above). The fine adjustment is tricky. What worked for me was to measure the beat rate with the Cuckoo Clock Calibration app, move the weight on one side to make the clock faster or slower, then move the weight on the other size until the pendulum shaft was horizontal. Towards the end of the adjustment, you may need to move the pen weights as little as 0.5 or 1mm, which can be hard to do precisely.

Another nice design - many thanks to A26.

Sunday, August 08, 2021

Steve Peterson's 3D Printed Clock

I have made several attempts at making clocks using a 3D printer, always ending in a clock that didn't run at all or that would only run for a short time. Some of this is attributable to the quality of the prints. My first two printers really weren't up to the level of precision that is needed. Another source of problems is my inexperience with debugging clocks, and mechanisms in general. I know how to think about solving software problems, but I don't have a good feel for where to start with mechanical ones. I've gotten better at this over time, and in the case of clocks I have a better understanding of them as physical systems than I did at first; I mean things like how power is transmitted through the system and how it interacts with the elements that control the timing. And finally, some of the designs that I tried just weren't as good as they might be. I don't mean that the designer was negligent, just that you find many objects on 3D printing sites which worked when the designer made then and so they generously shared the design with the community, but they didn't test them to allow for variation in printers, materials and the abilities of the person making the clock.

I recently came across a design by Steve Peterson for a clock intended to be easy to make and get going. He accompanies the design with detailed videos on assembling and debugging the clock. It has variants for different run times, from 7 days up to 32 days, with 10 days being the recommended starting point. (Strictly speaking, the run time depends on how long it takes the weights that drive the clock to reach the ground; if hung in a deep stairwell, it would run for longer.) I successfully built this clock and have it running, and enjoyed the process.

Here are some pictures and a video of my build of it:

One element which is not complete is the weight shell. I am waiting for Amazon to deliver the BBs to fill it and will then fit it.

In the mean time, metal water bottles provide the weight:

The dog bed provides a convenient soft landing in case something should break.

The frame and weight shell are printed at 0.3mm instead of the recommended 0.15mm to make the print time more manageable. Most of the parts are printed in regular or silk PLA. The weight shell is rainbow PETG; it's a bit rough due to the 0.3mm layers and because I upped the print speed for it. I made one modification to the original design. There is a gear that has to be slid to the right position on its arbor, and also has to be so tight on the arbor that it it won't rotate. I replaced this with a version that could be held in place with two M2x6 machine screws like this:

The screws would be better as M2x4, but they were just too short. This change makes it easier to position, while giving some confidence that it won't slip.

The debugging procedure recommended by Steve starts with checking the pendulum will swing freely for about 10-12 minutes. He recommends cleaning the factory grease out the bearings to reduce friction. At first, I got it to run for just under 10 minutes, this was because I had put the wrong bearing on, so that only one of them was clean. The clock as a whole ran initially for 20 minutes and then 40 minutes. At this point, I disassembled it, fixed the bearing and visually inspected everything. One of the gears has some distorted teeth due to first layer adhesion and two others had minor amounts of elephant's footing. I reprinted all of these. With 2 pounds 15 ounces of weight, it ran for 7 hours and then on a second run for almost 28 hours. I increased the weight to 4 pounds 7 ounces, and and time of writing it is just coming up to 60 hours, with one rewind.

I think when it stopped after 7 hours, it was probably because I didn't have the beat right. Steve discusses this at length in the debugging video. I found an app called Cuckoo Clock Calibration which really helped in checking it, as well as setting the beats per hour by adjusting the pendulum length. The app uses the phone's microphone to listen to the ticking and reports the time between ticks, whether the clock is level and the overall rate. One other thing I noticed is that the tick sometimes has a slight double-click sound to it. Perhaps the pallet is bouncing off the escape wheel tooth for a moment. The app confirms this: you can see an occasional double spike in its display of the sound waves (I've tried to take a screenshot, but the noise of pressing the button to do it swamps the sound of the clock).

I also noticed that the ratchet was not completely in position after rewinding, like this:

I'm planning to lightly sand the inside of the ratchet drum and make the springs a little weaker. This could be the source of the stoppage after 28 hours, as if the ratchet then slips, it might interrupt the operation of the clock.

A couple of other build notes. I used brass for the 3mm arbors, as it's easy to cut. For the 1.5mm ones, I already had some 1.4mm steel axles of about the right length, and then seem to have worked fine. Several ballpoint pens gave up their lives in order to supply me with springs. There's a little finish work I still intent to do, for example the minute hand has a small blob of filament on the edging.

Huge credit goes to Steve Peterson. It's a good design with good supporting information. There are many thoughtful decisions, such as using gear teeth with a profile that makes them easier to print. I'm really happy with it, and plan to move on to some more challenging clock models next.

Monday, June 14, 2021

NOP21's Kinetic Gears Sculpture

 I my previous post about triaxial tourbillons, I mentioned that I had built the Gyrotourbillon designed by Thingiverse user NOP21 (build, video). I've built a few other designs from the same person including a complex and beautiful escapement (build, video) and some intriguing gears (build). NOP21's designs are always careful and well thought-out. Their recent designs include a couple of kinetic sculptures (1, 2), and as this is something I've been getting interested in, I built the first of them.

Here's a couple of pictures and some video:

The filaments are Geeetech silver, bronze and gold silk PLA, Mika3D white and black PLA, and Sunhokey rainbow PETG for the base.

I've found that the tolerances for most mechanical designs off Thingiverse are too tight. The design was an exception. The frame elements (the black structural parts) didn't fit together tightly, and the bearings were also too loose to stay in securely. I made the bearings fit better by lining the inside of the opening for them with a sliver of blue tape, and I got the parts to fit together by gluing them. Usually cyanoacrylate glue works fine for PLA but in this case it didn't do a good job and I resorted to using a hot glue gun instead. This worked OK, though you have to act fast after applying the glue, which can be tricky in the stages where you need to fit several pieces together at once.

The original design used a motor like this one with a variable speed controller board. I though it would be interesting to replace this with a small stepper motor, the widely used 28byj-48. In combination with an Arduino Nano and a ULN 2003 driver board, it means you can program more complex movement pattern, such as a gradual change in speed or a reversing the direction. I designed a simple coupler to connect the frame to the stepper shaft and I also redesigned the base to accommodate the motor and electronics.

There are two other minor changes. The axles for the gears are designed to be printing lying on their side (axis horizontal). This entails some cleaning them up afterwards to smooth out the lowermost layers. I prefer to print them with the axis vertical. This doesn't quite work as the triangular end of the axles is not quite flat. It's designed to follow the curvature of the overall design. I flattened out the ends; you can't really see the difference unless you know to look for it. Secondly, I needed to make the washers for the gears ("rondelle A") thinner. As originally printed they were simply too thick and the gears wouldn't turn. Either 0.4 or 0.2mm worked better.

I wrote controller code which allows you to create a program made up of steps., each consisting of a move of specified duration and speed, followed by an optional pause. You can have several programs. The box design allows for three buttons, which I use for pause, faster and slower. When pause is pressed, the faster and slower buttons are used to step between programs or set up to auto-advance to the next program when the current one is complete. There are also some status LEDs.

There is a bit of wobble in the movement, especially at slow speeds and when starting or changing direction. I think this is due to the shaft coupler not being a tight enough fit.

The modified parts and code are available on request; leave a comment if you are interested. I'm not usually posting remixes on Thingiverse now as the site has become so difficult to use.

Thanks to NOP21 for the original design. I am thinking of exploring kinetic sculptures further and this was a good initial project, easy and enjoyable.

Friday, June 04, 2021

Triaxial Tourbillons

Some History And Background

I've written in the past about 3D printing tourbillons. These are, in essence, the timing core of certain clock and watch mechanisms. They regulate the rate of the overall mechanism by means of an arrangement of a spring, an escapement wheel and a shaped piece called a fork. You can think of a clock as consisting of a power source (like a weight or mainspring) and a gear train which provides the right ratio between the movement of the hour, minute and seconds hands. The tourbillon alternately locks and then releases the entire mechanism so that the timing of this gear train is regulated. It requires precision, to get the timing right, and strength, as it has to slam into place to halt the whole mechanism and then hold back the power source until it is time for the next tick

As such, 3D printing from plastic doesn't seem like a good design choice. Plastic deforms (bad for holding back the mechanism), is springy (bad for exact timing) and is weak (bad for resisting the forces when it has to halt the mechanism). Nevertheless, there have been some remarkable successes in printed designs for clockwork mechanisms based on tourbillons. Here are some examples:

  • Mechanical watch by TheGoofy (design, video), driven by a plastic spring.
  • Clockwerk deep space tourbillon (design, video), driven by a weight.
  • NOP21's Gyrotourbillon (design, video), driven by a metal spring.
  • Cabestan triaxial design by mcmaven (designvideo), driven by a stepper motor.
  • Astronomia triaxial tourbillon, based on a watch design by Jacob and Co. This has been through multiple versions:
    • the original design by A26 (design, video). It used a weight as a power source.
    • mcmaven's improved version (design, video), also using a weight.
    • a variant in which the overall motion and the tourbillon are driven mechanically with a weight as the power source, but the timepiece is replaced by an off-the-shelf quartz clock (design, video).
    • a further modification in which the weight is replaced by a pair of stepper motors (design, video 1, video 2). This is called the Triaxial Motorized design, and it's what I'll mostly be talking about here.

There are more on Thingiverse and other 3D printing sites, plus a few on YouTube for which the designers have not released the build files or charge for them.

I have tried building several of these, with varying degrees of success. I never got TheGoofy's watch to work, and didn't have much success with the Clockwerk design. In both cases, I tried these when I had a printer that is less good than my current one (Prusa MK3S) and when I had less understanding of how to debug the mechanisms. Over time, the designers have also provided better documentation. mcmaven's assembly notes are good and with the most recent design, the stepper driven Astronomia, go into a lot of detail about the assembly process and problems to watch out for.

Here are videos of some of the my past builds:
The second of these took a lot of weight to run. What you can't see on the videos is that there is a bag containing two heavy iron wedges. The weight was so heavy that it was quite scary attaching it, and it pretty quickly distorted the mechanism, magnifying any imbalances or misalignments in the assembly.

The use of stepper motors as a power source is interesting. Stepper motors can apply a lot of torque and then hold the mechanism in place when they are halted. However, it's also weird to have them as well as a tourbillon, as there are now two separate elements which regulate the timing: the step period, and the period of the tourbillon. Bad things happen when the periods are not equal. If the stepper tries to advance the mechanism while the tourbillon is blocking it, then something is going to give. Usually this means a gear somewhere jumping forward. It could also break weaker components. If the stepper is running slower than the tourbillon, when the tourbillon releases there won't be a need dollop of energy ready for it, and it may not have enough momentum to drive the escape wheel and fork to the next tick.

A Build Of The Triaxial Motorized Tourbillon
After a long break from printing mechanical devices, I decided to have a go at the Triaxial Motorized Tourbillon. Here are some videos and photos, including a few at intermediate stages.

I'll come back to that weird little circuit board in a moment.

The tourbillon running:

The core at normal speed and slowed down:

There is no battery in the clock mechanism in these videos, which is why the hands don't move.

In previous builds, I used whatever filaments I had in stock, but this time I chose ones which were a bit more pleasing aesthetically. mcmaven took some trouble in this latest design to emphasize the appearance, for example in the shape of the carrier and the "jewels" which cap parts of the mechanism. The filaments I picked included silver, gold and bronze Geeetech silk PLA, and white Mika3D PLA. For the base, globes and clock face I used Sunhokey rainbow PETG. The rainbow filament is just filament which is dyed with different colors along its length. I had used it before when printing PPE faceshield frames and enjoyed using it. I was lucky with the transitions, so that where there are cut-out letters and numbers on the base on clock face, the color that shows through is different from the surface color. It's a little hard to see, but here is an example:

I also used a little orange Prusa PETG for the base bottom.

(I'm going to refer to a few specific parts in the following. If you care about the details and want to understand what I am referring to, look at the PDF in mcmaven's design under "Thing files".)

I made a number of changes to the design. Some of these were to make fitting parts together a little easier when the tolerances were tight. In a couple of cases, I took large parts and split them up, so I could divide up the printing time, and also to reduce the need for support. An example is the base bridge which conveniently can be split into two parts. A few of the original parts are designed to be printed in pieces and then glued together. In some cases, I modified them so that I could insert a 1mm pin to keep the parts aligned while the glue set. For example, the globes each have three pins aligning the halves, and similarly for the two halves of the carrier shaft. Speaking of the globes, I replaced the original sun and moon globes with a smooth sphere and a faceted one, made using a UV sphere and an icosphere in blender. Both were printed with rainbow filament, though I happened to hit a rather boring part of the roll and so the colors are not very striking.

The electronics in the original design uses a rotary encoder to adjust the speed, with the push button pausing the steppers. As several others have found, there seems to be a bug which means it can never be unpaused. I've started at the code for some time and it's not apparent to me why other than one slighly suspicious call to the stepper library. I also found reading the rotary encoder to be flaky even with debouncing, and so I replaced it with three microswitches (faster, slower, pause) mounted on a small piece of stripboard. This entailed rewriting the code to control it. Otherwise, I am using the same as the original: an Arduino Uno, and two 28BYJ-48 steppers attached to ULN2003 driver boards.

Here's a more or less complete list of the parts I modified or gave special treatment to:
  • Escape wheel: needed special slicer configuration to set the perimeter width to 0.35mm. Otherwise the PrusaSlicer discards part of the model.
  • Fork frame back: slightly changed the dimensions of the hex "plugs" so they fit more easily into the fork frame.
  • 40T fork frame gear: added a MR52 bearing
  • Crown gear: dispensed with the bearing spacer and instead added set screws for the bearings. . More on this and the 40T gear below.
  • Base Gear 2: split into two parts.
  • Base Frame 2: split into two parts.
  • Carrier shaft: added 1mm pins for aligning the halves and scaled by 0.98.
  • Stepper pinions: slightly scaled the interior hole so it fits more easily on the stepper shaft, after breaking them several times.
  • Counter weight and cover: added screws to hold them together. Slightly scaled down the length so it fits in the crown gear more easily.
  • 8T gear: scaled the interior hole for a closer fit.
  • Base bottom: added a rim to get extra depth for the wiring. This would have been better as a change to the base, but by then I had already printed it.
  • Globe shafts: merged the half models and then split them perpendicular to the axis. This gives a nicer appearance in the printed result. Used a 1mm pin to align the parts.
  • Globes: I replaced these.
  • T Frame Middle B: slightly reduced the size of the top cylindrical element. See below.
  • Fork: made the fork pin slightly thinner. See below.
Several other parts needed sanding or filing. In general I found most of the fit to be too tight rather than too loose. This was quite widespread (see the scaling on the carrier shaft in the list above, for example), and I wonder if either slicer settings or my printer's calibration made the parts slightly larger than mcmaven's. I have the same model of printer as mcmaven, and only changed the settings that he specifies as needing non-default values. Perhaps the climate or variations in the filament diameter make a difference.

I'm not intending to publish a remix for the modified parts on Thingiverse as it's such a pain to use these days, but if anyone reading this wants them, please leave a comment.

One other minor note. The steppers are specified as drawing 240mA, and the USB chip on the Arduino Uno is supposed to have a limit of 500mA, with most people recommending you don't draw more than 400mA. I didn't see any problems, but it could be pushing the limits. As an experiment I used an external power source and took the stepper power from the Vin pin on the Uno. I couldn't see any difference in this other than the steppers getting hotter and a bit louder.

Making it run
The biggest issue is getting it to run reliably. The tourbillon in isolation ran fine right off when I drove the escape wheel by hand. I tested everything else by assembling it with just the 8T gear from the tourbillion omitted so as to temporarily disable the escapement. There were a few minor problems, such as some elephant's footing on the carrier globe gears causing friction against the carrier, but nothing serious.

After reinstating the 8T gear and so connecting everything together, two problems were immediately apparent, both resulting in the mechanism skipping. First, the 40T fork frame gear skewed out of position, and secondly the 608 bearing in the crown gear slipped so that the 40T gear's teeth only partly engaged with the crown gear. As mcmaven notes in his documentation, the 40T gear is one of the most critical pieces to print and assemble accurately. It takes a lot of force and will try to skew out of position. I found it helped to redesign it so that it has a MR52 bearing in it instead of mounting it directly on a 2mm shaft. This is a component which perhaps scales poorly from the original watch design, where it is subjected to much smaller forces and the bearing or shaft is made from a more rigid material. To solve the problem with the 608 bearings in the crown gear, I replaced the glued-on 22x19x2 spacer with set screws, similar to those used elsewhere in the design.

I played around with various speeds for the stepper. Too low and the movement of the balance wheel was so weak that it would stall. Usually it would restart by itself, but sometimes it needed a nudge. With the stepper speed set higher, the balance wheel swung nicely, but occasionally the mechanism would slip. I assume that what was happening is that they drive from the steppers and the timing of the escape/fork/balance combination were just enough out of step that the tourbillon would halt the mechanism but the steppers would force it on. I recall mcmaven noting a similar problem with one of his other designs, which he solved by replacing the gear drive with a rubber band.

It's possible to approach this more scientifically. The analysis in a comment thread for a make establishes that 2400 beats should be equal in duration to 9178 steps.  Using a sound recorder and running the tourbillon by hand, I measured the time between beats as 0.32 seconds on average, for a balance wheel with two M2.5x6 screws. This gives 0.0837 seconds per step of the motors. In the stepper library, the time between each step is 60/steps per rev/speed. The steps per rev is set to 32 (not actually the true steps per revolution: it's only used in time between steps calculation), giving a speed of 22.4. In fact these will be slightly out as the stepper library does not account for overhead both within its own code and in calling code. But even it that overhead was an extra 1ms, it would only change the speed by about 0.2. As the speed is an integer, the default value of 22 seems about right here.
(Side note: I later reprinted the spring and balance wheel, and ended up needing a faster speed, 30 or 31. However, the logic here still holds.)

Having said all this, the point of a tourbillon is to average out variations in timing caused by different orientations, so the idea of measuring the beat time and picking the exact stepper speed for it doesn't quite make sense. This goes back to the observation I made earlier that the presence of both stepper and tourbillon means there are two source of timing in the system, and that may result in problems.

The model sometimes ran for 10 minutes or more without any problems, and I also had occasions when it would run for less than a minute before stalling or skipping. After a while, things seemed to be getting worse. A very close inspection at various orientations showed two problems: the 40T gear was just interfering with the cylindrical top of T Frame Middle B, and sometimes the pin of the fork would just interfere with the balance wheel. The second of these was not initially an issue, but at one point I decided to reprint the spring as it was deforming, and in changing it I broke the balance wheel and so needed to reprint it as well. The new balance wheel was a fractionally different fit to the previous one and so interfered with the fork when the original one had not.

To help with these problems, I modified the models, to make the top of T Frame Middle B a bit smaller, and to make the fork pin thinner. After these changes, it ran quite well; not as perfectly as mcmaven's or jdirgo's, but quite successfully all the same. Here's a timelapse:

What next?
I enjoyed making this, and was glad to getting it working with moderate reliability in the end. If I spent longer (or was more generally ept to begin with), I could probably make it smoother and run longer. I'm not all that interested in it a functional clock. I have plenty of these already, and I am not sure that I want to share my life, or at least my room, with something that goes tick all the time. But it's entertaining and soothing to watch it run.

The design is an improvement over the previous variants both in the engineering and the aesthetics, and something I might do with it is use it as a base for kinetic sculptures. What I have in mind is to remove both the clock face and the tourbillon and replace them with other elements, perhaps something along the lines of David Roy's designs or Peter Verhaart's.

Like it? Leave me a comment!