Big problem with1.17b that isn't present with 1.17RC3
-
I think the only change to M220 that was intended was to prevent the command from affecting homing. Perhaps that changed to not affecting all z moves, but non-print moves were still meant to be affected by M220 afaik.
-
@bot:
I think the only change to M220 that was intended was to prevent the command from affecting homing. Perhaps that changed to not affecting all z moves, but non-print moves were still meant to be affected by M220 afaik.
You could be right - my memory gets worse the older I get:) I just remember that someone commented that they had started a print with very low speeds in their config, upped it using the slider to something like 200% but forgot to reset the slider at the end of the print. So when they next did a move or something they ran into issues. That's how the debate started but I'm not sure what the outcome was.
-
@bot:
I think the only change to M220 that was intended was to prevent the command from affecting homing.
That is correct.
-
S3D Does support Firmware retraction it just uses the M103/101 codes instead of G10 and G11 and this can be changed by adding the following 2 lines into the Post process box on the Scripts tab
{REPLACE "M103" "G10; retract"}
{REPLACE "M101" "G11; unretract"}I have been running like this for some time now
HTH
Doug
Thanks, Doug! I have added support for M101 and M103 in the forthcoming 1.17c release.
-
Hi David,
I've tested the experimental firmware (1.17b+1 (2017-01-13)).
M220 speed override works as expected during a print. However, the speed override still works for non print moves while the machine is idle. (Actually, I'm fine with that but I understand that other users want it changed).
The over extrusion which seems to be caused by G11 after a G10 issue remains an issue - no discernable difference in print behaviour between this experimental version and 1.17b. I'll go back to 1.17rc3 for now,
Cheers
Ian.
P.S. - Take the weekend off - this stuff can wait a while.
Hi Ian,
I'm sorry, I can't reproduce that. G11 un-retracts the same amount of filament as G10 on my printers, assuming I don't configure it to do otherwise.
If you send G10 manually followed by G11, does it extrude more than it retracts? If it doesn't and you only see this problem in an actual print, can you send me a snippet of gcode showing the context of the G10 and G11 commands in your print?
Are you doing anything else unusual, such as using absolute extruder coordinates?
I have a 1.17c release almost ready to go and I'd really like to sort out this issue before I release it.
-
Hi David,
Sending G10 then G11 manually via the web interface works as expected in both 1.17rc3 and 1.17b - I checked by putting a Tipex mark on the extruder gear and it moves back and forth to the same position.
I've uploaded the entire gcode file for the object that is in the pictures and which prints fine in 1.17rc3 but not in 1.17b. You can access it here https://drive.google.com/file/d/0B_MwtHtQR_ZveG45ek54Wld6cG8/view?usp=sharing. The problems (using 1.17b) become most noticeable after the solid base layers are printed, so from about line 8387 onwards.
I can't see anything untoward in the gcode file but then I wouldn't expect to as it works fine in "rc3" but not "b" and no, I'm not using absolute extruder coordinates anywhere (except for M207 which is set to 2.0 mm).
So maybe it isn't G11 but something else that happens immediately before or after which visually looks like the same thing. Could the firmware send multiple G11s instead of just the one? Could it be trying to do something with pressure advance even though I'm not using it?
Is there a way to see what commands are sent to the printer to check them against the gcode file?
What else can I do to help?
Cheers
Edit. If it makes any difference, my Web interface is 1.13 - had problems as reported using 1.14.
Ian
Further edit. Could it be anything to do with me using 3 extruders simultaneously? The tool definition I'm using is set to a mixing ratio of 90:05:05. I could change it to 100:0:0 if you think it's worth trying.
-
I've just committed firmware 1.17c. Please check it in case the problem is fixed, although I doubt that it is.
-
Hi David,
Sorry to report that 1.17c has the same issues as 1.17b. Again, I had to abort the print dues to all the excess extruded filament causing the nozzle to collide.
At least it's repeatable. That is to say that 1.17rc3 always produces good results and 1.17b (or c) always produces bad results.
The sequence has been:1.17rc3 - good
1.17b - bad
1.17 rc3 - good
1.17 "experimental" -bad
1.17 rc3 - good
1.17c - bad
1.17rcs - TBA but I'll try it later and will be very surprised if it's not good. EDIT - result is good.Also, the good prints look identical to each other, and the bad prints look identical to each other (apart from the fact that they all have to be aborted early).
The other little nagging thought I have is that this is all a bit reminiscent of the seeming over extrusion issues I had when I first started to commission the printer back in November. If you remember, I was running an extrusion multiplier of 70% to get good results. I tried just about everything imaginable but nothing worked. Then one day it magically cured itself after I had to make several changes due to my IR probe getting destroyed. I can't help but wondering if all along it might have been akin to the issue that I'm seeing now - i.e. something in the firmware?
Maybe it's a red herring - just trying to give you as much info as possible.
Ian
Last reason for edit - latest print with RC3 was good (as expected)
-
Hi Ian,
Please can you try a print with mixing disabled (not just set to 100%/0/0). There may be a difference.
-
Hi Ian,
Please can you try a print with mixing disabled (not just set to 100%/0/0). There may be a difference.
Will do. I just need to wait for this print to finish then I'll define a tool with no mixing and try 1.17c again.
BTW this latest print with 1.17rc3 is looking fine (as expected).
Ian
-
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.
