Reid Carlberg

Connected Devices, & Other Adventures

Tag Archives: 3D Printing

Minor Adventures in 3D Design & 3D Printing: Traxxas Stampede 25C Battery Box


You might remember that I have a Traxxas Stampede VXL 4×4 RC truck.  (Then again, you might not.) It’s a pretty fun toy I bought a couple of years ago, and the other day I decided on impulse that it was time for a more powerful battery.  I was a little too impulsive as it turns out.  The additional batteries I bought were WAY to big.  Like ~17mm longer than the battery space.  Rather than do the smart thing — return them for the right size — I decided to take this as a challenge: could I 3D print an adapter that would let me use these too large batteries in my truck?


Well, it turns out the answer is mostly yes, but getting from never having done an original 3D design to the point where something worked was a interesting process, which is why I’m blogging about it.

I decided I would use Tinkercad.  It’s an easy online CAD program that lets you do some pretty sophisticated designs.  You start off with a blank slate, add shapes and letters which you can then resize and move around in 3D space, and then you can download it.  It turns out your can download for 3D printing or for Minecraft, and this Minecraft capability has created a whole new series of questions for my son and I to answer at a later date.

Since I was new to the software and to 3D design, I decided to start by answering a very simple question: could I build an adapter that would fit over the too large battery and stock battery holder at the same time.  I used the published measurements, and built the simplest thing I thought might possibly work:


Which when wrapped around a battery and connected to the stock battery holder looks like this:


So on the plus side it fit around the battery and my idea of connecting the battery holder through a narrow slot worked as I suspected.  On the downside, the battery still slid around, so this wouldn’t work for a car in motion.

Attempt 2 was really just a longer version of this sleeve, but with a solid end.  This also worked, since it’s basically just a stretched out version of Attempt 1, but in the end the battery would still slide around.

Pasted_Image_8_25_14_9_03_AMI started from scratch for Attempt 3 and did two designs, one for each end of the battery box.  I reused the public measurements, and then created a 5mm overlap designed to close the box up.  The walls are 3mm thick, so one side of the overlap was 2mm and the other was 1mm. A couple of things I learned here. First, apparently I made a math mistake when I created Attempt 1, because the published depth of this battery — 25mm — isn’t quite right.  It’s more like 27.5mm.  So my battery didn’t fit in the new box. Second, in order for the stock battery holder to work, I needed to leave more space to account for the larger battery’s need to hang over the place where the battery holder clips in to the truck body. Third, the 2mm + 1mm registration on the 5mm overlap was too tight for a 3d printed box.  It took quite a bit of force to get the two pieces together.  Finally, I need to be more careful about printing straight lines that span 45mm and start 20mm in the air.  The printer did remarkably well, but that’s not a recipe for success.


Attempt 4 addressed all of these issues and I’m pleased to say it worked fairly well.  The lipo battery pushed the truck into high gear and my in-the-dark truck vs. fire hydrant accident wasn’t fatal (although that’s probably not because of the battery box).  The 3D model for the back half of the box now looks like this:



This version also wasn’t perfect, for example the sides of the battery holder sleeve cracked at some point. I’m guessing that the strain of a relatively heavy battery on top and crashing at speed was a bit too much. My next iteration will have two main design changes. First, the battery holder sleeve will need to be on both sides of the box. This will help to keep it together. Second, the 5mm overlap will be changed to 1.5mm and 1mm to eliminate some of the slack where the box comes together.


Overall, I’d call my first 3D Design Experiment a success.  The design process doesn’t take that long, and printing it out gave me a huge amount of feedback very quickly.  Once I’ve had a chance to do these, I’ll share the designs.  As a side note, the adapter does raise the center of gravity for the truck, which means my already dangerous driving is now even more subject to flips, but that’s a subject for another post.


3D Printer Management Goes Mobile with Salesforce1


Full confession: when you look up “3D Printer Newbie” in the OED, you’ll see a picture of me.  I am early on this particular learning curve but as enamored of it as most people who start down this path. This of course means I must somehow connect it to my primary area of interest, Salesforce. That is what I’m going to talk about today.

This post has six parts. 3D Printer Fundamentals, Introducing OctoPrint, The Salesforce Side of the House, Code Review, Practical Applications and Things That Went Wrong Along the Way.  But let’s start with a demo!

(Yes, that bonus soundtrack you hear in the far background is in fact my child.)

3D Printer Fundamentals

My work here was done with a couple of PrintrBot Simple Metal printers I picked up online. They’re not the most advanced printer on the market — if anything, they’re a minimalist interpretation of the form — but they are pretty sweet and at $599 the price is certainly right.

