jes notes Index Gallery . Shaft passers Snap issues

2024-11-28

Last modified: 2024-11-28 23:39:37

< 2024-11-26 2024-11-29 >

Ratcheting winding drum

The plan is to make the ratcheting winding drum, and then see how much difference it makes to the accuracy of the escapement, on the theory that slapdash winding causes variations in tension.

It needs to have 2 parts, one part locked to the shaft, and one part free to rotate on the shaft, but not slide axially, and engage only in one direction. And then I'll wind it up by manually rotating the outer part, but you can imagine using a key to turn it.

I'll use one of those little shaft collars with a washer piece to constrain the outer part axially, it can just slide over the inner otherwise.

There are 6 click springs but 8 ratchet teeth, so we get some "differential" meshing, which results in 24 clicks per revolution. I went with 6 instead of 7 click springs so that the forces are closer to being balanced. With 7 you would get 56 clicks per revolution but only one would be engaged at a time instead of 2.

And that has a helical groove to make sure the string doesn't snake and doesn't rub against itself. The root of the helical groove is at the same diameter as the old barrel so that the resulting torque from the string is the same.

I still have 3x M20 nuts drive weight, and still have 2x M12 bolts for balance weights.

First a control run with today's temperature etc.:

After the initial ramp-up, it varies over about 8 degrees of amplitude and 1.75 ms period, over about 45 minutes.

Average period is about 4.0075 secs, and average amplitude is about 257 degrees.

The period of the period variation is about 460 seconds, which works out to about half a turn of the winding drum? Roughly?

What I'm hoping to see is that with the new winding drum, the variation in amplitude is substantially reduced, and with it the variation in period. It's printing at the moment.

Looking good, let's see how it goes.

No improvement whatsoever. It is basically the same, maybe slightly worse.

Varies over 10 degrees of amplitude and 2.0 ms period, over about 20 minutes.

And we're still seeing the period variation at a rate of about twice per revolution of the winding drum.

Could this be caused by the helical rust on the shaft that the winding drum is on? The part of the shaft engaged with the plain bearing surfaces will alternate between shiny and rusty, maybe that's the problem??

This is what the rust pattern looks like:

This rod came out of a laser toner cartridge. I had tried to polish the rust out but it goes too deep.

I'll make up a new polished aluminium shaft and try again. Still using the 3d-printed plain bearings because my new ones haven't arrived.

While this is going I'm noting the winding drum orientation.

At the first peak in period (trough in amplitude) the screws on the gear & drum are both pointing pretty much horizontally towards the escape wheel shaft.

At the following trough in period (peak in amplitude) the screws are about a third of a turn further around, maybe a bit more. Not as much as directly opposite the escape wheel shaft.

The next peak in period (trough in amplitude) was only maybe 60 deg. further around.

The next trough in period (peak in amplitude) was maybe 45 deg. before directly facing the escape wheel shaft.

So I think it is looking like this variation is not actually caused by anything that is fixed to the winding drum shaft.

So we're still seeing the cyclical amplitude & period variation, but the amplitude is slightly higher than it was before because of (presumably) reduced friction in the plain bearings.

I noticed that the back (unused) corner of the inactive pallet was swinging all the way around and (slightly? or not quite?) touching the adjacent tooth. Whether it was touching or not, we should fix the problem so that larger amplitudes are possible.

The rollers on the lantern pinion don't appear to be turning very much, if at all, so I don't think the hunting amplitude/period is due to those either.

I wonder if this could be caused by temperature changes from heat generated by my PC nearby??

Average peak-to-peak time is 462 seconds, which is very close to twice per revolution of the winding drum shaft (4.005 secs period, times 37 teeth escape wheel, times 43/7 gear ratio, divided by 2, = 455.1 secs).

I think it is periodic with the rotation of the winding drum shaft, but the peaks are quite flat and I don't have enough peaks to get a precise enough interval to be sure.

I noticed there is some stringing between some of the teeth on the gear, I can pull that off and see if it improves anything, seems unlikely.

I burnt off the stringing with a lighter.

Also I'm going to watch nvtop and note the temperature at the peaks/troughs in the period/amplitude. Meh, it seems to vary between about 47 and 50 deg. C independently of the cycles in the clock data.

As a better test, I've closed everything that is consuming GPU time (including minimising Firefox, which sadly stops me from seeing the live data) at about t=700s, will see if the data shows any change after then.

This doesn't seem to have made any difference to the GPU temperature.

Oops, one of the things I killed was Cursor. Which was running the Go program that collects the data from the USB serial. So I killed my data collection.

I'm going to rotate the winding drum by 180 degrees but leave the gear where it is, and see if that changes anything.

I previously thought (with admittedly low probability) that the peak in period occurs when the screws point directly towards the escape wheel.

Now if the peak occurs when the gear screw points towards the escape wheel then I know it's to do with the gear, and if it occurs when the drum screw points towards the escape wheel then I know it's to do with the drum.

Oh, but actually, I thought it happened twice per revolution of the drum. So I wouldn't expect this to make any difference?

So the conclusion here is that having the ratcheting winder is a medium-level quality-of-life improvement, but doesn't actually appear to have improved the running of the clock.

Amplitude interpolation

So the plan is that every time we get a change in position, we can interpolate N points in between the previous 2 points.

To avoid interfering with the amplitude detection stuff I think always hold 1 data point back before giving it to addReading() or whatever, and then interpolate using the buffered data point as a reference. Since we're just buffering position data points I don't think the lag will be significant.

If you have a curve like this:

Then note that the peak is a single data point, but we know that while we had the position at that data point, the balance wheel was swinging further around, stopping, and then reversing.

So let's say the peak is position p at time t. The next data point we get is p-1 at t+2 on the drawing. But at the exact instant t+2, we had just dropped below the level that would put us in the next position down. So the position at t+2 is actually equal to the position at t, and we only pass below p-1 at t+4.

So I think for the purpose of interpolation, we need to adjust the position point up by 1 if we moved in the negative direction?

For now I've just put this in detectPeaks() - although the "velocity" and "acceleration" plots could probgably benefit from it.

Looks like it is an improvement:

The noise here is a lot less than 2 degrees, so I think we are actually extracting more position information from the timestamps, not just making it up. Good.

And I've now added 2 decimal places of precision to the "amplitude" display, and I can see it mostly moving in consistently the same direction, which is further confirmation that this is working. Good.

Hunting amplitude

To try to debug the hunting amplitude, I'm going to put the winding drum back directly on the escape wheel shaft, and see if the hunting goes away. And down to 1 nut drive weight to partly account for the 43/7 gear reduction

Also I noticed the escape wheel is pretty badly out of balance. I'll see how I get on with just moving the winding drum first, then balance the escape wheel.

I accidentally moved the shaft collars, so will have to reset depthing as carefully as I can.

With 1 nut the amplitude was only about 160 degrees, why so low? I think that should still be at least 2x the drive torque it had before.

I've switched to a lighter nut to make it closer to equal drive torque, but that hasn't helped either, worse if anything.

OK, I see the problem. It is because the frame is so flexible. With the drive weight hanging off one side it was bending the frame apart, but with the drive weight closer to the centre, the frame isn't bending open and the balance pivots are too stiff.

I loosened up the lower pivot slightly, also tweaked the frame alignment to try to put it back in beat.

It now is swinging far enough that the unused end of the pallet is very obviously hitting the wheel and making the wheel flex, at about 290 degrees amplitude.

Hilariously, I think the pallet hitting the wheel is actually helping. We know that previously the clock would run "fast in the long arcs". Well now that the inactive pallet is striking the wheel, it is pushing the wheel harder into the resting surface of the active pallet, which increases drag and slows the wheel down, so it is not as badly fast in the long arcs as it otherwise would be!

You can see that after about 295 degrees the period starts going up again! (Ignore the trail off at the end when it runs out of string).

Sadly I think without the gear reduction the clock does not run for long enough to definitively exhibit the hunting amplitude thing.

Here's the longest I can run it for without the gear reduction.

And that is shorter than one cycle of the hunting amplitude was before. Which it seems like I should have been able to calculate before trying it out.

Previously the amplitude was varying in a range of about 8 degrees, and this also shows a range of 8 degrees, so does that mean it is still there? It does kind of look like amplitude has peaked and is coming down again.

Maybe I just forget about the hunting amplitude problem. Keep an eye on it, but move on.

So I will put it back how it was, but first I'll balance the escape wheel while it's convenient to do so.

I'm expecting balancing the esacpe wheel not to make much difference to the "averaged over 74 samples" output, and I haven't been collecting the un-averaged output to compare against, but let's see anyway.

The hunting is still there, and now the period variation is worse. FML.

I think the next step is to modify the pallets so that they don't hit the escape wheel.

TODO

< 2024-11-26 2024-11-29 >