jes notes Index Gallery . Shaft passers Snap issues

2023-09-11

Last modified: 2023-10-08 09:49:16

< 2023-09-10 2023-09-12 >

Roof

I've screwed the strange-shaped flap down to the wall, filled its cavity with spray foam, and siliconed everywhere else. Tomorrow I need to silicone the strange-shaped flap and then I'm done with silicone I think. Oh, need to seal the gutter as well.

Car

So next job is to try to access the fuel tank and either clean it out or work out what is wrong. This would be more convenient if there were less fuel in it, but that risks making the problem happen again.

New plan: I've cleaned all the loose crap from around the filler cap and put some Redex in it. I bought enough Redex to do the next 4 fill-ups. If the problem returns then I'll reconsider.

Office

Office tidied, great success. That's all of yesterday's jobs ticked off, so now I'm back to where I was on Friday evening...

Next

Next was:

Escapement geometry

What does it mean to improve on the escapement geometry? What is a list of properties we would want the escapement to have?

To optimise for "easy to make" (which, realistically, is the top priority) I think we can't do any better than the escapement we already have. It's even easier to make than a verge and foliot because we don't need to turn the drive through 90 degrees.

So then we want the simulator to give us some measure of how much torque the escapement requires, how accurate it is, and maybe how much it changes if made with poor tolerances, and then we want to build an escapement on the Pareto frontier of that space.

"Accuracy" can be further broken down into how accurate it is under varying drive torque, and how accurate it is if swinging around on a wrist. But I think we can ignore swinging around on a wrist for now. Just make it balanced so it runs the same in every static orientation.

Apart from optimising the pure geometry, we also want to know how best to attach the spring, how strong the spring should be, how heavy the balance wheel should be, and how to allow for adjustment.

Low drive torque

To optimise for low drive torque, I'm going to reduce the supplied torque in the simulator until it stops running, and then mess with the parameters until I can make it work with that reduced torque.

Working from commit 2788abd3cb4a668d665c1eac6d89c0d2ea169640

Baseline: runs at 0.002 torque.

impulse60: change "impulse face angle" from -56 to -60. Runs at 0.001 torque.

impulse70: change "impulse fance angle" from -56 to -70, and "impulse face length" from 16 to 18. Runs at 0.0008 torque.

longsprings60: same as impulse60 but change "banking angle" from 20 to 90 to smooth out the spring tension, and "spring stiffness" from 0.000001 to 0.0001. Runs at 0.0002 torque.

moremass60: same as longsprings60 but change "pallet mass" from 0.1 to 1.0 and change "spring stiffness" from 0.0001 to 0.001. Runs at 0.005 torque.

baseline2:

and simulation iterations set to 100, and escape wheel mass set to 0.01. Runs at 0.0003 torque.

Accuracy

To check accuracy, I'll vary the drive torque and see how much the frequency changes

Baseline:

|   Torque   | Frequency (Hz) | Amplitude (deg.) |
|------------|----------------|------------------|
| 0.002 (1x) | 0.37           | 16.5 - 17.3      |
| 0.004 (2x) | 0.54 (+46%)    | 16.2 - 18.3      |
| 0.008 (4x) | 0.77 (+43%)    | 16.6 - 18.4      |
| 0.016 (8x) | 1.12 (+45%)    | 17.1 - 18.7      |

It looks like the frequency increases about linearly with the applied torque. Doubling the torque increases frequency by about 45%.

One observation is that at the lower torques, the bouncing is non-uniform.

This image shows one oscillation had a reversal of the anchor and the others didn't:

- this badly ruins accuracy, you can see how much further the adjacent peaks are on the incident with the bounce than on the others.

impulse60:

|   Torque   | Frequency (Hz) | Amplitude (deg.) |
|------------|----------------|------------------|
| 0.001 (1x) | 0.58           | 9.9 - 10.5       |
| 0.002 (2x) | 0.72 (+24%)    | 10.9 - 11.9      |
| 0.004 (4x) | 0.88 (+22%)    | 11.6 - 12.6      |
| 0.008 (8x) | 1.14 (+30%)    | 11.9 - 12.9      |

(The last reading was just on the cusp of skipping teeth in Matter.js, so maybe take the "+38%" with a pinch of salt).

So this looks like an improvement over the baseline, because although the frequency still changes with the torque, it changes by a smaller percentage each time the torque is doubled. Additionally, it can run with less drive torque.

Maybe let's try an even steeper tooth angle then? Keep going until something gets worse.

impulse70:

|   Torque    | Frequency (Hz) | Amplitude (deg.) |
|-------------|----------------|------------------|
| 0.0008 (1x) | 0.57           | 9.1 - 9.8        |
| 0.0016 (2x) | 0.72 (+26%)    | 10.4 - 11.1      |
| 0.0032 (4x) | 0.90 (+25%)    | 10.6 - 11.6      |
| 0.0064 (8x) | 1.18 (+31%)    | 11.2 - 11.8      |

So in terms of torque requirement, impulse70 is an improvement, but in terms of accuracy it is worse, compared to impulse60. It is an improvement over the baseline in both directions however.

longsprings60:

|   Torque     | Frequency (Hz) | Amplitude (deg.) |
|--------------|----------------|------------------|
| 0.0002 (1x)  | 0.18           | 10.0 - 10.2      |
| 0.0004 (2x)  | 0.24 (+33%)    | 10.7 - 11.5      |
| 0.0008 (4x)  | 0.32 (+33%)    | 11.2 - 12.3      |
| 0.0016 (8x)  | 0.43 (+34%)    | 12.3 - 13.1      |
| 0.0032 (16x) | 0.60 (+40%)    | 11.7 - 13.4      |
| 0.0048 (32x) | 0.74 (+23%)    | 12.2 - 13.7      |
| 0.0096 (64x) | 1.08 (+46%)    | 11.9 - 13.1      |

moremass60:

|   Torque     | Frequency (Hz) | Amplitude (deg.) |
|--------------|----------------|------------------|
| 0.005 (1x)   | 0.45           | 9.0 - 9.4        |
| 0.01 (2x)    | 0.58 (+29%)    | 9.1 - 9.7        |

As soon as we get up to 0.02 torque, Matter.js starts skipping teeth.

But I think what we've learnt is that the springs and the weights make a big difference. If we want more energy in the balance wheel then we want more weight and stiffer springs, and we want the springs further away so that they provide more uniform force.

So let's revert to the baseline impulse face angle but with heavier pallets, longer springs, stiffer springs, and call it baseline2.

baseline2:

|   Torque     | Frequency (Hz) | Amplitude (deg.) |
|--------------|----------------|------------------|
| 0.0003 (1x)  | 0.32           | 10.8 - 10.9      |
| 0.0006 (2x)  | 0.39 (+22%)    | 11.8 - 12.3      |
| 0.0012 (4x)  | 0.48 (+23%)    | 12.4 - 13.2      |
| 0.0024 (8x)  | 0.63 (+31%)    | 12.3 - 13.4      |

At 0.0048 torque we're back at Matter.js skipping teeth.

We have quite a large "drop" into the receiving pallet.

See

The sharp uptick in anchor angular velocity is the drop to the receiving pallet. We see this also results in a lot of bouncing at the impact against the receiving pallet. Probably an improvement would be to sort out the pallet angles to balance the two drops.

Occasionally the bouncing does not appear, which results in some inaccuracy. Not clear why it sometimes doesn't happen.

Update: messing with the pallet angles doesn't change it much. What about changing back to 60 degree angle on the impulse face?

Conclusion

Meh, can't really figure anything out. I think the baseline configuration is mostly fine. I can't tell whether changing from 56 degrees to 60 degrees is an improvement or not. The biggest differences come from changing the torque, mass, and springs, rather than minor changes to the geometry.

That could mean I'm at an optimal geometry, or at a local optimum, or just that the local search space is flat enough that it's hard to tell.

Maybe I should reset all numbers to 0, start again from first principles, and see if what I come up with is better or worse than the existing baseline.

Escapement redesign

A principle I came up with is that the angle between the normal to the tooth and the pallet motion should be equal at both pallets:

I don't know if this is actually helpful, but it would appear to make the escapement act more symmetrically.

Also, this angle should be as small as possible, to minimise losses.

Just want to bank this configuration:

- it has the most sine-like "anchor angular velocity" of anything I've seen yet, and tick rate only increases by 15% when torque is doubled, which is also the best so far.

Strangely, the real-life model only incread tick rate by 7% even when torque increased by about 4x. Why is that so different? Are the friction losses too different?

So comparing the old baseline to the new version in 4620... (and with some code changes, to increase iterations and decrease escape wheel mass).

|   Torque     | Old frequency (Hz) | New frequency (Hz) |
|--------------|--------------------|--------------------|
| 0.0004 (1x)  | doesn't run        | 0.97               |
| 0.0008 (2x)  | 0.46               | 1.08 (+11%)        |
| 0.0016 (4x)  | 0.60 (+30%)        | ~1.30 (+20%)       |
| 0.0032 (8x)  | 0.85 (+42%)        | skipping teeth     |

The "new" version exhibiting skipping teeth from 0.0016 torque upwards. The "old" version from 0.0064 torque upwards.

The frequency stability of the new version is better though, so I will 3d print a model and see how it looks.

It's not obvious that it is better. The "sine-like" nature of the "anchor angular velocity" was worse than the previous version, at certain torque levels. Definitely keen to try a 3d-printed one.

Actually, before that, here's another interesting one:

Has decently high amplitude, but fewer teeth on the escape wheel. Let's 3d print one of these as well.

3d-printed models

I can base it on the old 3d printed model, although the pivot separation is shorter so a new frame will be required. And I want to modify it so that the balance can be more easily balanced, and so that a coiled spring can be attached to the frame and the balance wheel. And maybe drive it off a separate gear so that it can run for longer on one winding. And maybe reduce the scale a bit so that the parts print more quickly.

Here's the one for 4620:

There is a "collet" part that screws to the back of the balance wheel that holds one end of a hairpsring. Before printing the frames I need to remember to add something to clamp the other end of the hairspring!

Tomorrow

< 2023-09-10 2023-09-12 >