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
Abort command in load.g or unload.g filament macros changes filament, as it was correctly loaded/unloaded #437
Comments
forget abort, you can't even change filament without it resetting |
You mean the error present in latest beta release? It has already been fixed for the next beta release |
Yes, so how are you testing this without it resetting? |
I'm using latest working release and, since I haven't found anyone reporting this bug, I assumed that it wasn't fixed yet |
you're running 3.1.1? |
Yes, 3.1.1, last stable release |
I found out that if the tool is deselected (with T-1) at the time the load/unload macro ends, the filament won't change its state. So, if you do T-1 before calling abort, it works fine. |
This issue is present in This also happens if your macro contains EDIT |
Closed as M99 is the correct approach - see the forum thread. abort commands are not supported at this point in system macros. |
If an abort command is called when loading or unloading a filament (both with M701 or M702 and with the Duet Web Control), Duet will then change the filament name of the associated tool, as the filament was correctly loaded or unloaded. A very strange behavior happens, instead, when an error (such as G0/G1: insufficient axes homed) is thrown: in this case the filament name is not changed. The problem happens both if the abort command is inside load.g/unload.g file and if it is inside a nested macro called by load.g/unload.g.
The text was updated successfully, but these errors were encountered: