Big problem with1.17b that isn't present with 1.17RC3
-
Hi David - my comments in bold
Ian, thanks for the video. From a knowledge of the gearing, the steps/mm and the amount of retraction configured, can you tell whether it is under-retracting or over-priming?
That's a tough one to call but looking at the video, I'd say it's pretty conclusive that the retraction amount is the same for both versions of firmware and it's the recovery that is greater in 1.17c. For info, these are E3D Titan extruders, 3:1. No difference in settings between them. Here are the relevant settings from my config
M350 X16 Y16 Z16 E16:16:16 I1; Configure XYZ and 3 extruders microstepping with interpolation
M92 X80 Y80 Z3200 E405:405:405 ; Set steps per mm
M566 X600 Y600 Z10 E300:300:300 ; Set maximum instantaneous speed changes (mm/min)
M203 X70000 Y45000 Z300 E2400:2400:2400 ; Set maximum speeds (mm/min)
M201 X1200 Y1200 Z10 E1000:1000:1000 ; Set accelerations (mm/s^2)
M906 X1800 Y1800 Z1800 E350:350:350 I20 ; Set motor currents (mA) and motor idle factor in per centPlease can you do a few more tests:
1. Confirm that when you send G10 and G11 manually, the amounts of retraction and un-retraction are the same on all extruders.
With 1.17c, 1.17rc3 or both?
2. Try reducing extruder max speed, acceleration and jerk, to rule out something mechanical.
Seriously? Why would it work fine with one version of firmware and not another?
3. Do you use Z hop? If you do, does the problem still occur without it?
No, don't use it - you asked me that before.4. During that print, after a few retracts send M122 and check that "Step errors" in the report is zero.
Again, 1.17c, 1.17rc3 or both?
5. During that print , or a similar one, with a USB host connected send M111 S1 P4 amd M111 S1 P6. You will get copious amounts of debug to the USB port. Let it run long enough to do a few retracts, then pause the print or just reset the machine, copy and paste the debug output into a text editor, and make it available for me to look at.
…....and again, which firmware do you want me to do that on - or is it both?
Cheers
Ian
-
David,
Ref point 1 above. I did a series of G10 G11 with both 1.17rc3 and 1.17c and counted extruder teeth moved in each direction for all 3 extruders, Here are the results: This to the nearest whole tooth so allow +/- 1 tooth for measurement errors
1.17 rc3.
T0 G10=6, G11=6
T1 G10=5, G11=5
T1 G10=6, G11=61.17c
T0 G10=5, G11=8
T1 G10=6, G11=8
T2 G10=5, G11=9I guess that's fairly conclusive in that G10 and G11 are consistently the same in firmware 1.17rc3. Also G10 is the same in 1.17rc3 and 1.17c but G11 is high in 1.17c.
What doesn't make sense is that this behaviour is the same for all 3 extruders, yet in the video it is clear that during a print, only extruders 0 and 2 exhibited this behaviour but extruder 1 appeared to be acting normally.
After the series of G10/G11s using 1.17c (the one with the high G11 compared to G10), I ran M122. There are no step errors or anything else untoward that I can spot. I have the entire file if you want it.
Ian
-
HI Ian,
As it appears that you can replicate the problem just by sending G10 and G11, please can you load firmware 1.17c, connect Pronterface, send M111 S1 P4 and M111 S1 P6, then do one G10 followed by one G11. Monitor the teeth during this to be sure that the problem has occurred. Then copy the debug output from Pronterface. Also send M207 to check that there is still no extra priming configured.
-
PS - the reason I suggested reducing speed/acceleration/jerk was in case the two firmwares were applying different limits. But send me the debug output first, that will tell me what is happening. Depending on what I see, I may ask for similar debug output from 1,17RC3.
-
Hi David,
All done as requested and you can get at the debug file here. https://drive.google.com/file/d/0B_MwtHtQR_ZvT19UcDNVMEQ2RFU/view?usp=sharing
Interestingly, when I did the M207 at the end, as you'll see from the debug file, it reported back retract length of 2.0mm and unretract of 3.0 which I guess is the problem. When I tried this several posts before, I got 2.0 and 2.0 but I can't now be absolutely certain which version of firmware that was with. What I can say for sure is that there is no R parameter in my config/g setting.
This is the M207 at the end of my config.g, so as you'll also see, the pressure advance is all commented out as well (tried it once but had issues so commented it out). This is copied and pasted from the system editor of DWC so we can be sure that is what the Duet board is seeing (and I have no config.g override)
; Custom settings
M207 S2.0 F3000 ;set firmware retraction S=amount in mm, F=Feed rate mm/min(/60 to get mm/sec), R = additional length, Z = additional Z lift in mm
;M572 D0 S0.20 ; set pressure advance coefficient
;M572 D1 S0.20
;M572 D2 S0.20Ian
-
So the problem is that the unretract length is somehow getting changed. Can you pin down what it is? I don't see it on my machine. I suggest you reboot the Duet, then run M207 to check. Then home the printer and check again. if the unretract length is still ok, try other things, e.g. running bed probing if you usually do that, and printing the first 50 or so lines of one of your gcode files.
-
Yes but it never happens with 1.17rc3. When I update to 17.b (or c) I get the problem. When I go back to 1.17rc3, I don't see the problem. It isn't random. I'll do some more tests, just doing M207 to see if I can nail it down.
-
OK. I cancelled the print I was about to start using 1.17rc3.
At 20:06:53 did M207 and got Retraction settings length 2.00/2.00 (this is with 1.17rc3). At 20:07:21 I updated the firmware to 1.17c. Without doing anything else I did M207 and got retraction settings length 2.00/3.00. At 20:08:25 I "update" the firmware back to 1.17rc3 and without doing anything else, I did M207 and got retraction settings length 2.00/2.00 (back to normal).
Here is a screen shot to prove it. The only commands other than M207 are M997 S0 when it updates the firmware.
https://drive.google.com/file/d/0B_MwtHtQR_ZvQWZhdFhRem5QR1E/view?usp=sharing
All I have to do is update the firmware from 1.17rc3 to 1.17c and the retraction (unretract) gets screwed.
Edit. If you look at the output, using 1.17rc3 the words say "M207 Retraction settings:" etc. Unsing 1.17c the words are different too "M207 Retraction/un-retraction settings:" etc. Don't know if that's a clue. Trying to find anything to help but I feel like I'm just banging my head against a wall.
-
Thanks, problem solved. Both the retract length and the extra unretract length are defaulted to 1.0mm, which isn't right. So when you send M207 S2 without the R parameter, it leaves the extra unretract length as 1mm. I'll change it to default the extra unretract length to 0 in the next release. Meanwhile, adding R0 to your M207 command will avoid the problem.
I'm sorry it's taken so long to track down such a simple cause. I had R0 explicitly in my M207 command, which is why I didn't see the problem.
EDIT: now that this is sorted, I'll release 1.17c+1 (with the fix included) which I was holding up to see if I could fix this issue too.
-
Phewwww. Glad we got there.
TBH I can't fathom the need for extra length on unretract. I think the theory is that during retract, the hobbed bolt squashes the filament a tiny bit so that when it comes to unretract, that part of the filament is now a slightly smaller diameter so needs a bit more. It's probably another of those theories that have never actually been properly tested and evaluated and I'm guessing that in "real life" if any compensation is needed, it would only be a tiny amount - perhaps 1 or 2 percent?
Anyway. Thanks for getting it sorted - I appreciate that it must be difficult because you can't possibly test everything on every combination of machine. - Always happy to beta test
PS. I've already added R0 to the M207 in my config,g
Ian
