Speed factor (M220) doing absolutely nothing
-
As title. Trying to find the speed where my extruder starts to skip steps or my hot end cannot melt filament quickly enough. Printing a 300mm x 300 "cube" to generate long print moves (400mm plus on the diagonal). Using the slider or sending M220 makes no difference at all from 20% to 200%. The fact that I can't go slower, rules out the fact that it might be limited by the maxima as set in my config.g. I've been running with M220 S20 (20%) for the last 20 minutes and there is no change in the machine speed so it's not a question of waiting for commands in the queue to be processed either.
Update. I aborted the print at the end of a layer and just before it aborted (still processing commands in the queue), it started the next layer at what looked like 20% speed. So I suspect that speed change/M220 only happens on layer change?
Firmware Electronics: Duet WiFi 1.0 + DueX5
Firmware Version: 1.17RC3 (2016-12-21)
WiFi Server Version: 1.03 (ch fork)
Web Interface Version: 1.13Machine is coreXY.
Is this due to the changes in speed override that other users were asking for and how it is mean to be? If so, I'm not a happy bunny.
Second update. Now that the machine has finished printing, I can send M220 commands (or use the slider) and X and Y move in accordance with that speed setting but Z is unaffected.
Edit. This look like it's back to front to me. That is to say, I can set a speed factor of 200% and it'll use that for non print moves when the machine is idle but ignores the speed override when it's printing (but maybe acts on it at layer change)?
-
Ian, can you try with firmware 1.17b and see if you are still getting the issue
-
OK. I've updated to 1.17b
Firmware Name: RepRapFirmware for Duet WiFi
Firmware Electronics: Duet WiFi 1.0 + DueX5
Firmware Version: 1.17b (2017-01-07)
WiFi Server Version: 1.03 (ch fork)
Web Interface Version: 1.13Non print moves are as before. That is to say, when the machine is idle (turned on and homed but no other action taken) setting the speed using the slider to 20% results in XY moves running considerably slower (I'd guess it's 20% speed as expected). Setting the slider to 200% results in X and Y moves running at twice normal speed. I thought this was what the firmware change was meant to avoid (although personally I'm happy that it doesn't alter anything). The Z axis is unaffected - i.e. there is no difference in speed between 20%, 100% and 200% (although Z max speed may be capped in my config.g).
I'm about to start another print so I'll report back on what happens during a print with 1.17b.
Ian -
The speed slider won't affect moves that are already in the DDA queue, so you may have to wait for ~30 moves to complete before the speed change takes effect. When printing curves this happens quite quickly, but when printing rectilinear infill it can take a while. OTOH there is code to prevent the DDA queue from being filled with a lot of slow moves, so I am surprised you are seeing this.
-
@ David, Yes I'm aware of the queue thing - as I explained in my OP, I ran it for 20 minutes after changing the slider .
OK this is weird. I started a print (a 100mm x 100mm x 3mm "cube") and about 10 seconds after it started doing the zig zag inside moves, I set the slider to 20% and checked the gcode console to make sure that M220 S20 had been sent (which it had). The speed remained unchanged for the entire layer until it changed layer, then it slowed right down. While it was doing the perimeters, I changed the slider to 200%. It did a few more perimeter moves then sped up to twice the "normal" speed but after that, while it was doing the zigzag moves, the slider had no effect and I couldn't slow it down again until the next layer change/perimeter moves. (I did discover that my hot end won't melt filament fast enough for 200% speed but that's another story).
So in summary, M220 changes speed for non-print moves while the printer is idle but only for X and Y, (not Z). This is contrary to my understand of what the firmware should now allow. As if the logic for the firmware override of the speed override was inverted.
During a print, M220 has no effect when doing zigzag moves. I initially thought that it was becoming effective at layer change but now I'm leaning towards the theory that it is only effective during straight up and down or left to right moves (i.e pure X or pure Y but not X plus Y ). I know that sound hard to believe but that's what I am observing. I'm going to slice the same "cube" again but orient it at 45 degrees to the build plate so that the perimeters are at 45 degrees but the inside should get printed with pure X and Y moves to see if that proves the point.
Just a reminder again, it's coreXY - just in case that has any effect.
Ian
Ian
-
The speed factor worked for me yesterday (1.17b), had an 80mm/s print that I kicked up to 160mm/s (200%) with 4000 acceleration. Quality suffered a bit, but no missed steps
Jeff
-
Well bang goes that theory - it's not to do with zigzag vs pure X or Y moves. I ended up setting the fill angle to 90 degrees in order to get it to print with all pure X or Y moves. The same thing happened. That is to say that moving the slider or sending M220 commands has no effect doing the first layer. Again, about 10 seconds after it had finished the perimeters and started the print proper, I set the slider to 20% and nothing happened until the first layer change where it immediately slowed to 20% speed.
Interestingly, while it was doing the perimeters I changed the slider to 100% and a few moves later, while still doing perimeters, it sped up to 100% but for the rest of the next layer, moving the slider had no effect again.
Maybe the speed change only happens when a non-print move occurs? i.e. when moving from the inner perimeter to the outer or on layer change? Dunno, I give up on postulating theories.
Let me know if there is any more testing I can do but I'd really like to have his working again.
Ian
-
@(In)Sanity:
The speed factor worked for me yesterday (1.17b), had an 80mm/s print that I kicked up to 160mm/s (200%) with 4000 acceleration. Quality suffered a bit, but no missed steps
Jeff
Try doing a 100mm x 100mm "cuboid" as I am doing and see if the speed factor still works.
-
@(In)Sanity:
The speed factor worked for me yesterday (1.17b), had an 80mm/s print that I kicked up to 160mm/s (200%) with 4000 acceleration. Quality suffered a bit, but no missed steps
Jeff
Try doing a 100mm x 100mm "cuboid" as I am doing and see if the speed factor still works.
So your saying you can't slow it down, or can't speed it up ? The slowdown of course should always work however the speed up will be limited ultimately to your max speed and acceleration settings. I've done speed ups before with test towers with expected results. If your doing a lot of long straight extrusions your not going to see the speed change for some time due to the queue.
Jeff
-
@(In)Sanity:
@(In)Sanity:
The speed factor worked for me yesterday (1.17b), had an 80mm/s print that I kicked up to 160mm/s (200%) with 4000 acceleration. Quality suffered a bit, but no missed steps
Jeff
Try doing a 100mm x 100mm "cuboid" as I am doing and see if the speed factor still works.
So your saying you can't slow it down, or can't speed it up ? The slowdown of course should always work however the speed up will be limited ultimately to your max speed and acceleration settings. I've done speed ups before with test towers with expected results. If your doing a lot of long straight extrusions your not going to see the speed change for some time due to the queue.
Jeff
Just read my previous posts please, especially the very first paragraph of the very first post. (It'll save me having to repeat myself yet again).
-
I'm now doing a more "normal" print with lots of direction changes, arcs, and non-print moves. By observation, I'm 99% convinced that the speed modifier (M220 command) is only acted on when the printer next encounters a non-print move. That is to say that while the printer is doing normal print moves (those that require extrusion) the M220 command is ignored until the printer does a non-print move. At that point, the speed is modified and will remain so.
-
I can imagine how that type of issue may have crept in at version 1.17, so I'll check the code.
-
I found the problem. It's because each input channel now has its own current feedrate setting. When you send M220, it needs to update the feed rate on all input channels, not just the one that sent the M220 command. I've fixed the code and I will do a 1,17c release when I've looked at a couple of other issues. Thank you for your patience.
-
David you are amazing. Thanks for being so sharp and responsive in here. I'm in awe of your firmware mastery and technical prowess. Bravo!
