Ummmmm!
It seems to work, holy wowzers! I just compiled a dual endstop build with no pin edits!!! I have to test this ASAP.
For those unsure of the excitement, this means all 5 driver boards can now do dual endstops by editing only two lines in config advanced. We used to have to go in and fudge the pins files for each individual board! Easy Peazy!
More exclamation points!!!
And such a simple change as well, sweet!
That is my git commit. Now I can strike that from my bucket list. :- ) To be honest though Thinkyhead (Scott) had done the majority of the work a couple of weeks ago, I just fixed a regression that stopped the build from compiling.
I’ve been running my LR2 for the past 2 weeks with EXTRUDERS=0. Makes it much easier since I’m using 5 drivers on my SKR 1.3. So this way I don’t have to mess with my pins file. Only config modifications required.
One thing I noticed is that octoprint will time out if the printer is idling since it doesn’t send temperatures (or anything). I simply configured a dummy bed thermistor and now it works.
THANK YOU SO MUCH!!!
Good to know, I will keep that as is then (170) until someone edits octoprint that is.
Freaking amazing, thank you so much, glad to have you around!
Well I’m glad to be part of this community. Really don’t want to take credit for this though - here’s one of Scott’s related commits. I actually think it’s great that Marlin’s maintainer is committed to making Marlin work for non-3D-printing CNC machines.
Okay, well I appreciate your part in it no matter how big or small, thank you.
Did you play with the octoprint settings? I know there used to be several focused on the temperature polling. But a dummy bed temp is NBD either.
I was able to make it work by setting “Max. consecutive timeouts while idle” to 0, but somehow I didn’t feel comfortable with that since octoprint might not recognize if the board crashed. Ideally the HOST_KEEPALIVE_FEATURE should be extended to send keepalive messages if there is no thermistor.
That makes sense. Might be worth a PR, although the parsers of that message might still fail to understand if there are no temperatures.
Oh man that is a huge improvement. Thank you so much! Time to recompile… again hehe
This is great. I must try this soon. Does anyone know if that means that all the redundant extruder-stuff disappears from the menu automatically?
Last time i compiled, i did quite some work, to remove extruder related menu items throughout the menu to keep it simpler.
Would be nice to not have to do that again.
I can not believe my eyes! I just applied this minimal patch to latest bugfix-2.0.x branch.
The patch basically sets #define EXTRUDERS 0 and configures basic dual X and Y stepper drivers.
Lo and behold it BUILDS! For both megaatmega2560 and LPC1768. No messing around in pins.h to lie to Marlin about the pins.
I should port over the rest of the config and flash this into my board.
The newest PR even sets some of the LCD to not be there with extruder=0…glorious days!
Ok, so I ported MPCNC ramps configs over and flashed this to SKR 1.3 board I’m testing now.
The good news is that it compiles, switching a board is as easy as changing one line in Configuration.h and extruder is gone from menus and the main screen. The FAN logo remains.
This is totally untested: The board I have does not have anything attached to it. I’ll dry-run some gcode on it and then will flash it to my old RAMPS board that actually has steppers connected to it.
Here’s a patch for the brave
PS! I saw that JUNCTION_DEVIATION is gone now and it got replaced with CLASSIC_JERK. I may send a PR later this week to update MPCNC configs to use the new #define.
That was the first of what I assume to be many more LCD tweaks that is why I have not updated. They are also scrambling to get some sort of release so I am probably going to hang back until they do that. This is when things usually get a little funky. On the horizon is also the laser tweaks we nee to use M3-5 so Kinda holding off for that as well. It looks more complicated but it is very closer to being solved.
And… drumroll … there is a bug and the entire thing crashes and resets when executing my beloved lion face gcode 
I guess I have to send the file from computer now to figure out at which line it happens :S
EDIT: 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 had the exact same expierince. I’m also running SKR V1.3 I’m pretty sure its not a specific line that does it. When my board crashes it is dependant on how fast i’m going. Sometimes my gcode runs all the way and sometimes not. If i turn up speed percentage, i get some jerky movements and pauses, and that is when it happens.
I confirm this. I’m hoping the fan will go away also. I mean, what use does the part cooling fan have, with no extruder??
I’ve noticed similar issues and have switched from JUNCTION_DEVIATION back to CLASSIC_JERK. I think there is an incompatibility with arc movements and JD (potentially in combination with the LPC1768 CPU and/or TMC drivers). For now this works.
How old is the version you are using? It seems there have been some changes to JUNCTION_DEVIATION lately
I’m on the latest commit as of yesterday.