Moved to Duet + RepRapFirmware-1.09e-dc42 => got print quality issues

You can upload this short file to gcode.ws viewer and slide left-right bottom slider to view what happens.

If I understand right, printer freezes right after printing smallest (inner) circle before going to do bottom level "infill" between outer and inner circle




Edited 1 time(s). Last edit at 08/22/2015 07:08AM by roboprint.

Quote
dc42
PS - don't enable the Move debug (M111S1P4) or any other debug unless you have the USB port connected to a PC and a program such as Pronterface ready to receive it. The debug code uses blocking I/O to make sure that none of the debug output gets lost, and that may cause the main loop to hang if there is nothing to receive it.

Well that explains one problem I had today...

Quote
roboprint
If I understand right, printer freezes right after printing smallest (inner) circle before going to do bottom level "infill" between outer and inner circle

I found a likely cause of the problem - I introduced a possible race condition in one of the changes I made in the test version. Please try the binary now at [dl.dropboxusercontent.com].

Quote
shadowphile
Well that explains one problem I had today...

I've logged this as a bug. In the next release, I'll introduce a timeout to detect blocking caused by lack of a consumer for the data.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Looks like this freeze bug is fixed, first 10 layers is printed without problems, still carefully look at my printer.

update: first 50 layers of 306 is printed without issues

Edited 1 time(s). Last edit at 08/22/2015 01:04PM by roboprint.

Quote
roboprint
Looks like this freeze bug is fixed, first 10 layers is printed without problems, still carefully look at my printer.

Glad to hear it! Please can you try pause/resume and see if that is fixed too.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I think pause/resume bug is fixed now, but seems like now I have another type of first bug (from topic start, "seams"). I don't know who is responsible now for this seams (mechanics, slicer, or firmware), I need more time to figure it out. I will post additional info later as I print test models.

update: I'm preparing photos of this seams, I will upload this in 10-20 minutes

Edited 1 time(s). Last edit at 08/22/2015 03:33PM by roboprint.

Its very hard to take photo of this seams on red semitransparent plastic in my light, so I drew blue lines parallel to the seams and blue arrows pointing to seams.








Rose is this model: [www.thingiverse.com] Sliced with Cura. G-code is available in zip archive on previous page.
Ring is just cylinder-25-30-1024_cura.gcode with 0.1 layer height and 250% speed (about 50 mm/second): [link-removed]

I don't know who is responsible for this now, as both models sliced with Cura.

Model of cylinder sliced in Slic3r with 0.3 mm layer is printed perfectly.

Edited 3 time(s). Last edit at 08/23/2015 04:01PM by roboprint.

Quote
roboprint
I don't know who is responsible for this now, as both models sliced with Cura.

Model of cylinder sliced in Slic3r with 0.3 mm layer is printed perfectly.

I guess you will need to try printing the Cura-sliced models using your other electronics and firmware in order to find out. Have you tried slicing the rose in slic3r?

I'll take a look at the gcode for the Cure-sliced ring. What is the alignment of the seam?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

It's not very simple task to connect back ramps electronics, but I will try one more time. I still think problem is in firmware. First, I will try to reproduce the problem by using another slicer or another models.

Seam position is unknown for now, as I forgot to mark rings positions on printer bed.

[link-removed]

David, please try to print both attached g-code files (sliced with cura and slic3r), both files are printed on my printer with audible micropauses and seams. Please print at least 3-5 mm of height.

Seams on slic3r model is every 5-7 millimeters of perimeter. Model, sliced with Cura is just making printer weird after 3-5 mm of print height, it looks like CPU completely overloaded or something like this.

Slic3r model is printed at 100% speed, Cura model is printed at 250% speed

Edited 3 time(s). Last edit at 08/23/2015 04:01PM by roboprint.

I just printed your 0.1mm Cure-sliced cylinder. There is a very slight seam, present on some layers only, that I can feel better than I can see. It is at the 4 o'clock position, lined up exactly with the point at which the print finishes. Looking at the gcode, I see that Cura has inserted some tiny non-extruding moves at exactly those points on some layers. Here is an example:

G1 X8.497 Y-23.298 Z29.599 E806.73345
G1 X9.061 Y-23.086 E806.74347
G1 X9.629 Y-22.854 Z29.600 E806.75367
;LAYER:293
G0 F6000 X9.629 Y-22.853
;TYPE:WALL-OUTER
G1 F1080 X10.188 Y-22.610 E806.76381
G1 X10.736 Y-22.355 E806.77386
G1 X11.281 Y-22.086 Z29.601 E806.78397

Notice the G0 move by 0.001mm. What I am seeing on the simulator is that 2 times out of 3, this tiny move does not change the stepper endpoints, so the move will be thrown away. The other 1 time out of 3, it will be executed. This raises a number of potential problems:

1. There is no extrusion in this move, so the extruder has to stop. This may cause a deceleration at the end of the previous move.

2. The requested feed rate is 6000, much higher than the feed rate of 1080 being used for the normal moves.

3. The apparent direction of the move is sharply different from the tangent of the cylinder at that point, because it's generally a pure X or a pure Y movement.

IMO this is a bug in Cura. I guess I could work around it in the firmware, but once I start adding workarounds for one slicing bug, where do I stop? Also, I am puzzled as to why Cura uses G0 instead of G1 for that command. Does Cura expect printers to handle G0 differently from G1?

You might like to try commenting out all those G0 F6000 lines - I think that will get rid of that tiny seam.

