-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
M600 "PAUSE_PARK_NO_STEPPER_TIMEOUT" not working #6979
Comments
It's not a bug so much as the nomenclature is a little confusing. If PAUSE_PARK_NO_STEPPER_TIMEOUT is enabled, then none of the steppers will timeout during a I could see how this might be a bit of a problem on a multi-extruder printer since |
Thank You! Of course what you just said makes sense! I knew the things you said but just didn't come to the right conclusion. |
OK, it seems I was expecting something different in behavior. |
@Lord-Quake That's odd. What version of Marlin are you running? |
Sorry, should have added that. I'm running 1.1.2. |
PARK_HEAD_ON_PAUSE only applies when you pause a print using Looking at the code in 1.1.2, I can't see why the X axis stepper would be deactivated. Does the Y axis stepper also get deactivated? |
Ok, just tested it once more. When the extruder is in park position both X and Y are freely movable. |
What can I do to further help out? I can't risk print jobs that run several hours if the X Y steppers aren't frozen while I change filament. |
I might be able to look into this further this afternoon.
|
@Lord-Quake can you zip up your Configuration.h and Configuration_adv.h files and add them to this issue? I just tried M600 with 1.1.2 on my printer and the steppers stayed active. |
Here they are.... |
I've looked through the configuration files, and I don't immediately see anything that would make the steppers shut off. Have you made any other changes to the code? I noticed some additions for the LCD, so it may be possible that there's some other change that's breaking One thing I did notice that the X_MIN_POS and Y_MIN_POS values set to negative numbers, but the MANUAL_[X|Y|Z]_HOME_POS values are still set to 0. I may not be thinking of it properly, but it seems not possible to be able to move in a negative direction after homing if you haven't also set a home offset. When the nozzle parks during |
First thanks for taking the time for analyzing the files! When M600 is executed the extruder parks at the defined location as set in the config (X3 Y3 Z+10). It does not hit the endstops. |
Doing a M600 on today's code base on a 'Normal' Cartesian (examples/gCreate gMax 1.5+) It holds the X & Y axis locked well after the nozzle times out and cools down. But I can't get the nozzle to re-heat. |
@Lord-Quake that's probably why we can't reproduce it. If you have a link to @oderwat's fork, I'm happy to take a look at it, but you should also let him know that it's broken in his fork. #Roxy-3D yes, |
Thanks @tcm0116 , I just verified and merged #6963. I think we still need to resolve if we can do something better than just 'Error Out' if the nozzle is too cold to do the M600. But like I say... M600 is working again. The reason doing more is difficult (at least for me) is because we don't know what temperature is 'suitable'. For some users, it is PLA temperatures. For others it might be ABS temperatures. For others, it might make sense to be the last hot temperature. We need a discussion to work through the corner cases. |
Some more info using Marlin 1.1.2 (Skynet fork): |
Did you mean:
|
Yes. I wonder why the word went missing :-) |
@Lord-Quake can you prove a link to exactly which branch in the fork your using? We are unable to replicate this issue using the base Marlin code, so it's likely that there's an issue in the forked code you're using. I'm happy to take a look at it, but you also need to report this issue in the fork that you're using. |
@tcm0116 I have. See reference link issue 17 (https://github.com/SkyNet3D/Marlin/issues/17) in this thread which is directed to the Skynet fork. I haven't gotten an answer their yet. |
Well. You should use https://github.com/SkyNet3D/Marlin/tree/SkyNet3D-Devel ... which is based on Marlin 1.1.3. Easiest way to spot an error is to check this commit: SkyNet3D@baf750f which is basically all the changes for the Anet board without changes to configurations for Anet printers. There are changes to |
I think I figured it out. It looks like the Anet A10 printer is based on the Sanguinololu 1.2 board. Looking at the pin definitions for that board, all of the stepper drivers share one enable pin (14). As such, when we disable the extruder drivers in How difficult is it on that printer to load filament with the extruder stepper powered and holding position? If it's do-able, then we can probably put something in that won't disable the extruder drivers if they share the same enable pins as the X and Y drivers. |
@tcm0116 Thanks for taking the time to look for a possible cause. It's very easy to change the filament on standard Anet extruders. In fact I had it set for manual unloading the reloading simply because I also wanted full control of the filament switch. |
@Lord-Quake I'll try to put something together tomorrow evening for you to try, if you wouldn't mind doing a little testing for me. |
@tcm0116 On the contrary. I'll gladly do any test you require! |
@Lord-Quake if you want to validate my theory, you can try the following steps:
|
@tcm0116 |
So we have a bug in M84 ??? |
I have a friend that calls these kinds of things "design features". There's a check in |
I think one way is to use the "#define MOTHERBOARD BOARD_ANET_10" as key and within the M600 code decide whether the steppers are to be deactivated or not. At least I'd use this as a workaround but I'm having difficulty finding the spot in the code where best I can add the "if" function :-/ |
I don't think that using a board identifier (which is not even available for the current Marlin version) can be a solution. There must be another way. If there isn't this needs to get an advanced config parameter imho. Skimming the code it tests E0 = X and E1 = Y pins and only accepts parameter "E" for "M84" if thats not the case. Which means all disable/enable stepper code does not check this at all. G28 X will disable all steppers if they share pins. As will calling So no, M84 has no bug. It does not what you think it does (it just don't allow E to work if shared pins are there). M600 can't work if the pin is shared. Solution for a general fix can only test for shared pins and avoid disabling all steppers (because there is no way that it does not harm if they are all disabled after homing). |
@oderwat that check I put in |
@tcm0116 I did not check your PR until now. Looks good to me 👍 |
For now I'd like to hard code the function to keep the steppers from disabling themselves when in M600 mode until a viable solution is presented. |
@Lord-Quake until #7048 is merged, you can use the following lines in
|
I just gave it a try and it worked fine. Thanks @tcm0116 However I came up with something new (unless it's already a known issue). |
@Lord-Quake if you're using SkyNet3D-Devel, it looks like it doesn't have #6963, which fixes that issue. You could try doing |
Thanks Thomas. I'll leave that to Oderwat who maintains the Skynet fork and wait for the next updated version. I just too unfamiliar on how Github works. |
@Lord-Quake I created a branch in my repository for you that is based on SkyNet3D-Devel, but also includes all the fixes in bugfix-1.1.x plus my changes in #7048. You can checkout that branch from my repository and copy your current configuration files, and it should work. Here's the URL for the branch: |
@Bob-the-Kuhn all I did was checkout SkyNet3D-Devel and then merge bugfix-1.1.x from Marlin and my changes from #7048. You're welcome to do whatever you'd like with it, but keep in mind that I didn't even try and compile it. I know for sure all of the changes to the configuration files would need to be reverted and new example confusion files created. Not sure about all of the other changes that were made. |
Thanks - I've created one without your #7048 changes. My biggest problem was getting the revert process to stop favoring the old Marlin code. |
@tcm0116 I downloaded your branch and gave M600 another try. However I did notice that with the Skynet fork I had |
Just for the records: The SkyNet3D fork is meant to be "rebased" on to of the latest Marlin branch. Not that the changes from there get merged on top of the skynet devel branch, which will make it all a big mess. All the changes for the Anet hardware which are meant to go into a PR are in one single commit. This is easy to see if you look at the commits here: https://github.com/SkyNet3D/Marlin/commits/SkyNet3D-Devel ... So basically the PR you are looking for to integrate the Anet stuff to Marlin is just the commit: SkyNet3D@baf750f ... + the configurations as examples. The configuration changes are in the following commit and needed to go to example configs for a PR to the original Marlin. It is mostly trivial to update (rebase) the SkyNet3D-Devel Branch to a new Marlin version. People don't seem to understand that and this all eats so much time :( As soon as the new stuff is in a Marlin release it cost me usually 15-30 minutes to create a new SkyNet3D Version which I then test with three displays and different sensors. |
@oderwat I didn't intend to make more work for you. I just wanted to put together something for @Lord-Quake so that he could check the changes to M600 on his printer. That branch in my fork is meant to be thrown away once #7048 makes it into bugfix-1.1.x, and I have no plans of creating a PR from that branch. |
OK. I am going to update SkyNet3D to 1.1.4 next. I followed bugfix in the past but had no testers while some users jumped on it and did not understand the implications :) |
The initial support is about ready over at #7016. Just waiting for my suggested changes to be added in, and then it can be merged. |
@thinkyhead any reason we can go ahead and merge #7048 so we can close this issue? |
It seems good. I will merge it now. |
@tcm0116 I appreciate it a lot for making a test branch and giving me the opportunity to test the code! @oderwat Let me know if you need me to test something on my A8 / full display for you in the future. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Marlin 1.1.2
When using M600 the extruder stepper will not hold position.
"ADVANCED_PAUSE_FEATURE" and "PAUSE_PARK_NO_STEPPER_TIMEOUT" are active.
Could this be a bug or am I missing something?
The text was updated successfully, but these errors were encountered: