jes notes Index Gallery . 4th axis Blog ideas Micro-machining CNC milling machine Paint colours CNC Router Shaft passers Software ideas Stepper motor clock Toy ideas Watchmaking

2023-12-03

Last modified: 2023-12-03 21:41:04

< 2023-12-02 2023-12-04 >

Stepper motor clocks

11.05am: I reckon they're both a minute or so behind the other stepper motor clock. I am starting to lean towards the idea that the gear ratio in the motors is slightly different from what is advertised.

Probably I should set up an Arduino on a breadboard with a stepper driver and maybe the light gate I made for the oscillating engine, and try to measure the actual steps/rev of these motors.

First let's look again at the datasheet.

Lol:

There are only 32 step (11.25 degree) per revolution, and inside is a 1/16 reduction gear set. (Actually its 1/16.128 but for most purposes 1/16 is a good enough approximation)

Well at least they were nice enough to say! I assumed that being from a reputable reseller like Adafruit, it would actually have the ratio marked on the case.

Do we reckon it is actually 16.128, or is that also an approximation?

And what would I have to do to make it run 16.128/16 = 1.008x faster?

The beech clock showed 11:15:00 (horizontal minute hand) at about 11:18:00 on the PC, at which time the plywood clock showed about 11:17:15.

So at 11:18am, the beech clock was about 2m15s behind the plywood clock.

In ~/gear-ratios/find5 I have a program to search for geartrain solutions if the ratio is indeed 16.128, and it finds no solutions :(.

The datasheet also says:

As of Jan 2021, these have been coming with 1/64 gearing rather than 1/16 gearing! As of Nov 2021, we now have them back with 1/16 gearing as we prefer!

So possibly as of Nov 2021 they are a different "1:16" ratio, and they haven't measured it properly.

Instead of trying to replace the geartrain, would I be better off attempting to source true 1:16 motors? It seems they're more commonly supplied with "1:64", if I'd have managed to get that I could have avoided having to redesign the geartrain in the first place!

Plywood clock is showing 11:30:00 (vertical minute hand) at 11:30:55. Beech clock is showing vertical minute hand at 11:33:27, so it is 2m32s behind as of 11:33:27. And I think this measurement was more accurate than the prior one.

Plywood clock is showing 18:00:00 (vertical minute hand) at 18:00:48. Beech clock is showing vertical minute hand at about 18:04:00, so it is 3m12s behind as of 18:04:00.

It has lost 40s over the course of 6h30m33s, which means it is running 0.17% slow, which works out to a ratio of 1:16.027?

Plywood clock is showing 21:00:00 (vertical minute hand) at 21:00:26. Beech clock is showing vertical minute hand at 21:04:03, so it is 3m37s behind as of 21:04:03.

So since 11:33:27 it has lost 1m5s over the course of 9h30m36s, which means it is running 0.19% slow, which works out to a ratio of 1:16.030?

If we assume that the plywood clock has actually always been 26 seconds behind real-time, and I just measured it wrong before, then the beech clock had actually only lost 36 seconds over 9h30m36s, which means it is running 0.11% slow, which works out to a ratio of 1:16.017.

Well I think we've proven that the ratio is not 1:16.128. So far it appears to be between 1:16.027 and 1:16.037 if my timestamps are accurate. The average of those is 1:16.032, which strikes me as likely because 32 is a power of 2, not sure how much validity there is in that.

But if it is 1:16.032, then the good news is a sensible solution exists: 1:25 6:43 6:47 will take just under 3600.075 seconds to do one revolution of the minute hand, which is 0.002% wrong, which works out to just over 5 minutes in 6 months. Since the time will need changing every 6 months for daylight savings, this is acceptable to me. It's also quite close to the existing ratios, so the existing shaft spacings will probably be workable.

If my timestamps are not accurate, and the plywood clock timestamps should all have been xx:xx:26, then the ratio appears to be between 1:16.004 and 1:16.023, the average being 16.0135, for which there is no good solution.

I think the plan tomorrow is:

< 2023-12-02 2023-12-04 >