Some Day My Prints Will Come

...And they did.

So the box from Shapeways arrived today.  Cost of the model with shipping; about fifty bucks (using the sintered Nylon-3 they call "White Soft Flexible.")

 Cut the pieces from the sprue with diagonal cutters, and tried a rough assembly.  All the parts fit, and there wasn't any significant warpage.

As it turns out, I needn't have worried about the fit of the "socket" on the wheels; at that scale, it is going to be eyeball and a blob of glue anyhow.

And the turret is plenty generous.  I might even shrink that tolerance a little.

And here it is, rough-fit (omitted the undercarriage and just balanced it on the wheels instead.)  As you can see, some details got dropped/filled in.  The only really objectionable part, though, is the stair-stepping on the rear of the hull.  This is inevitable when combining a gently sloped surface with the 0.12mm print head motion.

For reference, this is a "hero" render of the actual model (note; this is with all edges beveled to reveal the actual polygons better.  Ordinary renders would smooth out the curves instead.)

So what is next for this model?  Well, a few minor modifications to improve the print -- which is currently being offered for sale at my Shapeways store.

And the Poser version, which is taking a long time; I had to throw out most of the hull thickness so as to permit working vision blocks and opening doors.  And although the details are a bit too fine to print properly in the material of choice, they are not quite fine enough for the Poserverse -- I need to replace hinges and latches with more detailed ones, and the vision blocks need to be completely rebuilt.  Not to mention, you know, interior detail!

How to Ring a Prop Phone from QLab

Opening Remarks

There are new plays being written every day, but so many of the plays in our repertoire are older (if not actual old chestnuts.)  Between the aging subscriber base and the desire for familiar pleasures, you can be sure that in most theaters you work at, you will be doing "Charlie's Aunt" at some point.

Which means that although we've moved on in our own lives to men without hats, jackets without vests, carriages without horses, lighting without gas, freezers without ice delivery, in fully half the repertoire older ways and older technology are part of the action.  There are few plays yet in which appear an iPad or a tweet -- but many in which a telephone has to ring.  And I mean ring -- not a ringtone, but the good old electric clapper that was part of our lives for almost eighty years.

Theater sound design is changing as well.  I am tempted to say it might be less realistic, less diagetic, but fuller and more complex.  But that might just be the companies I've tended to work for.  Result being, you are more likely today to play a sound effect off of digital media and through speakers, and less likely to make use of the storehouse of theater tradition with its crash boxes, starter pistols, thunder runs and, yes, phone ringers.

In any case, making a phone ring is an instructive problem.  One word used around the Arduino community is "Physical Computing."  Or, as Tom Igoe puts it, Making Things Talk.  And that is the problem of getting software in the virtual world to do something out here in meatspace.

(How bizarre is it that Chrome's built-in spellcheck flags "diagetic" but not "meatspace?")

And thus, here is how I got an actual period piece of telecommunications to go through its paces once again under software control.

Physical Layer

I got lucky.  I happen to own a 1U rackmount module that puts out Bell standard voltage and ring signal (90 VAC at 20 Hz, super-imposed on a 48v DC offset).  This has been the standard almost since Alexander Graham spilled acid on his trousers (prompting him to call out, famously, "Watson, come here.")  The theater also owns a 90V 30 Hz machine (British standard).

There some cheesy ways to do this.  The craziest and most dangerous is to half-rectify wall voltage.  You then get a sort of pulse DC at approximately 60 volts and 40 Hz.  The next step up in cludge is to use a step-down transformer to bring wall voltage close to 48 volts, then switch it on and off again through relays driven by an oscillator at 20 Hz.  This works better, although it lacks the DC offset.

Better yet is step-up schemes, because these can operate from the safety of batteries or the isolation of a wall-wart power supply.  But this is not the moment to go into those (perhaps later I'll build one of my own from scratch, and document that.)

Since I had the module, all I needed is a relay to switch it.  Since it is an AC signal, I am running it through a relay.  Some reading affords that the ring signal is probably under half a watt, and this puts it within the range of a PC-mount relay.  I was lucky enough to find one at the Rat Shack with a coil voltage of only 5V (12V is a lot more common for relays.)

Since even that coil is a bit too much heavy lifting for an Arduino, a power darlington -- the old standby the TIP-120 -- is running it.  A resistor between Arduino output and darlington just for extra protection.  And, also; when a relay or solenoid is switched off, the collapsing magnetic field produces a transient voltage of inverse polarity to what was applied.  A diode is soldered backwards across the coil of the relay for just this reason; the transient bleeds off through the diode instead of attacking the transistor.

This is quick-and-dirty electronics as well as temporary, so Arduino is fine, with an Arduino proto shield to hang the wires on.  (This is a bare board with Arduino matching headers on it; they have them at SparkFun, Adafruit, and the other usual suspects.  I particularly like the one from Modern Devices myself.)


(The button you see taped to the desk is a back-up, wired in parallel.)

Software Layer

The chain of software starts in QLab, with a combination of MIDI cues, GOTO and RESET cues to set the cadence of the ring.  (New picture, showing some of the MidiPipe window as well as the Processing ap's window.)

To detail a little; the Phone On and Phone Off cues send a MIDI note event.  On is a MIDI "NoteOn" event, and Off is, well, a NoteOff.  These are MIDI cues, which you need to unlock with the MIDI license for QLab (which has gotten quite a bit costlier since the Version 1 pictured here, sorry!)

Both cues are in a group cue so they fire together automatically.  The pre-delay set for the Phone Off cue means it waits for 1.5 seconds before it actually fires.  After an even longer pre-delay, the GOTO cue sends us back to the top of the sound group again.  The actual standard US cadence is 2 seconds on, 4 seconds off.  I picked a faster cadence -- and it works perfectly with the action.

The entire group cue was dropped on the RESET cue.  Which is inside a second group.  This group has a noteOff event in case the loop was in the middle of a ring when the RESET cue was hit, and a sound cue.  So it kills the GOTO, stops all the MIDI cues, fires off a second noteOff to make sure the phone stops ringing, and then plays the answering machine message.

The next step in the software chain is Processing, which receives the MIDI event sent from QLab and sends a serial message to the Arduino:

Above is the window for the Processing ap (compiled as a stand-alone).  As you can see, it gives no options for selecting the correct ports; those identities are hard-coded.  The display text exists only to confirm everything is working correctly.

(There is also MIDIPipe working here because Processing wouldn't recognize QLab as a viable MIDI source).

The key functions here are at the bottom; the NoteOn and NoteOff function are from themidibus library; they are called automatically if the appropriate event shows up at the designated MIDI port.  When each function is called, a single ASCII character is output to the selected serial device (the associated Arduino).

The rest of this is boiler-plate; list the available ports, pick a port, instantiate a MIDI object from the themidibus class.



The last stage to the software chain is the code loaded on the Arduino itself:

Even simpler code here (and a lot of it is leftover cruft from a different project and doesn't actually do anything here).

We're using the hardware serial port and the Arduino serial library.  It simply checks on every program loop if there is a character waiting on the serial port.  If I had saved to a string, I'd need to flush that string on detect, but in this case it just has whatever character is present (usually "null.")

When the right character shows, the relay and a blinkenlight are activated.  Since the outputs toggle, they remain in the state set until the loop is presented with the appropriate serial signal to turn them off again.

I added a button to perform on-board testing and over-ride the Processing end, but never got around to coding it.

Iron Cars, Wooden Fingers

I am on the home stretch now for the V150 model.  Adding hinges and lifting eyes and other stuff to it now.  Which is going quickly because there's no real point in doing careful research, or even careful scaling; these items are right at the verges of printability and have to be made large and crude just to pass the software tests.

Oops -- got the periscopes turned around.  Don't worry, it will be fixed before printing.

I simplified the undercarriage a lot, but it still took up the better part of two days.  I left off shocks, power steering cylinders, brake lines, etc., etc.  But then messed around for a while figuring out a way to connect to the wheels so someone could use other wheels if they had them on hand (the wheels have enough thickness in them to cost a whopping $3.98 each to print).

For some reason it took the better part of today to work up the rather simple-looking Rheinmetall Mk20, otherwise known as the Rh202 20mm autocannon.  Several hours of that was looking for better reference material.  The bulk of the rest was not in modeling per se, but trying to get the mesh to agree with two different references which were incomplete, confusing, and contradictory.




For this project I worked in real-world scale.  This is what I have been doing with my Poser stuff of late; it is much simpler to set the workspace to real world scale, including a reference grid, and then re-scale during export.

Carrara's obj export is unscaled (thus useless in Shapeways).  Collada is broken.  So far the only export chain I have working is Wavefront obj from Carrara, re-scale to print size in Hexagon and export as stl (which does have a scale).

But since Hex only displays three significant figures, and Carrara a mere two, I really have no way of knowing if I have more than one piece in scale to each other.  So I'm going to have to do something clever when comes time to send the complete model to the printer.  It might even involve sprues.

A new trick I used this time; I cropped the reference image square, then, using the exact pixel size of an object of known scale (in this case, the hull of the V150), was able to determine the world size of the reference image (8.21 meters, as it happens).  With that, I could set the Carrara working box to 8.21 meters and thus the drawing became exactly world scale.

(Well, almost exactly; an error of 1:100335 somehow snuck in there.  And, yes, I'm using entirely too many digits when my confidence is barely to the first "3.")

At least I'm done with shocks and struts.  On this vehicle, anyhow.  My own needs a little attention now.

Another Fine Mesh

So.  Mesh design, for 3d printing and for Poser, and how those differ.

This is going to be a rambling post, an exploration of concepts and ways to explain them that might, one day, make it into a tighter and better edited post.  With pictures.