The Neptune 4 Max runs a customized build of Klipper, the same open-source firmware used on Voron, Prusa’s newer machines, and a growing list of budget CoreXY and Cartesian printers. That matters for how errors show up. Unlike Bambu Lab’s HMS codes or Creality’s numeric fault list, the Neptune 4 Max mostly shows plain-English Klipper error strings on its touchscreen and, if you connect through Fluidd or Mainsail, in the console log. There is no central “error code database” with a lookup number for each fault. Instead, Elegoo has published individual wiki articles for the specific error strings its support team sees most often, and Klipper itself defines a smaller set of generic shutdown messages that apply to any Klipper printer, Neptune included.
This creates two layers worth knowing. The first is Elegoo-specific troubleshooting for messages tied to this printer’s hardware: its TMC2209 stepper drivers, its ADXL345-based input shaping accelerometers on the X and Y carriages, its strain-gauge style bed probe, and its ceramic heater cartridge. The second is generic Klipper shutdown language (“MCU shutdown,” “Timer to close,” “Rescheduled timer in the past”) that Elegoo has written its own repair-package fix for, since these usually trace back to a corrupted Klipper config file rather than a hardware fault on this particular machine. Below is what’s documented, organized by the part of the printer each error points to, with what Elegoo says causes it and how they say to fix it.
MCU shutdown and firmware corruption errors
The broadest category on the Neptune 4 Max is anything beginning with MCU shutdown or MCU mcu shutdown. These come straight from Klipper’s own fault-detection logic, not from an Elegoo-specific check, and Elegoo’s wiki groups several distinct strings under this heading with mostly the same fix.
MCU shutdown: ADC out of range shows up when a thermistor reading falls outside the configured minimum or maximum temperature window for a heater. Elegoo’s dedicated page for this one says the usual cause is a damaged or intermittently connected thermal sensor on the hotend or the bed, not a firmware bug. The fix path they document: power off, reseat the connector in question, wait about a minute before powering back on (which can clear the fault on its own), straighten any bent pins with a 2.0mm hex key nearby for leverage, and check the hotend and bed wiring for kinks, especially where the bed cable flexes as the bed moves. If the nozzle temperature reads a negative number on the web interface, that’s a strong sign the thermistor itself has failed rather than the wiring.
MCU shutdown: Timer to close and the closely related Rescheduled timer in the past are different animals. Elegoo attributes both to third-party plugins or moonraker components overloading the mainboard’s real-time scheduling, or to a manually edited configuration file that’s now out of sync with what the firmware expects. There’s no hardware check for these. The documented fix is to reflash the printer’s repair package first, then update mainboard and touchscreen firmware to matching versions, since a mismatched firmware pair between the two boards is itself a common trigger for scheduling faults. If the fault comes back after that, Elegoo asks for the printer.cfg, klippy.log, and moonraker.log files along with the G-code that was printing, which suggests these two errors don’t always resolve cleanly with a firmware reflash alone.
MCU rpi shutdown: Unable to open spi device is narrower: it appears right at startup and locks you out of the system interface entirely. Elegoo’s explanation is blunt: the firmware was either flashed incorrectly or the underlying Klipper installation on the board’s eMMC storage is missing files it needs. The fix isn’t a simple firmware update, it requires downloading the matched repair package and firmware pair for the Neptune 4 Max specifically from Elegoo’s download page (repair package “Neptune 4 MAX_1.2.2.65_1.2.12” paired with firmware “V1.2.3.1-UI_1.2.14” at time of writing), reburning it to the mainboard, and restarting. Elegoo notes the mainboard and touchscreen firmware versions have to match exactly or the printer will misbehave even after a successful flash.
A related one worth flagging: Internal error during connect: can’t convert negative number to unsigned appears immediately after power-on, on either the touchscreen or Fluidd. Elegoo’s page for this is explicit that it usually follows an attempt to flash firmware through Fluidd that didn’t come from Elegoo’s own channels, since the Neptune 4 line runs a customized Klipper build and generic upstream Klipper firmware isn’t compatible with it. Installing third-party firmware can brick the board outright. The fix is the same repair-package-plus-matched-firmware process as above, and in stubborn cases a full image reinstall via eMMC adapter.
Heater and thermal errors
Heater extruder not heating at expected rate is the message you’ll see if the hotend can’t reach temperature fast enough during heating or bed leveling, and Elegoo treats it as an electrical or hardware issue rather than a config problem. Their checklist runs through the printer’s voltage switch first (110V vs 220V, set only with the printer unplugged), then the ceramic heater’s connector and the adapter board pins for looseness or damage, then the mainboard-side ceramic heater wiring itself. If everything there checks out electrically, Elegoo’s own conclusion is that the hotend assembly, extruder cable, or adapter board needs replacing, which points to this being a genuine part failure more often than a settings issue.
The ADC out of range message covered above is also, functionally, a thermal error, since it’s Klipper’s generic response to any thermistor reading going out of bounds. Standard Klipper firmware separately defines a “thermal runaway” shutdown for cases where a heater is commanded on but the temperature doesn’t rise as expected within a time window, which is a related but distinct fault from a simple out-of-range ADC reading. Elegoo’s wiki doesn’t have a dedicated page phrased as “thermal runaway” for the Neptune 4 Max specifically, so if you see that exact wording it’s worth treating it as the standard Klipper safety cutout and checking heater wiring and thermistor seating the same way you would for ADC out of range.
Stepper motor (TMC) errors
The Neptune 4 Max uses TMC2209 drivers, and Elegoo’s wiki documents at least three distinct fault strings from them.
TMC Extruder…lowside short points to a wiring problem on the extruder motor circuit. Elegoo’s fix is to power off and physically check the connector at the extruder motor plug for looseness or damage before doing anything else; they note this check doesn’t void the warranty, which implies it’s a common enough complaint that they want customers doing the first pass themselves.
TMC Stepper_X / Y 00000002 drv_err=1 is a driver-level fault on the X or Y axis motor. The documented cause is a loose or damaged motor connector, and the fix is the same: power down, reseat the plug, and check for bent pins.
TMC stepper_y_reports error: DRV STATUS: 401b0103 otpw=1 (OvertempWarning!) is different from the two above in that it’s a thermal warning on the driver chip itself, not a wiring short. Elegoo’s guidance ties this to the cooling fan at the bottom of the printer’s chassis: if that fan isn’t spinning, the Y driver can overheat under load. That fan is designed to only kick in once the nozzle passes 50°C, so seeing it stationary at room temperature is normal, not a fault. Community discussion around this same error (including threads on the Klipper forum and the OpenNept4une project) also points to belt tension that’s too tight, or Y-axis current settings that have drifted from default after a manual config edit, as contributing causes. If the fan is confirmed working and the error persists, Elegoo’s advice is to reflash firmware to restore default motor current values before assuming a driver has failed.
Accelerometer and input shaping errors
The Neptune 4 Max calibrates input shaping using onboard ADXL345 accelerometers on the X and Y gantry, and both axes have their own documented failure modes.
Y axis vibration detection failed / Y-axis sensor status is abnormal / Failed to set ADXL345 register / invalid adxl345 id are grouped together on one Elegoo wiki page as variants of the same underlying problem. Listed causes: a loose Y-accelerometer connector, a damaged accelerometer or its cable, the printer not being restarted after a firmware update, or mismatched mainboard and touchscreen firmware versions. The fix order Elegoo gives is cable reseating first, then a firmware update if versions are out of step, then replacing the Y-axis accelerometer if neither resolves it.
X-axis vibration detection failed / X-axis sensor status is abnormal gets a nearly identical page with the same underlying causes on the X side: a bad extruder cable connection (the X accelerometer runs through the same cable as the extruder on this design) or an incompatible firmware pairing between board and screen. Elegoo’s page usefully lists the correct firmware version pairs for the Neptune 4 series: mainboard 1.2.2.64 with touchscreen 1.2.11, mainboard 1.2.2.65 with touchscreen 1.2.12, mainboard 1.2.3.0 with touchscreen 1.2.13, and mainboard 1.2.3.1 or 1.2.3.2 both paired with touchscreen 1.2.14. Running mismatched pairs from that list is called out as a direct cause of accelerometer faults, not just a general compatibility suggestion.
Bed leveling and probe errors
Community reports (notably a Klipper forum thread from Neptune 4 Max owners) describe a “No trigger on probe after full movement” error during auto bed leveling, and Elegoo has a wiki page titled “How should I deal with Homelevel nozzle to bedsensor not triggered” that addresses the same underlying symptom under different wording. Documented causes include a damaged or loose proximity switch plug, using a nozzle that isn’t the specific type made for the Neptune 4 Plus/Max (Elegoo notes their nozzles are custom and aftermarket ones can behave inconsistently with the leveling sensor), and running the leveling or homing routine without the PEI build plate actually attached. Firmware mismatch between mainboard and touchscreen is listed again here as a contributing factor, which is a recurring theme across nearly every sensor-related fault on this printer.
G-code, SD card, and slicing errors
SDCARD_RESET_FILE and the closely worded SD Card reset message both point Elegoo’s troubleshooting toward the slicer rather than the hardware first: check that the correct printer profile is selected in your slicing software, and if you’re unsure, delete the saved profile and re-add it from Elegoo Cura or Elegoo Slicer’s defaults rather than a hand-edited one. If reslicing doesn’t help, the next steps are a firmware update, then a physical check of the pins near the X-axis connector, then the proximity switch plug and extruder cable, in that order. Elegoo will replace the breakout board, proximity switch, or extruder cable under warranty if those checks come back damaged.
Move exceeds maximum extrusion, shown alongside the instruction to run ‘SDCARD RESET FILE’ or ‘FIRMWARE RESTART’ to resume, is a slicer-side issue in Elegoo’s telling: either the wrong printer profile was selected when the file was sliced, or relative extrusion mode wasn’t enabled in the slicer’s special settings. Re-slicing with the correct profile and relative extrusion turned on is the documented fix, not a hardware repair.
Unable to parse move, with the same ‘SDCARD RESET FILE’ or ‘FIRMWARE RESTART’ prompt attached, is described as either a corrupted or illegally-formatted G-code file, or an abnormal firmware configuration file. Elegoo’s recommendation is to re-slice using Elegoo Cura or Elegoo Slicer’s default settings and print a known-good test file from a freshly formatted FAT32 USB drive or TF card to isolate whether the problem is the file or the printer’s own config.
Connectivity errors
Connect moonracker timeout (Elegoo’s own spelling of Moonraker, the API layer Klipper’s web interfaces run on) gets the same fix as the generic MCU shutdown errors: reflash the repair package, then update mainboard and touchscreen firmware together. This suggests the underlying cause is the same class of Klipper service corruption rather than a distinct network problem.
Separately, an HTTP 500 error when uploading files through OrcaSlicer’s built-in printer connection is addressed with a network-configuration fix rather than a firmware one: check that your network connection is stable, then edit moonraker.conf to change the listening host from localhost to 0.0.0.0 so Moonraker accepts connections from other devices on the network.
The Neptune 4 Max shares its Klipper firmware track with the rest of the Neptune 4 series. See the Elegoo Neptune 4 Error and Warning Index for the base model’s own fault set, and the Neptune 4 Pro error and warning index for the Pro’s documented faults, most of which match what’s listed here.
The Neptune 4 Max shares most of its documented error messages with the Neptune 4 Plus, since Elegoo files many of these faults under shared “Plus & Max” wiki pages. See the Elegoo Neptune 4 Plus Error Code Index for the handful of codes indexed only on the Plus’s own product page.