OMG!!!!! Extruders = 0

Software / Firmware
41

Well, I do have the skill set but I don’t have the time right now :frowning: Nor a working in-circuit debugger setup to debug without good old “serial_echo” and/or shooting into the darkness.

Although I do have a few 32bit boards and a a surplus RPI Zero so in theory I don’t need to buy any new specialized debugging hardware: PiOCD and some wires routed to GPIO pins should be enough. Unfortunately most of this stuff is really finicky and takes a long time to set up.

1 Like
42

@anttix

I can’t replicate the issue. Have you tried my crown gcode on your boards with my firmware settings intact?

Looking at your lion gcode from the PR and I would not trust that. You have your rapids set really high, above my firmware max on both axis. That is also using sticky rates, which is also an extremely new feature of marlin that I am pretty sure only the users of Guffys fusion PP use. No slicers do that yet, and our estlcam and vectrix PP do not use it either.

43

No, I have not tried to run crown gcode with E0 setup, however I was able to crash the boards even with a smaller file. I’ll see if I can find it and post it later.

The gcode is what MPCNC Fusion 360 PP generates. I can regenerate with slower rapids to see if it makes a difference, however the gcode works w/o any problems if EXTRUDERS is set to 1.

EDIT: Looks like I may be able reproduce it with the crown. I flashed my E0 setup to RAMPS, executed G1 X100 Y100 by hand, load, print, monitor and it was stuck at 3.2% for ages, now it’s stuck at 9.5%. I need to do some more testing to see if it’s a stable repro and also update my ramps branch to the latest 2.0.x.

44

The 2.0.0 would probably be more useful, since 2.0.x is a moving target.

45

Well, 2.0.x is supposed to be the new stable branch vs bugfix-2.0.x which was used for development. Or am I mistaken? I guess I can build off a tag …

1 Like
46

Well, looks like the world regressed and E0 doesn’t compile any more.

Compiling .pio/build/megaatmega2560/src/src/module/planner.cpp.o
Marlin/src/module/configuration_store.cpp: In static member function 'static bool MarlinSettings::save()':
Marlin/src/module/configuration_store.cpp:792:40: error: 'unscalePID_i' was not declared in this scope
           unscalePID_i(PID_PARAM(Ki, e)),
                                        ^
Marlin/src/module/configuration_store.cpp:793:40: error: 'unscalePID_d' was not declared in this scope
           unscalePID_d(PID_PARAM(Kd, e)),
                                        ^
  In file included from Marlin/src/module/configuration_store.cpp:52:0:
  Marlin/src/module/temperature.h:101:34: error: '_PID_Kf' was not declared in this scope
   #define PID_PARAM(F,H) _PID_##F(H)
                                    ^
  Marlin/src/module/configuration_store.cpp:795:24: note: in expansion of macro 'PID_PARAM'
                          PID_PARAM(Kf, e)
                          ^
  *** [.pio/build/megaatmega2560/src/src/module/configuration_store.cpp.o] Error 1
47

I have a ramps extruders=0 branch up. Can you try that with no changes. I would like to figure this out but I can’t find an issue.

The fusion PP you are talking about was not made by me, Guffy uses the new sticky speeds which I do not feel are complete yet, we need a separate Z or to make the declaration anytime a Z vs XY Go or G1 is used. My older fusion PP declares a speed every line and using estlcam is the safest at this point for testing. I know other work but I believe in eliminating variables for such a major issue I think we should test with known good GCode.

49

I am seeing the same issue as Anttix. I am using 2.0.0 from Marlin, configured for an SKR board, using platform.io to build it.

I’d be OK trying another branch. Where is the ramps E0 branch?

50

Sure, I can flash that to my board once I get home to see if it makes a difference. My ramps tree with E0 is available here if some1 wants to try with their board. https://github.com/anttix/Marlin/tree/2367640567ec05f4ccad53c01c0e7f1f8347ead1

@vicious1 what’s the name of your E0 branch/repository? At first glance I didn’t find one from Allted/Marlin

51
52

I must be blind, what is the branch name? MPCNC_Ramps_T8_16T_LCD_32step_DualEndstop has EXTRUDERS 1 in the Marlin/Configuration.h …

1 Like
53

Well crud, I had changed them. My lack of Git-Fu must have reversed the change. My bad. I will need to test it again then.

54

PR to fix the compile error with latest 2.0.x https://github.com/MarlinFirmware/Marlin/pull/16108

55

The last commit I see in the ramps dual endstop branch is from Oct 23. Maybe push failed?

56

I just tried it with a vanilla 2.0.0 checkout and set EXTRUDERS=0 and #define EEPROM and it’s broken.

Looks like Anttix is ahead of me.

57

Did you commit, but not push?

58

Pushed my current work to https://github.com/anttix/Marlin/tree/mpcnc-e0 if you want to try. should compile for ramps out of the box, SKR probably needs a board changed. Includes configs identical to Ryan’s 413 configs, I haven’t diffe-d against 414 yet.

The only testing this tree has received is a build .

1 Like
59

Well no idea how that happened. I will have to look into it this evening after shipping.

60

I have a configured from 2.0.0 version of Marlin, configured for an SKR v1.3 (2209s) that I’m spinning up. I took your patch and set EXTRUDERS=0, and I was able to draw the crown just fine. No pauses, 2 minute run time.

It’s odd though, the CI on Marlin failed, in the SKR build, but it looks like it’s a network issue or something. Very odd.

At any rate, not a definitive test, but it’s at least something. I don’t run my machine often, but when I do, I hope it’s with EXTRUDERS=0 :slight_smile:

1 Like
61

Ok, so I did some more testing and it seems the issue is indeed not reproducible with latest Marlin on RAMPS. I also re-tested my old branch and it crashes and burns even with crown. This can mean either that some unrelated change fixed it or that timings changed in a way which makes it less likely to happen now. I have to do some more testing with other boards.

Here are the specific steps:

  1. platformio run -t upload -e megaatmega2560 --upload-port /dev/serial/by-id/usb-Arduino__www.arduino.cc__0042_55731323036351B00122-if00
  2. pronsole -e 'connect /dev/serial/by-id/usb-Arduino__www.arduino.cc__0042_55731323036351B00122-if00 250000'
  3. G1 X100 Y100
  4. load Test-Crown-12mms.gcode
  5. print
  6. monitor

Results:

Test-Crown-12mms.gcode 02:30
lion.gcode 36:17

36min runtime of lion.gcode is an expected improvement over old MPCNC_Ramps_T8_16T_LCD_32step_DualEndstop branch which used to take 52min to run the same file.

So the change that “fixed” it must be between these two git hashes:
git diff b3f81eead5179d70e4e205f3ff0c9a8617ad780d 4c261313eec206280e1c1163563e9fe62a89ea96

2 Likes