Let's Design and Build a (mostly) Digital Theremin!

Send In The Reinforcements!

My OpenSCAD experience has improved as I've become more familiar with how it works.  Thread design was a really good exercise, and made me much more aware of general thread geometry and tolerances, as well as some rendering limitations of OpenSCAD. 

There are some things I'd probably change in OpenSCAD, like have negative volumes so that those could track at the module level, but nothing seems to be terribly missing.  And since it's a language, you can always add your own primitives by including their files.  Some features feel really clumsy at first - because they are! - but like anything you get used to it.  Final render times can be on the order of minutes, but the preview is usually pretty snappy.  If you're familiar with C / C++ syntax, you will immediately be familiar with OpenSCAD coding syntax, as they are largely equivalent.  And text file input means you can document critical design elements (like parameters) to your heart's content in the comments, a gigantic advantage over GUI type CAD entry.

I'm using the "hull" quite a bit lately, coupled with the "cylinder" which allows for different top and bottom radii, to form face plates, ribs, LCD windows, etc.  You see the "minkowski" used a lot, but I've read that it can be really slow to render, and I've gotten away from it with more direct basic forms.  The biggest challenge in SCAD has been in adding a casual chamfer or fillet - sometimes you have to really think about how to do it, but usually there's a way that works well with the overall base geometry, and it never hurts (or, I should say, it always helps) to think about that some more.

One thing I'm doing lately is CADing up any mating parts as transparent red/orange, and turning them on and off with a debug flag (along with some ECHOed fit dimensional reporting).  Really useful for eyeballing fits and catching those sorts of mistakes.  Here is my latest LCD & Encoders plate with the LCD module and encoder PWBs enabled:

You can see that I've beefed up the reinforcing ribs around the LCD module.  And here is my latest tuner plate:

Added some ribs around the perimeter, one down the center, and some skirting for the LEDs.

