jes notes Index Gallery . Shaft passers Snap issues

2024-12-05

Last modified: 2024-12-06 00:04:24

< 2024-12-04 2024-12-06 >

Raspberry Pi case

I'll try and get the case designed. It wants:

https://www.thingiverse.com/thing:3747610

This is a "dummy" model to use for making a case, very handy.

One very annoying thing in FreeCAD is if you accidentally typo the number of occurrences in a LinearPattern and have to wait for it to spend minutes calculating an object you don't want.

I wanted 15 copies of this vent slot, not 115. And I can't remember when I last saved, so it's not safe to "Force Quit" and reload it in case I lose more time than I would have spent waiting for this stupid calculation to finish.

It's taking ages, I think I'm going to have to kill it, it's basically maxed out my RAM. Very annoying.

The FreeCAD snap can't access /usr/share/fonts for some stupid reason, so to get fonts I have to copy them into my home directory.

Let's give this a go.

The Pi will be held inside with M3 screws. I was planning to put a bottom cover on, but come to think of it I don't think it's necessary, it can just be covered on the other side by whatever surface it is attached to.

Bambu Studio wants to print it like this:

I'll give it a go, it might surprise me. My choice would have been to print it with the mounting holes flat against the bed and the inside filled with support material. I don't mind if the inside surface is messy because it is hidden.

It is a 3-hour print my way and a 2-hour print Bambu's way, so the Bambu way is preferable if it works.

The writing is kind of bad, I would make the writing less prominent, maybe put it on the side, if I did it again. But this is firmly adequate.

FML, this is not going well. Getting the Pi into the case is an extremely tight fit, because I made the connectors sit "into" the walls of the case, which makes it hard to get them in.

And then my little peice of stripboard interferes with one of the standoffs, so I trimmed the stripboard down.

And then another standoff interferes with the plastic base of the GPIO header, so I trimmed the standoff.

I finally got it in where I'm happy, only to discover that M3 screws don't fit through the holes in the Pi PCB! And the stupid thing is I now remember having made exactly the same mistake once before. Sigh. Why don't I learn?

I think just force the screw through the hole, it's super close. And if I can't do that, then try to drill out the hole.

Beautiful.

OK, a few more blunders in this...

The connectors are too close together to conveniently do up the screw threads. It is OK, just slightly inconvenient.

And the right-angle headers end up with the cable pointing "down" instead of "up", which means when I mount it on the clock, either the cables are going to loop down before going up to the actual sensors, or the writing is going to be upside down.

I could take it apart and re-fit the connectors upside down but I don't fancy it.

With power, 2 sensors, and quadrature encoder connections:

And tested in the web UI, all still working. Good.

Weight pulley

I'll design a simple weight pulley and try it out.

I think I just want a pulley to guide the string, with a hole in the middle to take a bearing (or even not - to test my theory about the friction not mattering), and a hook dangling underneath it to hang the weight on.

Let's try this. It springs apart to close over the bearing, and then bolts together through the bearing.

And I'll screw a hook into the remontoire frame to support the fixed end of the string, or something.

Remontoire fly

This can just be a part that is a friction-fit over the remontoire-catching arm.

We want the bulk of the moment of inertia to be in the part that is able to continue spinning once the arm is caught, so maybe I'll put some bolts in it or something. It wants to be balanced so that it doesn't prevent the remontoire from winding. (Which, incidentally, the existing remontoire-catching arm is not).

For ease of fitting, I think make 2 identical halves that bolt together around the existing part. And there is some springy part that provides the friction fit.

The diameter of the catching-arm part is 15mm. On top of that we have to go less than 30mm further else we hit the shaft collar.

The fly needs to clear the catching arm by a few mm, but can otherwise be up to 15mm wide.

These will bolt together with 2x M3 screws, and take an M4 screw for a weight.

I've fitted it and it seems to basically work, but I think the gear still has more moment of inertia than the fly, so it isn't as effective as it could be. The arm definitely lands less violently though. I'll run the clock and see if it has made any observable difference.

I expect to see more difference in the non-averaged data than in the averaged data, and sadly I don't have a recent capture of non-averaged data. So the plan is to run it for half an hour or so with the fly installed, and then un-bolt it with as little disruption to the balance as possible and compare the before and after non-averaged data.

