Clockathon code base up on Github, and next steps...
Mathieu Glachant
the old Printable Clock Project code up on Github, fork it, apply all
the changes we made during the Clockathons, break them up into logical
chunks as individual commits, and merge the branch back to master.
This means that the GitHub repository is now in synch with the last
version posted on Thingiverse, and it should be much easier to
understand what we changed over the course of the Clockathons.
https://github.com/syvwlch/Printable-Clock-Project
This is going to be the base from which I will keep developing, so I'm
going to fork it again and work on that fork for a while. Since I'm
still loaning my ToM to a friend, and since the urgency of TED2012 is
behind us -- Congrats Bre! Can't wait to see the video. ;-) -- I'm
going to work on refactoring the code for a while.
Specifically, I want to break up the code into individual scripts for
each part, write a command line script to compile and render all the
corresponding STLs without the GUI, (kinda like doing MAKE on your
source files) and then have the assembled-view script just import the
STLs. Some reasons for this choice:
1. Guarantees that the assembled-view actually corresponds to what you
would get if you printed the current batch of STLs.
2. Makes assembled-view much more responsive, even in F5.
3. Include some testing in assembled-view, or in dedicated testing
scripts, e.g. intersections between parts to check for collisions.
3. Eventually automate the entire chain, so that you can commit a
change to Master, run the compile/render script, and check the results
in assembled-view or the testing scripts. Heck, have the
compile/render trigger off the commit for true continuous integration.
:-)
I'm sure that's how the big boys do it already for complex OpenSCAD
designs like a fork of a reprap.
ruste...@prototribe.net
When I get some time i'll be uploading an openscad file of a 30 tooth
escapement mechanism that seems to work pretty reliably (after dozens of
tests and prints). The longest ticking time i've gotten was 12 hours and
it only stopped because the weight started colliding with the pendulum.
And even then it ran for hours like that which I found sort of amusing.
I also re-discovered that the length of the pendulum is partially
determined by the mass within that length. The ~1m length for a 2 second
period only applies to a theoretical pendulum with all the mass at that
distance. Adding mass across the pendulums length changes that a bit and
required a slightly longer pendulum.
Fun!
Mathieu Glachant
Settled on a display method yet? Hands or numbers on the gears with a static indicator pointing at them?
ruste...@prototribe.net
Once I shore up the indicators, drum and rewind mechanisms i'll probably be setting up some tests with an arduino, rtc & ir emitter/detector to measure and experiment with the pendulum period to refine that aspect.
Mathieu Glachant
On Wednesday, March 7, 2012, <ruste...@prototribe.net> wrote:
> I'm going with numbered plates with a static indicator (bottom of each disc). Its proven quite useful in testing as I can reset them to 12:00 and start the pendulum to see how long it runs. I've also moved the weight from the hour gear to the minute gear but I don't have a working drum design there yet. The larger the drum the more torque the weight will provide, but 30 turns on the hour gear requires a pretty small drum and I haven't put together a design that doesn't require support material yet. (But the drum itself now hosts the teeth and the base gear hosts the arms due to size).
>
> </mail/u/0/s/?view=att&th=135ee35e1d33d237&attid=0.2&disp=emb&zw>