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.

Sign up for GitHub

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

Jump to bottom

Make the export of "Machine limits" into the G-code optional #1212

Closed
Hal1949 opened this issue Sep 8, 2018 · 30 comments
Closed

Make the export of "Machine limits" into the G-code optional #1212

Hal1949 opened this issue Sep 8, 2018 · 30 comments

Comments

@Hal1949
Copy link

Hal1949 commented Sep 8, 2018

Version

Slic3rPE-1.41.0+win32

Copyright © 2016-2018 Prusa Research.
Copyright © 2011-2017 Alessandro Ranellucci.
Slic3r is licensed under the GNU Affero General Public License, version 3.

Operating system type + version

Windows 7 Ultimate SP1

Behavior

All appears to function well up to the point of clicking on the PRINT button. Bed and Hotends heat up as should, but when the bed temperature reaches it's set temp and then HOME. This is where the problem is. The Z-axis when it tries to home, approx. 12mm from home position the stepper motors make a squealing sound for approx. 3-seconds. Then when the head moves to the part position the nozzle is approx. 12mm above the plate. This is consistant.

Version 1.40.1+win32 does not do this, so I reverted back.
@nessatse
Copy link

nessatse commented Sep 9, 2018

Ran into the same problem today. Your default feedrates and acceleration are now being overridden by the values in Printer Settings->Machine Limits. Edit those to correspond to your own printer and the problem should be fixed.

There should really be an option to disable this new feature

@Sebastianv650
Copy link

Sebastianv650 commented Sep 9, 2018 •
edited

Your default feedrates and acceleration are now being overridden by the values in Printer Settings->Machine Limits. Edit those to correspond to your own printer and the problem should be fixed.
There should really be an option to disable this new feature.

Similar request as #1202. I also vote for a "disable" switch regarding the gcode generation. For example a drop down menu with the choice "Overwrite FW limits" and "Use values for time calculation only". While it's very handy we can enter all the limits to get a good print time estimation, I don't want the gcode overwriting my machine settings.

There are multiple reasons for that:

  • Tweak settings (after moding the printer or just for beeing curious): It's much simpler to use one test gcode, changing the settings on LCD between test prints.
  • Hard to find error source: As users are used to change this settings via FW (LCD or source code), they might not even notice why their changes don't result in print quality changes as the gcode overwrites the settings in a silent way.
  • Compatibility with recent and future FW versions: For example the meaning and even the handling of "jerk" has changed already at least once during time. Remeber the change where Marlin moved to Prusa FW way of calculating jerk, basicaly meaning a jerk of 10 now has the value of 5 to result in the same movements. Now we have junction deviation, where the term jerk isn't even existing any longer, instead we have a junction deviation value in mm. Another example would be the often requested seperate limit for extruder max. speed and / or acceleration for retraction and prime moves, if this comes to reality.
    In this cases the user most likely also wants to have a time estimastion, and even when the estimation might not be 100% true it can still be better than anything else if you enter some kind of equivalent values into Slic3r. But the gcodes generated might even confuse the FW in some way.

@Hal1949
Copy link
Author

Hal1949 commented Sep 9, 2018 via email

@Hal1949
Copy link
Author

Hal1949 commented Sep 9, 2018 via email

@bubnikv bubnikv changed the title Slic3rPE-1.41.0 Make the export of "Machine limits" into the G-code optional Sep 27, 2018
@bubnikv bubnikv mentioned this issue Oct 11, 2018
Closed
@drdelaney
Copy link

I understand this helps with time estimates, but I honestly never trusted them 100% anyways, and only used it as a rough idea.

I am also in favor of a toggle to disable these, as I found this also was impacting my printer. (Heats up bed, goes to start my level probe, makes a "quick movement" and just stops.). I now realized that it was actually homing, just very-very-very-very slowly, which is odd because it was using the default numbers. I had to do a reset on the controller and management software due to it not responding to any other request. I removed the lines at be beginning that are from these settings, and everything works just as expected.

