[BUG] Mega Pro only printing first layer

[CraftoHohenvels]

Bug Description

My Mega Pro only prints the first layer and then stops extruding. The fan settings are not causing this (ie. disabling the fan results in the same problem). I honestly can't provide much more details - everything seems fine (gcode stream from OctoPrint, etc.).

NOTE: this is not a hardware problem! I reverted back to the original fw and it is fine again!

Steps to Reproduce

1. Download the firmware
2. Flash the firmware using OctoPrint Firmware Flasher
3. Try to start a print over "network" (aka OctoPrint or Cura)

Expected behavior: print everything beyond the first layer

Actual behavior: stops extruding, but keeps moving. Strange thing I observed: the head stops moving randomly

[CraftoHohenvels]

@stklcode sorry for disturbing you, but you mentioned you are operating a AMP, so am I. May I ask whether you are printing via the SD-Card or USB? And may I ask which fw version you are using?

[stklcode]

Typically via USB from an OctoPrint server. SD only for firmware testing purposes.

Running a custom fork of upstream Marlin 2.1.2 which has pretty much all changes from Knutwurst MEGA_P_DGUS_BLT_10 1.5.2.
Board is “0.0.2“ stepper drivers and extruder all stock. Just the BLT, frame lighting and a custom wiring harness for the laser module, so I can use the hotend fan while operating the laser.

I did not experience any issues with 1.5.2 (except the manual leveling, but it’s trivial to work around this). I’m on an updated version right now (#513), but only a single small test print so far.

[CraftoHohenvels]

Thanks a lot for the quick response! I will give 1.5.1 a try and maybe one of the development versions - maybe I can get something to work

[stklcode]

Just one thing, that came to my mind: did you reload EEPROM defaults (from the special menu or with M502) once after flashing from stock FW to Marlin 2? No idea what happens, if old data structures are still present.

[CraftoHohenvels]

Yeah, I pressed "Load Firmware Defaults" (if that is what you mean), then hit reload and save and reload

[CraftoHohenvels]

Update after re-doing the installation (for the third time with this firmware / first time with the 1.5.1) with the version 1.5.1 it works! At least on a very small test print (i.e. a 7.5 x 7.5 x 3 mm cube). For me this is very essential (well no shit Sherlock), as I want to equip my printer with a BLTouch module in order to hopefully improve up on quality further (additionally hardware maintenance is on the calendar - probably at the same time).

I can image that some of the refactoring killed it (happens the best), but luckily the older version seems to work.

I will try a few more prints this week and report back!

For good measure:

• Board is currently unknown
• Working version is the 1.5.1
• Faulty version is the 1.5.2
• Printer is the "Anycubic Mega Pro" (fully stock)
• Printed via OctoPrint

[stklcode]

Was there any error message in the serial output when the printer stopped or did you maybe save the last log lines?

I thought I had a suspicion, but on a second look I was on the wrong path here... Wondering why I didn't notice that, pretty sure I did some prints since this change 🤔

I'll likely try by end of this week and hopefully figure out what is actually causing the instabilities.

[CraftoHohenvels]

The output looked fine as far as I could tell, but on the other hand I didn't save the logs.

If it helps I could however upgrade the version and get some

[CraftoHohenvels]

Update:
I tried to print a Benchy on the 1.5.1... Didn't go well
Send: N4355 M486 S0*93 Recv: echo:Unknown command: "M486 S0"
this snippet seems related...

gcode:
Benchy.zip

(Hopefully) the full terminal output:
Terminal.txt

[CraftoHohenvels]

One thought upon looking up the command
M486 (https://marlinfw.org/docs/gcode/M486.html)

This OctoPrint Plugin may be related, although it worked with the original firmware

The Slicer (Super Slicer) seems to add this command

[CraftoHohenvels]

Update on the Update:
The print still fails at the same point, now I found this error:
Send: N133 M73 P1 R89*36 Recv: echo:Unknown command: "M73 P1 R89"

again the gcode:
Benchy.zip
and Terminal:
Terminal.txt

[CraftoHohenvels]

Update on the Update on the Update:
I found no more errors, so I am at a dead end...

gcode:
Benchy.zip
Serial log:
serial (1).log

[stklcode]

Thanks for testing again. Looks like the host is cancelling the job. Actually, it's not exactly the the first layer, there is one move missing, before fan speed goes up (M106) and the layer is finished.

GCode at the end of layer 1:

...
G2 X101.087 Y102.816 I56.428 J71.255 E.06127
G2 X99.372 Y106.747 I3.351 J3.802 E.13042
G2 X100.308 Y108.494 I2.538 J-.236 E.05995
G3 X101.924 Y109.805 I-56.422 J71.248 E.06127
M106 S255
G1 E-2.8 F1200
;WIPE_START
...

Log around these lines

...
Send: N5475 G2 X101.087 Y102.816 I56.428 J71.255 E.06127
Recv: ok
Send: N5476 G2 X99.372 Y106.747 I3.351 J3.802 E.13042
Recv: ok
Send: N5477 G2 X100.308 Y108.494 I2.538 J-.236 E.05995
Changing monitoring state from "Printing" to "Cancelling"
Send: N5478 M108
Recv: ok
Recv: ok
Send: N5479 M400
Recv: ok
Send: N5480 M114
...

[CraftoHohenvels]

Changing monitoring state from "Printing" to "Cancelling"

This part of the log is caused by me. I stopped the print, as the printer wasn't extruding anymore. I should also note that only the first layer is fully printed, the second one starts, but then stops extruding.

[CraftoHohenvels]

I will try to replicate this problem with a heavily trimmed down version of the original gcode tomorrow. I hope that is going to make debugging a little easier.

Edit: one thing I just noticed while removing the latest fail is that it seems the extruder pushed out the filament (like retraction) by quite a bit at the end. Although my retraction settings are "only" around 4-5mm. I don't know how Octoprint handles.the canceling though

[CraftoHohenvels]

I may have cracked it...

Looking at KnutWursts start code I can see that he is using M82 (absolute extruder position), while I have M83 (relative extruder position). I don't know how your firmware/Marlin 2 handles this, but I will look into that.

Judging by the fact that this command is about the extruder and my problem is related to the extruder...

Edit: this may also explain the retraction from my last message

[CraftoHohenvels]

Update on the Update on the Update on the Update:
I was right.

The error was actually caused by the Slicer generating gcode for the relative mode, while the firmware expects the absolute mode.
(I have more to say, but I am not at my laptop currently, so I will edit my message as soon as I am)

[CraftoHohenvels]

The problem I see now is not that the firmware has a problem, but rather that the documentation is lacking.
Although AnyCubic recommends UltiMaker Cure, I feel like many people rather go down the Slic3r path (so did I). In Prusa Slicer I created a profile based off the AnyCubic Mega S - problem is just that the default is the relative extruder mode, which doesn't seem supported in this firmware / Marlin 2. What makes this problem worse is that the original firmware (1.2.9) does actually accept the relative mode.

The only mention of the absolute mode is in the Start and Endcode section. If you don't mind I would like to rewrite the Beginners Guide - I would be able to edit the German and English version, then I would recreate a pull request.

[stklcode]

Well, Marlin 2 should support relative positioning, I'm not aware of anything that prevents you from using it.

To be honest I never cared about it, but my previous GCode files do have M82 (absolute) in the preamble, added by the slicer (Cura) automatically before the custom start code. I could have a look at some older stuff from different slicers, if there are some files left.

What leads you to the assumption that Marlin 2 does not support it? Didn't you write, v1.5.1 works fine with the same GCode? It's the very same Marlin 2.1.2.1 base as v1.5.2...

Also, if relative extrusion is unsupported, shouldn't the print job fail somewhere in the very first moves and not after a full layer?

[CraftoHohenvels]

As mentioned in this comment I tried it with a larger print in 1.5.1 and it didn't print it fully either. But after changing the extruder mode to absolute, the print is just fine - without changing anything else.

Edit: About the time of failure you are right, the proper wording would be that it doesn't behave as intended.

[stklcode]

OK, missed that one 👍

Still interesting, but good to know that there's a simple solution. I'll try to do a relative job next time I use my printer with updated core, but at least there's nothing about relative extrusion in the changelogs, so likely no better than 1.5.2

[CraftoHohenvels]

Unfortunately (probably for the better in terms of data integrity) I am not allowed to make changes to the Wiki. Therefore I would suggest my changes in this issue instead:

At the red line I would place the following:
German:

Bitte beachten: einige Slicer der Slic3r-Familie (einschließich PrusaSlicer und SuperSlicer) nutzen standardmäßig den "relativen Extruder Modus". Das bedeutet, dass der M83 Befehl im Startcode zu finden ist und in einigen Fällen ist die Option "Relative Abstände für Extrusion benutzen" eingeschaltet. Der M83 Befehl muss in diesem Fall durch den Befehl M82 (für den relativen Modus) ersetzt, der Befehl G92 E0.0 in dem Bereich "G-Code vor dem Schichtwechsel" entfernt und die Option "Relative Abstände für Extrusion benutzen" deaktiviert werden. Siehe folgende Bilder.

---

English:

Note: some slicers based off the Slic3r family (including PrusaSlicer and SuperSlicer) default to the relative extrusion mode. That means you will find the M83 in your custom Startcode and in some cases the option "Use relative E distances" is enabled. In this case the M83 command has to be replaced with M82 (to use the relative mode), the G92 E0.0 in the "Before layer change G-Code" has to be removed and you need to disable "Use relative E distances". See the image below.

[CraftoHohenvels]

A new, probably related, problem appeared... I have a larger print currently. The gcode was generated by Super Slicer by the same settings that printed my Benchy fine on this firmware just fine.

Now I have had a similar problem as observed in this comment. Mid print all the filament was retracted to a point where the print can't continue (the extruder no longer grips the filament, as it is too far out).

gcode:
TealightBunnyEgg.zip
slicer profile:
config.zip

[CraftoHohenvels]

As a last resort I will try UltiMaker Cura again...

[CraftoHohenvels]

Cura did Cura stuff and it turned out worse than Super Slicer or Prusa Slicer (aka no extrusion while taking random movement patterns). The profile is correct though, as it worked on the stock firmware

[CraftoHohenvels]

@stklcode if you don't mind may I send you my Slicer profile and you try to replicate my problems on one of your AMP? I use Super Slicer, but I can provide a config for Prusa Slicer too.

I am specifically referring to this issue and profile: #517 (comment)