My 10 year old kids have finally caught the Gloomhaven bug. For anyone who hasn’t played this game (or doesn’t play with 10 year olds), let’s just say keeping things on the level and organized during a scenario and across a campaign can pose a challenge. I started looking around for things I could 3D print to ease this burden. I found a few existing models for player dashboards and box organization that looked promising. I started making some rough prototypes and quickly realized that I wanted everything to be as dimensionally accurate as possible in order to make sure that everything fit perfectly.
I will describe my steps in terms of my printer… a heavily customized Printrbot Simple Metal. Printrbot is sadly no longer in business, but the reasonably open nature of this printer has allowed it to live on. Even though I’ll be describing everything in terms of this printer, I’ll summarize with high level steps that should be applicable to any printer/slicer combination.
I started off printing lots of test cubes of known dimensions. These guys print fast and then I measure them with a digital caliper. If the dimensions aren’t near perfect, it’s time to make some adjustments and print again. Assuming your printer isn’t completely out of whack, this model will mostly help you perfect your hot end and heated bed temperatures for the filament that you are using. The goal here is to perfect the balance of adhesion to the build surface without making the part difficult to remove or squashing things in the Z-axis.
No matter what I did, I couldn’t really get my Z height to be perfect. It was always smaller than it should be and I kept adjusting my Z Offset using the G-code M212 ZXXX where XXX was some Z probe Offset adjusted over and over again in .1 mm increments. No matter what value I used, I could not get this perfect before reaching an offset that negatively impacted the first layer adhesion. I noticed that at a certain Z offset, where there was no possibility of the hotend smashing the first layer, the discrepancy in the Z height always remained the same. I decided to print a taller model to see if the issue with Z dimension accuracy was an issue with every layer (I should see a larger discrepancy with a larger model) or if it was purely a first layer problem (Z height discrepancy should be about the same no matter the model height).
I moved to printing a pyramid calibration print that was taller and would also allow me to test stacking dimensional accuracy in the X/Y axes. The first print proved that the Z height dimensional problems were absolutely a first layer issue.
I recently switched my preferred slicer from Simplify3d back to Cura due to an issue I had where Simplify3d’s overaggressive license protection scheme kept locking me out of being able to use the software requiring me to wait on their customer support (sometimes for days) to unlock my legitimate copy so that I can use it again. When this initially happened, I was in a hurry to continue printing a project that I was working on and I breezed through the Cura setup mostly accepting the defaults for my printer. Up until this point, extreme accuracy in the Z dimension wasn’t a high priority and I didn’t really notice any issues until diving into this project. I did some digging in Cura and noticed that a default setting was to do about an 80% extrusion on the first layer. I changed this to be 100% and after adjusting some hotend and heated bed temperatures on a few more cubes and my Z height was perfect!
By now, I had tons of little cubes in all sorts of colors littering my printing area. They might print fast, but they’re fairly useless. I decided to look for a test print that had at least some utility. I found a jenga block that took about 20 minutes to print and decided to go for it. I thought that since my printer was fairly dialed in now, I could use this to print when making subtle slicer changes or swapping filament to see how overall printing would be impacted. My kids saw a few of these in different colors and wanted a ‘giant’ jenga set so I scaled up the model and went to work.
Within a few minutes of printing a jenga block that pushed the limits of my build area in the X direction, I noticed some obvious warping in the corners. How could this be when everything was dialed in? I initially blamed the cooling fan. I felt maybe it was cooling the PLA to fast which was killing edge adhesion. I modified my slicer settings to turn the cooling fan off completely for the first two layers and then gradually ramp up to 100% over the next 5 layers. This seemed to fix the warping for the jenga blocks.
I finally got back to what originally led me down this path… printing inserts to organize GloomHaven. I unfortunately couldn’t print everything in a single piece since the largest inserts needed a 285 mm print surface in one direction and my franken bot maxed out at 250 mm in all directions 🙁 I contemplated putting everything on hold and figuring out how to enlarge my print surface, but then recalled what that process was like when I upgraded from my original 150 mm axes to my current 250 mm. It took forever to iron out the kinks. I decided to just split up the models to make them print using my constraints and added tabs so they could then be glued together (For most of my PLA based projects I use the E6000 craft adhesive).
Even by splitting the models, some of these pieces still pushed me almost to the limits of my build area in at least one direction. I continued to notice warping and in some cases, failed adhesion in the extreme ranges of both the X and Y axis. This was perplexing at first and after doing some research with several additional test prints it appeared that I had an issue with my bed not being level. This was crazy since one of the reasons I favored the printrbot early on was because it had an auto bed leveling capability. This was supposed to correct for minor imperfections in the bed’s levelness by modifying the gcode sent to the printer to compensate.
The printrbot uses a metallic sensor to determine where the bed is. Before each print, it probes the bed in 3 places in order to get an idea of how it needs to compensate for any slant in the bed. I started by taking apart everything and recalibrating this sensor thinking that was the problem. Of course after doing this, I pretty much had to walk back through everything I had just done to dial in my printer… a few days later, I was back in the same place… still having issues in the extreme X/Y regions of my build area.
I started reading more about the auto bed leveling procedure and remembered a former co-worker (who did not have an auto bed leveling feature) telling me about Simplify3d’s bed leveling wizard. I decided to give this a shot and record the results. This process basically moves the print head around to many points in the X and Y axis at a Z of 0 and probes the actual Z offset. It immediately became obvious that the problem was related to the 3 points probing that my auto bed level probe used. Everything within those points was fine, but there were several areas outside that were noticeably off in the Z offset compared to the probing points. These points that get probed are baked into the firmware, so I started digging around to see how I could change that.
I still use the original Printrbot firmware which is no longer maintained and it’s based on a fairly old version of the Marlin firmware. This version does not really support much modification in terms of how the auto leveling procedure works. While becoming knowledgable on the Marlin firmware, I discovered that newer versions of Marlin support a much more robust bed leveling procedure that arose out of the needs of SLA printers but was then modified for FDM printers. This procedure, called skewness compensation, allows you to define a ‘bed skew’ matrix that is applied before the auto bed level procedure is run. This sounded like the exact solution that I needed. Unfortunately, there isn’t an official printrbot firmware that supports this… but I found a project to get the Printrbot Simple series running on a modern Marlin based firmware.
My initial investigation suggested that using this firmware is still experimental and I may sacrifice other behaviors that haven’t been implemented yet in order to get bed skew compensation. Being that I have a bit of a print backlog and didn’t want this printer to be out of commission (especially since it prints things that are smaller and centered on the build plate perfectly), I decided to hold off on a firmware upgrade for now, but I am actively watching this project and plan to upgrade at some point.
I needed another solution, so I spent tons of filament and time tweaking the z-offset and generated g-code manually in order to be able to print at the extremes, but this resulted in a return of Z dimension accuracy issues when printing items that don’t expand beyond 75 mm from the bed center in the X or Y axis. I treat custom G-Code and firmware changes like a software project and keep meticulous records about what I changed and I, so I used this changelog to define an ideal ‘profile’ for printing things within a 75 mm square centered on the build plate and another ‘profile’ for printing outside of this square. This got me close enough for just about every use case I was immediately working on. I printed for a few days swapping out firmware profiles depending on whether the model I was printing crossed this imaginary boundary or not.
All the time I was doing this, I still had this nagging item in the back of my head… how do people who don’t have auto bed leveling deal with this issue? This led me down the path of an area I forgot all about from my early 3D printing days using home made rep raps… hardware bed leveling. To be honest, I probably more blocked this out of my mind rather than forgot about it because it was so nightmarish in the early days and was one of the reasons I insisted on a printer with auto bed level feature when I upgraded. I ultimately found someone who added hardware bed leveling to their Printrbot Simple Metal. I had to mess around a bit to get this working with my hardware modifications, but it ultimately allowed me to dial in the printer reasonably well for the remaining part of this project.
Leave a Reply