When printing an object with 2nd extruder temperature does not get set. Printer head moves but nothing gets extruded.
This worked prior to RC6 and was introduced in one of the RCBugFix releases
When printing with both extruders it works.
You can try the below gcodes to reproduce:
This issue is not a Marlin bug but a Slic3r issue where it does not correctly set the T1 temperature if it finds any M140 or M104 in the start gcode section.
I spent more time on this today.
The issue is actually with Slic3r, which had M109 in it's start-code.
Slic3r does not generate ANY M109 codes at the start if it finds temperature related gcodes in its start-gcode-script because of this it never generated M109 statements for my second extruder
However I think Marlin should prevent the print from continuing if the Temperature is below the printable threshhold, as it just prints without extruding anything.
Issue can be reproduced by using extruder2.txt (gcode)
Would we want to prevent this in Marlin?
Are you sure not to be in dryrun mode and have set PREVENT_DANGEROUS_EXTRUDE and EXTRUDE_MINTEMP is not set to high?
#define PREVENT_DANGEROUS_EXTRUDE is defined and EXTRUDE_MINTEMPis set to 170
How do I know if I am in "dryrun" mode?
@lavato I'm sure you're not in DRYRUN mode. You would need to have enabled it specifically with M111 S8. But when PREVENT_DANGEROUS_EXTRUDE is doing its thing it behaves in the same way.
I think Marlin should prevent the print from continuing if the Temperature is below the printable threshhold
A feature worth considering. I'm not sure why Marlin has historically kept on going even when the temperature is low. No one really needs the printer to just keep going in these cases. Will you post it as a feature request so we can put it on our TODO list?
@thinkyhead
Sorry not sure how to do that, do you mean just raise a new issue and state it is a "Feature request"?
Also I will raise an issue with Slic3r as I think it should still place the relevant M109 codes regardless of the start code, since the start code cannot have any print functions in dual extruder mode without it preventing the second extruder from working.
do you mean just raise a new issue and state it is a "Feature request"?
Yep! State it however makes the most sense. We'll know if it's a feature request and label it so.
Also I will raise an issue with Slic3r
A sound plan. It should be smart about that second extruder.
@thinkyhead
In #4247 jbrazio suggested this may be a desired behavior for debugging, so should I raise this or not?
I agree for debugging it should be OK but I think Marlin should stop the air-print if temperature is below threshold.
Well I don't agree that the feature is broken.. the feature name is PREVENT_DANGEROUS_EXTRUDE which we're doing plus we output a warning to the LCD and to the Serial console.
If we want to change the feature behavior to kill() instead.. this is another discussion and not for the RC release.
@jbrazio
I am not saying it is necessarily broken and I agree it is not for RC release but it is more like a "Feature Request" as per thinkyhead's comments.
feature worth considering.
If I you put a user hat on and start printing from a file and the printer is not printing ,
I would expect a message like "Invalid gcode ..." and a printer stopped.
I am not sure I would kill it because it is not a fatal error.
In any case I don't mind raising it.
I'm positive we issue a flood of "extrusion prevented" to the serial console..
In my case that will not help, and in fact caused all these issues to be raised, as I almost never use a computer when printing,
I also raised non generation of M109 as a Feature Request with Slic3r dev and it appears they will build it in 1.3.5 milestone.
In any case I will not raise it if there is no agreement on this.
@thinkyhead any thoughts?
I also raised non generation of M109 as a Feature Request with Slic3r dev and it appears they will build it in 1.3.5 milestone.
This seems the correct approach to me. :+1:
@lavato To tell you the truth, I am at pains to justify the continuing movement of a machine whose extruder temperature has fallen below extrusion temperature. However, I am also unable to specify a better alternative which does not itself come with caveats. I have proposed in the past to add an audible alarm to Marlin for conditions that we can easily miss when not paying direct attention. Perhaps this brings some middle ground. The machine won't turn itself off, but if the alarm is annoying enough, it will get its "mother" to feed it.
but if the alarm is annoying enough, it will get its "mother" to feed it.
LOL
OK, I will raise it with two or three options when I have some more time.