Open Ro3Deee opened 3 months ago
As the source code already states here, the P and Q parameters are planned to be developed already and meanwhile, if preheating is required, M104 is being run instead. So it isn't implemented right now and thus no bug.
@bkerler , I read the code (i even provided the commit). Not a bug, but an issue. Even with prusasliced models, sometimes the nozzle stops after initial purging waiting for temp because M104.1 cooled the nozzle
Yep, it is an issue and it's even more an issue as Prusaslicer already seems to make active usage of it. I'll check with the devs in case this might already be implemented in a beta firmware.
In my opinion, what is need is not an early preheating command M104.1 that tell the firmware "I need X degrees for that extruder in 10 seconds from now", but a gcode that sets the extruder temperature when is need (like M109 with a boolean param for preheating) that actually starts heating earlier. So the fw should look ahead (for 1-2 minutes of gcode), find the relevant M109 commands (with that boolean param true) for the other tools and start to preheat them according to their pid values at the appropriate time so when execution arrives at M109 for that tool, it already has the desired temp. When parking a tool, the fw should determine the minimum temperature allowed for cooling and start heating it up when reached so, when it will be picked it will have the needed temp.
@petrubecheru yes, I agree. Imho as of now, this issue has to be handled within PrusaSlicer. The changes within the printer firmware seem to be pretty huge to match the expected behaviour vs. the current behaviour.
I agree. Imho as of now, this issue has to be handled within PrusaSlicer. The changes within the printer firmware seem to be pretty huge to match the expected behaviour vs. the current behaviour.
@bkerler
So at least M104.1 should not default to m104 for the current tool as it sometimes cools the nozzle. For others tools its ok (it will heat them earlier so a little bit of energy lost and minor filament cooking, but no big deal).
Thank you for your contribution to our project. This issue has not received any updates for 60 days and may be considered "stale." If this issue is still important to you, please add an update within the next 7 days to keep it open. Administrators can manually reopen the issue if necessary.
Printer model
XL
Firmware version
6.0.4
Describe the bug
M104.1 GCode was introduced to Prusa-Firmware-Buddy by this commit: https://github.com/prusa3d/Prusa-Firmware-Buddy/commit/652a65f8c176db7069917d13bb51dab6b40769ae to early set hotend temperature so that the printer can start preheating the tool in advance.
PrusaSlicer started to use M104.1 in place of M104 with this commit: https://github.com/prusa3d/PrusaSlicer/commit/c916249f2b0e2d9b50077cf3c2402115426ef4f4
But the current implementation of M104.1 is to ignore the P and Q params ( time in seconds till the temperature S is required) simply process this command as if it was standard M104.
Because an M104 command on current tool immediately starts to modify the current temperature, an M104.1 (that is M104 in fact) on current tool can destroy a print if used with P and Q params in mind.
So, until m104.1 is properly implemented as requested here #4117 , it shouldn't do anything on current tool