And here they both are printed in black PETG (I've since reduced the depth and angle of both the LCD and 7-segment LED windows, and I've applied Roger's red filter to the 7-segment):

Lordy, I wish I'd gotten into 3D printing a whole lot earlier for this project.  I've wasted enormous amounts of time shopping for cabinetry related stuff.  Even finding suitable prototyping enclosures, where you don't give a hoot what it looks like, can take forever.  And 3D designing & printing is sorta fun, particularly if you're a control freak like me.  But just sorta, as it certainly has downsides - much of the pleasure has been in the achievement of specific goals.

Pix are hot-linked from my D-Lev web site (https://d-lev.com/) storage, TW photo album upload seems to be broken?

And text file input means you can document critical design elements (like parameters) to your heart's content in the comments, a gigantic advantage over GUI type CAD entry.

Comments - and deltas between versions that diff-tools can make clearly visible, if you use source control.
*casually reminding, without any nagging tone at all. Maybe*

Comments can lie. Showing you what exactly actually did change is quite valuable.
Also, source control commit messages are comments - but better - comments tagged to those actual changes. So you have a contrast between what you were thinking at the time you were doing, vs. what you actually did - if you always enter meaningful commit messages, that is.
(and all depending on the granularity of your commits and all that, of course)
And casually switching between branches of your project to try out different trajectories, and re-merging stuff to a synthesized version (perhaps with "cherry pick" command) can be quite time saving to "manual" alternatives.
I like this way of doing things, roughly:
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

And it can be routinely done auto-backup with you not even thinking about it anymore.
Ok for me at home it's easy. I have my Synology NAS with RAID-1 where such stuff is on (and if I weren't so cheap I'd have a UPS incl. network port protection before it, instead of the mere "overvolt protection" power strip),
and as those guys like to make it easy for the user, installing a git server on that thing was about a click or two. (next to a wiki and an issue tracker, which is also nicely usable as a TODO list with priorities and inter-links to other stuff).
Would probably make sense, too, to put stuff on github, then even fire or water might not destroy my work. But non-open repos cost something of course. Not that I had top secret stuff, more like "not yet ready for anyone else's eyes" kinda stuff, haha.

In case you don't like git-scm in particular:
One interesting niche (inherent disadvantage alert) program I found was fossil-scm. Had that for a while on an old similarly low-power-ish machine as server.
I did really like it, but have gotten used to git at work for a long time. Also last I looked, no "well made" GUI for the everyday tasks exists.
It's made by the guy behind SQLite.
It is dead simple to install - one self-contained executable.
But hosts a distributed source management system, somewhat simplified in use compared to git - but still distributed which means no forced server access and slooow as a dog work all the time and branching hell like in SVN (or, much worse yet in all thinkable regards, CVS).
It also has a built-in wiki system with a nicely simple syntax that gets the job done. The source control can be applied to the wiki itself, IIRC.

"One interesting niche (inherent disadvantage alert) program I found was fossil-scm. Had that for a while on an old similarly low-power-ish machine as server.  It is dead simple to install - one self-contained executable."  - tinkeringdude

Interesting, thanks!

"But hosts a distributed source management system, somewhat simplified in use compared to git - but still distributed which means no forced server access and slooow as a dog work all the time and branching hell like in SVN (or, much worse yet in all thinkable regards, CVS)."

My contact with version control SW has been as minimal as I've been able to make it.  Someone else archived my code at work, and an early version of my Hive processor posted to opencores.org required me to use SVN, which I was able to sufficiently navigate to some degree after much pain with TortoiseSVN (no good deed goes unpunished).

For all my coding on this project (SystemVerilog, C++, HAL assembly) I keep a changelog text file going, and zip up the relevant code before starting any new edits.

Seven Brides For Seven Encoders

Worked on the encoder knobs again some yesterday and today.  Reworked the SCAD file to bring it more in-line with my latest coding style and methods.  Gave it a DEBUG parameter that shows you a cross-section for better squinting at the thinness of the skirt and transition region:

Printed many out, adjusting the various parameters until it fit snugly on the shaft and felt nice to operate.  Small adjustments to the diameters, draft angle, and skirt height can make a big difference in the feel.  Then I used the multiply feature in Cura to print 7 more with the Overture "space gray" PETG which arrived the other day:

Printing 7 at once really cleans up the inside features, which otherwise come out kind of stringy.  Here they are installed:

I'm obsessing over tiny stuff when I should be concentrating on building the P3 enclosure, but it's kinda fun, and it's hard to stop until it feels like it's been put to bed.

required me to use SVN, which I was able to sufficiently navigate to some degree after much pain with TortoiseSVN

I remember years of using SVN "fondly". No matter what UI client.
Oh wait, that was not the English word for ROYAL PITA, was it? No, no. It was *that*.

For all my coding on this project (SystemVerilog, C++, HAL assembly) I keep a changelog text file going, and zip up the relevant code before starting any new edits

You know that every time you do that, somewhere in the world a kitten dies, right?

SCM is sufficiently complicated to make it a not good idea to just try out some program "oh there is a GUI, then it's easy, right?",
but read a bit about the principles of the logic of the system.
But then, it's not *that* complicated, for usual use cases anyway, not doing fancy stuff and knowing every inch of a system's guts.
But, what I'm trying to say is, there's some room between self-explanatory and rocket science

Often GUI clients add their own logic flavor on top of it (to some criticism, notably, TortoiseGit - but I like what it does for the most basic everyday use, accelerating that - and then go to the command line for parts where I won't bother with the funny abstractions Tortoise has).
I myself use only a probably small subset of e.g. git, though. Stick to some ways of doing things that never created big trouble for me in all those years. The only times there was trouble on occasion was when one a particular colleague did something weird again, IDK whether the UI software he used was prone to create weird states or he had a hand for making things explode unexpectedly (no other person on the team managed to.)

While I used some form of SCM (earlier so called version control, in the simpler days) since I first got wind of its existence and never looked back, somewhere in the mid noughties, I was initially hesitant to adopt distributed SCM.
Because Mr. Torvalds, in his (in)famous talk about how bad SVN, CVS etc are, was rather big mouthed and also exaggerated with the uselessness of said systems (tunnel view of someone maintaining a thousands developer global project - there are other legit use cases).
But if you didn't like working with SVN, maybe you should listen to that talk and get some inspiration to use something more modern
And again, after I started using it... I saw the light and now almost condone Torvald's loud mouth about it And never looked back. The model of how things work is so much better, for almost any imaginable use case.
Only that git in particular makes no secret of being (really) bad with binary files, it's not their aim.

For all my coding on this project (SystemVerilog, C++, HAL assembly) I keep a changelog text file going, and zip up the relevant code before starting any new edits.

SCM is very helpful, even if you just using it for logging of changes.
I'd suggest to use git+github.

Learn git commands status, add, commit, push - that's enough.
You will get easy change logging and backup. Easy to share your code, easy to accept modifications.

Rolling Them Bones

The huge circular cutouts on the antenna plates seemed kinda too big and made the sides rather weak.  Looked at many types of lightening holes, finally settled on my own rounded diamond design (proof-of-concept 1/2 scale print):

And while I was fiddling while Rome burned / rearranging the Titanic deck chairs, I decided to commit the general sin of premature optimization by parameterizing the rows and columns - hey, gotta learn 3D CAD somehow! 

Though I'm having second thoughts about any kind of venting / airing out going on here.  Proto #1 had the antenna guts in completely separate boxes and the drift over time seemed much less than P2 where everything is living together in one box.  The antennas draw very little power and shouldn't warm up on their own much at all.

Also printed out the latest tuner plate full size in space gray, and that turned out pretty nice.  Tomorrow I'll do the same with the LCD & encoders plate.

On a whim, I turned my chamfered test cube into loaded dice, something I've always wanted since I heard about them as a kid.  You "load" them in the slicer by putting the face you want down, and jacking up the top layers - fun stuff!  These are only mildly loaded to give 5+2=7, someone might not notice the odds difference right off - though they would definitely notice the homely print job and the sharpie dots! [SCAD FILE].

If that's PETG, it looks like you've made transition from PLA rather quickly. It's hard to completely eliminate fine hairs using PETG with a Bowden system (or a direct extruder, for that matter).  A hot air gun will take care of any remaining wispy strings, but you have to use very quick blasts or you will soften the sides.

When you're not printing any overhangs (and this would include any 45 degree chamfers on the bed face), consider checking the "Print Outer Wall First" option (under SHELL I think).  It usually gives the best outer surface finish because the outer perimeter extrusion is defined more by the precision of the extruder travel path alone without the influence of the cumulative lumps and bumps of previously-printed inner perimeters.

Regarding your loaded dice, one of the more interesting capabilities of 3D printing is the ability to completely embed an object inside the printed part by creating an internal pocket and then pausing the print at the correct point so that you can manually insert an object such as a magnet, threaded bushing, or in the case of your dice, a small weight. Think of how you could embed a small circuit board with a side connector or protruding pins.  The inverted pcb surface could act as the required support for the subsequent top layers to seal everything inside. It would be an easy way to spiff up a dead-bug circuit or a perf-board DIY project like the YAEWSBM.

Another thing comes to mind looking at your knobs above.  Printing in "vase" mode can provide a single-wall, spirally-printed shell that is devoid of any seam artifacts caused by the layer shift.  If desired you could print the core of the knob normally and then print a high-resolution vase-mode outer shell to dress it up.  A spot of glue would supplement the friction fit to permanently merge the parts. It's not much effort if you really have a need for custom knobs. 

"If that's PETG, it looks like you've made transition from PLA rather quickly."  - pitts8rh

Trial by fire!  I've had a reel of black PETG for ages and just never used it for anything but knobs because it seemed so temperamental (up to this point, everything in this thread printed black has been PETG, everything gray PLA).  Larger parts in PLA with 2 layers all around and 20% cubic infill are hard as rocks, whereas PETG with 3 layers all around and 25% infill are rather rubbery, and this has forced me to really beef up the reinforcements.

PETG seems really, really sensitive to nozzle height, and it's hit or miss lately whether I continue a run after seeing what's happening on the first layer.  95% flow for the first layer seems to kill the wavy oversplooge.  And I'm not sure I trust Cura to actually do 100% elsewhere without overriding that to 99%?  Probably just getting superstitious...  Anyway, z-axis repeatability seems to be job #1 with PETG, so I'm doing longer warm-ups and am considering including a small test part instead of the raft, which doesn't have room to print with larger parts.

"Another thing comes to mind looking at your knobs above.  Printing in "vase" mode can provide a single-wall, spirally-printed shell that is devoid of any seam artifacts caused by the layer shift.  If desired you could print the core of the knob normally and then print a high-resolution vase-mode outer shell to dress it up.  A spot of glue would supplement the friction fit to permanently merge the parts. It's not much effort if you really have a need for custom knobs."

You're going to have me retiring on just the knobs!

I prefer my custom knobs over the commercial small communication knobs I've been using, and I don't think it's entirely a NIH thing.  My knobs cover and hide the encoder nut and washer underneath, and the upper face of the skirt is just high enough to keep my finger tips from brushing against the faceplate when spinning them.  The lack of a setscrew also dramatically lowers the chance of ESD events upsetting the D-Lev, which did happen in the past (mostly during the dry winter months when I'm wearing my plastic soled booties). 

Which reminds me: maybe consider a separate ESD ground for your encoder boards, rather than lumping it together with digital ground?

Grey / Silver look so metallic.
Doesn't this filament have metal powder inside? (If so, it could interfere with LC).