Big problem with1.17b that isn't present with 1.17RC3
-
Hi David,
OK I've commented out all of my old tool definitions and created a single tool with a single extruder (M563 P0 D0 H1) Tested with 1.17c and the problem still exists. It's not as extreme but I'd say that was only because using a single extruder I'm effectively only using a third of the retraction/recovery that I'd normally need. i.e. the other two extruders now remain stationary whereas with mixing enabled, they too retract and recover.
The other thing is, with a single extruder I cannot now visually be sure that recovery from retraction is greater because this single extruder moves a lot more than the extruders that were only feeding 5% of the total needed, but my guess is that it is acting the same because the print quality adversely affected the same way.
That being the case, I'm assuming it has nothing to do with mixing. Given that nobody else is reporting having these issues, I think it's also safe to assume that it must be related to firmware retraction.
I guess I could turn off firmware retraction and slice the object using "normal" retraction but I'd be reluctant to try. I don't like running the printer configured as it is. In my experience, I need to keep the filament moving on all the inputs (not just have it loaded) otherwise I can get blockages (hence the reason for using 90:05:05 as my normal mixing ratio).
I need to re-enable all 3 tools and purge some filament through all the inputs as matter of some urgency but if you want me to try a single tool again, let me know.
Ian
-
David,
I have managed to capture what is going on in a video. I created a simple test piece which is just 4 off 10mm x 10mm x 10mm cubes, spaced in a square pattern about 20 mm apart. I also put 4 marks on the extruder gears with tipex about 90 degrees apart so that we can see what is happening.
The mixing ratio was set to 90:05:05 so extruder 0 (zero) does most of the work, extruders 1 and 2 only do 5% of the work each. Extruder 0 is at the front of the machine (has a plain wall behind it) then extruders 1 and 2 are in a clockwise pattern when viewed from above.
The video is just a series of clips, all hand held with no fancy editing so excuse the shaky nature. As you will see, the first part of the video up to about 1:30 is using 1.17 rc3 and is what I would describe as normal behaviour. The rest of the video is using 1.17c (the latest release). The difference is not hard to spot - it's like night and day. You'll see what I mean about it looking as if the recovery from retraction is greater than the retraction itself. It is most noticeable on extruder 2 which, because it only moves 5% of the total, looks like it's almost stationary during the print, then there is a step change in position after the retraction. Once you see this, it's easy to spot that extruder 0 is doing the same thing.
What is really flaky, is that extruder 1 seems not to be affected the same way and exhibits normal behaviour. There is a clip of it from about 4:48 in the video then from about 5:08 to 5.30 is me filming each extruder and walking around the machine. There is no doubt in my mind that only extrudes 0 and 2 are affected and the extruder 1 seems to be unaffected (or perhaps affected to far lesser extent so that it is not visually obvious). The final clip shows the result on print quality.
So, it seems that something happens immediately after retraction, it only affects extruders 0 and 2, extruder 1 does not exhibit the same behaviour. All extruders visually behave as expected using firmware 1.17 rc3 but exhibit the problem using 1.17c. I'd expect the same is the case using 1.17b. It is certainly true that extruders 0 and 2 behave the same way but I cannot confirm that extruder 1 is unaffected in 1.17b because I didn't consciously look at it.
Link to the video is here. https://drive.google.com/file/d/0B_MwtHtQR_ZvOUFBQ3o3YUtUSlE/view?usp=sharing
Hope that helps to shed some light.
Ian
-
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?
Please 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.
2. Try reducing extruder max speed, acceleration and jerk, to rule out something mechanical.
3. Do you use Z hop? If you do, does the problem still occur without it?
4. During that print, after a few retracts send M122 and check that "Step errors" in the report is zero.
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.
-
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