@dumski
Copy link

dumski commented Dec 31, 2018 •
edited

Hello, I also think it's a good idea. The machine limits causes my printer to override default values (saved in EEPROM) which are safe for my printer. It wouldn't be such a big problem when it can be ovverriden only by lowering limits. It would affect only printing time. But since it changes also upper limits to even higher, I have always to copy the same values from EEPROM to "Machine limits" section in Slic3r. This causes calibration and tunning the printer more unpredictible.

@bubnikv
Copy link
Collaborator

bubnikv commented Jan 2, 2019

@drdelaney

I am also in favor of a toggle to disable these, as I found this also was impacting my printer. (Heats up bed, goes to start my level probe, makes a "quick movement" and just stops.). I now realized that it was actually homing, just very-very-very-very slowly, which is odd because it was using the default numbers. I had to do a reset on the controller and management software due to it not responding to any other request. I removed the lines at be beginning that are from these settings, and everything works just as expected.

What machine, what firmware? Maybe you have a wrong firmware type selected in Slic3r?

@drdelaney
Copy link

@bubnikv

What machine, what firmware? Maybe you have a wrong firmware type selected in Slic3r?

A custom Prusa i3 Clone, running RAMPS 1.4 with Marlin 1.1.9. This happened with Marlin 1.1.8 too believe (been a while since I first noticed it and found out the problem). I made sure to have the correct option chosen for Marlin as my firmware type. I compared a sliced gcode with the same settings between the .39 and .41 and the only difference was the first few lines which overrode the settings in question.

@bubnikv bubnikv mentioned this issue Apr 13, 2019
Closed
@bubnikv bubnikv mentioned this issue May 23, 2019
Closed
@sigwinch28
Copy link

sigwinch28 commented Jun 26, 2019 •
edited

Any update or progress on this? I'm using a Duet and it is becoming somewhat tedious to remove these lines from every gcode file.

Edit: Switched the firmware flavour to RepRap and it seems to no longer be inserting this code.

@bubnikv
Copy link
Collaborator

bubnikv commented Jun 27, 2019 via email

@thierryzoller
Copy link

This heped me in 2020, please make a button to reset/remove Machine Limits.
Took 30 minutes of my life to find this hack to solve my problem.

@SonBroku
Copy link

Yeah, we shouldn't have to change our gcode flavor to a firmware we aren't using to avoid having the slicer mess with our movement settings. Especially since the way it's formatting M204 isn't correct for current marlin. It's using M204 S which is depreciated, making it impossible to use a faster travel acceleration without this weird workaround.

@Schokobecher
Copy link

Still nothing new on the matter... back to Cura I guess.

@VanessaE
Copy link

VanessaE commented Sep 17, 2020 •
edited

I don't understand why this is so controversial? Just let us disable/omit the machine limits from the g-code, without resorting to hacks like switching the firmware setting.

@neildarlow
Copy link

Because it has more utility than disadvantage.

If you copy the firmware defaults into the slicer then the effect is to apply the same settings. You can then tweak those settings from a convenient screen on a per-printer basis.

While disabling the generation of the machine limits gcode forces the use of the firmware defaults, who's to say those are optimal?

@Schokobecher
Copy link

@neildarlow
It's a choice - simple checkbox called "Generate Machine Limits in GCode", tick it by default, hide it in the "Advanced View" and be done with it.
Why force something that a percentage of people simply don't want, for various reasons?

@drdelaney
Copy link

While disabling the generation of the machine limits gcode forces the use of the firmware defaults, who's to say those are optimal?

The firmware settings on my printer were a heck of a lot more optimal than the prusa slicer defaults that I ignored when I first set up my profile.
First print with the updated slicer that forced the settings sent me on a few hour diagnostics trip when my printer tried to home, but then sat there doing "nothing", or so I thought. It was moving extremely slow. On the magnitude of (probably not exactly, but close to) 1mm a minute.
Moving the settings from firmware to the slicer did infact fix the problem, the first thing I looked for was the obvious "there has to be a way to disable this setting" option, which didn't exist.

