...
Fine, but only so I can move on. After all, I didn't drop over $1.5k and (metaphorically) lug this box across the country just for it to take up valuable floor space:
A quick recap of this project:
Back as a sophomore, at the height of the 3d printer buzz (or so it felt at the time), I decided to make an overbuilt FDM printer. In the absence of any prior 3d printer experience, the result was a semi-functional but eternally unfinished machine. About once a year I picked it up again for a few weeks and made some minor progress. As frustrating as it is to work on a project I'd design very differently today, I'd rather have a final product at this point than a never ending cycle of changes.
Picking up the pieces from the last work session started with...picking up pieces from all the boxes and corners they'd floated into. I replaced a few things immediately. The electrical enclosure was upgraded to my favorite inexpensive hinged box. After messing around with last post's improved hot end cooling solution, I gave up and just bought a new, better extruder. The tensioning arm and idler on the inexpensive AnyCubic MK8 fixes most of my gripes about the old extruder I spent so long fighting with. As a bonus, it played nicely with the same mounting plate cutout so the swap was relatively painless:
After a day or two of rewiring, tidying, and mounting the new extruder, the firmware battle began. I settled on the Repetier firmware, which was fairly quick to get up to speed with. One challenge was figuring out how to convince the machine to zero the Z axis at the bottom of the bed's travel (where the limit switch was) with an appropriate offset so that it could raise the bed again up to the extruder. Most sample settings I found online were for machines that raised and lowered the extruder instead of the part and kept the limit switch at the other end of travel. At one point, I thought I needed to treat the position with the bed touching the extruder as Z0, with the negative Z being the bed moving down. This would make the position at the limit switch Z-330 (in my case). My mistake was interpreting this as Z_MIN_POSITION in the code. It also made me think I had to flip my Z axis direction around, which wasn't necessary.
In reality, I found that I needed to maintain Z positive as the bed moving up toward the extruder, Z max being the lowest position of the bed (touching the limit switch) and Z min being the bed touching the extruder nozzle. This means that the bottom of the bed's travel (which I think most would call the maximum position of the bed relative to the extruder) should become position 330. This puts the machine in the confusing situation of considering the extruder height position zero and the limit switch position 330, yet move up when you give it a Z10 command (for instance). My recollection of G-code is pretty shaky, so I'm going to chalk this up to something I'm missing when I type in manual G-code commands.
The combination of numerous similarly named constants in the code and very minimal constant documentation (that I could find) made this unnecessarily difficult to debug. In case anyone is similarly confused, here were the relevant config.h lines for me:
#define Z_HOME_DIR 1 //Home downward
#define MIN_HARDWARE_ENDSTOP_Z false //No limit on min
#define MAX_HARDWARE_ENDSTOP_Z true //Limit switch on max
#define Z_MAX_LENGTH 330 //330 mm of bed travel between limit switch and extruder nozzle
#define Z_MIN_POS 0 //Bed touching extruder is the min position, so make this zero
Once the coordinate system troubles were behind me, I ran into another old friend, z-axis binding. Due to the unnecessarily heavy duty components used to make up the z-axis linear guide system (looking at you oil-infused bronze bushings) and the weight of the bed platform itself, the z axis has needed a couple modifications in the past. As I began to test, I quickly found that the z axis stepper driver kept overheating and cutting out at the currents needed to drive the axis without stalling. As a remedy, I enabled 16X microstepping on the driver. This worked very nicely, and also minimized the terrible grinding noise that the motor was previously prone too. I did still notice the occasional overheat after this during long prints. Modifying the firmware setting to disable the z axis between movements seems to have solved it once and for all. One benefit to a hefty leadscrew and high radial load (but not necessarily low friction) bearings is that there's no backdriving or movement even with the motor turning off between layers.
Okay, back to the fun stuff. With firmware sorted and high expectations, I pressed start on my first print:
It might be a mess of plastic noodles, but it's my mess of plastic noodles. The above effect was caused by mis-tuned X and Y motor parameters and a mechanically slipping drive belt. With those sorted, the "ramen" result went away.
Gradually.
Some incorrect steps per mm led to my companion cube ending up a little squashed. This was eventually remedied.
Even with correct firmware parameters, I still noticed some disturbing variation in z height. I did a quick study to find the z movement accuracy, revealing that there really wasn't any. I could see up to almost 10mm of variance in parts, and it seemed to compound with different steps and direction reversal. A little head scratching led to an "oh-duh" moment. Back in the day when I designed this machine, I intended to use a solid coupling between the motor and the leadscrew. As usually happens in the real world, the motor shaft did not end up being perfectly co-axial to the leadscrew, leading me to add a helical coupler between the two at some point in the past without fully considering the ramifications. While the helical coupler transmits torque despite angular misalignments, it also acts as a loose spring in the axial direction. I've seen helical couplers used successfully in other printers without axial constraining, but they were typically supporting light loads in compression. To solve the problem, I started by disassembling the z axis and machining the upper and lower leadscrew pass-throughs to accept pressed bearings.
Easy enough. Now I needed a way to constrain the leadscrew against the inner flange of these bearings. My first attempt at turning a shoulder on the leadscrew was a disaster. The steel was far too soft and quickly bent. Instead, I found some conventional shaft collars and faced them off partway, leaving a small ring protruding out one side that could sit against the bearing.
I installed these onto the leadscrew, taking care to ensure there was no perceivable gap between the collars and bearings at either end that would permit wiggle.
It seemed to work. Results weren't spectacular, but they were usable. Over the next two weeks I kept tweaking the formula, trying different speeds, accelerations, retraction rates, materials, layer heights, and just about everything else I could think of. Eventually I got the results to a point that I believe was close to the best I could expect from the machine.
I could go on for a while about the imperfections in print quality. The machine vibrates too much, leading to layer inconsistency. The bent leadscrew creates a slight bump out when the bed raises past a certain point, creating telltale shifts in layer position. Unnecessary gantry mass makes acceleration slower than it could be. Using an imperial pitch leadscrew with metric-centric firmware leads to small rounding errors that show up as layer z-height differences.
Despite this, over the past few months I've gotten a huge amount of use out of it. It's a joy to be able to hold prototype parts in my hands a few hours after designing them. Unlike the CNC mill, it requires little supervision and set up. With the addition of a server running OctoPrint, loading up parts and monitoring progress is easy. It's also been remarkably reliable. I'll usually run it unattended for 10-12 hours a day, every day.
In summary:
Was this a practical use of time and money for the end result? No.
Is the quality of this 2014-era homebuilt machine as good as what's on the market now? No.
Would I spend time rebuilding this project again to make it way more awesome? No.
Was it worth it?
Yes, I think so. I actually learned a huge amount from the project, especially in the design and first revisions back in college. It's satisfying to have a highly functional end result that I can make use of every day. Even the process of going back and considering all the things I would change has been refreshing. It's also character building to go through the pain of rediscovering how the last 20% of the project contains 80% of the work, as usual.
With that said, it's ultimately a tool, and spending most of your time making or fixing the tools makes it difficult to actually accomplish anything with them. I look forward to buying an off-the-shelf printer in the near future to increase my prototyping output.