PrintrBot-Simple-Metal-Anatomy-453D printers are what’s referred to as “additive manufacturing.”  This means they start with nothing and add something to create their output. Most 3D printers on the market extrude thin layers of plastic over and over again, and these devices share a few common attributes.  First, since they work in three dimensions, they must be able to move a printhead in three dimensions.  I’ve labeled these as the X, Y and Z axises above so you can see which parts of the PrintrBot move. Second, they have a micro-controller that moves the printhead and regulates temperature and a bed that holds the results.  Finally, they all have a feed that moves plastic filament into a hot end where it melts and is extruded on to the bed.  For filament, I used 1.75mm wide PLA (plant based and compostable).  Layers are about 0.3mm thick, and come out of a 0.4mm hot end nozzle at 190° C.

Controlling a 3D printer is a cooperative effort between the onboard micro-controller and host software. The host software feeds printing instructions to the micro-controller which in turn provides operating details back to the host software.  The most important of these operating details is the temperature of the hot-end.  Probably the most common host software you will hear about is Repetier, and it’s definitely a great way to go. However, it’s not the only way to go and I ended up using another one for this project, which I’ll get to in a second.

Now, this is most of the picture, but you still need to tell the host software what you want to print. A 3D print generally starts off as a 3D design in some kind of CAD program.  There are a bunch of these you can choose from.  SketchUp is popular and free for non-commercial use, TinkerCAD is an online web-app that does it, and there are a bunch of others.  Once you have a 3D design, you need to convert it to something your 3D printer can understand.  Slic3r is the tool of choice for that. It converts 3D designs into a “gcode” file that contains actual instructions your printer can use.  If you want to use someone else’s design to start, checkout the good people at Thingiverse.  They have a lot of designs you can download and use for free.


Introducing OctoPrint

Probably the best part of my job is poking my head into a new-to-me corner of the technology world and discovering an unexpected gem. OctoPrint is that gem. OctoPrint is 3D printer host software delivered as a web-app. It’s open source, written in Python, optionally runs on a Raspberry Pi and the devel branch has a pretty sweet API.

If you’ve read any of my earlier posts about controlling quadcopters, Philips Hues or DIY wireless sensor networks, you probably know what happens next.

If you guessed:

3D-Printer-OctoPrint-Salesforce1-NodeJS-Raspberry-Pi_2You are correct.  The basic setup is pretty simple.  I install the OctoPrint friendly Rasbian distro OctoPi (yes, it’s as easy as they make it look — completely awesome, too) on a Raspberry Pi I have sitting around.  I then added Node JS to it and created some familiar looking JS to talk to Salesforce via the Streaming API. OctoPrint talks to the PrintrBot Simple by way of a USB cable, so nothing special there. Also, in case you’re curious, I opted to have a single Pi control a single PrintrBot, so the setup in the video requires two units.

(Incidentally, I wanted to mix this architecture up this time, but was stymied.  See “Things That Went Wrong Along the Way” below for details on that.)3D-Printer-Salesforce

The Salesforce Side of the House

Let’s start with the data model.  It’s pretty easy, but a little different than the ones I’ve used before.

Historically, I’ve used a single message object.  The OctoPrint API is pretty rich, though, and has a variety of requirements (some commands are GETS and others are POSTS with bodies requiring a JSON object, for example), so I added an additional object to store API Command Templates.  The UI simply lists the available commands, and then creates a printer message based on the template.


I really like this approach because it let’s me add new API commands as data, not metadata, so it’s super easy to add functionality and update the system as OctoPrint changes without having to deploy code.  (I can’t remember who, but I think I’m stealing this idea from someone.  Sam maybe?  I hate it when I can’t remember, so ping me if it’s you.)

Notice I don’t have a Printer object here. I do have one in the code, but it only holds names. It should be a relationship on the Printer Message object, but I didn’t get around to it.

The rest of the app is plain old Visualforce and Apex.  I’m not using any of the modern JS frameworks (Angular JS, etc), and I haven’t gone out of my way to optimize queries etc.  As you can see in the YouTube above, it performs pretty well.  The longest delay is doing the asynchronous round trip all the way back from the PrintrBot.

(Full confession: Christophe talked me into adding a little padding around the page so the Bootstrap based CSS didn’t extend completely end to end.  He was right.)

Code Review

As I said, the code on the Salesforce side of the house is pretty basic.  You can see it on the Github repo and yes there’s a link to an unmanaged package there too.  Literally all I’m doing is inserting an object based on a template contained in another object. The code that’s doing the interface is pretty similar the the quadcopter code, but it has a couple of twists.  The full gist is here.

In the likely event you don’t want to parse through the code pasted below, the simple flow is:

  1. On Salesforce1, create a Printer Message using a little step-by-step process governed by a controller in Apex (here).
  2. Wait for messages on the Streaming API, send them to handleOctoPrintCall and store the message’s original SFDC ID (below).
  3. Determine if we need a GET or a POST, create the outbound request and send it to OctoPrint. OctoPrint then sends it to the printer.  Note that OctoPrint and this script are running on the same Raspberry Pi.
  4. When the results come back, get the original message ID, and update the original request using a custom Apex REST service (here).

