Doing some electronics testing now…have the Arduino Due, RAMPS-FD v2.2 (the one I built a while back), a 128×64 LCD module (the usual ReprapDiscount design), and a Raspberry Pi 3 B+ all hooked together, with OctoPrint running on 64-bit Gentoo on the Raspberry Pi.
At some point, something changed in Marlin such that it now doesn’t want to write to the EEPROM. M500 throws an error: “field esteppers mismatch” [sic].
The SD-card slot in the display works well enough to get a listing, but not to read or write files, which makes it kinda useless. I reworked the display adapter a little to use a different chip (a 74HCT244 instead of a 74HC07) that was more readily available, but could this substitution affect SD-card performance? Should I try whacking in a 74HC244, or should I go back to the original design and hope I can find 74HC07s somewhere?
On the other hand, I did get OctoPrint to talk to the Due/RAMPS stack over the Due’s native USB port, which is much faster than the “programming” port that uses the same ATMEGA16U2 as in the 8-bit Arduinos. (Marlin images are burned through the native port in about 4 seconds, vs. 32 seconds when going through the AVR.) I had to patch OctoPrint’s firmware updater plugin to talk to the native port; those changes have been put in a pull request. Maybe faster communication between the Raspberry Pi and the Arduino Due’s native USB port will mitigate the need for the SD-card slot when running complex print jobs.
Just got the CoreXY mechanism working. This is just the right motor, but I also checked the left motor and it moved the carriage the other way. I think I’ll need to put endstops on the rods to constrain motion so that (for instance) the hotend doesn’t slam into the motors; that should be a fairly simple design. (I’m thinking printed rings clamped to the rods with screws, as I plan on using stall detection in the TMC2130 drivers in place of endstop switches on X and Y.)
Right now, I’m driving one motor at a time with a DRV8825 stepstick and a Teensy 2.0 on a breadboard. Maybe it’s time to finish wiring the electronics. :)
For the first time, I printed this tolerance test and got all of the inserts to spin. 0.1 mm took a little bit of persuasion, but I was able to break it loose with my fingers. Previously, I was lucky if I could break 0.2 mm loose at all, and I’d frequently need tools to break gaps smaller than 0.3 mm loose.
What changed? I’m calculating flow percentages for my filament, according to this page I ran across recently:
I also usually set the first-layer horizontal expansion to something like -0.1 mm to combat elephant foot. That and overextrusion from the default 100% flow rate (I’d sometimes punch in 95% for PLA if I remembered, but the rolls I’ve tested so far have come back at 90-92%) were the likely culprits of previous tolerance tests that got stuck.
Bottom line: high precision (by 3D-printer standards, anyway) is achievable, even with the A8. :)
A few months back, I bought my first 3D printer, an Anet A8 kit for somewhere around $150, shipped. It was an OK printer to start with, but various upgrades (and a repair or two) have made it into a fairly solid workhorse that still hasn’t come home from the office.
I replaced the stock firmware (whatever it was) with Marlin fairly early on. When the original motherboard crapped out after a month or two, I replaced it with an Arduino Mega and RAMPS 1.4 combination with DRV8825 stepper drivers, which made the printer both quieter and more precise.
I’m now building a Hypercube 300 for use at home. While looking into hardware and software options for that, I ran across Klipper, a relative newcomer with a different idea: move most of the computations for 3D printing out of the weedy little 16-MHz 8-bit AVR microcontroller on an Arduino and onto the much faster 1.4-GHz quad-core 64-bit ARM microprocessor in a Raspberry Pi 3. (Raspbian only has a 32-bit userspace, but I’ve built Gentoo with a 64-bit userspace…but that’s straying off-topic.) The Arduino is retained, but only as a real-time auxiliary controller that only makes sure the commands sent to it by the Raspberry Pi are carried out on time and in the right order.
I thought I’d seen some video of a Klipper-powered Hypercube a while back…can’t find it now, but here’s a Creality CR10 running at 100 mm/s with Klipper. My A8’s been loafing along at 60. I need to look into this.
Since I already had a Raspberry Pi running OctoPrint plugged into the A8, I thought I’d give Klipper a shot. It took a while to get the configuration sorted out (it’s here), but this morning I got it pretty much stabilized. First print was a Cali Dog, and it turned out just fine at 60 mm/s. With basic functionality sorted, I figured I’d try seeing how fast my printer could go.
I sliced it in Cura 3.4.1 with some basic settings: 60 mm/s base speed, 2 perimeters all around, 15% cubic infill, and a 350-mm skirt to get the nozzle primed. I also used a set of ChangeAtZ post-processing scripts to increase the feedrate every 8 mm, from 100% at the bottom to 200% at the top. This produces 8-mm sections printed at 60, 72, 84, 96, and 108 mm/s, capped by a 10-mm section printed at 120 mm/s. That’s the theory, at least.
Since Klipper was already on the printer, I let it go first:
You can hear it get faster on each programmed feedrate change, and the finished quality is pretty good. There’s what looks like a seam on one side where I think it always started the outer wall, but that’s it. Print time was 20 minutes.
Next up, I flashed Marlin back onto the printer. I only tweaked the gcode for different homing and bed-leveling commands used by Klipper and Marlin; the rest was unaltered. Here’s what I got with Marlin:
Even at 60 mm/s, the printer was stuttering on the inner perimeter. Each “circle” is cut into 90 short line segments, and the resultant flood of gcode couldn’t be sent fast enough. At 72 mm/s, it got even worse. Now, the printer was stuttering on the (visible) outer perimeter as well, which produced stippling artifacts where the printhead stopped and restarted. It never got any faster; if it was having trouble keeping up at slower speeds, it certainly wasn’t going to do any better with faster speeds. To add insult to injury, print time increased to 33 minutes. Slower and worse quality.
I’d heard somewhere that sometimes the USB serial connection from OctoPrint to Marlin can be a bottleneck, so I put the gcode on an SD card and printed it again:
Not much faster than when printing from OctoPrint (finished in about 30 minutes), but at least the quality was much better. It wasn’t too different from what Klipper produced, other than that it took about 50% longer.
Here’s a close-up of the three prints side-by-side:
(K=Klipper, M=Marlin streamed from OctoPrint, MS=Marlin printed from SD card)
Even without zooming in, the stippling is quite visible on the middle cylinder.
Bottom line: Klipper’s a little bit more tricky to install, and it’s not yet as loaded with features as Marlin (Klipper currently does nothing with the rotary encoder or kill button on the display, and it doesn’t have automated filament changing), but the speed and quality improvements make it a winner for most daily use. If I need something that only Marlin handles for now, it’s easy enough to switch back to it temporarily.
"It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong." -- Richard Feynman