If someone else writes the patch to add this option in, would it be accepted so this can be closed and we can move on?

@VanessaE
Copy link

Because it has more utility than disadvantage.

If you copy the firmware defaults into the slicer then the effect is to apply the same settings. You can then tweak those settings from a convenient screen on a per-printer basis.

While disabling the generation of the machine limits gcode forces the use of the firmware defaults, who's to say those are optimal?

That's why printer controllers have EEPROM (or some emulation of it).

When you're fine-tuning a new, rebuilt, or refurbished machine, or even just making tweaks after a minor change like replacing the nozzle or part fan, it's highly useful to be able to slice a test object just once, and then re-print over and over, sending commands just before or during each run to fine-tune things.

Your preference has the user either editing the g-code file to get rid of the machine limit lines, or re-slicing/exporting/reloading after making each change by the GUI, which inevitably leads to conflicts between the settings saved in the EEPROM, those enforced by the machine limits screen, and what the user has changed in realtime -- something WILL get botched, as most of those settings are saved with M500. And that's just when working with one model, to say nothing of switching among several (like if you've collected a nice "test suite").

And as mentioned earlier, some of the settings enforced there are obsolete now (Marlin encourages the use of junction deviation now, in lieu of the four jerk settings).

To put it bluntly, and I think I speak for a lot of people: I don't give a damn if some feature seems undeniably useful to someone, so long as I can turn it off gracefully if I don't want it; to me, the machine limits tab has absolutely zero utility.

@Braccoz
Copy link

Braccoz commented Sep 18, 2020

I don't understand why this is so controversial? Just let us disable/omit the machine limits from the g-code, without resorting to hacks like switching the firmware setting.

it's not controversial for the users, it's controversial for the developers: it's a feature put in specifically for prusa users. this is prusaslicer so it's not really their priority to implement stuff for the non-prusa users, even something as trivial as a checkbox to disable those parameters.

kinda same with cura. there are some things they absolutely just don't care about because it would not be useful on ultimakers, so they just won't do it

bubnikv added a commit that referenced this issue Oct 2, 2020
@bubnikv
Limiting the application of Machine Limits
8df0181 
#1212

WIP: The hints do not rescale when switching the "usage" combo box.
The new g-code time estimator needs to be updated to not read
the machine limits if not enabled.
@bubnikv
Copy link
Collaborator

bubnikv commented Oct 2, 2020

it's not controversial for the users, it's controversial for the developers: it's a feature put in specifically for prusa users. this is prusaslicer so it's not really their priority to implement stuff for the non-prusa users, even something as trivial as a checkbox to disable those parameters.

That is not correct. It is not about the developers not wanting to implement some feature that is so super necessary to an owner of non-Prusa machine. Please understand that it will not be you to have to explain to our users why the slicer does not produce correct time estimates after they messed up with the settings.

The world is not black and white. We have the reasons to NOT implement what is requested. You have your believes that the slicer emitting the machine limits G-code is fundamentally wrong (fundamental is the right world in this context). But it is a lucky day for you. There was so much negative feedback around this topic, that we decided to make it configurable, with a hint text explaining that if you touch that settings, you will likely get INCORRECT time estimates. I guess that about half of the people will actually read it.

It will be part of the upcoming PrusaSlicer 2.3.0-alpha1 release. Enjoy.

@bubnikv bubnikv closed this as completed Oct 2, 2020
@thierryzoller
Copy link

Having waded through some of the nonsense on this thread and seeing how much energy was spent on such a simple request
I'd recommend to take these feature requests to Superslicer in the future https://github.com/supermerill/SuperSlicer

@Braccoz
Copy link

Braccoz commented Oct 2, 2020 •
edited

it's not controversial for the users, it's controversial for the developers: it's a feature put in specifically for prusa users. this is prusaslicer so it's not really their priority to implement stuff for the non-prusa users, even something as trivial as a checkbox to disable those parameters.

That is not correct. It is not about the developers not wanting to implement some feature that is so super necessary to an owner of non-Prusa machine. Please understand that it will not be you to have to explain to our users why the slicer does not produce correct time estimates after they messed up with the settings.

The world is not black and white. We have the reasons to NOT implement what is requested. You have your believes that the slicer emitting the machine limits G-code is fundamentally wrong (fundamental is the right world in this context). But it is a lucky day for you. There was so much negative feedback around this topic, that we decided to make it configurable, with a hint text explaining that if you touch that settings, you will likely get INCORRECT time estimates. I guess that about half of the people will actually read it.

It will be part of the upcoming PrusaSlicer 2.3.0-alpha1 release. Enjoy.

well, i understand your logic. however, that same logic apparently did not apply when the feature was introduced and wrecked havoc on non-prusa printers. Also it does not apply if you leave it on by default, and possibly pop up a warning if the user disables it.

all in all i still love prusa and the work you guys do for free on prusaslicer and i had no resentment in writing my post, altho i was quite pissed a couple years ago before finding out the workaround

@Schokobecher
Copy link

Schokobecher commented Oct 2, 2020 •
edited

But it is a lucky day for you.
I guess that about half of the people will actually read it.

It's nice how a developer (with a whole 8 commits this year) can be so cynic about implementing what users go out their way to request 👍

No wonder people take off to forks and alternative slicers, with that attitude I also wouldn't want to contribute alongside such nice people.

There was so much negative feedback around this topic

Go figure why... guess everyone is dumb for wanting the FREEdom of choice in FREE (as in Libré ) software. Code is heavily influenced by the Users, no matter if open- or closed-source. If a developer has the standpoint of I know best what my user should do/want/get he might be better off not communicating with those users and let someone handle it who can translate between code and user. Free Pro-Tip from my end for @bubnikv

@mikolaszuza
Copy link
Collaborator

@Schokobecher bubnikv being the lead PrusaSlicer dev has little more than 8 commits this year ;) (haha don't even look at the number of commits and lines changed overall)
Emotions are running high and that's ok, we're all passionate about this piece of software.

Some forks have all sorts of these settings exposed. Which is great for the power user.
But I think it's reasonable to be really cautious even if it's a single checkbox we're talking about. It's a thin line between letting the users do what they want and giving the everyday user too many options, that the software becomes unusable.

@n8bot
Copy link
Contributor

n8bot commented Oct 2, 2020

[...] if you touch that settings, you will likely get INCORRECT time estimates. [...]

Could the machine's parameters not be used to calculate time estimates, but then omitted from GCode? This way, the estimates can be as close to correct as the user specifies, while also not actually modifying the machine's settings when the GCode is executed.

@lukasmatena
Copy link
Collaborator

lukasmatena commented Oct 3, 2020 •
edited

@n8bot Look at how its implemented. This is one of the options.

@thierryzoller
Copy link

thierryzoller commented Oct 3, 2020 •
edited

Some forks have all sorts of these settings exposed. Which is great for the power user.

This confirms my point of taking it to the SuperSlicer fork, you'll get tons of advanced settings and let Prusaslicer target their enduser base primarily.

@VanessaE
Copy link

VanessaE commented Oct 6, 2020

@bubnikv it still isn't working -- machine limits are still emitted to G-code regardless of the setting in the dropdown menu (commit f47ad1f).

lukasmatena added a commit that referenced this issue Oct 6, 2020
@lukasmatena
Fixup of 8df0181 (turning off the export of machine limits)
b42a12d 
This should solve #1212 for good
@lukasmatena
Copy link
Collaborator

@VanessaE Thanks. It should now work after b42a12d.

@VanessaE
Copy link

VanessaE commented Oct 6, 2020

@bubnikv yep, that seems to have sorted it.

This was referenced Oct 10, 2020
Closed
Closed
@lukasmatena lukasmatena mentioned this issue Mar 10, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests