History ¶

• We purchased an Elegoo Neptune 3 Pro on 3djake.de in April 2023.

• We got it and assembled it on 2023-05-03.

• We ran the bed calibration.

• We used the included white PLA filament to print the buddha gcode included on the SD card. The print was flawless.

• We flashed Klipper.

• We tightened numerous screws and nuts, including

  • the eccentric nuts for the y axis wheels
  • one of the eccentric nuts of the x axis wheels
  • all bed screws

Klipper ¶

We based our original config on [1]. We removed the virtual_sdcard section, adjusted the path to the serial device in the mcu section, and converted the configuration to Nix syntax to be used with the klipper NixOS service. We also made minor adjustments to the descriptions of the gcode macros.

After writing the initial config, we ran all of the steps in https://www.klipper3d.org/Config_checks.html and updated the config with more accurate values.

We used the CAD model of the printer to slightly adjust the probe offset, and our eyes to adjust the X endstop. The Y endstop was already perfect.

We also lowered the move speed at the start of bed mesh calibration.

We then added virtual_sdcard back because fluidd depends on it.

NixOS ¶

We use NixOS’s klipper service for building the firmware as well as running the host. Running the klipper-flash-mcu script doesn’t work on this printer, so we instead manually copy the klipper.bin file (the path of which we find in the aforementioned script) to an SD card and boot the printer from it.

We had problems getting Fluidd to connect to Moonraker. Ultimately it turned out that the NixOS moonraker service didn’t restart the sytemd moonraker service on configuration changes. The same applies to klipper. Another problem was that the NixOS klipper service doesn’t validate the configuration, and the systemd klipper service doesn’t fail to start with invalid configurations.

When using NixOS ’’ strings for gcode, make sure the first line is indented less than the others. Otherwise, None of the lines will have indentation and the config will not parse correctly.

Next, Moonraker wasn’t able to connect to Klipper, emitting “JSON-RPC Request Error: -32601” and “Method not found” to its log. This was caused by Moonraker not being able to connect to Klipper because the process, running under the user “moonraker”, didn’t have the permissions required to use the UNIX domain socket at /run/klipper/api. We solve this by adding the moonraker user to the klipper group.

Stuff ¶

When printing grid infill, the nozzle would scrape the surface. But not on most of the grid, but instead on the grid’s “perimeter”, because of small blobs whenever the nozzle moved to the next line to print.

We turned on z hop because the nozzle was scraping print surfaces, despite accurate e-step, z-step, and extrusion multiplier.

Snug supports are buggy: https://github.com/supermerill/SuperSlicer/issues/3256

We use firmware retractions.

We switched from SuperSlicer to PrusaSlicer

Speed and acceleration ¶

Using https://ellis3dp.com/Print-Tuning-Guide/articles/determining_max_speeds_accels.html#determining-if-skipping-occured we’ve tested the max acceleration.

10000 mm/s² failed at 1 iteration. 9000 mm/s² failed the 50 iteration test after approximately 10 iterations. 5000 mm/s² passed 10 iterations and we didn’t try harder. We didn’t test values between 5000 mm/s² and 9000 mm/s² because they’re not realistically useful, anyway.

We tested speed at 500 mm/s for 1 iteration and didn’t care to test much more. We’ll never use these speeds in practice.

For Z velocity, 15 mm/s is the highest that doesn’t sound like it is abusing the motors.

TODO ¶

Calibration prints ¶

Default settings ¶

20mm * 20mm * 20mm calibration cube, 2023-05-06 ¶

Summary ¶

• Overall good quality
• Face opposite of X has some minor issues, probably due to insufficient part cooling
• Dimensions are correct to 0.01mm

All-in-one test, 2023-05-06 ¶

Settings ¶

Summary ¶

• https://www.thingiverse.com/thing:2806295)
• no over-extreusion
• no stringing
• no warping
• all bridges are flawless
• overhangs are perfect up to and including 45 degrees. 60 deg is acceptable, the rest are usable, but ugly, but drooping.
• hole diameters are 2mm too small

Clearance tolerance test, 2023-05-06 ¶

Settings ¶

Summary ¶

• https://www.printables.com/model/116911-clearance-tolerance-test/files
• 0.10 and 0.15 are stuck at 0.45 extrusion width without Arachne
• 0.10 is stuck at 0.3 extrusion width with Arachne
• 0.10 is stuck at 0.24 extrusion width with Arachne

Skew correction ¶

We’ve used both https://www.thingiverse.com/thing:2972743 and https://www.printables.com/model/70792-easy-3-axis-skew-calibration-tower-with-spreadshee to measure skew. In both cases, the amount of skew was insignificant (0.05-0.1 degrees). The two models did not agree on the amount of skew, and using either one’s values for correcting in the XZ and YZ planes did not eliminate skew. It is therefore likely that other issues (measurement errors, backlash, …) affect the dimensions, and not skew. Correcting for XY skew did work, but since the amount of skew was tiny to begin with it doesn’t seem worth the trouble of setting up skew correction for.

References ¶

Print head dimensions ¶

7.4 cm wide * 7.6 cm deep

Extrusion tests ¶

Filament: 3DJake ecoPLA Black Filament diameter: 1.75mm Extrusion length: 200 mm Extrusion volume: extrusion length * (1.75 mm / 2)² * pi = 481.0563751 mm³ Extrusion mass: extrusion volume * 1.24 g/cm³ = 596.5099051 mg Printer: Elegoo Neptune 3 Pro, stock extruder, running Klipper

library(tidyverse)

xTicks <- unique(data["Flow rate (mm³/s)"])
yTicks <- unique(data["Extruded (g)"] / expected - 1)

g <- ggplot(data = data, mapping = aes(x=`Flow rate (mm³/s)`, y=(`Extruded (g)`/expected - 1), group=factor(`Temperature (°C)`))) +
    geom_point() +
    geom_line(aes(color=factor(`Temperature (°C)`))) +
    labs(colour = "Temperature (°C)") +
    scale_x_continuous(
      breaks = pull(xTicks),
      minor_breaks = NULL,
    ) +
    scale_y_continuous(
      name = "Underextrusion (%)",
      breaks = pull(yTicks),
      minor_breaks = NULL,
      labels = . %>% map (\(x) round(x, 2) * 100)
    ) +
    facet_wrap(
      vars(`Nozzle (mm)`),
      labeller = labeller(`Nozzle (mm)` = (\(x) glue::glue("Nozzle: {x}")))
    )
print(g)

Practical applications ¶

When printing at 13 mm³/s with a 0.8 mm nozzle, the measured under-extrusion is 3.16%, which is close to the theoretical (and rounded) 3%. Printing with an adjusted extrusion multiplier resulted in an over-extrusion of 0.63%. We can attribute this to imprecisions in the extrusion system, the filament diameter, and rounding in the gcode. It seems appropriate to assume a ~3% under-extrusion and use a multiplier of 1.031. We used the 1.031 multiplier with a 5 mm³/s print and had an over-extrusion of 0.47%.

We can’t possibly print the calibration cube at 13 mm³/s at the moment, though. Our cooling isn’t remotely good enough, and the extruded filament probably has a solid core.

When we printed the ringing tower at 100 mm/s (resulting in a nominal 18.4 mm³/s volumetric speed) and 215 C, we ended up with a matte finish (i.e. significantly under the targeted temperature), but couldn’t spot any obvious under-extrusions. Nevertheless, the strength of the part was noticeably less than when it was printed at 3.6 mm³/s.

Notes on calibrating extrusion multiplier ¶

• Make sure to print without a skirt, as it contributes to the “filament used” statistic computed by PrusaSlicer
• The extrusion multiplier contributes to PrusaSlicer’s “filament used” statistic. That is, a print that takes 1g at a 100% extrusion multiplier is shown to take 2g at 200%.