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.

Snow Crash

Well, the crazy system I am running "Drowsy" on finally let me down.

It has been a show full of fun.  Opening night the main rag slipped the lower pulley and barely made it in and out, and the work lights were left on, spoiling the opening blackout.  One night the follow spot got locked out of all cues and they had to turn it on manually.  Which was good, because the next night the "robo-light" (some moving light, I don't know the make or model) didn't light, and they had to cover for it with a manual follow-spot.

I'm running all the sound through my laptop.  Well...everything but backstage and conductor's monitor.  Us old-school techs are scared of depending on a computer.  I've seen a BSOD in a booth.  I've had to restart a Mac a couple of times, too.

Here's the set-up; wired microphones along the proscenium line, four wireless belt-packs on actors.  All plugged into a Mackie 1602 mixing board.  Then the group outputs of the Mackie are run into a MOTU firewire interface and into the computer.

In the computer, Reaper takes the different buses (proscenium mics, wireless mics, off-stage chorus mic) and processes them with compression and graphic equalizer.  (Plus there's a little corrective EQ done in the MOTU itself with its on-board DSP.)  Then Reaper exports to the primary firewire outputs, which are plugged directly into the house mains.

The other outputs of the MOTU are being sent to effects speakers.  QLab speaks to those.  And as I mentioned in a previous post, QLab is also generating MIDI events which are translated into a serial signal via a Processing sketch, and sent to an Arduino that switches the practical ringing phone on and off.



Saturday I had no signal on the vocal bus.  Same night we lost the moving light.  And, of course, it was the night I had friends in the audience...!

There's no intermission.  There really isn't a spot in the show where it was safe to reset the systems or otherwise do anything more than the most conservative problem-solving.  So I routed all the mics to the one working bus and worked with that.  Which didn't sound anything as good, but got me through the show.

Part of the problem was, I couldn't send any useful diagnostics to headset, and the average vocal material was too low to tickle the meters.  As it turned out, I still had the chorus mic bus, and that would have helped me zero in on the problem.  But the only times I had a hot enough signal to trace via metering, were times I didn't dare do anything that might kill the signal.

Well, following the show I could.  And it turned out...Reaper was fine.  The computer didn't crash.  Even the MOTU was fine.  The problem was on the group faders on the Mackie.  For some obscure Mackie reason, if the button to assign a group back to the main bus gets some corrosion in it, the signal out of the unique group output goes dead as well.

All it took to restore the sound was pressing the button a couple of times.  Today I sprayed the button, and the show went flawlessly.

And, yes; the contrast between not having the computer properly in the loop, and having the corrective EQ and dialed-in compression I'd set for the vocal mics....well, it was a huge difference in how transparent the reinforcement was.  So I am prepared to say this was a good way to do it.

Details, Details

The V150 hull is closed up and watertight now, and is probably printable.  I'm doing most of the detail work before I send the test mesh in, though.

Yesterday was turning it from a solid model to a hollow model.  And that was a lot more painful than I had expected. 

First, all of Carrara's automated tools bollixed on the mesh.  So I had to do it manually, one plane at a time.

Then I checked dimensions.  And the thickness I'd eyeballed was way under.  The minimum printable wall thickness is 0.7mm, and I was aiming for a margin with 1.0mm (or a little more).  That's almost 6 centimeters in the scale world.  Let's put it this way; the bottom plate armor of the real thing is less than 1/4 the thickness I have to make it in order for it to work in the 3d printer.

A lot of this would have been much faster if I hadn't made the doors and vision blocks and hatches as framed "holes" in the mesh.  For the battlemat version, none of the hatches need to open and in any case it would have been faster to do the extrusion and thickness if I had the simpler slab sides.  Lesson for next time.

So all that ate up a day.  Today was starting in on detailing.  Although the print will support details as fine as 0.2mm (a bit over a centimeter on the real vehicle), I've enough experience both with how smaller details can collapse or fill in, and how much I have to exaggerate details in order for them to be properly visible in scale.  On the real vehicle, for instance, the outside of the vision blocks is mostly a weld line, with a small retainer plate holding a gasket.

In the model, I am extruding the whole edge a couple of centimeters.  And, yes...since the shapes are already in the model, I'm making a smoother mesh and less material waste by extruding many details instead of adding them on.  The only exception so far is the exhaust shroud.

I've also been tesselating the various curves.  Originally, I intended to subdivide the entire model.  But Carrara's tools get a little funky around some shapes, and I was having to dial up the Sub-D to ridiculous levels in order to smooth out the puckers.  Plus the mesh was wrapping around itself in places and might end up unprintable as a result.  Oh, and Carrara crashed a lot.  It doesn't seem to like Sub-D on a model with multiple surfaces.



To do all these small details I'm jumping around between nicely drawn plans of a V150S, a walk-around book of the V100, and a plastic model of a late-issue foreign-export V150.  Many details don't match, of course.  Some are just plain difficult to find reference on.  I have a fairly good sense of what should be on a Morrow Project era V150, and I'm able to chart my way around some of the things present on Thai and Philippines reference photographs that shouldn't be on this version.

But with all that, plus the issues of having to build a mesh that can be 3d printed, means accuracy is pretty much gone by the roadside now.  I'm eyeballing everything at this point.  At least the basic hull shape is about the right proportions and angles.  And I've got the locations and more-or-less sizes of the various hatches off of references.  But the details and curves and thicknesses are all eyeball and trackball now.



A few more days.  I should be able to test the hull with the Shapeways software tonight, but I still have undercarriage, wheel hubs, turret detailing, and random bits like filler caps and jerry cans to do before the thing is complete.

More Fun With Math, and a Joke

I did a little calculating on the printing cost.  Unfortunately, once you assume a hollow model, the final price is exquisitely sensitive to the wall thickness.  So the difference between a generous thickness and getting right down to the margins of what is printable is a range of 4:1 in cubic centimeters of plastic, hence cost.

And this is the point at which the project forks.  The original request was for a hex mat model; detailed enough to be representative, but no functioning hatches or interior detail and, indeed, few small details of the sort that might break off in transit to the game and back.

The laser-sintered nylon (PA 2200) Shapeways offers as "White Strong Flexible" is the best choice for this, and can print down to a wall size of .7 mm, but given the strength should probably be between 1 and 2 mm in wall thickness for this model.  At $1.40 a cm^3, the hull comes out under $25.  So as a guess, the entire model is around $40 in this material.  Sans wheels, which as solids add as much as $8 to the print.

Since I intend to add some of the surface details, including suspension and hubs, jerry cans, lifting eyes, etc., I figure the complete and total print cost will be a bit over $60.

Here's the current state of the thing:

I am ready now to close up the hatches and vision blocks, add thickness to the walls and make them "watertight" (necessary for printing), and then extrude some select surface details around the vision blocks and hatchs.  The Rh202 barrel is just a mock-up for me; the final print will omit the gun barrel as it is too thin to print.

Actually, I have one other step before that.  Right now the mesh is at arbitrary scale (it is scaled to how big the drawings were in the workspace).  I need to fiddle with the bounding boxes and so forth in order to get a true scale representation, so I can keep the printable mesh within the Shapeways design rules.  Of course Carrara is poor at dealing with changes to its workspace defaults (and what else is new?)



The second fork is a diorama version with posable hatches (although I shudder at the idea of interior detail).  The thinner walls are more than offset by the possible upgrade to SLS ("White Detail" on Shapeways); a full $2.99 per cm^3.  I've worked with the SLS more than I have with the nylon, so I am not a good judge yet whether this materials upgrade is strictly necessary.

There has always been a military modeling community in 1:56, although they tend to gravitate to World War II era.  There is a growing number of models available of later armor these days (by much better modelers than I am), but, as yet, obscure post-Vietnam armored cars are not among them.

So there are people who could make use of this.  Enough to justify the effort, I don't know.




The putative third fork would be Poser-izing it.  Which would be a pain, mostly as my current mesh has extremely poor flow, is not Poser-optimized, and isn't UV mapped either.  Wouldn't hurt to have another 3d model in my online store, though...




Someone landed on this blog with a search for theater tech jokes.  Given time I'd remember a few.  At the moment all I remember is traditions at certain theaters, like "Pumatic" tools at the Rep (due to a badly spelled drawer label on the road box).

And a few lightbulb jokes.  The kind of theater person who says each, you can probably fill in on your own...

"How many ___ does it take to screw in a lightbulb?"

"One...two...one...two..."
"It's a LAMP, dammit!"
"It's not a prop or a set piece.  Get an electrician to do it."
"Ooh, I like it.  Keep it!"
"Five six seven eight!"

And related, there's the one a bass player told me; "One, five, one, five, one, five, one, five, one, five......"