That’s is.

function handleOctoPrintCall(command, body) {
	var options;
  if (body == null) {
    console.log("body is null");
    options = {
	    url: OctoPrintURL + command,
	    headers: {
           	'X-Api-Key': OctoPrintApiKey
   } else {
      console.log("body isn't null");
     options = {
      url: OctoPrintURL + command,
      method: "POST",
      body: body,
      headers: {
            'X-Api-Key': OctoPrintApiKey,
            'Content-Type': 'application/json'
	request(options, callback);
function callback(error, response, body) {
  console.log("callback from printer");
  console.log("end callback from printer");
  if (!error && response.statusCode == 200) {
  } else if (!error && response.statusCode == 204) {
    console.log("Empty Body (204)");
    sendPrinterResponse( JSON.stringify({ "result" : "OK" }) );
function sendPrinterResponse(body) {
  var newBody = {
    originalId : lastMessageId,
    responseJson : body
  var options = {
      url: orgOauth.instance_url + '/services/apexrest/PrinterResponse',
      method: "POST",
      body: JSON.stringify(newBody),
      headers: {
            'Authorization': 'OAuth ' + orgOauth.access_token,
            "Content-Type": 'application/json'
  request(options, printerResponseCallback);  
function printerResponseCallback(error, response, body) {
  lastMessageId = '';
  if (!error) {
  } else { 

The other bits of code in the gist are relatively mundane — a heartbeat so I know the system is alive, OAuth magic with salesforce (thanks Kevin et al!)

Practical Applications

The most frequent question people ask me when I tie together a few interesting bits of technology is simple: why? That’s a great question, and sometimes I’m doing it just to demonstrate that it’s possible. 3D printing and Salesforce is different.

One practical (but abstract) application  of an integration like this is to check asset utilization.  The more expensive, specialized equipment you have, the more likely you are to care about it’s utilization.  In general, the more you utilize these assets, the better.  The classic example here is Southwest Airlines and their drive to turn their planes around very quickly. The more often their planes are flying, the more money they’re making.  All of these assets and this data should be surfaced through whatever interface your team is likely to use in service of this goal.

More concretely, let’s say you have a 3D printer farm at your company, and you use those printers to create parts.  Maybe these are R&D parts, maybe they’re spare parts, maybe they’re promotional chochkies.  Having something to spawn jobs and monitor progress is a good thing.  More than that, having a source of engineered, iterated on and blessed 3D designs means that users are more likely to get the results they want.  A central resource like the one I’ve shown here is a step in the right direction.

If you take this idea one level further, let’s saying you have a very interesting service scenario where a piece of equipment reports a system fault automatically.  That fault is then diagnosed as needing a unique spare part, which is 3D printed and then automatically delivered by, for example, a quadcopter.  That’s some next generation stuff right there.

There are more ideas, but you get my general train of thought here.


Things That Went Wrong Along the Way

Lots of things went wrong and didn’t work.

  1. Most irritatingly, I accidentally aborted printing this super-cool T-Rex skull.  Totally blaming Seligman but it’s my fault for wanting to show him another project.  ProTip: think before you unplug that USB. Hours of printing and meters of filament down the drain.
  2. I wanted to get out of the Streaming API pattern and connected OctoPrint directly to the Internet.  No reason that shouldn’t work, except my attempts at using VyperVPN and No-Ip to get that going failed, failed and failed again.  Killed a whole day.  Someone better at networking could do it. The Streaming API is dead easy because I don’t have to worry about open a port on my network, etc.
  3. Turns out 3D printers are relatively hard to get.  I somehow caught a window where I could buy these on Amazon.  The first two that arrived were all busted up like someone had dropped them off a pretty tall conveyor, but replacements were only a couple days away.  Lots of places advertise filament and printers and neglect to mention a 6 week lead time and even on Amazon these are now a 2-4 week delivery item.
  4. At one point, I jammed the feed on the printer so bad I had to call in backup.  Gory details over on their forum. Turned into a great excuse to take apart the printer though and I always like that.
  5. The PrintrBot Simple intro video made some mention of the various kinds of surface treatments you could use to enhance your printing.  The standard is blue painters tape–it works like a charm!  I also tried some beige masking tape I had lying around the house, since The blue stuff was a Home Depot away, and it was an unmitigated disaster.

Wrap Up

Over all, I end where I started: this stuff is super cool.  But it’s also still pretty new and not very polished yet.  If you jump in now, you’ll need to be patient and interested in tinkering.  And if you are those things — WOW.  You’re going to love it!

%d bloggers like this: