M600 "PAUSE_PARK_NO_STEPPER_TIMEOUT" not working

[Lord-Quake]

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?

[Roxy-3D]

Yes.. It can be a bug. But the person that just recently updated M600 here: #6407 is very careful.

Please get more detail and try a few permutations of M600 and report all of the details.

@tcm0116 Is the because there are open Pull Requests that we have not merged?

[tcm0116]

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 M125 pause command. However, the extruder steppers will always be disabled during M600 in order to facilitate changing of the filament. This is by design because it can be very difficult on a lot of printers to load filament with the extruder stepper motor powered on.

I could see how this might be a bit of a problem on a multi-extruder printer since M600 only really applies to the active extruder. A possible improvement would be to only disable the active extruder in M600 rather than all of the extruders, but probably only on machines without mixing extruders (not sure why you'd want to do a M600 with a mixing extruder, but someone probably would want to).

[Roxy-3D]

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.

[Lord-Quake]

OK, it seems I was expecting something different in behavior.
In the code it states:
"#define PAUSE_PARK_NO_STEPPER_TIMEOUT // Enable to have stepper motors hold position during filament change
// even if it takes longer than DEFAULT_STEPPER_DEACTIVE_TIME."
which tells me that all steppers are kept active (on) even after DEFAULT_STEPPER_DEACTIVE_TIME has been reached.
However in my case as soon as the extruder carriage reached it's parking position for filament change I was able to move the carriager in x-axis which obviously was destructive.
My expectation was and is that all steppers (alternatively with the exception of the extruder stepper because it is not relevant for extruder carriage movement) are frozen while the filament is being changed.

[tcm0116]

@Lord-Quake That's odd. What version of Marlin are you running?

[Lord-Quake]

Sorry, should have added that. I'm running 1.1.2.
Since you are saying that it's odd then I must assume you are sure that it should work.
So I looked add the settings once more....
"ADVANCED_PAUSE_FEATURE" and "PAUSE_PARK_NO_STEPPER_TIMEOUT" are active or else M600 wouldn't be working.
However inside "ADVANCED_PAUSE_FEATURE" the define "//#define PARK_HEAD_ON_PAUSE" is inactive. Could this be the culprit?

[tcm0116]

PARK_HEAD_ON_PAUSE only applies when you pause a print using M125 or if you pause a SD print from the LCD, so it shouldn't have any bearing on this issue. Are you printing from SD or from a host?

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?

[Lord-Quake]

Ok, just tested it once more.
I am using host with no SD inserted in the printer.

When the extruder is in park position both X and Y are freely movable.

[Lord-Quake]

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.

[tcm0116]

I might be able to look into this further this afternoon.

[tcm0116]

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

[Lord-Quake]

Here they are....
Configuration_adv.zip

[tcm0116]

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

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 M600 does the printer hit the endstops?

[Lord-Quake]

First thanks for taking the time for analyzing the files!
The code I'm using is a fork for the Anet printers made by @oderwat
The only files I have changed are the two configs. The lines I changed are stamped with "-Leo". The rest is default.

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.

[Roxy-3D]

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.

[tcm0116]

@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, M600 is currently broken. I submitted #6963 a few days ago to fix it, but it's waiting for a re-review.

[Roxy-3D]

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.

[Lord-Quake]

Some more info using Marlin 1.1.2 (Skynet fork):
Today I had the SD card active to see if there is a difference in behavior.
Ran my test code. As soon as the extruder came to park position I immediately was to move both X and Y axis.

[Roxy-3D]

Did you mean:

As soon as the extruder came to park position I immediately was able to move both X and Y axis.

[Lord-Quake]

Yes. I wonder why the word went missing :-)

[tcm0116]

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

[Lord-Quake]

@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.
I'm using (Update of SkyNet3D to Marlin 1.1.2 stable release): https://github.com/SkyNet3D/Marlin/archive/SkyNet3D-V2.4.4.zip

[oderwat]

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 temperature.cpp and temperature.h which may be the culprit even with me not noticing what the error could be. Probably there is some dependency of the state which is not kept by how I added the ADC code. This is what I would check if I had more time right now.

[tcm0116]

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 M600, the X and Y stepper drivers are also disabled.

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.

[Lord-Quake]

@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.
Your suggestion would be a very good solution!

[tcm0116]

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

[Lord-Quake]

@tcm0116 On the contrary. I'll gladly do any test you require!

[tcm0116]

@Lord-Quake if you want to validate my theory, you can try the following steps:

1. Send G28 to the printer to home
2. Verify all steppers are holding position after the homing is complete (including extruder)
3. Send M84 X to the printer to attempt to only disable the X axis stepper
4. Verify that all of the steppers are no longer holding position (even though we only commanded the printer to disable the X axis stepper)

[Lord-Quake]

@tcm0116
Update:
Did the test twice. Steppers held position after G28. When M84 X command was sent ALL steppers no longer held position.

[Roxy-3D]

So we have a bug in M84 ???

[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 M84 that won't disable the extruder if it shares the same enable like as the X stepper, but doesn't have similar checks for X, Y, or Z. I'm not sure of the best way to handle this in a generic fashion.

[Lord-Quake]

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 :-/

[oderwat]

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 disable_e_steppers(). So M600 would need to check for shared enable pins too. Skimming the code I don't see anything like that.

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

[tcm0116]

@oderwat that check I put in M600 was copied directly from M84 when E is passed as a parameter. My guess is that most boards either have individual enable lines, two enable lines (one for extruders and another for XYZ), or just one enable line for all of the steppers. If that assertion is true, then the check from M84 that I used in M600 will work.

[oderwat]

@tcm0116 I did not check your PR until now. Looks good to me 👍

[Lord-Quake]

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.
Where in the code would I do this? Thanks.

[tcm0116]

@Lord-Quake until #7048 is merged, you can use the following lines in pause_print:

// Disable extruders steppers for manual filament changing (only on boards that have separate ENABLE_PINS)
#if ((E0_ENABLE_PIN != X_ENABLE_PIN) && (E1_ENABLE_PIN != Y_ENABLE_PIN))
  disable_e_steppers();
  safe_delay(100);
#endif

[Lord-Quake]

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).
After waiting the 45 sec timeout (I wanted to see what would happen with the steppers) the LCD changed to heating nozzle... but the temperature kept going down and I couldn't do anything. I was forced to hard reset the printer.

[tcm0116]

@Lord-Quake if you're using SkyNet3D-Devel, it looks like it doesn't have #6963, which fixes that issue. You could try doing git pull bugfix-1.1.x https://github.com/MarlinFirmware/Marlin.git to try and merge the latest from the Marin bugfix-1.1.x bench into your sandbox. I'm not 100% sure about that command, so make sure you backup your configuration files if you don't have them committed.

[Lord-Quake]

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.

[tcm0116]

@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:

https://github.com/tcm0116/Marlin/tree/SkyNet3D-Devel

[Bob-the-Kuhn]

@tcm0116 - we're planning on merging SkyNet3D-Devel into bugfix-1.1.x.

Is your branch a complete integration of the two?

If yes, do you mind if we use your branch in PR #7016? That would save us a bunch of work.

[tcm0116]

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

[Bob-the-Kuhn]

Thanks - I've created one without your #7048 changes.

My biggest problem was getting the revert process to stop favoring the old Marlin code.

[Lord-Quake]

https://github.com/tcm0116/Marlin/tree/SkyNet3D-Devel

@tcm0116 I downloaded your branch and gave M600 another try.
Extruder went into park position. I then waited longer than 45 sec after which the extruder started to cool down. Pressed the button to reheat. After heat was reached pressed button to continue. LCD gave appropriate notifications in all cases. The steppers always stayed active through the whole process. Conclusion: 100% success 👍

However I did notice that with the Skynet fork I had

used storage space.
With your modifications it now comes to

which is getting real close to the limit :-(

[oderwat]

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.

[tcm0116]

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

[oderwat]

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 :)

[thinkyhead]

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.

[tcm0116]

@thinkyhead any reason we can go ahead and merge #7048 so we can close this issue?

[thinkyhead]

It seems good. I will merge it now.

[Lord-Quake]

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

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

[github-actions]

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.