I'll try the files you just uploaded next.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I agree with you, adding workarounds for slicer bugs is not the best solution.

But I cannot print with both Slic3r and Cura slicers. What slicer and its version you use?

I just printed the slic3r version of the cone from your zip file. I could not see any micro pauses, and there are no seams. There is faint horizontal banding at 10mm vertical intervals.

I'll try the Cura version now.

PS - I am using version 1.09-rc1, available here [github.com] (follow the link and then press the raw button to download it).

Edited 1 time(s). Last edit at 08/23/2015 08:10AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

David, have you changed anything in moving code in the new firmware since this post, where you fixed freeze?


update: I'm asked this question before your edit previous post with firmware details. I will try new firmware version now.

Edited 1 time(s). Last edit at 08/23/2015 08:13AM by roboprint.

Seems like something is fixed in RepRapFirmware-1.09grc1-dc42.bin (md5 is 3559f26f8a1ac893f83eb713fbff42cd), Slic3r model is printing perfectly now:



Upper ring is old firmware (where freeze is fixed), lower ring is this newest firmware

Edited 1 time(s). Last edit at 08/23/2015 08:33AM by roboprint.

1.

Quote
roboprint
David, have you changed anything in moving code in the new firmware since this post, where you fixed freeze?

No. The changes between the version that you had the freezing problem with and 1.09g-rc1 are in this commit [github.com]. The Move module change is the fix for the freezing problem. The Platform changes are so that if you have debug output enabled but you don't have any program to consume the debug data sent over USB, it gives up trying to send the debug data.

Please note, if you have debug enabled and any debug data is generated then this may cause stuttering, because Pronterface is rather slow at consuming the debug data, and the firmware will wait a little while for the data to be consumed so that debug data is not lost.

2. I tried the Cura version of the cylinder. The print was very jerky when printing the skirt, but smooth after that. This time there is a very pronounced seam at the 5 o-clock position. One look at the gcode showed why:

G1 X8.420 Y-33.627 E76.01848
G1 X9.242 Y-33.410 E76.03262
G1 X9.449 Y-33.351 Z0.600 E76.03620
;LAYER:3
G0 F6000 X9.234 Y-33.381
;TYPE:WALL-OUTER
G1 F1560 X9.849 Y-33.204 E76.04684
G1 X10.457 Y-33.018 E76.05741
G1 X10.658 Y-32.954 E76.06092

Once again there is the G0 F6000 move. This time it is not by 0.001mm, it is by about 0.2mm in X and 0.03mm in Y. So it's asking to stop extruding while it makes a small jump in the XY plane. My guess is that Cura is accumulating some rounding error as it draws the spiral, and when it gets back to the starting position it is trying to correct for it by making a jump. This is IMO very definitely a Cura bug.

I suggest you report this bug to the people who maintain Cura. It may be that this bug only affects spiral vase prints, in which case it might not matter much as spiral vase mode is rarely used in real prints..

Edited 1 time(s). Last edit at 08/23/2015 09:39AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

David, thank you very much for you help!

Slic3r's code is now printing just perfect:


Cura printed model (I'm using 250% speed set via Web UI) is contains seam and 4 symmetric areas where effector is jerky (not at every layer), this looks like area about 3-7 mm of perimeter with nano (not micro) pauses. Sensible by fingers then you touch carets. One of this area is near seam (seam at the right):


I think I will not pay attention to this. Looks like everything is OK now. Thank you again!

Now I will try to print rose model (from this topic), I will check differences.

Update: just finished printing rose using this yellow transparent plastic. WHOLE rose surface contains random blobs, it is extremely difficult to take photo of this blobs. Previous (red) rose have much smoother surface.

Edited 2 time(s). Last edit at 08/23/2015 12:29PM by roboprint.

The seam on that Cura cone print is identical to the seam I got - it wiggles at the bottom and becomes straight higher up. I didn't get the 4 poor areas you describe, but I didn't print it at high speed. It could be that there is a shortage of throughput at high printing speeds when printing the very short segments that Cura generates. I have some work in hand on increasing the maximum travel speed by reducing processor load in the step ISR, which may help.

Regarding your yellow filament rose, if the red one printed OK using the same gcode, settings and speed, then it could be a problem with the filament, e.g. water absorption - unless you can see that the blobs are being caused by pauses .

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I just tried again rose using red plastic - everything is OK. So I think this issue is fixed now.

Both yellow and red PLA plastics are from one manufacturer, purchased at the same time, sealed in the two plastic bags with silica gel bag. Both spools are newly open. Also yellow cone is printed very well, so I thought plastic isn't affect print quality. It seems that I was wrong. I will test yellow pla again later.

Thank you!

Wow!

It's been happening a lot here I see!!

Been away for the weekend.

Kudos to you David, great support!!

I believe the entire community owes you a couple of pints, I certainly do anyway!

Quote
roboprint
I just tried again rose using red plastic - everything is OK. So I think this issue is fixed now.

Both yellow and red PLA plastics are from one manufacturer, purchased at the same time, sealed in the two plastic bags with silica gel bag. Both spools are newly open. Also yellow cone is printed very well, so I thought plastic isn't affect print quality. It seems that I was wrong. I will test yellow pla again later.

Thank you!

Can we add SOLVED to the topic name then?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Can we add SOLVED to the topic name then?

Sorry, I have no ability to do this. There is no edit link in first few posts in this topic. Seems like edit feature available only 2-4 days.