Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Change in default for runout sensor is a breaking change, makes old slices missing runout detection #19

Closed
joesanford opened this issue Oct 25, 2020 · 4 comments

Comments

@joesanford
Copy link

joesanford commented Oct 25, 2020

Description

In Community Release 3 the default for the runout sensor was changed from enabled to disabled. For those of us with functioning runout sensors, this is a breaking change if we were to upgrade to the new firmware, or we have to re-slice any old models we already have.

This is a proposal to revert 6d5bdd5, and update documentation fo those with filament runout sensors to add the correct gcode to their slicer configuration. Additionally, while the flag was flipped, the in-line comments were not, so there is now a disconnect.

@joesanford joesanford changed the title Change in default for runout sensor is a breaking change, makes old slices useless Change in default for runout sensor is a breaking change, makes old slices missing runout detection Oct 25, 2020
@Sebazzz
Copy link
Collaborator

Sebazzz commented Oct 25, 2020

For those of us with functioning runout sensors, this is a breaking change if we were to upgrade to the new firmware, or we have to re-slice any old models we already have.

This is a breaking change only if updating from Creality firmware.

By creating a gcode file with:

M412 S1
M500

and "printing" this file is easily and "permanently" enabled.

It is currently disabled by default because some members (@nickacker among others) had issues with filament runout and needs more testing before I want to enable by default.

@joesanford
Copy link
Author

joesanford commented Oct 25, 2020

I understand the motive and reasoning behind the change, but what I don't get is the motive for making a change that breaks backwards compatibility with code previously sliced for this printer. Especially when you also say this is something that will eventually change. (I understand the fix for those of us with functioning sensors now, but the release notes weren't as clear as your comment)

IMO those with broken sensors should be doing a workaround in the meantime, instead of disabling functionality for those with functioning hardware. This is a very backwards and confusing approach to a problem like this.

e: if you do want to make compatibility-breaking changes in the future, I highly recommend moving them to their own section so it's called out. Had a few people on the FB and reddit groups with the same issue. Thankfully, I didn't hit a runout today.

I'm also a bit confused by "This is a breaking change only if updating from Creality firmware", as this change was mentioned only in the release notes for Release 3. Does this mean it wasn't changed between Release 2 and 3?

Apologies if I'm coming off rude or defensive, I just get a bit concerned given the issues so far with the printers. Maybe sticking to stock firmware for now is best for me.

@nickacker
Copy link

As the development of the community firmware continues, we will attempt to make the best efforts to ensure backwards compatibility with previous slices. In this case we found the majority of use cases simply dont need the runout detection for now and as such until it can be detected properly and resumed properly, we've simply turned it off on the startup of the machine.

This is untested(but should work just fine), using pronterface or other machine interface, you can send M412 S1 to turn the setting back on, and then M500 to save it permanently which will restore your previous slice run out detection and future as well.

If you dont have a machine interface. You can also create a basic text file with these two lines. Then rename it to a .gcode file and have the printer 'print' this file which will renable and save your runout state.

@joesanford
Copy link
Author

Thank you for providing a solution until runout sensor hardware is fixed for everyone.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants