Lucas Status Update: Printer Tuning and Repair

After restoring the PrintrBot’s z probe and getting it operational, I had to tackle the issue of still having relatively poor print quality. Several issues presented almost simultaneously. First of all, various prints had pretty severe layer shifts along the x-axis. More perplexing was the observation that print quality suffered when run through the Octoprint system rather than directly from a laptop.

After some digging around and more test prints, it became clear that the problem of shifting layers was due to a mechanical failure: the set screw in the gear driving the x-axis timing belt had come lose. This problem was remedied by completely dismantling the entire printer – sides, bed plate, top, and all – and then tightening the set screw.

The second issue of varying print qualities seemingly depending on the host software was a bit more curious. Despite the printer being fed the exact same g-code, the prints faired better when being run from my laptop via programs such as Pronterface, Repetier-Host, and Cura rather than from the Octopi operating system on the raspberry pi. More digging on the matter brought up the issue that Octoprint really was sending commands at a slightly slower rate from the raspberry pi than a different host software from a laptop or desktop. This slower communication rate, paired with a tiny instruction buffer, was causing starvation issues. Essentially, the printer would occasionally execute all of the instructions in its small USB input buffer faster than Octoprint could fill it leading to short pauses between movements – these in turn would result in physical artifacts and gaps in the print layers. Changing the firmware’s default ASCII input buffer from 4 bytes to 32 largely solved the issue and resulted in much cleaner prints.

Finally, I used the repetier-host software to better calibrate the printer’s starting height by running short test prints and then adjusting the z offset height accordingly.

After all of these changes were said and done – tightening set screws and belts, changing the input buffer size, and calibrating the z probe offset – the printer was finally producing high quality prints consistently.

Hannah’s Status Update Week 4/19

so this past week was a lot of playing around with the parsing and graphing code that I wrote to get it to be able to automatically slice the image into the different layers.

this week I also worked on “injecting” bad / faulty gcode into my plotter so that way we can actually start to compare the good & bad models against joshua’s edges from images of what the print should look like.

Team Status Update for Week of 4/19

This week the team created the slides and the final Gantt chart of team accomplishments.

Blue -Joshua
Yellow – Hannah
Red – Lucas

We’ve had some major setbacks (see Lucas’ post) and are working to find solutions to these challenges.

Joshua’s Status Update for Week of 4/19

Well, I had been continuing development for the Octoprint plugin. This plugin captures a picture on each Z-axis increment, and is supposed to process the images and the pre-computed model that Hannah’s code generated. However, apparently Lucas’ computer and 3D printer are broken, and since he never sent real images using our camera (and corresponding intrinsic/extrinsic matrices), I couldn’t do full tests of the system with known camera parameters. So this past week I’ve been trying to figure out how to, with only 1 image and 1 point cloud, estimate 3D-2D point correspondences without knowing the world-to-camera matrix — since we didn’t have access to a 3D printer, I thought the easiest way to test the whole system was to stream in a timelapse of a 3D print (many can be found on YouTube, and usually include a link to the STL file or gcode being used). It’s easier said than done, because as the number of point cloud points increase, many of the algorithms I looked at performed in the order of magnitude of an hour (which is not useful for our project nor is it feasible debugging-wise).

Continue reading “Joshua’s Status Update for Week of 4/19”

Lucas’s Status Update, 4/12 -4/26

So my laptop finally croaked last week – it crashed, had a kernel panic, and subsequently entered a boot loop. After a weekend spent trying and failing to fix it or at least get a backup, I sent it in for repairs. It is currently still sitting there, as the shop says the Covid-19 situation has seriously impacted their repair/diagnosis timeframes.

Big oof
My daily driver experiencing a kernel panic

I was able to dig up a couple ancient and broken Macbook Pros from 2010/2012 and spent the next few days fixing them up with what few parts I could find at the shop:

One of the laptops literally had its battery swell up to the point of bulging out the top case…


I removed the logic board from another to better clean up what appeared to be some very old gunk…

I gave them some ram and replaced the hdd’s with ssd’s; at least one seems to work ok for now…the other two are waiting for new batteries to get shipped.

That’s not all though – the 3D printer broke again. Once again, the z probe was not registering. Previously, the printer was broken because it was registering that the z limit was triggered no matter what state the inductive probe was in. This time, it had the opposite issue of never triggering the z limit even though the probe looked to be working just fine.

One thing I did not realize is that the Printrbot was totally open source. I was able to find the schematics and board diagram:

Notice that the Z endstop (in the upper box second from the right) is tied to a transistor
The endstops are the three, three pin connectors at the bottom left

Thinking it was once again an issue with the z probe transistor, I replaced it. And I took pictures this time:

Last time, the transistor had an internal short, meaning that the z limit line was always held High. This time it seemed like it had internally blown open such that the z limit line was always held Low. Without a multimeter, it was very difficult to diagnose.

My rough setup of what parts and tools I could scrounge around the house. I’ve got a reflow station but no multimeter or solder wick…go figure.
Sop-23-3 packages are a pain to reflow…especially when they’re located right next to a bunch of easily-meltable plastic connectors…

I replaced the original mosfet with an MMUN2211LT3G NPN BJT. Having nothing other than that, I replaced the BJT with another of the same kind.

After manually testing the z probe trigger by jumping 12V to the input of the transistor, I confirmed that the printer was correctly registering the z open and closed states. Curiously, the z did not trigger with the inductive probe plugged in even though the probe’s led correctly lit up when it got within range of the metal build plate.

Within range of the build plate, the inductive probe correctly turned on its signal LED
When it was far enough off the build plate, the probe also correctly turned off its LED…

After some more digging, I learned that it was totally possible and even somewhat common to have this kind of inductive probe break without destroying the LED signal function. Essentially, the probe was registering the build plate proximity correctly, but couldn’t generate enough voltage to flip the state of the transistor on the board.

I have ordered several more probes on Amazon but they will take another 1-2 weeks to arrive 🙁

I have also explored running the printer without a hardware limit for the Z, but I am having trouble generating the right hex files for the printer. There are a number of pre-existing firmware hex files and I have been able to upload them to the printer, but they all have specific configurations. I need to find a way to edit the configuration file and generate a new hex file. Then I can possibly manually level and home the printer, and then set up a software limit for the z.

A Rough Patch:

I’ve been dealing with a lot of family issues lately that really put a strain on the project. Among those were my mother being bedridden for a couple weeks with Covid-19  as well as a family friend recently passing away from of the virus.

In a way, my laptop  exploding and the 3D printer fiasco let me escape it for a bit, but on the other hand these issues also made me realize how much farther along we’d be if I had gotten things together sooner. This past month has been incredibly taxing but I shouldn’t have let that keep me from having my head in the game.

Joshua’s Status Update for Week of 4/12

This week I optimized the edge error code. Originally, I was using Edward Cui’s code for the modified Hausdorff, but after slow computation times, I reimplemented the algorithm myself, which was a lot simpler than I had previously thought. Cui’s implementation imported numpy.core.umath_tests, which apparently is deprecated and runs rather slowly. Instead I call the scipy.spatial_distance.directed_hausdorff function, and use the max of the forward and reverse directed hausdorff distances as my distance metric. This is described in Comparing Images Using the Hausdorff Distance by Huttenlocher.

Hannah’s Status Update Weeks 4/5 & 4/12

So the past two weeks I’ve been working on creating a grapher for the prints we want using their gcode files.

I’ve finished my first passes at it, but the issue that is now arising is it’s presentation when it comes time to compare it to the actual image.

I have two examples included, (both gcode files I got off of thingiverse)

The first is a puzzle piece. From all around, it looks good and similar to the slicer’s view of it, but when looking at the graph from the view we think our camera would be at, there are all the gaps in between each layer. I think this is because of how python has automatic axes (I’m not entirely sure of this and will work on fixing it)

The second object was a classic coke bottle. This one had some different issues. With the puzzle piece, There’s the final line of the extruder returning to its original position, but that doesn’t get in the way of the piece. For the coke bottle, the extruder is returning to such a high z-value, that it shrunk the look of the print in the graph. I will probably need to go into the actual gcode file and find out where this last step is and change it’s value so that this issue is fixed.

So this upcoming week is really about fixing my graphs and getting these images to Joshua so we can test the edge detection. Then, working with Lucas and the more advanced parser, we want to try and be able to figure out how long each layer takes and from there perform multiple comparison tests for one object.

Joshua’s Status Update for Week of 4/5

I didn’t really do much for Capstone this week due to other exams and labs, but I am planning on continuing refining the edge/blob code I wrote last week, as well as furthering the Octoprint plugin code I had previously started on.

Joshua’s Status Update for Week of 3/29

This week I was able to accomplish my tasks of creating an edge/blob function  . I also completed a function that determined whether an error has occurred, based on the edge/blob results and a reference image. I will be demonstrating these functions using several images of small 3D printed parts.