I took one of these a while back when I dropped the machining to have most of the gun printed. But I'm choosing not to take two others; to go with "good enough" on the programming, and to accept the results of the Rub 'n Buff experiment.
The latter first. I did several pieces in Rub n' Buff before discovering that although it generally wears well, it was coming off the sharp edges. Such as on the grips, with the decorative grooves. So I've gone back to Krylon Premium Original Chrome. Over the black epoxy enamel I'd sprayed earlier (for strength, mostly.)
Paint on the left, Rub 'n Buff in the middle. The trigger guard is real metal; CNC'd aluminium with my M40 Grenade-tested treatment of 220 then 400 grit wet-dry paper, a buff with 0000 steel wool, then a protective film of sewing machine oil.
The picture is a little misleading. The Rub 'n Buff looks better at a distance, and the aluminium piece is at the wrong angle to the light to catch highlights here. And I can see some typical orange-peel in the paint (like a lot of metallics, it doesn't achieve the really good shine unless you put it on heavy enough for it to self-level).
But it works. And, yes; this is another huge advantage to all-metal construction; you can ding that stuff up pretty badly without scratching the "paint." (Would have also helped in some of my mechanical connections -- the e-cell catch, for instance, was really designed around metal-on-metal contact, and it also suffers from the larger footprint required of brass thread inserts over the original plan to tap the aluminium.)
The final details are coming together. I spent another day at the 3d printer. TechShop finally got a second printer working -- which they gave to the classes, but at least that gets those out of the way of making a reservation. And they have at least four of the Zim machines being prepped now. So in the long term printing there will be less of a chore.
Speaking of which. Someone had run nickel-powder PET through the machine I logged into, and perhaps because of that or perhaps because the bed is increasing warped (Type A Machines really need to look into a better print bed) I could not get my prints to adhere. Spent a good hour messing around with the settings (and adding more and more glue to the print bed) until I finally started getting clean prints.
Also oddly -- I set up the first print using the Cura v.15.06 they had loaded on the machines at Techshop, but the subsequent prints I sliced with my own copy of Cura v14.12. And whether it was the software itself, or the possibility that my own tweaked settings had been saved to my copy, but I got nicer prints and a better printing experience with those.
My original idea was a Starburst; a typical Googie design element I really wanted to incorporate (just as the design consciously includes boomerang shapes, jet nacelles, tail fins, etc.) But a last-minute suggest from a friend was another famous bit of Atomic Age design; the atom.
The top is the Starburst idea, but that side is actually where the power setting knob will be. The Atom will be on the other side. And, yes...it should have had three orbits for a proper Bohr atom (which would be Lithium, right?) but I was modeling at warp speed while sitting at the printer with the minutes on my reservation running low.
While I was trying to figure out how many electrons I wanted I had the inspiration to make this the element Tikium, atomic number 12:8 -- with a tiki head for a nucleus. Which is a little easier to see in the Cura display (where I tried and tried to put the quick Carrara model into the quick Fusion model, and after crashing Fusion multiple times finally gave up and did with two prints and some superglue).
Besides re-painting -- and painting up the fresh elements -- the only physical task left on the gun is to lathe out the emitter. Which with luck I'll get to on Sunday.
And finish the wiring harness. All the electronics are mounted now, but it is a good thing I left some of the wiring loose because I had to make several adjustments in how things were wired. I've really fallen out of love with the ATtiny84. I picked that chip for the DuckNode as a compromise between the tiny footprint of the ATtiny45 and the greater number of I/O ports. But there really aren't a lot of ports anyhow. I'm sharing ones I'd rather not share, and at some point I'll be in that ugly little round of having to disconnect the ISP in order to test a pin function properly.
It also only has two hardware timers (not including the watchdog timer, which I'm not about to get into. So my program has ended up taking on certain aspects of RTOS programming again. I have to really watch the operations I perform (modulus is an ugly one on the smaller AVR's -- even though they have a math co-processor it takes them 15x longer to run a modulus calculation than it does to run an "if" statement.)
So within the loops I have to program exceptionally lean. Because the program has to step through everything fast enough to be able to run a software PWM of the light (in order that I can fade it smoothly), and fast enough to not put too much jitter into the audio. And the timing is hyper-critical to where the sound only sounds right with the right number of delaying elements in the loop; meaning there's at least one spot where I have to use modulus just to get the timing to come out right!
Yes, more discoveries. The Arduino "delaymicroseconds" function leverages a timer. So I can't call it without messing up my own timers. And for some reason changing the system clock prescaler on either of the timers makes the "delay" function either run slow or not at all. Don't understand what's going on there.
More so, it appears my stick of ATtiny84's shipped with, instead of the 8 mHz internal oscillator ATmel promises they are supposed to default to, but the 128 kHz low-power oscillator selected! Fortunately, "burn bootloader" from the latest Arduino IDE -- patched with various third-party AVR-duino packages -- reset the fuses. Because I'm not up for trying to remember how to use the avrdude chain right now. (No doubt discovering a broken instal somewhere along the way!)
Thing is, in this kind of micro-computing one doesn't write a program. One writes a "sketch." The idea is you aren't trying to make something bulletproof, and test it before uploading to production. You just throw together whatever pile of code gets the project of the moment working. If Larry Niven's Pak Protectors programmed, this is how they'd do it.
Hence my current code-in-development, a horrible hybrid of Arduino macros and register directives written down so close to the metal they might as well be in Assembly. And of course lots of lines commented out, magic numbers everywhere, a few scrawled notes here and there, function calls done entirely so I can see where I am in the program flow, etc. Sure, your code might look like this when you are coming up with ideas, but I'm quite literally testing this in production; uploading it in real time to the hardware to see what happens.
But with any luck, I won't need to make any more hardware layer alterations, and I can finish the wiring harness and close it up. Today, I'm hoping. I just need to finish writing the Power Selector Knob routines, a nice Continuous Wave setting, and if I get ambitious a Power On hum for when the system boots and a "Phaser on Overload" for when you twist the control knob all the way over.
That is, assuming all the paint has dried by then. I may have to wait until Monday to bolt everything back together (it was all bolted together for the test assembly so I know that part is all good). And switch to working on the holster instead. Picked up a couple yards of white pleather and clear vinyl to play with...
No comments:
Post a Comment