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!
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.
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.
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.
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.
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.