Last modified: 2023-12-01 04:36:05
< 2023-11-29 2023-12-01 >I've installed both of the motors, including little copper wires to earth the cases, and set them both running.
I noticed that the motor on the bamboo clock motor was briefly stopping and restarting, but it seems fine now, maybe it just needed to wear in its gears a bit.
I noticed that the distance between the first wheel and the motor on the beech clock is too large, I can probably rememdy this by making the bit that goes on the motor slightly larger.
I've left both clocks running with the first wheel's synchronised, and the flats on the minute hand shafts roughly synchronised, so that I'll be able to tell if either of them has stopped when I come back later.
Hmm, the bamboo clock is definitely running slower than the beech clock. I wonder if it is missing steps? It is almost a full revolution behind after only about 15 minutes, which would be about 4 minutes per day.
Both motors stall more easily than I remember, if pressed with a finger. I wonder if the capacitors have got knocked loose when I was shoving the wires inside the housing? Or if I just have more leverage now that I'm not trying to grab the shaft directly?
I do have the option to double the voltage if necessary. But I'll leave them running some more and see if they free up acceptably.
Actually, I'll leave the bamboo one running as-is, and I'll double the voltage on the beech one and see what difference it makes.
Transformer got very hot, bad smell, motor not turning. OK, so I can't double the output voltage this way.
So the next plan is to put it back to 6.3v, and hook up the oscilloscope to check the phase difference between the two waveforms.
I put the voltage back, switched it on, still didn't work. Replaced the 3 amp fuse, switched it on, it briefly worked, but then there was a flash from the transformer and it stopped working. So I think I have broken this transformer.
I do have a 9v transformer in the drawer though, so I can put that one on and get a bit more voltage out. And also probe it with the oscilloscope to see if the capacitor is unsuitable.
Ah, the issue with the motor alignment on the beech clock is that the motor is angled downwards because the earth wire pushes the top of it away from the frame.
I tried to adjust it but not sure how successful I was. Probably I should just print a bigger piece to go on the motor shaft.
So I'm leaving the beech clock running at 9v to see if it gets unacceptably hot.
This is what the oscilloscope says:
So not a particularly satisfying phase shift. The old one was:
I could try putting a second 47uF capacitor in parallel to see if it is any better. Surprisingly, that makes it worse! So I need less capacitance?
If 9v doesn't get too hot, then I also have a 12v transformer that I can use, and if that doesn't get too hot either then I can run one on 9v and one on 12v and have them work. Failing that, I can acquire slightly lower-valued capacitors and run them on 6.3v.
I'm going to install the hands, even though the dials aren't ready, just so I can track their progress.
Both clocks are in sync, with the hands showing the correct time, the first wheels lined up, and the motors lined up:
17:03: The bamboo clock is definitely losing time. The beech clock is not getting appreciably warm. I'll leave them both going a bit longer, but I think 9v is going to be acceptable.
I'm having an issue with the test suite where it runs out of memory in slangi, but if I add code to print out
how much memory is being used, it no longer runs out of memory. What is going on here? Is it wrong about having
run out of memory? Maybe there is a bug that makes it think it has run out of memory before it really has, so
fixing that would be a big win.
Bad that I'm struggling with this now, because it's nearly 8pm, so Advent of Code starts in only 9 hours.
Man I am deep in a rabbit hole now. I've made the bigint lib use a lot more global temporary allocations instead of doing so many runtime allocations.
I've made the interpreter use an arena allocator for the AST.
My best theory if there is not a bug in malloc or slangi is that the exact layout of allocations matters for whether
or not it runs out of memory, and that is changed by the amount of code, so counterintuitively, having more code
can make an sbrk fail sooner, which causes a different memory layout, which allows it to work a bit longer before
actually running out. Maybe?
Now I'm seeing:
run test again under slangi:
error: test_bigint.sl: line 27: use of undefined global: ^@est_bigint
Where the "^@" is a nul character - could this be the lesser-spotted filesystem bug that was producing bad binaries before? Or just a bug I wrote this evening?
Ah, it was just a bug in my arena allocator. (On the first allocation inside a fresh arena it forgot to subtract out that allocation's size from the space remaining).
The good news is that with these changes it no longer runs out of memory in the test. It has like an extra 2 Kwords available I think. That is massive. Not clear whether there is indeed a malloc bug, or the more efficient usage of memory has made this much difference.
Anyway, it's passing tests now. Must keep an eye out for possible malloc bugs though.
Next up, I need to install the latest microcode and filesystem, and do a end-to-end dry run of an Advent of Code problem.
< 2023-11-29 2023-12-01 >