Before removing the fly:

Averaged:

Non-averaged:

And I managed to remove the fly with almost no disruption to the clock, by making sure to let go when the remontoire was about to rewind, and only continue undoing the screws once it had spun around and come to a stop again.

And then the full run:

So this actually looks like the fly might be helping a tiny bit! The "hunting amplitude" variation was lower while the fly was installed, which means the amplitude range is lower and therefore the period range is lower.

Although obviously the way the period varies with amplitude is still a big problem.

Environmental data for reference:

I had noticed that the bottom pallet was catching the escape wheel tooth (again...) so adjusted the frame to solve that. I also re-fitted the fly but with the screws looser, and added 3 nuts to each of the weighting screws to give it some more moment of inertia, and it is very obviously spinning for longer after the remontoire rewinds, although the arm doesn't obviously impact any more gently (although reason says it must). I did both at once because a good scientist always changes 2 variables at a time.

So this is quite a lot better now. Hard to say whether it's because of stopping the pallet from catching the escape wheel, because the remontoire winds up more gently, or just because the amplitude has increased to a more favourable point on the curve.

My guess is that the remontoire change hasn't made much difference, but stopping the pallet from catching the escape wheel has let it swing with slightly more amplitude, which helps because of the curve rather than because the unwanted interaction is gone.

Coefficients of friction

How are we going to measure these?

I'm imagining some test setup made of any material, and then you just attach "shoes" made of the individual materials, to the places that rub together, and then measure how much force you can apply through the friction interface?

One material is fixed to the floor, one is placed on top, loaded up with a weight, and then you pull horizontally and see how much force it takes to move it?

ChatGPT pointed me at https://en.wikipedia.org/wiki/Tribometer

A "pin on disc" tribometer has one surface be a spinning disc and one surface be a pin resting on the disc. The pin is loaded with some weight, and some arm measures how hard the pin is being pushed around by the disc, and then you leave the disc spinning and plot how the friction varies over time as the surfaces wear:

Quite interesting, maybe I am fine with something simpler though.

Something like this:

So you put a test sample in the little cup, and you put another test sample on top of it, with some string attached to it (maybe we have another cup which goes upside down and holds the string?). If the test samples are square then we have the option to load one or other perpendicular to also test the perpendicular friction without making any more samples.

And then you let the weights on the pivot sit on the top sample, and then you load weights the other side of the pulley until the test sample slips out, and then the coefficient of friction is the ratio of the weights.

The pivot is maybe not necessary, it just stops the weights falling over.

We could put a "stop" before the pulley so that the string only has enough freedom to pull the sample out from under the weights, and not enough to let everything fall on to the floor.

I think the pivot is actually harmful, the weights need to move with the test sample, otherwise you also have the friction between the test sample and the pivoting arm.

Period/amplitude relationship

I'm wondering how much of the period/amplitude relationship is actually due to the change in amplitude (i.e. a natural property of the balance), and how much is just due to changes in drive torque, which then affect both period and amplitude.

So the plan is to disconnect the escapement and monitor the balance wheel swinging back and forth and see what the period-amplitude relationship looks like under 0 drive torque.

Very interesting, I didn't expect to see a "hill" on this.

And 300 degrees to 200 degrees spans a range of 30 ms of period.

I noticed the spring looked like it was hitting the balance shaft, so I adjusted it a bit, and it looks better now.

And the plot shows that between 300 degrees and 200 degrees it's now only a range of about 7 ms. And that was only a very rough adjustment that I made, it seems like you could do better.

Of course, ideally the balance would actually be isochronous.

I don't know what the cause for the isochrony is. Maybe friction in the pivots? I've re-adjusted the pivots and am trying again.

Wow! Now from 300 degrees to 200 degrees it stayed within 0.8 milliseconds. Just goes to show how important it is to do a good job.

I don't know why it gets steeper below about 180 degrees.

Encoder UI bugs

I noticed the reset button didn't reset all the data one time I clicked it.

The position/velocity plot gets out of sync.

The timestamps on the environmental data don't seem to match the other data. The example I'm looking at now has environmental timestamps starting at 8600 instead of 0.

TODO

< 2024-12-04 2024-12-06 >