Big problem with1.17b that isn't present with 1.17RC3

deckingman

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=6

1.17c

T0 G10=5, G11=8
T1 G10=6, G11=8
T2 G10=5, G11=9

I 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

dc42

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.

dc42

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.

deckingman

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.20

Ian

dc42

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.

deckingman

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.

deckingman

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.

dc42

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.

deckingman

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