OMG!!!!! Extruders = 0

New Home Forum Software / Firmware Development OMG!!!!! Extruders = 0

This topic contains 29 replies, has 8 voices, and was last updated by  Ryan 3 days, 1 hour ago.

Viewing 30 posts - 1 through 30 (of 30 total)
  • Author
    Posts
  • #115874

    Ryan
    Keymaster

    Ummmmm!

    https://github.com/MarlinFirmware/Marlin/commit/4564ad292048e3aae530d693304b589dd2905e6e

     

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

    1 user thanked author for this post.
    #115878

    Bill
    Participant

    And such a simple change as well, sweet!

    1 user thanked author for this post.
    #115885

    Frederik
    Participant

    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.

    4 users thanked author for this post.
    #115889

    Ryan
    Keymaster

    THANK YOU SO MUCH!!!!!!

    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.

    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!

    #115892

    Frederik
    Participant

    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.

    2 users thanked author for this post.
    #115899

    Ryan
    Keymaster

    Okay, well I appreciate your part in it no matter how big or small, thank you.

    #115936

    Jeffeb3
    Participant

    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.

    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.

    #116077

    Frederik
    Participant

    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.

    #116081

    Jeffeb3
    Participant

    That makes sense. Might be worth a PR, although the parsers of that message might still fail to understand if there are no temperatures.

    #116341

    Sean
    Participant

    Oh man that is a huge improvement.   Thank you so much!  Time to recompile.. again hehe

    1 user thanked author for this post.
    #116352

    Migger
    Participant

    …do dual endstops by editing only two lines in config advanced.

    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.

    #117359

    Anttix
    Participant

    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.

    1 user thanked author for this post.
    #117361

    Ryan
    Keymaster

    The newest PR even sets some of the LCD to not be there with extruder=0…glorious days!

    1 user thanked author for this post.
    #117379

    Anttix
    Participant

    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.

    #117380

    Ryan
    Keymaster

    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.

    #117469

    Anttix
    Participant

    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.

    • This reply was modified 1 week, 1 day ago by  Anttix.
    1 user thanked author for this post.
    #117486

    Migger
    Participant

    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

    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.

    extruder is gone from menus and the main screen. The FAN logo remains.

    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??

    1 user thanked author for this post.
    #117487

    Frederik
    Participant

    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.

    #117492

    Migger
    Participant

    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

     

    #117553

    Frederik
    Participant

    I’m on the latest commit as of yesterday.

    #117557

    Jeffeb3
    Participant

    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 user thanked author for this post.
    #117559

    Anttix
    Participant

    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.

     

     

    • This reply was modified 1 week, 1 day ago by  Anttix.
    #117561

    K Cummins
    Participant

    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.

    • This reply was modified 1 week, 1 day ago by  K Cummins.
    #117563

    Anttix
    Participant

    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.

    I can confirm that it’s random and there is no specific line it crashes at.

    #117565

    Anttix
    Participant

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

    #117614

    Anttix
    Participant

    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.

    • This reply was modified 1 week ago by  Anttix.
    #117680

    Frederik
    Participant

    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 user thanked author for this post.
    #117926

    Anttix
    Participant

    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 https://github.com/MarlinFirmware/Marlin/issues/15567

    #117930

    Anttix
    Participant

    Created a PR to address the issue with pronterface / octoprint refusing to connect

    https://github.com/MarlinFirmware/Marlin/pull/15568

    EDIT: This is now merged. Big thanx to @thinkyhead thinkyhead for merging this super quick.

    • This reply was modified 4 days, 8 hours ago by  Anttix.
    #118118

    Ryan
    Keymaster

    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.

Viewing 30 posts - 1 through 30 (of 30 total)

You must be logged in to reply to this topic.