Big problem with1.17b that isn't present with 1.17RC3
-
Hi Ian,
1. Please try the new firmware at https://dl.dropboxusercontent.com/u/19369680/DuetWiFiFirmware.bin so see if it fixes your M220 problem and the new one. Caution: it is highly experimental! I have not done a print using firmware retraction yet because S3D doesn't support it, so I will have to find a copy of Slic3r.
2. Do you use retract on layer change? There was a bug in the old code when you used firmware retraction with Z hop and retract on layer change. The gcode typically had the G10 retract command, then the command to set the new height, then the G11 command to undo the retraction. The G11 was causing the head to drop to the new height less the Z hop height. I fixed this late in the 1.17 development cycle, so I am wondering if the fix has anything to do with the new problem.
-
PS - what M207 settings are you using? Please also check that when you run M207 with no parameters, it reports the same parameters that you entered.
-
Hi David,
Thanks for getting back.
I'll try the new firmware this afternoon (hopefully) and report back.
I do retract on layer change but not with a Z hop. Note that I'm observing the issue on all retract/unretract moves, not just those that occur on layer change.
M207 in config.g is "M207 S2.0 F3000". Entering M207 with no parameters reports back "12:36:39 M207 Retraction settings: length 2.00/2.00mm, speed 3000/3000mm/min, Z hop 0.00mm"
HTH
Ian
P.S. The weekend is fast approaching so don't bust a gut over this. Everything is fine using 1.17 RC3 (well apart from the M220 thing but that's no big deal).
-
Hi Ian,
1. Please try the new firmware at https://dl.dropboxusercontent.com/u/19369680/DuetWiFiFirmware.bin so see if it fixes your M220 problem and the new one. Caution: it is highly experimental! I have not done a print using firmware retraction yet because S3D doesn't support it, so I will have to find a copy of Slic3r.
2. Do you use retract on layer change? There was a bug in the old code when you used firmware retraction with Z hop and retract on layer change. The gcode typically had the G10 retract command, then the command to set the new height, then the G11 command to undo the retraction. The G11 was causing the head to drop to the new height less the Z hop height. I fixed this late in the 1.17 development cycle, so I am wondering if the fix has anything to do with the new problem.
David
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
-
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.
-
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
