I think posting issues on the Marlin github makes some sense here. They are furiously trying to finish up 2.0, it would be good for them to know what the issues are for CNC users. Things like certain gcodes causing crashes when extruders=0 might be really useful testing feedback for them.
1 Like
Turning off ADAPTIVE_STEP_SMOOTHING resolved the crash but the thing is slooooooooow now. The gcode that used to take 48min on Marlin now takes 4h 50min. Clearly something is seriously wrong with the motion planner. I’ll do some more digging before I report this to upstream.
I am not sure arcs have much to do with that. The gcode I’m running has no G3/4-s in it. I generated this way from Fusion so I could test with Klipper which doesn’t support arcs. I’ll post my klipper experiences to the klipper thread once I’m ready to share 
EDIT: Correction. Klipper does support arcs but only the J variety and doesn’t like it at all if one of the x/y coordinates is not specified. I know, I should report this to klipper github and I will.
Gut reaction is that it’s tied up with #15513, but because there’s no extruders, it’s trying to do some impossible maths to compute extrusion rates and therefore goes tits-up.
But that’s just a guess from a guy who’s bored, waiting out the last hour or so of work…
ETA: Further guess: when your speeds and feeds are slow enough, the firmware JD never really kicks in, but when you’ve got things cranked up, the firmware starts trying to compensate for your hell-bent-for-the-leatherboys speed, and the JD code isn’t clued in that you’ve emasculated your “printer”, and is trying to twiddle about with non-existent extruder data.
I can confirm that it’s random and there is no specific line it crashes at.
Does any1 here know how linux_native target is supposed to work? I get a binary that reads gcode from stdin. Are there any other tricks to using this? I assume I have to wire it up to a pty to persuade pronsole or octoprint to “connect” to it.,
Update: I think I have this narrowed down to some bad interaction between junction deviation, S_CURVE_ACCELERATION and EXTRUDERS=0
Disabling S_CURVE_ACCELERATION or switching to CLASSIC_JERK seems to work around the problem.
I’m not even certain if bezier curve acceleration mode is compatible with junction deviation. I can’t find anything from the docs about this.
I’ve filed a bug in the Marlin github. My machine’s behavior is a bit different and it’s really the arc moves that are most visibly problematic.
1 Like
I did a lot more testing with a RAMPS board as well. Looks like the EXTRUDERS == 0 doesn’t only interfere with S_CURVE_ACCELERATION, it also messes up dual end-stop steppers mode.
I’d call it unusable at this stage 
Filed a bug here [BUG] Can't use EXTRUDERS == 0 · Issue #15567 · MarlinFirmware/Marlin · GitHub
Created a PR to address the issue with pronterface / octoprint refusing to connect
EDIT: This is now merged. Big thanx to 
Well the PR log is getting low (16) so maybe this sort of stuff will get looked into. I am really not sure how to even dig into the planner, it is pretty far above my coding abilities at the moment.
Not sure if anyone else has ran into this but I recently ( two days ago ) setup Marlin again from scratch with the only different between it and my current firmware being the use of extruders=0 and ran into an issue where one of my Y motors was not always spinning with the other. I quadruple checked all of my wiring, motor drivers, motors ( swapped them around with known OK ones ) and always had the issue. It would randomly happen in the middle of a milling job and tweak my frame. I finally got fed up with making config changes ( basically guessing at fixes ) in Marlin and simply recompiled / uploaded my older version of the firmware and the problem stopped. Part of me is hoping that it is just my setup but part of my hopes it is actually a Marlin issue so I don’t have to keep diagnosing.
I let me machine do a dry run on a 30 minute job last night with the older version of the firmware and did not experience the issue so I am leaning towards it being an issue with Marlin.
Just a heads up to anyone trying this out to keep a close eye on their motors to make sure they are staying in sync for the first few runs. Mine would normally get out of sync about 5 minutes in.
Things I checked:
- motors
- motor drivers
- motor wires
- pin settings in Marlin
- software endstop limits not being triggered
- hardware endstops not being trigger
- motor drivers not over heating ( I have 5160s so they barely warm up as it is )
- only changes made in Marlin were ones that mimicked the older version of the firmware minus the pin changes needed before extruders=0 was an option
Marlin 2.0.x-bugfix still has some serious bugs and does not work correct when you set EXTRUDERS = 0 !
On my ATmega 2560 based board and I have 5 stepper drivers available and I want to use one for each the 5 motors of the MPCNC instead of putting two motors on one driver.
As soon as I set EXTRUDERS to 0 the steppers sometimes run correct and sometimes at about 1/100 of the speed.
Totally unacceptable for a CNC machine.
My solution was:
Leave the EXTRUDERS set to 1, otherwise the results are unpredictable!
To be able to still use the 5 individual stepper drivers and not to lose one driver as an extruder I did the following:
I have assigned extruder E0 (the first one) to digital pins that are unused on my board. This makes Marlin happy.
Now I used the original E0 pin numbers for E1 and the original E1 pin numbers for a new E2.
By enabling X_DUAL_STEPPER_DRIVERS and Y_DUAL_STEPPER_DRIVERS all stepper drivers are now working.
CH, that is exactly what the dual endstop firmware does now. The benefit of E=0 is that someone with another board can figure it out a lot easier. I suppose too, that something like the lcd changing for E=0 wpuld be nice, too.
Yeah, EXTRUDERS == 0 is terminally broken ATM. Marlin folks even closed my issue with a blunt statement that it’s been reported before and not supported. From the issues that are still open on the topic, it has been described as an effort that would take a gloomy weekend of gruntwork to make progress.
Do you know where the other issues are he’s referring to?
I would think [FR] Allow Zero Extruders · Issue #10212 · MarlinFirmware/Marlin · GitHub
Two stale PR-s mentioned in a related PR:
This has of course been attempted many times, and it’s a good project for a long weekend. There are many, many places where code needs to be altered to handle
EXTRUDERS == 0.
See #9074, #9091 for two somewhat stale PRs which aim to accomplish the same thing. You may want to start with one of those since they already cover many —if not most— of the needed changes.
1 Like
Someone should remind them that this weekend is a long weekend (at least in the US 
).
1 Like
Those PR’s are from before it was Merged and should be closed. This is some sort of new issue.
From what I get there have been a number of PR-s but none of these were actually considered “complete” . Comment on #9091 from Apr 10-th
The work required simply to support zero extruders is vast and sweeping, and will require many PRs over a long period of time. This cannot be considered a complete PR, and it is far out of date. Anyone who wants to apply a change here or there to move Marlin towards allowing zero extruders should please feel free to do so. Once all needed changes are applied Marlin will then be able to build with no extruder tools.
I guess the progress made so far is that Marlin now compiles with EXTRUDERS == 0. However if I look at what files these PR-s touched, some of the files have not received the changes. For example Stepper::set_directions is still the same. I don’t know the codebase well enough to understand if these changes were actually needed or not. However given the feature request is still open and the response to my bug report, it seems like Scott does not consider zero extruders support to be complete and as such it’s not expected to work.
1 Like
Bummer. I really don’t think I have the skill set to trouble shoot or try to come up with a solution…yet. I really want this to work so If I get some free time I might try to dig in.
1 Like