2024-11-18

Last modified: 2024-11-18 22:58:33

• Light gates
• Encoder UI
• Clock

Light gates

I need some sort of feature inside the housing to stop the PCB from tilting, and then just a straightforward bottom cover. And the bottom cover needs protrusions to constrain the actual light gates.

Stick up by 5 mm to constrain the light gates.

Stick up by 1 mm to hold the PCB.

And the PCB pocket is 18.5mm deep, less 1mm for the clampy part, less 3.4mm for the PCB thickness, so the protrusion to hold the PCB on the other side needs to be 14.1 mm.

Pretty pleased with this.

Encoder UI

I want this to have a "tare" button or something to mark the current count as the centre position.

I want units in seconds and degrees instead of the "count" and milliseconds or whatever it has at the moment.

And I want a second plot that shows the balance velocity, and maybe even a third that shows the acceleration.

I have this now:

But I'm seeing a lot of "buffer overflow detected" in the terminal, which means the Arduino code probably does need the buffering thing that I thought I could get away without.

Also the web ui is very laggy. I think it redraws the chart after every data point, I should make the server buffer data points for 100ms or so and send them in batches.

Also if the serial device gets out of sync by even 1 byte (e.g. because the device was plugged in but nothing was reading from it and the kernel buffer filled up), then we never recover.

I've added the buffering back to the sender.

I added some smoothing to velocity and acceleration and it looks like this:

I think it might just be an issue with not having enough precision in the data, because we can only measure down to 2 degrees.

With the balance swinging freely (no escapement) we have:

So the period is ever so slightly lower at high amplitudes. Is this because the spring is hitting the shaft? Or that's just life? And at low amplitudes the data precision is not enough to get a consistent value.

I'm printing some new shaft collars for the escape wheel shaft because they've been slipping and allowing it to run away. This time in PAHT-CF for stiffness. The PLA ones seemed fine at first but maybe they crept over time. Will be interesting to see if PAHT-CF also creeps.

With a bit more timestamp precision:

So that's very interesting! There looks like a linear relationship between ampltiude and period at high amplitudes, and then when the amplitude drops too low it switches into a different regime? The even/odd periods separating is just due to precision on the encoder I think, but if you average 2 consecutive readings then it still looks like it changes around 90 degrees. This has to be to do with the spring hitting something, right?

Maybe don't worry about it for now, but keep an eye on it in future.

Clock

And here's a trace of it actually running:

Is that good? Don't know yet! I expected to see a more obvious periodic signal, from variations in the escape wheel as it goes around to different teeth.

If the period is 2.1 seconds and it has 55 teeth, then it should repeat every 115.5 seconds? I'm going to shift it over in gimp by about 115.5 seconds and see if it looks more obvious.

Maybe! The parts that show up darker are approximately the same but offset by about 115.5 seconds. So there does look to be a periodic signal, but it is much more random than I expected.

That's running with just one M20 nut for a drive weight. Next I'll try with two.

It doesn't work with two, the escape wheel is too wobbly, so it either binds up on the pallets or skips teeth. I think I need to square it up again by tactically wedging paper in it. It has got bent either because I took it off the shaft and put it back on, or because I whacked it with my chair.

I've noticed that some of the escape wheel teeth have their tips missing. That's almost certainly from when I've whacked it with my chair. Darn. I'll just have to print another escape wheel.

Here it is with 1 nut after straightening out the escape wheel:

The amplitude is higher than before, possibly because with the escape wheel straighter I can get tighter depthing.

Now trying with 2 nuts. I think this is not working well, it keeps skipping teeth.

Should I reduce the number of teeth so that I can make them stronger?

Part of the teeth-skipping problem is that the depthing is not deep enough, so the angle that the escape wheel tooth rests on the resting surface is trying to deflect the escape wheel away.

So I think yes consider reducing the number of teeth on the escape wheel, but also increase the depthing. I don't really want to make the resting surface any larger, because that increases the distance travelled during frictional rest. I'd rather make it smaller if anything.

So the plan is:

• make the tooth tips stronger
• closen the depthing without increasing the resting diameter
• reduce number of teeth as necessary

And an idea to keep in the back pocket is that we could machine away part of the balance shaft to allow the escape wheel teeth to pass closer to its centre.

It is interesting to note that the period increases with amplitude in the running clock (i.e. ticks slower when it has more power) but the opposite when the balance is swinging freely.

But also the balance swings faster when the clock is running than when it is swinging freely, just less so as the amplitude increases.

For the new escape wheel CAD I'm just moving the escape wheel 1mm closer to the balance shaft, relieving the back side of the escape wheel tooth a bit more, and reducing the number of teeth until everything clears everything else properly.

I have something that looks like it will work with 37 teeth. Maybe should go down to 35 just to potentially take advantage of the extra factors.

Before committing to this design I want to take some traces with the encoder to show what happens if the depthing is changed and the pallet angles adjusted to suit.

Firstly I've moved the escape wheel "too close" to the pallets, and turned the lower pallet out by about 20 degrees so that the escapement actually works. This means we expect some beat error, because the balance spring is tied to the angle of the top pallet, but what else?

And running with just 1 nut.

Indeed there is about 30ms beat error, and maybe 6 degrees difference between the positive and negative half-amplitude.

Broadly the same as before I'd say. A similar amount of variation in the period, maybe the amplitude is a bit more stable.

Next up I'm going to do the same again but with 2 nuts, on the basis that the tighter depthing might stop it skipping teeth.

With 2 nuts we have:

Nice high amplitude here.

I think the thing where the period goes down at the highest amplitudes is because the back of the "inactive" pallet is spinning all the way around and hitting the escape wheel. That part of the pallet is never actually used, so we should get rid of it to support higher amplitudes.

And the next thing I want to try is going back down to 1 nut, and moving the escape wheel further away, and adjusting the pallets to minimise the drop, and see what the trace looks like then.

Meh, it's not going to work, it just skips teeth.

I think with the 37-tooth escape wheel and a pallet like this, we can go up to 400 degrees amplitude:

And then the back of the inactive pallet hits the escape wheel at about the same time as the active pallet runs out of frictional rest surface.

So I'm going to print the new pallets and escape wheel tomorrow.

And actually I'm going to make the escape wheel spokes slightly thicker so that it is stiffer.