Fixing Makerbot Replicator 2 X-axis skipping

After about 500 hours of printing reliably, my Makerbot Replicator 2 finally barfed. I walked in to a 4 hour print completion that looked like this:

Woah. When you walk in on a print failure like this, it’s important to root-cause the problem, so that you can prevent it in future. Not only did I lose about 4 hours on this job, but also about $5 in PLA. I looked over the printer first to check for the usual problems – extruder head movement restricted, PLA feed issues. Nothing there, so I took a closer look at the piece. I noticed an interesting pattern:

Notice how the problem started at a certain layer – that is not really interesting; notice instead how the layers above the break point are basically intact, just shifted over to the left (along the X axis). A couple of possibilities:

1. A problem with the SD card or the X3G file on the SD.
2. Corrupted firmware (on how it controls the X axis)
3. Problems on the X axis travel (bad lubrication, loose drive belt)

First I took a look at 1 and 2 – the software problems. I looked at those first because those are the simplest to fix. I reformatted the SD card, re-built the X3G file and reset the printer to factory defaults. Then I kicked off the same print job and noticed the problem in action (thankfully it was very easy to reproduce). Here is a video of the issue:

Hear the THUNK THUNK? That is the head either stopping without deceleration, or step skipping. This is what happens on the print:

The squiggly line is where the steps are skipped. This means that you loose alignment between layers. You can see it more clearly in this larger photo:

So this makes the printer basically useless. Bummer. I started digging around and found a great YouTube video by forbinone that describes the same problem and gives a very simple fix. Basically, the problem is that the X-axis servo cable, from being too tightly crimped in the factory, and the thousands of forwards-backwards cycles, causes some of the cores inside the cable to break. That means skipped steps. The solution of course is to replace the cable.

Once you remove the right-side MDF from the Replicator 2, you can see the problem in the X-axis stepper cable (light grey ribbon cable) – it is crimped far too tightly.

Mark the point where the kink in the cable forms (in the diagram above, the problem space is at the blue mark on the cable near the top-right of the picture), and then remove the little bar holding the cable in place to free the grey cable. Ensure the black ribbon remains in place (it is for the homing switch and does not suffer this problem), and replace the little bar.

Now you just trim away the problem section of cable, and splice in some new ribbon cable. To ensure the splicing did not lead to any shorts across the four wires, I decided to use some 0.1″ headers.

Then add in the new section. Be sure to add enough that there is no tension in the wire – there should be enough play to allow the X-axis gantry it to move smoothly forwards and backwards without getting tangled anywhere. It is critical to ensure you keep the polarity correct – that is, don’t accidentally flip the splice so that the leftmost cable on one end of the original ribbon is now connected to the rightmost cable of the ribbon. That could badly damage the printer.

To ensure the new longer section did not get tangled into the rest of the machine, I cable tied it to the front-right vertical beam.

To finish up, I added some insulation to the joints, and bolted the MDF back to the machine.

It definitely looks a little war weary, but after the operation, it runs perfectly. I did the same 4 hour part again, and it came out without any issues:

Read Full Post »

Creating the Rabbit Engineering Model I1

This story begins with a simple email about rotary encoders, and ends with me shipping my first paid commission.

It’s a big personal milestone, but really not as a big a deal as you might think in terms of just getting it done. The device I designed and delivered was the Rabbit Engineering Model I1, an interface module that lets flight sim cockpit builders (like my customer), home arcade cabinet builders, and anyone who wants to build a custom controller to connect a variety of buttons, switches, potentiometers, and rotary encoders to their computer by USB. You can get an overview on the product page, and order one for yourself.

By the way, if you get the chance to make a project for someone who has a real problem that you can solve for them, I strongly recommend you do it – this has easily been the most satisfying spare-time project I have worked on.

In early August, I got an email from Mr. G (he has a real name, but let’s keep it anonymous) asking about the rotary switches I used in my custom SF2 controller. He asked simply if I knew of a place that sold them cheaply. After  a couple of mails, I suggested he use rotary encoders together with a microcontroller like the TeensyUSB. Alas, Mr. G did not have the skills to pull that off. So I thought, hey, why not help a fellow flight simmer out and build it for him? I offered to do it for the cost of parts plus a small markup. He accepted. We had a commissioned job!

I had already had experience on similar projects and experiments such as the FSX MCP panel, the iPac distribution box, the SF2 controller, the Arduino Leonardo keyboard experiments, and the Multijoy_retro; so I was confident I could pull it off in a month or so.

When doing any kind of engineering project it’s important to set a clear spec (specification) by working with the customer – so we had a long exchange about exactly what the machine would do, I offered some options (with the relative costs), and Mr G. settled on what solved his problem and fit his budget. A simple agreement email locked us both in (I would deliver by end of August, and he would pay the agreed amount), and the three week clock began to tick down.

 

Essentially, it would be an interface device that would have as many as 42 buttons, switches, rotary encoders or potentiometers connected and converted to key presses, joystick buttons and/or joystick axis events. It would connect to the host by USB without drivers, and the configuration would be programmable by a config file on an SD card. Here is the final spec we agreed upon.

• 42 configurable inputs, all can be used as binary IO, each using one of two modes:
  Push-Hold – the event occurs as long as the button is held down (for push buttons).
  Push-Nohold – the event occurs only once, regardless of push duration (for single events coming out of toggle switches)
  
• All can be used to sense 21 rotary encoders (2 inputs needed per rotary). Clockwise rotation sends one event, Counterclockwise rotation sends a different event
• 6 can be configured as analog inputs, sensing a 10K potentiometer (linear or logarithmic).
• Inputs can generate any of the following events:
  Key press/release – single key, or with one modifier key (shift, ctrl, alt)
  Joystick button press (one of 32 buttons)
  Analog inputs can be mapped to one of 6 joystick axes
• Configuration of the inputs is done by modifying a text file in an SD card which is read when the device is plugged into the USB port.

I really tried to convince him on an option to have expansion cards that would add more inputs using shift registers, because it was a feature I wanted to work on; but it broke his budget. In the end, you build for the customer and not yourself, so his decision stood.

Now the design phase – I had already played around with rotary encoders and the TeensyUSB, but only using interrupts. To satisfy the spec I would need more than the handful of interrupts that the Teensy provides, so I began to experiment with polling modes. This was kind of a risky/dumb move on my part, because if I failed to figure it out I would have had to break the spec/cancel the project/upset the customer, but believe me, that fact was very motivating. After a couple of evenings slaving over a hot C++ compiler, I got that working; turn clockwise and you get one input set, turn counterclockwise and get another, with minimal side effects (turn the rotary too fast and you miss steps, which is a bug the Saitek Pro Flight Multi Panel also has!). The other interesting feature, PushNoHold (holding down a button triggers only one input event) was easily done using the standard Arduino Bounce library.

 

The next “interesting” part in terms of code was SD card reading, which really should not have been hard, but gave quite a few hassles. Ultimately it was all related to the type of SD card – I needed to use an SDHC type rather than the SD types I was assuming I could use. Remember kids, try different disk formats if you’re having disk reading issues.

The big technology choice for this project was the microprocessor to use. I am a big fan of the TeensyUSB line, and I already have experience with it, so I knew it would be the one. I chose the Teensy 2++ in the end because of its large number of input pins and RAM; To satisfy the configurability requirement in the spec, I would need storage per input and 2KB would not be enough.

 

One painful (hardware) bug I hit was around pin 6 on the Teensy 2++. This is connected to the LED, and so behaves differently from the other pins. In order to turn this into a normal input, I had to add a pull-down resistor, and have the input  connect to 5+ rather than to ground like the other pins. Rather than try to reconfigure a big part of the project, I decided to document the strange behavior in the manual (a trick I learned from Clive Sinclair and his scientific calculator).

Writing the code was fairly straightforward, but my days as a C# programmer have left me soft and flabby in terms of pointer handling, so I got slapped around a bit by C++. One fine evening, at about 5am, I finally got all the code running and tested. This project actually has the most code of any I have done (mostly around the config file parsing).

Time to move onto the physical design. There were two aspects to this: Provide an interface to the input pins, ground plane, and +5 supply (needed for potentiometers) in a way that would make for simple integration of the Model I1 into the electronics of the customer’s project; and then a protective shell and means to physically attach it into the customer’s project (by gluing, bolting, or whatever).

The interface was the most important part – I decided to simplify things by having three clusters of connectors: The input pins (two long headers), a ground plane (a pair of headers with way too many pins), and a power rail with +5 and ground right next to each other. This makes adding input devices simple – just add some male 0.1″ headers and away you go.

 

And here it is in the shell. The tolerances were tighter than in previous projects, because I wanted to be as compact as possible (the bigger this device, the bigger the customer’s enclosure would have to be). Why yes, that is our old friend hot glue there.

 

The manual (more on that below) explains how to wire and connect each type of input device (potentiometer, button, etc). I used color coding on the headers to ensure that connecting was as error-free as possible.

Here it is painted (the white numbers are not on the device – this is actually a screen grab from the manual):

Then came the testing. Testing is not my favorite part of any build, but on this project which would be going out into the wide world and would be hard to fix once deployed, I took some extra time and built a little test rig with the various types of input devices attached. Well, “test rig” is a kind term, it’s a chunk of MDF with some holes. Still, it did the job OK.

Then I tested every type of input on every pin. Good times. Grudgingly, I admit it was worth it because I found two software bugs and one short circuit.

The plastic shell was designed in OpenSCAD and 3D printed. As usual, it began with a sketch (which I made in Las Vegas while there for Black Hat 2014/Defcon 22 – always carry a sketch book with you!).

I wanted to give it a designed look, but at the same time this would live inside a beige box one day, so spending too much time was not necessary. It is essentially a flat box with mounting holes, but I used hex bolts instead of screws to give it a little interest.

Then the printing (I think total print time was around three hours):

And presto! We have a shell:

 

I embossed the Rabbit logo on the back, as there was a huge expanse of plastic.

I also printed a matching shell for the SD card disk drive.

For physically mounting the Model I1 to a project, there are two options – you can bolt it in using the bolt holes in the shell, or you can screw in the provided “gluing feet” – you then glue the feet to your project. The idea is that you don’t want to glue the device itself to your project, because if you need to move/remove, the force could damage it. So instead you can just unscrew the device from its feet, and then grunt and pull at the feet all you need without risking the delicate electronics (a trick I developed for the Multijoy_retro).

Then came the writing – this beast would need a detailed manual, because I had to document not only how to connect input devices, but also the file format for the configuration file (which is fairly complex due to all the options you can have). If you thought testing was bad, then writing is the worst, but a well documented product really makes a huge difference – not only does it give an impression of quality and thoroughness, but it saves you a lot of time and energy from all the customer questions/emails you have avoided.

Once all that was done, it was time for the finishing touch – update the Rabbit Engineering site with the product information, and then build a nice packaging experience. When you are building for a paying customer, their experience of their product starts from the very moment they open the box, so that deserves some design and attention also. Sadly, there is no cardboard 3D printer, so a lot of Xacto and sticky tape action followed.

The manual goes on top. This is essentially the first contact the customer has with the device they just bought, so you want to create a “Woah, cool!” reaction.

Then , when they remove the manual, they see all the parts neatly laid out in the box.

Pack all that into into a shipping box, and off it goes to its new home in the wilds of North Carolina. Apparently it’s wild there, I’ve never been, so I will take their word for it.

In the end I was able to get the project done just three days short of the promised date. From conception to shipping was just over 20 days – this was possible mostly because I had already solved all of the underlying problems before I began. If you need a Model I1 for your own project, you can order one up from our online store.

Read Full Post »

Building the Rabbit H1 controller

A larger project I want to complete as a RabbitEngineering.com milestone is a standalone computer, in 1980s style – complete with external storage, controller and screen. Top priority for this project is innovative and appealing design. I decided to begin with the controller (mouse replacement).

I decided to not use a mouse or trackball – those are not innovative enough; instead, I decided to model my controller on a well-established interface that is not used in computing, but popular in some areas of aviation – the HOTAS throttle. This is an example, from the McDonnell Douglas F-15 fighter:

The throttle is used to control the thrust of the engines by moving it forwards and backwards, but in the 1960s cockpit designers, realizing that a pilot’s hand needed to rest on the throttle for most of a flight, began to add controls for common functions – RADAR settings, the air brake, radio selectors, etc. This was done by adding first buttons to the throttle, and later 4 and even 5 way digital joysticks, in places where the fingers rested naturally.

I decided to use the throttle as the basis of my design. I wanted to keep the physical design minimalist and geometric, so I first settled on a simple cylinder with a flattened base. I 3D printed out test form in white PLA, and marked with sharpies where my fingers rested (this is a good technique for noting required adjustments to 3D printed parts).

Immediately a problem became apparent – the top part, where the fingers curl around the form, was too wide, leading the hand to be overextended and uncomfortable. Back to OpenSCAD. The tube was at least not wasted – I now use it as a pencil holder on my workbench.

For the next form, I narrowed the top, but kept the base wide for stability – in essence, the new form is a triangular prism with spheres for vertices. Again, I printed in white PLA and marked where the fingers naturally lay using sharpies.

Front view:

Left view (where the thumb rests, and the control for the mouse cursor will be):

Right view:

Once that was done, it was time to measure the locations of all the buttons and transfer them into OpenSCAD to begin modelling the complete shape. The final controller would have the following electronic components:

• A two-axis analog joystick to control the cursor (for compactness, I used the part used in the Nintendo PSP, which is available at Adafruit). Controlled by the thumb.
• A 5-way digital joystick for left click (depress the joystick), mouse wheel up and down, and scroll page left and right (also from Adafruit). Controlled by the index finger.
• 6mm tact switch for middle click. Controlled by the middle finger (from Adafruit)
• 6mm tact switch for right click. Controller by the ring finger (from Adafruit)
• A TeensyUSB 2.0 programmed as a USB keyboard and mouse as the HID interface. The teensy can be programmed with Arduino libraries, but is much more compact and has better USB device emulation (you can also get these from Adafruit).

A new technique I wanted to try on this project was to have plywood inlays in plastic parts. On the Nespoise I had mixed black PLA and plywood to a very nice effect, but I wanted to try and hide the edge of the plywood this time. Because OpenSCAD lets me export to STL which is consumed by both Makerware (for printing PLA) and CamBam (for CnC cutting), I thought it would be fairly straightforward to do. Here is the shell from the outside (minus buttons):

The shell consists of an upper and a lower half, joined by two #6 imperial screws. The top half is the complex part, with the buttons/joystick openings, screw posts, and hinges:

Internally it’s more compact that any other project I’ve worked on – to ensure all the parts deconflict correctly, I rendered a number of strange cross sections (OpenSCAD makes this very easy). Here are some of the more interesting ones:

I had never worked with hinges and only had limited experience with moving parts like d-pads, so I decided to make test prints of just these areas. Turned out this was a good idea, as the tight tolerances I originally put in caused annoying sticking of the parts.

   

 

 

 Once all the bugs in the top half were resolved, it was time to print the complete shell. This required the use of supports which I don’t often use, and I ended up with some untidy/incomplete areas in the print (for example, one screw post only printed halfway before breaking down). Given it was a 5 hour print, I decided I could live with the bugs, especially given they were all inside the body (the external surface was smooth). I then glued/screwed the switches and joysticks in, and got ready to wire them in place.

I then spent some time programming the firmware for the Teensy. It’s better to do the bulk of this before final assembly, because you might discover short circuits, bad switches, or other hardware related bugs during programming, and you want to avoid having to disassemble the project to resolve those.

Here are all the plastic parts (with most of the electronics) ready to test.

I then cut the plywood inlays and they snapped nicely into place, and I added a little superglue to ensure they stayed in place. Time to add the remaining electronics before further testing. Here are some views of the top half ready to close – it is a tight fit.

Here are all the parts labelled. For the power light, I used the “natural PLA lens with logo bezel” trick I invented for the NESPo and used in the NESPoise, this time with the Rabbit Engineering logo.

On the bottom half I added two 1 Oz fishing weights, to make the controller feel more solid on the table. I wanted to avoid users from mistakenly moving it around as they would a mouse. The extra weight plus rubber non-slip feet makes it adhere to the table surface nicely.

Time for final assembly – here it is next to the second form:

Now to test it for usability. I found the cursor speed needed some tweaking, so I made some changes to the firmware. Teensy makes this a simple and painless process.

Here are some views of the completed controller, showing the power light illuminated:

Here it is in use, to give an idea of how the hand fits:

You can grab all the files to make your own at Thingiverse.

 

 

 

Read Full Post »

Creating the Multijoy_Retro

UPDATE (9/1/2014): If you are looking to build a project like this, see my post on the Rabbit Engineering Model I1 device.

#1stworldproblems – I have a lot of very old joysticks. Too many? No, don’t be silly, no such thing. This hoarding habit is related to my collection of 80s and 90s flight sim paraphernalia in general.

It’s not too bad owning a lot of old flight sim software, because you can just crank up an emulator like DosBox or VICE and enjoy your clunky old untextured polygons. But using your retro flight sim hardware is not quite so easy. You can get an adaptor that allows you to use even the more complex joysticks such as the Thrustmaster FCS, but they have two problems: (1) They only convert PC 15 pin joysticks, and not the Atari/Commodore 9 pin digital sticks and (2) where’s the fun in that? Anyway, what I really wanted was a converter that:

1. Accepted 9 pin and 15 pin joysticks, including those using the CH Flightstick Pro and Thrustmaster FCS hat switch standards
2. Accepted two retro joystick simultaneously to allow for joystick/throttle/rudder combos
3. Converted an analog 15 pin joystick into digital output (for use with emulated 8 bit games)
4. Converted a digital 9 pin joystick into analog USB joystick (for using digital joysticks with PC sims)
5. Converted a digital 9 pin joystick into USB mouse input
6. Accepted arbitrary switches and converted them into joystick buttons for creating new custom input devices (like my previous Strike Fighters 2 radar/armament panel project)

That’s a tall order – this will need to be a microprocessor based project (my first). My first instinct was to use the Arduino Leonardo, which I really like and already have some experience with, but a couple of things put me off – it’s light on memory (2.5k), which limits growth potential for code; it has few digital inputs (20) and although it can be HID-configured as a joystick, it’s not trivial to make it be simultaneously a HID joystick, mouse and keyboard. Plus, it’s physically pretty big. Instead, I went with the Teensy++ 2.0, which uses the AT90USB1286, an 8 bit AVR running at 16MHz. It has 128k of flash, 8k of RAM, 40 digital inputs, 8 analog inputs, and more importantly, it can be easily configured as a Joystick (6 axis, 32 buttons), keyboard and mouse on the same HID device. It’s the size of two postage stamps, and costs $24. And it’s manufactured in the garage of an adorable Portland couple. Perfect.

First thing was to work out the electronics and firmware. For the two analog devices (15 pin joysticks), I would accept one as a full flight stick (i.e. 3 axis plus hat switch plus 4 buttons), and the other would be two axes and four buttons (I only have six output axes after all) – this one would be used as a throttle and/or rudder pedals. This step was fairly easy – get the pinout for a PC joystick, and then remember that PC joysticks use their potentiometers as voltage dividers – this means you need to add a 100kΩ resistor between the Teensy pin and ground:

This is required for each axis. The buttons are a simple case of connecting the Teensy’s digital pin to ground. The hat switches are a bit more complex, because CH Products and Thrustmaster came up with quite different ways of implementing those – more on that in this post. Now for the digital devices (9 pin joysticks), which are very simple – the joystick just connects the input to ground. I decided to expand slightly from the Atari standard by allowing two buttons (like the Commodore Amiga used). Here is the pinout. I also added a 37 pin input to expose all 32 buttons for a custom devices – it surfaces one pin per button, plus one for +5v and one for ground.

Those are the device inputs. In order to implement the various modes for the device, I also needed to add some support inputs:

1. For each digital device input, a ‘gain’ potentiometer to scale the amount of output on the mouse/joystick.
2. Because the digital and analog devices share joystick axis outputs, a switch to inhibit the digital devices (otherwise you get interference between them)
3. A switch to select joystick/keyboard mode output on digital device 1
4. A switch to select joystick/mouse mode output in digital device 2
5. A switch to select if analog device 1 uses Thrustmaster FCS or Flightstick Pro hat switch
6. A switch to select if analog device 2 outputs keyboard or joystick signals
7. A reset button (needed to reprogram the Teensy).

I also decided to add LEDs to indicate the whole box was live (plugged in), and another to show if the digital devices were inhibited. When you lay all that over the Teensy’s pins, this is what you get:

Note that not all the Teensy’s pins are surfaced on its two side edges – some are in the center of the board. Once all that was locked, I soldered 0.1″ pitch headers on some perf board, and plugged the Teensy in (like a shield). I then got to soldering headers for all the plugs and switches. At this point it is worth pointing out that this is project that used a lot of soldering – somewhere around 400 points. Here I was taking a hand-cramping break:

This took several evenings, because I decided to go slow and test each set of connections as I finished them. As there was a lot of cables in a  small space, I would not be able to reach every spot at the end to fix issues.

Notice how I added little labels to connections – this is because I wanted to easily be able to determine which switch connected to which part of the board. When the rat’s nest was all wired up, it would not be possible to visually trace the connections.

As I added physical connections to the board, I updated the firmware to expose the functionality. The code itself was fairly straight forward, and didn’t require a lot of bells and whistles (I did add some code to automatically detect when an analog device was unplugged which I am very chuffed with).

So much for the electronics – now on to the enclosure. I decided to keep the design simple; it would look avionics panel like and hardcore – I took inspiration from the great Cockpits of the Cold War. Last time I tried this, I used a large decal to add the captions to the panel; but after a couple of years, the decal corners have lost their glue, and are peeling slightly. I would avoid that this time by using a sheet of acrylic, with a printed overlay behind it. I also wanted the enclosure to have a clamp so that I could attach it to my desk, and flip switches without it sliding around. Here is the OpenSCAD render of the final design:

The clamp would be the difficult part, so I started on that. The original plan was to have one large, monolithic 3D printed PLA clamp piece (in yellow above), and then have another printed PLA part – essentially a threaded bolt – that would screw upwards to attach the clamp to the desk. Unfortunately that did not work, because the clamp and bolt had to be printed in different orientations which led to the threads sticking horribly. Because the clamp part took a little over 5 hours to print, I decided I wanted to keep that. So I switched to a #6 steel threaded rod and built an adapter for the clamp. This consisted of a tube that holds a steel nut in the hole of the clamp, sandwiched between two flat parts which are glued (using Super Glue/Cyanoacrylate) in place. Here is the tube with one half of the sandwich (the nut is already embedded in the tube):

And here it is sandwiched and glued into the clamp:

This wheel is what applies pressure to the bottom of the desk. It also has an embedded nut which accepts the threaded rod:

The enclosure body is just two simple flat U-shaped halves glued together with the help of some interior straps. Here is the whole thing (probably around 12 hours of printing in all these parts):

The back of the enclosure would be 1/8″ MDF (sprayed black), while the face plate would be 1/8″ acrylic. The faceplate really was the key to the whole thing. To ensure the profiles for the plugs, switches and buttons were the right size, I first did a trial run on MDF (which costs around 15% compared to acrylic) on the CnC router. Amazingly, I got the sizes right on the first try:

Then came the real cuts – I am not a fan of cutting acrylic on the CnC because the plastic melts and sticks to the router bit, slowly increasing it’s diameter, which leads to inaccurate cuts. Apparently you can get around this by increasing cutting speeds, but I have not yet gotten that to work for me. Another way to solve that would be to buy a laser engraver, but I don’t really want to drop $11k to improve my plastic parts by 10% or so (hardly seems worth it when you put it that way, Dave). Here is the acrylic, still with the blue adhesive protector in place. Actually turned out pretty well:

Once that was done, it was time to design the faceplate art (which labels all the switches, etc). I used OpenSCAD’s projection() function to export the outlines as DXF to Inkscape. Once there, I used the miso font to finish up the art:

I printed the art on my regular printer. Now onto the cutting. This had to be done carefully as the plugs have no bezel, so the edges of the cut would be visible. I used a plain old Exacto knife with a new blade and a lot of patience:

And then add in all the switches and plugs. This is actually the most fun part of the project, because you start to see the interface take shape. You need to be careful not to scratch the acrylic while you do this (which of course I did, but luckily it was a small one):

Instead of using regular screws, I decided to use some Hex-headed 3mm screws, which give a nicer aircraft panel-like look.

You’ll remember that part of the design was two LEDs – one to show if the device is live, and another to show if the digital devices have been inhibited. One of the pictures I saw in the Cockpits book showed indicator lights where the text itself lit up – this was very cool and I decided to replicate that. I 3D printed some housings for the LEDs in natural PLA (which is translucent). This is basically a square cone with the LED at the apex, and a transparency with the caption text at the base. I painted these (except for the base) using silver enamel paint to prevent the light from leaking out of the back of the housing. The entire thing is then attached to the face plate with two screws:

The effect is very cool – while the LED is off, the text is barely legible, and then really lights up in the color of the LED when it is turned on. I will be using this trick in future projects. Here is the entire enclosure coming together:

Next I hot-glued glued the perf to the back plate using some 3D printed standoffs (needed to provide space for the cables beneath). I also, as is my wont, signed the plate with my bunny sketch. You should be aware that when you make your own, this is an optional step:

I decided to done one last round of thorough testing before trying to stuff everything in the enclosure. There are many, many cables in this project:

Here you can see how the LED housing is bolted to the faceplate (top center of the plate):

It’s actually kind of hypnotic trying to see where all the cables connect. You can see why it was important to label everything before we got to this stage:

And here I am testing the mouse functionality – the Atari stick is actually moving the mouse cursor around. Very cool!

I also found a number of bugs around how the switches were labelled relative to what the code actually did (e.g. in the image above, the switches are set to use joystick mode, but the code was actually running in mouse mode). I also found one short circuit which nulled out one of the analog device axes. It always amazes how some bugs manage to hide till the bitter end.

Once everything was tested, it was time to compress it into the enclosure. I had to unplug everything, bolt the back plate (with electronics now attached) to the body, and then re-plug everything in (using tweezers) inside the enclosed space. In order to get everything to fit, I pre-folded some of the ribbon cables so that they collapsed in predictable ways as you squished them in. Then finally I grabbed an Allen key and bolted the faceplate in place:

Looks pretty good. Here it is with the desk clamp fitted, and running – notice how the light housings give you nice illuminated text captions (the red LED is brighter than the green):

I did some final testing by setting up Strike Fighters 2 to use the device, plugged in my Thrustmaster Top Gun Platinum stick, jumped in an Israeli Mirage IIIC, and started a huge furball with some Syrian MiG-21s. These two aircraft are very well matched, so there was a lot of stick pulling and grunting, but I got away with two kills before I ran out of ammo and had to run home with bingo fuel. Fantastic! My next round will be to set up Dos Box and use my CH Flightstick Pro to play through the US Navy Fighters Crimea campaign again.

This was a difficult project for sure – large 3D prints, lots of electronics/soldering and firmware coding on top of it all. But being able to use all my old controllers again makes it totally worth it. Total cost in parts was probably around $40 (the only “expensive” piece is the Teensy – the rest is plugs, switches and ribbon cable). If you’d like to make your own, you can get all the STL files as well as the source code for the firmware at Thingiverse.

Read Full Post »

Developing HIDBox

Lots going on at work, so little time for projects lately. I have been working on two large projects (one of which is in “secret” status), while the other is this: The working name is HIDBox. The goal is to create a box which will act as a USB HID device, and convert classic computer controllers (Atari/Commodore style 9 pin joysticks as well as PC 15 pin joysticks) for use with a modern PC.

The basis of this project is the TeensyUSB++ 2.0 microprocessor board, which can easily be programmed to become a USB joystick, mouse or keyboard (or all three at once if you prefer). Here I am testing an Atari CX-40 joystick on my PC (the switches were set up to have it become cursor keys plus the Z key, for using on VICE). I have also tested it using an old Thrustmaster FCS (playing US Navy Fighters in DOS Box – good times).

Lots of soldering and programming left, but so far all the concepts are proven, just need to get it finished.

Read Full Post »

Building the NESPo

This project goes back a ways. I first heard of the “portabilizing” thing (making a console into a handheld game system) around 2006 when I saw Ben Heckendorn’s VCSp. I thought it would be a fun project, but complex, so I put it aside. Last year, while working on the MULTICON_Retro, I decided I was ready to give it a try. When I got my Makerbot Replicator 2 all the pieces were in place – I decided I finally had the tools to allow me to make it, and make it look cool. It’s hardly an original project. There are many like it but this one is mine blah blah blah. Don’t care, I’m going to have fun doing it.

(BTW, all the pictures are clickable for more sizes, if you need to see details.)

The NES was the obvious choice to portabilize – it has the best selection of games among retro machines, and you can get a NOAC (NES on  chip) pretty cheap (I preferred not to chop up a real NES – call it honour among the elderly). The machine of choice was the Retro-BIT RES, which goes for about $15 (it’s a Yobo derivative). It’s a good thing I chose a cheap machine, because I fried one during early experiments (sorry, Steve). I ended up having to get a couple of replacements.

For the display, I used a 4.3″ TFT reverse camera screen, which goes for around $20. They run off around 7v, and have composite video in, meaning they can plug right into the RES. For the power source, I chose a 1500mAh NiMH rechargeable battery used in radio control cars. The trend in portables is to use lighter and smaller LiPo batteries, but these can be temperamental and require a special discharge circuit. Here are the main parts running together off the battery:

All the bits draw around 450mA, meaning you should easily get two and a half to three hours of game time between charges. Once the main components were locked in, it was time to start understanding how all the electronics fit together, and measure everything so we could design the case around them. The RES consists of three circuit boards:

• Board A contains the controller ports, power and reset switches, and the power LED. For this project I would only use controller port 1, so we can exclude this whole board from the final design.

• Board B holds the video and audio filters, and the power regulator (which is not very good; I replaced it with a 7805, which is less efficient but more robust).

• Board C is the big one – it contains the CPU, cartridge socket and other magic bits under a glop-top.

Time to grab the multimeter and start noting how all the pins fit together. Board A was cut from the project altogether; but B and C would need to find a home in the case. Here are my pinout notes:

The next step was the fun bit – measure all the components, then grab OpenSCAD and start designing the case. I decided that I wanted the cartridge to be enclosed by case to ensure that it would not wiggle while running (which would eventually ruin the contacts). This was the first iteration of the design:

I liked the general look, but it would be too fat to hold comfortably. I moved the battery to under the C board, and then made the top narrower. In the end, the case was made in a series of layers:

• Back of the case, which holds board C, the battery charging plug and the speaker. It is designed in two halves so that it fits in the Replicator 2 print volume.
• Separator tray, which holds most of the electronics, and provides a smooth surface facing the cartridge slot to ensure that the carts don’t snag on anything while being inserted.
• Support beams to allow better gluing of the case halves.
• Tac switch supports to hold the buttons in place.
• Front of the case, which holds the volume buttons, power and reset buttons, headphone jack and screen.
• The D-pad and buttons (more on those below).
• The power light/logo (more on that below).
  

Once all the parts were reviewed for printability, I got some nice bright white Zen Toolworks PLA (this is a really excellent filament), and started some test prints. I had a really tough time getting anything to print until I realized that although I was updating the Makerware client to create print files, but not the firmware on the Replicator 2. Oh. Once the firmware update was done, suddenly everything worked, like magic, dude. Here is a n early print to test relative size (this one has the wrong screen size, as marked by the red Sharpie notes):

Polylactic acid (PLA) is a great material for this kind of work where you match printed parts to pre-existing physical parts, because it shrinks very little – so you don’t really need to compensate by enlarging your parts. One word of warning – although PLA can be tapped, due to the rigidity of the plastic the threads can give if you are not careful with the screwdriver.

Once the test pieces were printed, there were quite a few bugs to iron out in OpenSCAD. Once I had those fixed, it was time to print the production parts. I used mostly medium resolution on the Replicator 2, and printed on blue painter’s tape with hair spray to ensure the parts grip the surface (plus I level the print surface after every part – it’s a pain, but it improves print quality). I have also upgraded the Replicator 2 with an anodized aluminium print surface, so I get good prints almost always (the Replicator 2 is a great machine, but the default print surface lets it down).

Printing all the parts, by the way, took fourteen and a quarter hours. 3D printing is very powerful, but it is slow as anything. What would Louis CK say? “Is your miracle machine that creates physical manifestations of figments of your imagination not fast enough for you? Six months ago you never even knew this was even possible but now it’s too slow for you?” Here is a breakdown of how those happy times were spent:

Due to the size of the project, I could not print the front and back halves in one shot – they were printed as halves with support beams between. These were all glued using cyanoacrylate (superglue), which on PLA gives a ridiculously strong bond in just a couple of hours curing time (and it’s $1 for a tube).

After all the printing was done, I did some testing of how the printed parts fit in with the other components. Once I started soldering and gluing electronics to the plastic, it would be too expensive to make design changes. Remember kids: Test early and test often!

Once that was done, it was time to sign the case, as is my wont.

Now to take care of the electronics. Board C was simply bolted into the back of the case, together with the power socket from the RES and an 8Ω speaker. The separator tray then gets the bulk of it – the PCB from one of the RES controllers, board B, the 7805 voltage regulator with a small heat sink (which hits 104°F/40ºC when the game is running!), and the audio components. For audio, I built my own LM386 based amplifier, which worked, but frankly sounded crap – I need to learn more about filters. So I replaced that with an off-the-shelf LM386 based amp module ($3, not too bad), and a DS1809-010 digital potentiometer to have push button volume control. And lots of solder and ribbon cable. A LOT of solder. And a fair bit of hot glue. Anyway, enough about my gels. Here is the layout of the back half (with separator tray screwed into place):

By comparison, the front half is pretty simple. It has only the screen, headphone jack (a model which disconnects the speaker), and 6mm tac switches for the buttons:

Once all this was done, it was time for the “squish test”, where you try to close the case to ensure all the cables and bits fit. During this test, I realized insulation is important because something shorted and I fried the screen. Ouch. Thanks to Amazon Prime, I was back in action two days later with a new screen. Then I cracked the glass on that, and I wondered if I was compus mentis enough to complete this project. Luckily marrying the driver board of the new screen with the glass of the old one left me with a working Frankenscreen (which I was then overly careful with):

That test also proved (1) that cable ties held the battery nicely to the case, (2) the whole machine it was a good size to hold and use (at least with hands my size) and (3) the taps and screws were strong enough to hold everything together. Big relief. The test also showed this was a hefty beast – you can play it during Crossfit and no-one will tell you you’re slacking off.

I decided to completely print the buttons rather than re-using the RES buttons – and designign them was quite a bit of fun. Each button consists of a bezel (which is inserted from the front of the machine), a retaining ring which, when glued to the bezel, grips the faceplate to keep the whole thing in place, and the button itself, which has a ridge at the bottom to prevent it from falling out of the machine if it is turned upside down. At the bottom is a 6mm tactile switch, which captures the clickies:

To get better curves on the rounded tops of the buttons, I used a hi-res print (0.10mm layers). It worked quite well, but I had to shrink the buttons slightly in relation to the bezels because the grooved edges of the bezels (a side effect of 3D printing) would grip the grooved edges of the buttons causing them to stick.

The D-Pad works on the same basic principle. Instead of being a single button though, there is a disc which rests on a sphere (so it can tilt in any direction), and four tac switches:

The final step was now to take care of the front and back faceplates. Rather than printing those, I decided to cut clear acrylic sheet (with the CNC router). There are a number of advantages to using acrylic sheet rather than printed pieces in this case:

1. The plates would give the case a lot of its torsional strength. A printed piece might delaminate and split, so continuous material is a better choice.
2. Acrylic sheet is completely smooth, giving a nice, professional look.
3. Being completely clear (a printed piece can never be clear, it is translucent at best) you can insert art under it. I put art in the front and left the back clear so you can see some of the guts as well as which cart you have inserted.
4. The entire face essentially becomes the safety glass over the delicate screen (I wasn’t going to lose another screen on this project).
5. Hey, I have a fearsome routing robot in the garage, might as well bend it to my will! Look how fearsome it is:

The one downside about acrylic is that it is a little pricey – I got my 12″x26″x0.125″ sheets at TAP plastics at about $11 a sheet. Because I had never married a CNC cut piece to a printed piece, I wanted to make sure it would work before I wasted $11 (this thing was already bleeding funds like a Pentagon project), so I cut test pieces out of 0.125″ MDF instead (that goes for about $1 a piece). Fortunately, everything measured up fine.

Once I had cut the acrylic places (so much faster than printing), I added the art (designed on Inkscape then printed on regular paper on my inkjet), and added the button bezels and retaining rings. Notice that they keep the artwork in place. Now to add the remaining electronics and close it up.

The pièce de résistance of this device was the light up logo. Using a nice retro font, I printed a black faceplate with the logo, and glued a transparent printed piece to the back of it which held two 5mm red LEDs, with some resistors to restrict current usage. This is then the new power light. I love this little thing.

Final assembly! Here is the beast, ready for play. The nice thing about it being so chunky is that it can stand by itself, which is nice for display.

I took a week off work to do this project, but even working pretty much full time, I did not finish (partly due to waiting for replacement parts, etc). In total – design and construction time – this took about two full working weeks. Excluding the parts I busted, it probably cost around $80. If you’d like to give this project a try, you can download the source files at Thingiverse.

Read Full Post »

Eight bits and Two Inches

My big project was stalled over the weekend, so I decided to go for another mini-machine from the 80s. This time it’s the venerable Nintendo Entertainment System. A little under two inches wide!

Once again, designed on OpenSCAD. This time the kit is a bit more complex – the NES has four parts, and the controller has five parts. It also features four colors. Oh my.

You can get it at Thingiverse to print your own.

Read Full Post »

Mini Arcade featuring slideshow

Steve and I had talked about making a tiny arcade machine for his little chibi Street Fighter guys (street fighter guys fighting each other but in their own game – very meta). It would be great a little project to make with the Replicator 2. So I got to thinking that it would be cool to make one, but a static piece of plastic would be too boring.

So while browsing Amazon one day, I noticed an odd little novelty item – keychains with a little 1.5″ screen to use as mini picture frames. Then it hit me – these would be a great bit to stick into my mini arcades – load ’em up with some screenshots, and presto, nice little desk toy…

On Amazon the screen ran for about $11, but on EBay you can get these ones from HK for about $6; much better. They have their own little 3.7v battery which you can charge via the built in USB plug. So I built a features list:

• Should be easy to reach the USB plug for charging/changing the pictures
• You should be able to change the side/marquee art easily to change the theme of the machine
• All the features of the picture frame (it has a clock, auto off settings etc) should be easily accessible
• It would have little red illuminated coin slots at the front.

The first step was to carefully measure all the non-printed parts (the picture frames, tac switches, magnets  and LED). Here are some keychain screens without their casings. Everything is square and therefore easy to print frames and attachments for:

Mostly the breakdown of the parts was based on printability (to avoid overhangs, etc). The sides I would attach with magnets – that would let you have easy access to the USB plug, as well as swap out the cabinet art. To avoid the problem of swapping out marquee art, I designed the machine to have no marquee (although an illuminated marquee would have been awesome too – maybe for V2).

So now off to design. I used OpenSCAD and InkScape again, and this gave me a good chance to learn some more features. They are a very good set of tools. Spending time designing in OpenSCAD pays off big time. Every hour you spend in design saves you two hours of aggravation after printing, kids. Here is the final design:

The cabinet consists of these printed parts:

• LED holder/coin slots (printed with natural PLA which is translucent clear, and works nicely as a light guide)
• shelf for tac switches (with indentations for each tac switch to ensure they are spaced correctly)
• cover/faceplate for the tac switches
• body
• sides with theme art

Once I felt I had the design nailed down, did some test prints to make sure the enclosure would fit together, and find bugs (I write comments directly on the piece when doing this, as it’s easier than describing where the issue is).

There were a good number of issues I didn’t spot in CAD, so back to the design board to get those ironed out. Once they were sorted, I printed another prototype shell (which turned out to have only one bug in it, which I fixed in the production shape). I find natural PLA to be a good material to do prototype prints in, because it is translucent, and so you can see a little of how things interact internally.

But before I this prototype lit up, I had to take care of the electronics. On taking apart the picture frame, everything was fairly simple – there were four buttons to be surfaced on the arcade machine, and you could tap those directly on the PCB (even though they use surface mount – you just need to be a little careful with your soldering iron). I surfaced those conenctions to a little .1″ header, to allow me easier assembly. Here is where to tap the PBCs:

The one cool feature I wanted was a little light illuminating the coin slots. For that I needed to find a 5v source on the PCB. I ended up tapping that from the screen’s back light (which is on the other side of the PCB):

Add a resistor and LED, and you’re good to go. Here is the “electronics package” ready to be inserted into the cabinet. Notice it is running (to test I didn’t fry it during soldering), and also note one end of the header is painted red – that’s to allow me to connect it the right way round to the buttons later (flip it around and you could fry some stuff, so pays to put a little indication of handedness in there):

The next step was to put the switches into the cabinet. I super glued the button spacer piece to the cabinet body, and then hot glued the switches to the spacer (maintaining the correct spacing is important, because there is a little cover piece with holes that goes over the switches, and if the spacing is wrong the buttons will be obscured). I cut the legs of the switches in the following way to allow for better soldering.

All the bottom legs are wired together and then to ground (i.e switch 1 to switch 2 to switch 3 to switch 4 to ground), and then the top connection goes to one of each of the buttons we surfaced to the header in the step above. This part was a bit annoying, because the heat form the soldering iron would cause the hot glue to let go sometimes, resulting in a messy re-glue. I will have to try harder with superglue if I do this again.

The final electronics related step is to insert the LED into the LED ‘lens” which pops out through the coin slots. This is printed in natural PLA so that they light can shine through. I added some black electrical tape around the edges to ensure the light escapes only out of the front of the lens – it ensures a brighter light, and also prevents a weird red glow from seeping from the edges of the cabinet (unless you’re into that sort of thing).

Now the only thing left to do is hot gluing:

1. Glue the coin lights to the main body
2. Glue the screen to the screen frame
3. Glue the screen frame (with electronics now attached) to the main body
4. Glue the magnets into the main body receptacles
5. Glue the button cover (over the switches) to the main body
6. Glue magnets to the cabinet sides
7. Glue the artwork to the sides

Here is all the bits glued in place (without the sides for clarity):

The idea of having the  ‘quick detach’ sides is to easily change the artwork of your machine, as well as being easy to open for charging. Note that when you do steps 4 and 5 above, you need to be sure the polarity of the magnets is correct, otherwise the main body will “reject” the sides. I thought this magnet based attachment system would be better than having a peg/hole system, because the pegs might snap off; but the truth is hot glue is not great at overcoming the magnetic force, so the magnets will sometimes come off the PLA. If I were to do this again I would either redesign with a peg/hole system, or use one magnet plus metallic surface rather than two magnets (it would be half the force, and presumably the hot glue could hold that).

I had a lot of fun making this thing, so I decided to make a couple (I ended doing six, including the prototype), and give them away as gifts. One of the great things about 3D printing is that you can make multiple copies of anything (provided you have PLA and patience –  printing the pieces for a single machine takes more than an hour). It is pretty satisfying, once you’ve figured out how they fit together, to knock out four or five cabinets in a single Saturday.

By loading different screenshots and customizing the side art, I came up with “themes” that the recipients would enjoy. I made a Street Fighter II theme, Classic Arcade theme, The Oregon Trail theme, Duke Nukem 3D theme, and a Classic PC Flight Sims theme. I printed out some instructions for each, added a little USB charging cable and put them in a nice gift bag for delivery. Here is my mini arcade, shortly before they all went off to their respective homes (click each for more sizes).

Here is a list of all the parts used:

• The STL files are available at Thingiverse
• 4x 4.5mm tac switch
• 1x 1.5″ keyring picture frame
• 1x 5mm red LED
• 12x 3mm x 1.5mm round magnet
• 200 Ohm resistor
• Card stock for cabinet art (template for the art is included in the Thingiverse project)
• Natural (transparent PLA) for the coin door light
• Whatever colour PLA you want for the body
• Hot glue
• Superglue (cyanoacrylate) – nothing glues PLA to PLA better.

Read Full Post »

Loading drivers from an SD card

Drivers (defining which keypress corresponds to which switch) are now loading from SD. The device bus is scanned on startup, and because each device emits its internal ID, the corresponding driver is located in the SD card and loaded.

Getting SD to work on a Leonardo was a pain – don’t use pins 11, 12 and 13 for SPI as 99% of tutorials tell you – use the pins on the ICSP header, which is on the back edge of the Leonardo, next to the “Made in Italy” caption. The SD library in version 1.0.3 of the SDK works fine without any modifications if you use these pins. More details in this instructibles page.

Read Full Post »

Full matrix keyboard on Leonardo

So now I have a matrix keyboard (just 2 rows x 2 columns for testing), with full masking and ghosting protection. There is still a little noise I need to filter out. Here it is being tested with Strike Fighters 2.

This is the prototype. The bottom board holds the CD4021BE (rows) and 74HC595 (columns). The top board has the four switches plus diodes that make up the ‘keys’. The third chip you see is another CD4021BE, which is used to store the device ID.

Read Full Post »