Slic3r temps settings not making it to Gcode output #2740

Closed
sstantz opened this Issue Mar 15, 2015 · 12 comments

Projects

None yet

4 participants

@sstantz
sstantz commented Mar 15, 2015

The gcode generated with 1.2.6 (experimental) is setting my print temperatures to 220C and 80C for nozzle and bed, regardless of what temps I tell it to set. I have to use my printer to readjust my temps after the print has started.

@alexrj
Owner
alexrj commented Mar 16, 2015

Can you please read guidelines?

@sstantz
sstantz commented Mar 16, 2015

Yes, I realize this post isn't the greatest for reporting a possible bug. But, cmon, Github will only allow me to attach image files. I'm not about to screenshot lines of gcode and config files.

Anyway, I figured the problem is pretty clear, but I'll explain further and explain another detail I noticed just now:

I just generated three more gcode files for the purpose of posting. (I could email them to you).
The first two were config files I keep saved as a template/starting point for many slices. These config files (i opened them up and read the text myself) indicates the proper temperatures set in the UI. I set all temps to 0, since I normally just preheat my printer from the printer itself. The exported these configs to a new file name and folder right before I generated the gcode. The configs show the correct temps.

Then, the generated the gcode for these two. The gcode shows temps as 220C, 80C for extruder and bed. Just as a said in the first post.

What I just did that is new, is to generate gcode without loading my saved config files. This default config generated proper gcode with respect to the temperatures.

Again, this is 1.2.6.

Also, this is running on windows 7.

@lordofhyphens
Collaborator

That's why you use a file locker service like 2shared or something else,
upload there and then link here.

On 03/16/2015 08:37 AM, sstantz wrote:

Yes, I realize this post isn't the greatest for reporting a possible
bug. But, cmon, Github will only allow me to attach image files. I'm
not about to screenshot lines of gcode and config files.

Anyway, I figured the problem is pretty clear, but I'll explain
further and explain another detail I noticed just now:

I just generated three more gcode files for the purpose of posting. (I
could email them to you).
The first two were config files I keep saved as a template/starting
point for many slices. These config files (i opened them up and read
the text myself) indicates the proper temperatures set in the UI. I
set all temps to 0, since I normally just preheat my printer from the
printer itself. The exported these configs to a new file name and
folder right before I generated the gcode. The configs show the
correct temps.

Then, the generated the gcode for these two. The gcode shows temps as
220C, 80C for extruder and bed. Just as a said in the first post.

What I just did that is new, is to generate gcode without loading my
saved config files. This default config generated proper gcode with
respect to the temperatures.

Again, this is 1.2.6.

Also, this is running on windows 7.


Reply to this email directly or view it on GitHub
#2740 (comment).

--Joseph Lenox, BS, MS
I'm an engineer. I solve problems.

@markwal
Contributor
markwal commented Mar 16, 2015

I think I've seen this one. My initial guess is that it is when the filament settings are unsaved. That is, in the "Modified" state, they get ignored. This is different behavior than Print Settings and Printer Settings. I'm running 1.2.7-dev. I believe the steps would be the following (I'm going to try to repro again after I post this):

Steps:

  • Choose Filament Settings tab
  • change extruder or bed temperatures from the preset
  • Plater.Export to Gcode

Result:
G-code contains temps from preset, not from the modified tab

@markwal
Contributor
markwal commented Mar 17, 2015

Yes it reproduces reliably for me. Saving the preset cures it so @sstantz, a workaround for you may be to save the filament preset after modifying your filament settings. I think, however, that it is a bug for the Filament presets not to work like the Printer or Print presets where the currently active modified settings win.

@markwal
Contributor
markwal commented Mar 21, 2015

Also, doesn't happen from the command line or if --no-plater. Has to be --gui and the plater has to be on. Then the modified filament settings are ignored in spite of "Modified" showing up on the plater under filament selection.

@alexrj
Owner
alexrj commented Mar 22, 2015

@markwal, what's your operating system?

@markwal
Contributor
markwal commented Mar 22, 2015

I'm running it under Windows 8.1. I've also got it running under Ubuntu 14.04 and just starting getting it up and running on a Raspberry Pi.

However, I tracked down my issue in the source:
lib/Slic3r/GUI/MainFrame.pm
in Slic3r::GUI::MainFrame::config
first TODO (line 640 in my version)

...
if (!$self->{plater} || $self->{plater}->filament_presets == 1 || $self->{mode} eq 'simple') {
$filament_config = $self->{options_tabs}{filament}->config;
} else {
# TODO: handle dirty presets.
# perhaps plater shouldn't expose dirty presets at all in multi-extruder environments.
...

So, the dirty preset is ignored if you have a plater, you have more than one extruder and you're in expert mode. Which I am. I'm not sure about @sstantz, but my guess is yes.

I understand why this is a difficulty. One preset for each extruder is very nice for using multiple materials. Yet, there is only one filament tab and so there can only be one dirty preset. And dirty presets are so nifty for twiddling with stuff.

One way to fix this is as proposed by the comment. That is, removed "(Modified)" from the preset selector on the plater. I'm not sure, but I think new users would still be confused because the behavior doesn't match the other type of preset. There's some inherent confusion here too because different materials may want contradictory things like different bed temperatures and, of course, the user would understand that he can't have it both ways, it's difficult to figure out how to tell him what will happen in a way that is clear.

I think perhaps the thing to do is to apply the dirty settings to all the extruders who are currently selecting the preset that is dirty in the tab? I think I can try and propose a change for that and test it out. I still need to read through merge and understand the resulting config a bit better before I proceed however. @alexrj what do you think?

@alexrj
Owner
alexrj commented Mar 23, 2015

Bug fixing would be much easier if people provided all the information required by the guidelines since the beginning (config files, operating system). @markwal says this only happens when multiple extruders are configured. We don't know about @sstantz because he didn't want to provide the required information.

@markwal
Contributor
markwal commented Mar 23, 2015

I'm chagrined. Sorry about that, I was offering additonal @sstantz's report so I neglected CONTRIBUTING.md. Here's my info, if it's helpful:

Slic3r version 1.2.7-dev git rev-parse HEAD: 13b63d0
config.ini: https://www.dropbox.com/s/1nunf5a5xraq60e/config.ini?dl=0

@markwal
Contributor
markwal commented Mar 23, 2015

@alexrj how about the following? If it's the right idea, I can send you a pull request. If I'm off track, I can go a different route. In my testing it appears to work the way I expected.

diff --git a/lib/Slic3r/GUI/MainFrame.pm b/lib/Slic3r/GUI/MainFrame.pm
index 6e32566..fa3da3b 100644
--- a/lib/Slic3r/GUI/MainFrame.pm
+++ b/lib/Slic3r/GUI/MainFrame.pm
@@ -635,13 +635,19 @@ sub config {
     if (!$self->{plater} || $self->{plater}->filament_presets == 1 || $self->{mode} eq 'simple') {
         $filament_config = $self->{options_tabs}{filament}->config;
     } else {
-        # TODO: handle dirty presets.
-        # perhaps plater shouldn't expose dirty presets at all in multi-extruder environments.
         my $i = -1;
         foreach my $preset_idx ($self->{plater}->filament_presets) {
             $i++;
             my $preset = $self->{options_tabs}{filament}->get_preset($preset_idx);
-            my $config = $self->{options_tabs}{filament}->get_preset_config($preset);
+            my $config;
+            if ($preset_idx == $self->{options_tabs}{filament}->current_preset) {
+                # the selected preset for this extruder is the one in the tab
+                # use the tab's config instead of the preset in case it is dirty
+                # perhaps plater shouldn't expose dirty presets at all in multi-extruder environments.
+                $config = $self->{options_tabs}{filament}->config;
+            } else {
+                $config = $self->{options_tabs}{filament}->get_preset_config($preset);
+            }
             if (!$filament_config) {
                 $filament_config = $config->clone;
                 next;
@alexrj alexrj removed the Needs more info label Mar 23, 2015
@alexrj alexrj added this to the 1.2.7 milestone Mar 23, 2015
@alexrj
Owner
alexrj commented Mar 23, 2015

Thank you @markwal, that patch looks very good. I pushed it.

@alexrj alexrj closed this Mar 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment