Skip to content
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

Disabled acceleration control still applies to print #1537

Closed
nwgruber opened this issue Sep 9, 2021 · 2 comments
Closed

Disabled acceleration control still applies to print #1537

nwgruber opened this issue Sep 9, 2021 · 2 comments
Labels
bug Something isn't working as intended fix is live in the last release Please download /build the last release and try to reproduce.

Comments

@nwgruber
Copy link

nwgruber commented Sep 9, 2021

Describe the bug
When I disable acceleration control by setting the default to 0, the additional acceleration parameters (perimeters, travel, etc.) are still applied to the print if left nonzero. Seeing as these input fields are disabled after default acceleration is set to 0 I don't think this is intended behavior.

To Reproduce
Steps to reproduce the behavior:

  1. Enable acceleration control if turned off by setting default to some value
  2. Assign a value to one of the other acceleration parameters (perimeters, infill, etc.)
  3. Disable acceleration control by setting default to 0
  4. Slice and print a model
  5. Check the acceleration value on your printer

Expected behavior
When acceleration control is disabled and all the other fields are greyed out, I expected that they would not be applied to the print. In my screen shot below, the greyed out travel acceleration value would still be applied to the print.

Screenshots
image

Desktop (please complete the following information):

  • OS: Windows 10
  • Version 2.3.57
  • Using klipper gcode flavor
@Laker87
Copy link

Laker87 commented Sep 9, 2021

Same

@supermerill supermerill added the bug Something isn't working as intended label Sep 9, 2021
@gpread
Copy link

gpread commented Sep 9, 2021

Yes I have seen this also but.... I saw it with prusaslicer (I think 2.3.1), so I suspect this is an inherited bug. I didn't report it since it was easy enough to get around (setting all the other entries to zero before setting default to 0).

@supermerill supermerill added the fixed for the next version That means that you should be able to test it in the latest nightly build label Sep 26, 2021
@supermerill supermerill added fix is live in the last release Please download /build the last release and try to reproduce. and removed fixed for the next version That means that you should be able to test it in the latest nightly build labels Oct 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working as intended fix is live in the last release Please download /build the last release and try to reproduce.
Projects
None yet
Development

No branches or pull requests

4 participants