alranel
commented
9 years ago Well, Slic3r shouldn't repeat useless commands but Smoothie should just ignore them :P
Open wolfmanjm opened 9 years ago
alranel
commented
9 years ago Well, Slic3r shouldn't repeat useless commands but Smoothie should just ignore them :P
alranel
commented
9 years ago I mean, while I can try to reduce them I can't guarantee that duplicates are totally removed since they're legal and Slic3r relies on that in order to save CPU time while generating G-code...
wolfmanjm
commented
9 years ago well unfortunately Smoothie needs to flush the queue each time it gets this command as it needs to be synchronous, and it can't check to see if the fan is already at that speed until it has flushed the queue. If I have the fan always on checked why does it need to send M106 again anyway? Is it so hard to see if the fan speed has changed and if not don't send this again? I mean it is everywhere :) I could write a filter to filter out all of the M106 I suppose, or just turn off the fan in slic3r altogether as a work around.
alranel
commented
9 years ago I really think Smoothie shouldn't flush the queue each time a M106 command is issued, as that breaks look-ahead and triggers a deceleration. I'll try to reduce the number of duplicated M106 commands, but I insist you should put fan speed changes into the queue (like Marlin does)...
alranel
commented
9 years ago Related discussion in Marlin repo: https://github.com/MarlinFirmware/Marlin/issues/2125
machinekoder
commented
9 years ago @wolfmanjm Machinekit handles these type of commands as synchronized commands so they are added to the motion queue. Smoothie probably should do the same.
alranel
commented
8 years ago @wolfmanjm, was this changed in Smoothie? Can we close this?
wolfmanjm
commented
8 years ago yea I suppose it can be closed, although I'd prefer to see if fixed in slic3r :) I hacked Smoothie to ignore a request to change speed if it was already at that speed.. Putting fan speed changes on the queue is not an option in smoothie, it wastes precious memory and as fan control is done with a generic Switch module it means all switch controls would be stuck on the queue.
l29ah
commented
4 years ago It wasn't changed in machinekit.
I tried to do
diff --git a/xs/src/libslic3r/GCode/CoolingBuffer.cpp b/xs/src/libslic3r/GCode/CoolingBuffer.cpp
index a9db021b..63133ac9 100644
--- a/xs/src/libslic3r/GCode/CoolingBuffer.cpp
+++ b/xs/src/libslic3r/GCode/CoolingBuffer.cpp
@@ -134,8 +134,8 @@ CoolingBuffer::flush()
boost::replace_all(gcode, ";_BRIDGE_FAN_START", "");
boost::replace_all(gcode, ";_BRIDGE_FAN_END", "");
} else {
- boost::replace_all(gcode, ";_BRIDGE_FAN_START", gg.writer.set_fan(gg.config.bridge_fan_speed, true));
- boost::replace_all(gcode, ";_BRIDGE_FAN_END", gg.writer.set_fan(fan_speed, true));
+ boost::replace_all(gcode, ";_BRIDGE_FAN_START", gg.writer.set_fan(gg.config.bridge_fan_speed));
+ boost::replace_all(gcode, ";_BRIDGE_FAN_END", gg.writer.set_fan(fan_speed));
}
boost::replace_all(gcode, ";_WIPE", "");
boost::replace_all(gcode, ";_EXTRUDE_SET_SPEED", "");
but it didn't do anything to the amount of M106 commands for some strange reason.
l29ah
commented
4 years ago Ah, i see why. Lemme try to correct it.
l29ah
commented
4 years ago Damn, now it doesn't cool at all:
diff --git a/xs/src/libslic3r/GCode.cpp b/xs/src/libslic3r/GCode.cpp
index 38e5d614..5b0aeb25 100644
--- a/xs/src/libslic3r/GCode.cpp
+++ b/xs/src/libslic3r/GCode.cpp
@@ -570,8 +570,12 @@ GCode::_extrude(ExtrusionPath path, std::string description, double speed)
double F = speed * 60; // convert mm/sec to mm/min
// extrude arc or line
- if (path.is_bridge() && this->enable_cooling_markers)
+ if (path.is_bridge() && this->enable_cooling_markers) {
gcode += ";_BRIDGE_FAN_START\n";
+ if (!this->config.cooling || this->config.bridge_fan_speed == 0 || this->layer_index < this->config.disable_fan_first_layers) {
+ gcode += this->writer.set_fan(this->config.bridge_fan_speed);
+ }
+ }
std::string comment = ";_EXTRUDE_SET_SPEED";
if (path.role == erExternalPerimeter) comment += ";_EXTERNAL_PERIMETER";
gcode += this->writer.set_speed(F, "", this->enable_cooling_markers ? comment : "");
@@ -594,8 +598,12 @@ GCode::_extrude(ExtrusionPath path, std::string description, double speed)
this->wipe.path = path.polyline;
this->wipe.path.reverse();
}
- if (path.is_bridge() && this->enable_cooling_markers)
+ if (path.is_bridge() && this->enable_cooling_markers) {
gcode += ";_BRIDGE_FAN_END\n";
+ if (!this->config.cooling || this->config.bridge_fan_speed == 0 || this->layer_index < this->config.disable_fan_first_layers) {
+ gcode += this->writer.set_fan(this->config.fan_always_on ? this->config.min_fan_speed.value : 0);
+ }
+ }
this->set_last_pos(path.last_point());
diff --git a/xs/src/libslic3r/GCode/CoolingBuffer.cpp b/xs/src/libslic3r/GCode/CoolingBuffer.cpp
index a9db021b..c1e40353 100644
--- a/xs/src/libslic3r/GCode/CoolingBuffer.cpp
+++ b/xs/src/libslic3r/GCode/CoolingBuffer.cpp
@@ -129,18 +129,6 @@ CoolingBuffer::flush()
gcode = gg.writer.set_fan(fan_speed) + gcode;
- // bridge fan speed
- if (!gg.config.cooling || gg.config.bridge_fan_speed == 0 || this->_layer_id < gg.config.disable_fan_first_layers) {
- boost::replace_all(gcode, ";_BRIDGE_FAN_START", "");
- boost::replace_all(gcode, ";_BRIDGE_FAN_END", "");
- } else {
- boost::replace_all(gcode, ";_BRIDGE_FAN_START", gg.writer.set_fan(gg.config.bridge_fan_speed, true));
- boost::replace_all(gcode, ";_BRIDGE_FAN_END", gg.writer.set_fan(fan_speed, true));
- }
- boost::replace_all(gcode, ";_WIPE", "");
- boost::replace_all(gcode, ";_EXTRUDE_SET_SPEED", "");
- boost::replace_all(gcode, ";_EXTERNAL_PERIMETER", "");
-
// Reset the buffer.
this->_elapsed_time = 0;
this->_elapsed_time_bridges = 0;
For some reason there appears to be a
M106 S255inserted at nearly every fast move and retract. I have the fan always on checked and would expect the fan to turn on on the second (or third) layer when I tell it to, and stay on the entire print, and not keep issuing M106 S255. This is particularly disruptive in smoothie as even though it does nothing it will flush the block queue everytimeFYI this does not appear to be a new bug, looking back I see it has been doing it since 1.1.7
for example....
and