Every undergraduate in the School of ECE at Georgia tech is required to take a two-semester senior design course. The first semester is mainly spent learning about topics in ethics, business, statistics and probability that are of use to those practicing engineering. Additionally, students select or create a project to complete during the second semester of the course. While there were some very interesting projects proposed by various professors and members of industry, I really wanted to work on my own project, not somebody else's. Me and a couple classmates met and I proposed working on a fuel economy estimator for vintage cars (that I could use on my vintage VW beetle). We proposed the project, found a professor that agreed to advise us, and submitted it for approval by the professors who run the ECE senior design course.

The idea went through a major change sometime near the end of the second semester which made it much more generic of a solution. We decided that we would make a generic sensor interface which wirelessly transmits car sensor data to a central "ECU" of sorts that would expose the data an OBD-II interface. This would mean that the sensors that were added to the car could be used with any off the shelf OBD-II peripheral, from insurance monitoring systems, to wireless Bluetooth gauge clusters and dataloggers. However, this meant that our solution would need to be able to interface with a multitude of sensors.

What resulted was the most complicated piece of electronics I've ever designed or built, and an extremely challenging (yet engaging) four months for me and my team. -- This entry is split into two parts. This covers the problem and the circuits I designed. The next part covers the board layout, construction of the boards, programing, and the end results. If you'd like to jump to that part, click here.

the problem(s)

While aftermarket gauges are very common addition to a large number of project cars, the data is "locked" into the gauge itself. This means that the only thing I can do with the data is read it with my eyeballs. Oftentimes the data collected from one sensor is not enough to tell a complete story. For example, low oil pressure can be an indicator of excessive main bearing wear, but the single datapoint of oil pressure = 20 psi reveals very little information as oil pressure can be highly dependent on oil pressure: as the engine turns faster, so does the oil pump, which increases oil pressure. For my VW, oil pressure should be roughly 10 psi per 1000 RPM. I have no way with my current gauge cluster to see this on a gauge or record the information, other than looking at the two gauges and doing the math in my head. Essentially, the main problem is there is no way to expose this data to any other interface to which it might be useful to record or use in different ways.

Another problem we wanted identified was the pain of wiring new sensors into a vehicle. While not a huge amount of effort, the routing of wires and installation of gauges may require permanent modification to the vehicle (drilling holes in the body or the dashboard) which may make some car owners (especially classic car owners) nervous to add sensors to their vehicle. We wanted to see if we could remove this necessary step in sensor installation.

the solution

We eventually settled on creating a wireless sensor interface that exposes the data over the automotive industry standard debug interface; the OBD-II port. Sensors would connect to modules that would be responsible for reading the sensor data. These would be easy to wire as twelve-volt power should be readily available almost everywhere in the vehicle that sensors need to be placed (mainly inside engine compartment), and would be located close to the sensor for minimal visible wiring. The sensors would then relay their information periodically to a central board which then communicates with any OBD-II peripheral that may be connected. To simplify the project and preserve its genericness, the "central control unit" would have no displays, gauges, or outputs, other than the OBD-II port. If the user wanted to see their oil pressure, then some OBD-II monitoring solution would need to be used with our board.

What's interesting, is that with our idea/solution, even though we had pivoted from the MPG estimation project, we could still estimate MPG by combining fuel consumption (using a flow sensor) and speed (using a rotary encoder on the speedometer cable, or a GPS module).

sensor interfacing

A difficult problem was identifying the common modes that automotive sensors communicate over. After extensive research, we settled on supporting voltage, resistive and digital (PWM and PFM) sensors. There are plenty more interfaces that were a bit more esoteric (bi-state current?), but we figured the three we chose were enough to cover a wide variety of sensors. We identified early on that we wanted to interface with my existing Speedhut oil pressure and oil temperature sensors (one outputs a voltage and one outputs a resistance), as well as a digital flow sensor we found.

Another problem was powering the sensors. While the resistive sensors wouldn't need to be "powered," the the voltage and digital output sensors would likely need to be. While I wish I had had enough time to prototype and build a continuously variable linear supply, I instead opted to just support four different common voltages, 1.8V, 3.3V, 5V and 12V.

design :: ccu

Though some particular elements of the design evolved during the circuit design process, I had the basic idea sometime in late January or early February. With that, I went into a frenzy with my group-mate Evan, I taught him the basics of Eagle so we could build the library together for the project, and we were off.

overview

The CCU is the simplest of the two boards I designed. There is some power supply protection circuity, and a pretty simple regulator setup. For this board we went with the mbed microcontroller board, since the majority of the software could be written before the boards were done by another member of my team. Connected to the mbed are two wireless transceivers, one for the 433MHz band and one for the 915MHz band, a CAN bus transceiver with some protection circuitry, and an SD card. There's also an RGB led (because why not), and two seven segment displays for a basic user interface to do board setup.

power supply input protection

A vehicle is a pretty nasty environment for electronics. Newer cars have relatively complex power conditioning circuitry, but in older cars there's likely nothing more than an alternator, a rectifier and the battery. I read a few papers which suggested load-dump conditions (lights turning on and off, etc) causing voltage spikes up to a hundred volts. Additionally, we wanted our boards to not fry when potentially plugged in backwards. I used this circuit I found in an app note from Texas Instruments entitled Step-Down Converter with Input Overvoltage Protection, and added an extra MOSFET (Q1A) at the input to protect against reverse power input polarity.

When the power is connected with the correct polarity, the body diode forward biases and the gate becomes biased below the source, which reinforces the FET on. When the supply is connected with reverse polarity, the body diode does not conduct, and the reverse polarity actually biases the FET further into a nonconducting mode. Zener Z1 (as well as Z3) protect the gate-source junction of the FET.

Q1B in conjunction with the two BJTs disconnect the entire board from th input when Z2 reverse biases. When Z2 goes into reverse breakdown and Q3 and Q2 conduct, connecting the gate of Q1B to its source, which turns Q1B off. If I had to do this again, I would instead build a input clamping circuit instead of an input "cutoff" circuit. To prevent the entire board going to sleep in an overvoltage condition, I slapped a big bulk capacitance after the cutoff circuit to hopefully keep the board alive during any transients.

The overvoltage condition output allows the microcontroller to sense when there has been an overvoltage condition so that it can potentially sleep any high-power devices to extend the time that the bulk capacitance can sustain the board. The jumper was there in case the protection circuitry didn't work at all (I hadn't worked out the bias resistor values before I sent the boards out), so I wanted an easy way to bypass the circuit entirely.

regulation

I used an LT3493 buck regulator from Linear followed by a linear regulator to provide lower power supply ripple. Most likely unnecessary, but it couldn't hurt. The buck regulator regulates the 12V input to 4.5V, which is then input to the linear regulator (an LD291 from STMicro). This keeps the power loss in the linear regulator to a minimum (as opposed to linear regulating the 12V input).

The only interesting thing about the use of the buck regulator is the diode-or gate which drives the shutdown pin of the buck regulator. The mbed drives the BUCK_ENABLE signal, while the keyed 12V line in the car (only present when the key is in the ignition/on position) drives the SWITCHED_SUPPLY_IN signal. The only way the board can be woken from sleep is when the driver turns the key on in the car. The first thing the mbed does on power-up is assert its buck enable line. The mbed monitors the switched supply line to determine when the key has been turned off, finishes any writes to the SD card, communicates to the sensor boards that the car is turned off, and then goes to sleep by de-asserting its buck enable signal.

Everything else is out of the datasheet for the regulator. I did add a zero ohm jumper resistor to the shutdown line so I could permanently enable the regulator in case the sleep feature didn't work. Actually, there's a lot of zero ohm resistors throughout the schematic. I used them whenever I was unsure at all if a feature was going to work. This let me be more sure that this first revision of the boards would be somewhat workable before the semester was over. There wasn't enough time in the semester to design, build, program, and test the boards, and then do a second revision. They had to work the first time.

CAN bus termination

At a minimum, the CAN bus must be 120 ohm terminated.

I did a little more than necessary, since the only other device on the bus will be the OBD-II peripheral, over a few milimeters of wire (as opposed to 50 devices over an entire car). The CAN transceiver I used (the SN65HVD23x from TI) has a VREF output, which is regulated to half the power supply voltage. This can be used to stabilize the common-mode voltage on the CAN bus. To do this, the termination is split and the reference voltage is connected in the middle. I also used a transient voltage suppression diode package that was intended for use in CAN bus transient suppression. Lastly, there are two capacitors which form an optional filter network in case the slew rates were to high on the bus lines.

There's also an empty symbol which holds the mounting holes that need to be cut out to mount the male OBD-II connector. I didn't want to solder wires directly into the board from the male connector (like is done here), so I added an additional connector to place behind the OBD-II connector (connector-ception), so that the OBD-II connector can be readily mounted and unmounted from the board.

wireless transceivers

There are two transceivers that we placed on the board. One operates in the 433Mhz band, and was really only put there as a "stretch" goal to get our board communicating with off the shelf tire pressure monitoring systems. The 915Mhz transceiver we used for communication between the boards. We used the MRF89XAM9A from Microchip. There's a myriad of these things available, and they all probably would have worked for what we needed them for, but I really like thorough documentation, and this module from Microchip had some of the best.

full ccu schematic

That's about all of the most interesting parts of the CCU board. The rest is pretty basic microcontroller interfacing stuff. I had to use an I/O expander to interface the seven segment displays and RGB LED. I actually found one that had PWM outputs so I could control the color of the LED. If you're interested in the whole thing, there's a PDF you can view here.

design :: wsb

The more complicated and interesting design was the board that interfaces to the sensors. There were some additional constraints here that made it much more interesting to figure out. As stated before the board needed to interface with voltage output, digital output and resistive output sensors, so a fairly complex analog front-end was needed to ensure accurate readings. I also didn't want to rely on the keyed ignition line being available throughout the car, so the power supply needed to have a very low-current sleep mode as well that could be enabled by the microcontroller.

power supplies

The same protection, buck and linear regulator are present from the CCU, but I placed down an additional low-current linear regulator (10mA maximum) which linear regulates from 12V down to 3V. To get the board to consume very little power during sleep, I used an auto-switching power multiplexer from TI. This muxes two power supplies, always switching in the one that is at a higher voltage. Every IC on the board other than the microcontroller is powered from the main 3.3V linear regulator, so when the microcontroller puts the buck to sleep, the 3.3V supply falls to 0V, the and mux switches in the 3V supply to keep the microcontroller alive when as it goes into a sleep state.

Every so often the microcontroller wakes up, listens for incoming packets from the CCU board, and if nothing is heard within a few milliseconds the board goes back to sleep for a few seconds. This reduces the average sleep current to microamps, instead of 50+ milliamps. This took a bit of work to get functioning, but I'll cover that later.

I didn't have enough time to design and build an adjustable power supply to power the sensors, so instead I took the brute-force approach and placed four linear regulators on the board, each at different output voltages: 12V, 5V, 3.3V and 1.8V. As the battery voltage in the car may at times be below 12V, to be able to rely on the 12V source, I needed to boost a bit above the input voltage to ensure there was always enough headroom to linear regulate to 12V. I placed a boost converter from Micrel (MIC2288) on the board to boost to 14V, which powers the 12V and 5V linear regulators. I used the common LM217 for the linear regulators.

sensor supply mux

We wanted to allow the microcontroller to pick which supply it powers the sensor with, so that the user can setup the board via software or DIP switches for different sensors that may require different supply voltages. I found this part from Vishay, the Si3865DDV, which is essentially a p-channel MOSFET switch with a n-channel MOSFET to drive its gate. This allows for a low-voltage control of a higher voltage. Since the output of each switch is chained together and connected to the sensor, two of these parts need to be used back to back to switch each supply. This prevents the body diode of the high-side p-channel MOSFET from reverse biasing, and shorting the regulators together. I added a final "gate" switch which can disconnect the sensor power supply with one signal.

There are some optional resistors which form a low-pass filter network with the 1000pF caps to control the slew rate on the output of the switch.

analog front-end

This is where I spent most of the time. I wanted to have a way to measure a large range of resistances and a large range of voltages, as well as support digital inputs. After stumbling upon a few vintage app-notes that covered building simple multimeters, I took what I could and cobbled something together that could be controlled from the microcontroller.

While I could have picked the highest input voltage that would be expected from a sensor (12V from a 12V sensor), and then used a fixed voltage division ratio to divide the voltage down within the range of the A/D converter, this would mean that 1.8V sensors would only be utilizing a very small portion of the A/D converter's conversion range, which felt like a sloppy solution. I created a variable division ratio voltage divider by using a hex-buffer (a 74xx series part) with open-drain outputs to ground the tails of the dividers. To enable a new division ratio, the driver pulls the tail of the specific resistor to ground. In theory, multiple resistors could be placed in the tail of the divider at once to enable higher granularity, but for the time being I decided to pick ratios that would stay enabled for the entirety of the range of the input.

I picked the MAX1117 A/D converter. It was minimalistic, and I liked that it had an internal reference and two channels. It seemed foolproof, until I later realized that it wasn't 12 bits, it was 8 bits. I picked it specifically because I wanted a 12 bit converter (the built in converter of the microcontroller was 10 bits, so I was purposfully going with an external A/D to gain the extra resolution). I didn't realize this until we were assembling the boards, a big mistake on my part, and made me a bit upset as I put so much effort into the design of the circuitry in front of the converter.

To measure resistance, I built a fairly simple current source. Opamp OP1A drives MOSFET Q4 in an attempt to hold the voltage after the resistors (R27 through R34) equal to the voltage at the noninverting input. This voltage is set by a 1.25V shunt reference (biased by R26). This means a 1.25V drop is held across the resistors on the high-side, which are all powers of 10 times 1.24. This means each magnitude increase in resistance decreases the current by an order of magnitude. The resistors are muxed on the high-side by a MAX4617 mux. There are some additional passives for optional low-pass filtering of the feedback path which might have been needed if there were parasitic oscillations in the current output.

To make a resistance measurement, the current source is enabled with the lowest output setting, this creates a voltage across the sensor. This voltage is measured, and the microcontroller determines if increasing the current further will create a voltage across the sensor that is out of the input range of the A/D. If not, the current is increased to create a larger voltage across the sensor to reduce the effect of noise on the measurement. During a current measurement, the voltage divider network is disabled such that all current is sunk through the sensor.

OP1B is a simple buffer which isolates the sensor from the input to the mux. Probably not necessary, but good practice. The opamp has much lower input current (in the femptoamp range) compared to the A/D converter. There's an optional lowpass filter network on the output of the buffer, which probably should be buffered as well, but I wasn't expecting to have to use it.

The relay was an idea I had that would allow for the current source to be calibrated by the voltage divider circuitry. One of the voltage dividers could be enabled, the sensor disconnected from the input (using the relay), and the current source enabled. Thus the voltage would be developed across the two series resistances in the voltage division circuit. There's a simple MOSFET to drive the primary side of the relay and a diode to suppress the inductive kickback of the coil as it discharges.

The LM7705 is a low-noise negative bias generator, which makes the buffer perform rail-to-rail. The buffer amp needed to be able to buffer voltages at the input up to around 2.048V (the reference voltage of the A/D converter). There was plenty of headroom as the opamp is powered from the 5V rail, but there would be problems buffering signals around 0V. This negative bias generator uses a charge pump to generate a very small negative voltage (around -0.23V) which extends the lower-end of the buffer's range past 0V, while not exceeding the maximum supply voltage of the opamp. In case this didn't work, there's a zero ohm jumper resistor that can connect the opamp to ground.

I'd never had to put a lot of effort into picking opamps before, so this taught me a lot. I ended up going with a rail-to-rail opamp from TI (the LMC6482). Selection was a little tricky as bandwidth wasn't super important. I was only planning on measuring the sensor data at about 10Hz or a little higher, and the only high frequency signals that would be buffered would be digital at fairly low frequencies (in the 10s of kHz range). Most important was the input current and input offset voltage. Input current needed to be low to avoid affecting the voltage division ratio as high input current would create measurement error by "sucking" current out of the middle node. Input offset voltage needed to be low as the opamp was not AC coupled (an AC coupled DC buffer stage would be quite useless).

There are diodes before and after the buffer stage for added protection of the opamp and the A/D converter. The second channel of the A/D converter is used to measure the battery voltage in the car, with a fixed divider followed by a clamp.

Lastly, I connected the internal adjustable voltage reference inside the microcontroller back into the comparator that's built into the microcontroller. By comparing this reference voltage with the output of the sensor, digital signals that are small in magnitude to be measured by adjusting the reference voltage. I also added some hysteresis to the comparator as well. This could clean up some noisy edges that may be present in PWM/PFM input signals.

I think that covers this whole schematic page.

extra I/O

Even though I picked a microcontroller with a large amount of I/O pins, I still ran out. I added three MCP23S08 I/O expanders from Microchip. One controls the four pairs of power supply output load switches and reads the state of a 4-position DIP switch. Another controls the open-drain output buffer and interfaces two pushbuttons. The third is a 2x6 LED matrix. One column of green and one column of red. What's interesting about these I/O expanders is that they share a chip select signal, and then have a 2 bit address which is used to discern between each device. So it's sort of like a weird SPI/I2C hybrid thing.

misc

The rest is boring microcontroller implementation and some other small parts, such a temperature sensor and some connectors. I used the same microcontroller as I did in my PCB business card, just in a larger package. I was already familiar with it and didn't want to risk trying something new on a project where I was already doing so many things I wasn't 100% sure would work.

The full schematic is available here.

I recently participated in 2017 Moog Hackathon with my great friend and synth/electronics genius Victor. Before I write anything here I'd like to make it clear that Victor really carried most of the weight for the team, and while I built some circuitry of my own that I was pretty proud of, Victor's ideas and performance chops are probably what won us the second place prize. He's been building synths and making crazy noises since high school, some of which are documented on his YouTube channel. He's also recently been doing some shows under his Root Locust moniker, there's a track you can listen to on Bandcamp.

hackathon objectives

Moog distributed to every team their semi-modular Werkstatt-01 synth to hack around. The semi-modular nature of the synth allowed for teams to interface with the synth using control voltages (CV) to control certain synthesis parameters. The judging was based on three criteria: conduciveness to musical expression, technical complexity, and artistic presentation. A lot of hacks focused on creating a completely new instrument in the classical sense, creating a new interface to "play" the Werkstatt. Victor and I were interested instead in enabling the Werkstatt to make completely new sounds through the use of analog circuits. So that's what we did.

what we built

The first two circuits I built were a peak and trough circuit, using Ken Stone's design. These were the first circuits I've ever built that were meant to modify audio, which made me regret not doing so earlier. I got pretty distracted making new sounds for about an hour or so after constructing them on my breadboard. After making sure they were in working order, I translated them onto a piece of perfboard that we were going to build all of our circuits on. I was pretty rusty at perfboarding, but I got better as the weekend went on.

These circuits are relatively simple but are really interesting to see work. Of N-inputs, the peak outputs the highest input voltage and the trough outputs the lowest input voltage. The circuits begin with either a diode-or or diode-and, and then are followed by a PNP or NPN emitter follower to reverse the diode drop or rise from the input. To reduce the emitter follower's beta-dependence a simple single-transistor current source is used to bias the emitter followers.

Victor built two designs based around Ken Stone's smooth and stepped generator and Grant Richter's analog tracking generator. What was most impressive is that while I was still trying to wrap my head around what each circuit did (let alone how they worked), Victor was busy modifying them to make them work with the components he had on hand. The sounds that Victor made blew mine completely out of the water, even when they weren't fully finished yet. Here's a video of one of the first things Victor got working, a random melody generator.

The last thing I built was a basic arpeggiator. I originally wanted to use a single 8-bit shift register, but I had none. I did however have four dual d-flip-flops. I wired up a classic 555 timer in an astable configuration to act as a clock source, along with a potentiometer to adjust the clock frequency. Each flip-flop output was wired to the input of the next, forming a chain of flip-flops. The input to the first flip flop was exposed on a female header socket. I mounted a pushbutton to the board to act as a gate output, which was also exposed on a header socket. The button could be connected via the headers, or the input to the first flip flop could come from another source (such as the Werkstatt).

The outputs of all of the flip flops were connected in a passive voltage summing configuration (eg. all connected to one another through a large series resistor). I could have buffered the output, but as most synth inputs are designed to be high impedance inputs, buffering is less important than it seems. Each flip flop output also lit up an LED. This let you see the bits "flow."

Here's a demo of the circuit when it was working on a breadboard. The oscilloscope shows the summed voltage output, which you can see "stepping" up and down. The input to the first flip flop is a gate output from the Werkstatt. When a key is pressed "ones" are shifted in. The output of the circuit is input back to the Werkstatt where it is used to modify the oscillator frequency.

Here's a video I took after the hackathon of the board I assembled. It's quite dark, and there's no sound. I might upload some more photos of the board later. The LED in the top left is the oscillator output and the LEDs on the right show the state of each flip flop output.

other performances + recap

Overall, I really enjoyed participating, even just getting to spend the weekend hacking away with a soldering iron was an enjoyable experience. It also gave me an appreciation for analog synthesis and some of the really interesting/elegant circuitry that is used to achieve strange effects. I'm really excited to start to play around a bit more with the Werkstatt I got to take home from the event.

I was also just blown away by the other hacks that were put together within the weekend and the other performances. There was everything from spinning platters to accelerometer-driven microphones and electronic bagpipes. I strongly suggest checking out some of the other groups in this recap of the event.

I've decided to build an enclosure for my 3D printer, for three reasons: noise containment, temperature control, and vapor containment. Though the printer is quiet, it's not quiet enough to print overnight, which somewhat limits me to shorter and smaller prints. I also want to try printing ABS, which prints better when the enviromet temperature is stable and above room temperature. ABS also emits a strong odor when printed, so I'd like to try and contain that as well.

I've seen lots of enclosures built out of the these Ikea LACK side-tables due to their low price. There are some completed enclosures here, here and here, though a search for "ikea lack enclosure" brings up many more results. Though it seemed like a good design at first, if I were starting over I would build the enclosure from scratch using aluminum extrusions or wood.

The concept is similar in all of the designs. One side table is stacked on top of the other. The printer goes the tabletop of the bottom table, and some sort of spool holder mounts to the tabletop of the top table. Some siding is mounted from leg to leg of the top table on three sides, and an access door goes on one side. This forms a box. More features are sometimes added, which I may consider when the enclosure is finished. These include an auxillary exhaust fan to control the temperature inside the enclosure, interior lighting, a master power switch, and an externally mounted display for the printer.

I thought this would be a good time to get even more familiar with Fusion360 and more experienced with my printer, so I decided I'd try and 3D print as many of the parts and design them all inside Fusion360. Trying to print most of the parts was also probably a bad idea, and my inner woodworker died a bit inside during the process, but that's okay, he'll live.

making clearance for the printer

The first step in all of these enclosures is lenghtening the legs in some fashion. The legs on the Ikea tables are just a few inches too short to fit the Prusa i3 under comfortablly. I designed and printed these little "peg-legs" for each leg, which each has a cooresponding socket that mounts to the tabletop of the bottom table.

This was my first time printing with a layer height above 200 microns. These were printed at 350 microns, and it was amazing to watch the plastic fly through the extruder. I a group of four (sockets or pegs) printed in about three and a half hours. Pretty incredible.

spool holder design

Since the spool no longer will fit atop the printer, it needs to be mounted on top of the enclosure (or somewhere outside where the printer is). I wanted something that would accept different spool sizes (both inside and outside diameters) and would allow for some adjustment as the spool ran down. I found this table that listed dimensions of some popular filament suppliers. The table is a bit dated, but I figured not much could change in two or three years as far as spools go.

The outside diameter drives how high the spools need to be mounted off the tabletop, while the inside diameter drives the design of the piece that the spools mount onto. I had a piece of half inch steel rod that I decided to use to mount the spools on. I happened to have two bearings with an ID of nearly a half inch. A little Dremel work and they slid nicely onto the rod. I designed these little mounts to accept the flanged bearing as a press-fit. The tapered design allows it to fit a range of different spool sizes.

To suspend the rod in the air, I designed this bracket and corresponding slide rail mount. The concept I had here is that since I'll be making a slot in the top tabletop for the filament to go through, I want to be able to slide the filament spool forward or backwards for different spool sizes. If the spool holder was mounted in a permanant location, then small spools would have the filament traveling off the spool and then scraping the edge of the slot as they it goes through. Larger spools would have the filament curving underneath and bending sharply into the slot. The extruder motor shouldn't have to exert much force to pull more filment, so these would both be bad scenarios.

The guide rail has countersunk wood screws that screw it into the tabletop. There are locations on the bottom for nuts to press into. Bolts go through the slots at the bottom of the rod holder, through the slide rail, and then into the nuts.

Speaking of the opening, I knew I wasn't going to be able to cut a perfect slot in the tabletop with my Dremel. I designed up this little cosmetic flange that goes in the slot in the table top and hides any imperfections in the cut. I also designed a similar flange for the slot that would be in the bottom of the tabletop (the table is actually a hollow box with some cardboard hexagonal "infill" inside for extra support). The flange for the inside of the table was wider, as the filament will be traveling to the left and right of the center of the printer.

The last problem was securing the spool spindles onto the rod and keeping them from spreading apart. Since the rod wasn't threaded, I couldn't use nuts. Instead, I designed this little snap-on c-clip. I sized the middle hole just under a half inch and gave it a slightly decreasing radius as it approached the opening.

spool holder assembly

After cutting slots in the top and bottom of the tabletop the spool holder was ready to go together. Here's the holder ready to go together.

The most satisfying part of the assembly of this was the c-clips. Here's a video of them snapping on. I also test the stability of the assembly by scientifically shaking and tapping it. Seems sturdy enough.

side panel mounting design

I decided to make the side panels out of MDF instead of clear acrylic. MDF is significantly cheaper than 2x2 acrylic sheet (about 15-20 dollars a sheet). I figured I could do a small acrylic window on the front wood panel. For the side panels, I designed some mounts so that they could easily slide on and off when needed. I didn't want to secure them permanantly to the enclosure, in case I wanted or needed access or viewing of the sides of the printer.

Here's the first idea I designed. I think this is a good example of how 3D printing can make it difficult to remain constrained in design. Becuase there's very few limitiations, I went kind of wild with unneeded complications.

This design was unnecessarily large. It may have been secure, but most of the force that the mounts are going to have to exert is vertically on the edges of the MDF panels, not laterally (as if someone was pushing outwards on the panel). I needed to make 4 of these per side of the enclosure (two for the front and back of the bottom of the panel, and two for the front and back of the top of the panel), this meant I was going to be printing 12 of these. After trying to add supports to this model in Meshmixer and gauging the print times in Pronterface, I realized these would take much to long to print. Which is when I decided to rethink the design.

I reduced the mount down to the bare minimums. A flange to support the MDF panel, two screw holes, and a little support for the side of the panel. They were also designed to be printed without supports. I designed two variants, one with a "stop" and one without. The ones printed with stops would go in the "rear" of the panel, so that the panel can be slid in from one direction and doesn't slide in too far.

mounting the side panels

I used a jigsaw to cut some quarter inch MDF sheet to size. Since the Ikea tables aren't exactly precision manufactured, I eyeballed the position of the brackets, instead of drilling them in precise locations. To ensure a tight fit, I installed the bottom two mounts first, rested the panel on them, and then marked the location of the screw holes using the top brackets. If I were designing these again, I would use pan head screws instead of flat head screws. I added recesses in the mounts to countersink the flat head screws, but the screws actually ended up acting as a wedge as I tightened them. Since the holes were not perpendicular to the print layers, the wedge tries to drive apart the layers, which is a very weak dimension for 3D printed parts. I had some problems with cracking. I made sure not to over-tighten the screws.

a front window + 3d printing failure

The last piece the enclosure needed was a front panel. I again looked into acrylic for the front, but to get something that would be thick enough to act as a sturdy door (I didn't want the front panel to bend while it was being opened) was quite expensive. I instead wanted to put a smaller piece of acrylic in the middle of an MDF panel. I know this could be accomplished using traditional woodworking techniques, I again thought it would be fitting to try and print a solution. This is what I designed.

The photo shows the profile of part, as well as a quarter of the frame. The idea is that this piece is recessed into a hole in the MDF panel, and locks the sheet of acrylic inside the channel. I think it will look really nice.

As the pieces were best printed on their sides, I decided to print it in eight sections. I printed a few test pieces that looked like they were going to work great, so I eight of them on to print before bed one night, left it alone for a few hours, and woke up to this:

This was a complete mistake on my part. I figured that I had printed one successfully with no problems already, and there were no drastic overhangs or features I was worried about going wrong, but I certainly learned my lesson about print supervision. Unfortunately the part that lifted from the bed became stuck to the hotend heating block. It looks like this combination blocked the nozzle which then caused the extruded plastic to wrap back around onto the extruder body. I thought it would be an easy fix until I noticed that the thermistor and heating element wires were both entombed in the blob of plastic.

I tried multiple techniques at the reccomendation of the Prusa online community. The first was heating the hotend up to PLA temperatures and waiting for the heat to break the hotend free. I think the block was too large for the hotend to heat to a uniform temperature, so this didn't get me far. I tried sawing at it, which didn't do much. I also tried submerging the entire assembly in boiling water (which made the plastic a little malleable). This also wasn't too successful, it became very difficult to handle to exert force on the extruder since the boiling water also heated up the heatbrake. What I ended up doing was setting the hotend temperature to around 275°C, much higher than PLA's printing temperature. This allowed me to push on the heatbrake and essentially "melt" the hotend through the blob of plastic.

While this worked, there's still plastic on every surface of the hotend and heatbrake, which I'm not sure how to remove. I may try and clean this extruder assembly up as good as possible to keep as a spare and order some new parts from E3D to install. Unfortunately for now, this project is halted.