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

Hello.

I'm moved from Arduino Mega 2560 + RAMPS 1.4 + A4988 + LCD12864 + Repetier firmware to Duet electronics (v0.6 from Replikeo) + RepRapFirmware 1.09e from dc42.

And now I'm experiencing print quality issues. I'll be grateful if someone could confirm or deny the existence of these problems for you.

My setup: Kossel Mini printer from builda3dprintereu shop, XYZ motors are Wantai 42BYGHW811 2.5A, extruder motor is Wantai 42BYGH4413A G5.18-X 1.3A (with 5.18:1 planetary gears), hotend is original E3D v6. I'm using LED power supply (12V 30A, real voltage on board terminals is 12.3V in idle and 12.2V with all heaters enabled). V-rollers used on 1515 extrusions. Glass heated bed, mechanical endstop switches. 16-teeth pulleys (100 steps per mm setting). All my prints going from SD-card.

My config mechanics-related is:

M665 R105.08 L214.350 B90 H236.31 X-0.20 Y-0.98
M666 X-1.26 Y0.56 Z0.70				; put your endstop adjustments here, or let auto calibration find them
M92 X100 Y100 Z100					; Set axis steps/mm
M906 X1000 Y1000 Z1000 E700			; Set motor currents (mA)
M201 X5000 Y5000 Z5000 E5000		; Accelerations (mm/s^2)
M203 X20000 Y20000 Z20000 E3600		; Maximum speeds (mm/min)
M566 X1200 Y1200 Z1200 E1200		; Maximum instant speed changes mm/minute

After having issues with print quality today I commissioned back Arduino+RAMPS and make test prints, then I commissioned again Duet electronics and make test prints again. All hardware (including sd-card) remains the same.

There is photos of test prints:

Cylinder, 25mm radius, 30mm height (I cancelled print at about 50% of height), OpenSCAD code is: cylinder(r = 25, h = 30, $fn = 1024); Sliced with Cura 15.02.1 in vase mode (0.1mm "layer" height), speed is about 20 mm/second:
Left side = Arduino + Repetier, surface is clean and smooth
Right side is Duet + RepRapFirmware 1.09e-dc42, surface with vertical lined-up blobs:


Cylinder, 25mm radius, 30mm height, OpenSCAD code is: cylinder(r = 25, h = 30, $fn = 1024); Sliced with Slic3r 1.2.9 in vase mode (0.3mm "layer" height), speed is about 50 mm/second:
Left side = Arduino + Repetier, surface is clean and smooth
Right side is Duet + RepRapFirmware 1.09e-dc42, audible pauses ("clicks") while printing where issue marked with arrows, also this clicks sensible then you put your finger on moving tower caret:


Cylinder, 25mm radius, 200mm height (I cancelled print after ~50mm printed), Sliced with Slic3r 1.2.9 in vase mode (0.3mm layer), speed is about 50mm/second, print speed and motors current does not change this pattern, very loud clicks (like firmware freezes printing for 0.1-0.2 second), I checked g-code for visual issues in gcode.ws, proterface and repetier, also I checked step-by-step all moves of few layers in text viewer and I cannot find any issues. File printed using Duet + RepRapFirmware 1.09e-dc42, the same file printing using Arduino + Repetier without issues, surface is clean and smooth.


Cylinder, 35mm radius, 30mm height, Sliced with Slic3r 1.2.9 in vase mode, 0.3mm layer, speed is about 50mm/second, the same lined-up vertical blobs on different sides, printed with Duet + RepRapFirmware 1.09d-dc42:


Vase (http://www.thingiverse.com/thing:85218) scaled to about 38.5 mm height, sliced with older version of Slic3r in vase mode:
Left side = Arduino + Repetier (I forgot to enable cooler, so bottom of vase is melted)
Right side is Duet + RepRapFirmware 1.09d-dc42, this blobs are on the six symmetrical sides of printed vase:


Very big vase (http://www.thingiverse.com/thing:810720), scaled to about 120-130 mm height, sliced with Cura, 0.2mm layer height, printed with Duet + RepRapFirmware 1.09d-dc42, blobs again on six symmetrical sides of printed vase:


Also there is more photos from me in this topic: [forums.reprap.org]

After this tests now I am fully confident that the problem is related to Duet+RepRapFirmware. I think the problem in the firmware, but I can not prove it. During printing, you can hear as well as then you printing with high segment rate and high speed with marlin/repetier firmware and graphic lcd screen (clicks/pauses on screen refresh). Printing stops for a while (<0.1 second) and is well heard, at this moment blobs occurs.

It is strange that all this is repeated, if the print twice the same. As these issues are changing their position in height during printing. They may appear to disappear with a change in height.

Also, 50x50x50 cube in vase mode is printed very well (photos is here: [forums.reprap.org]), so maybe this related to quantity of g-code commands per second or something like this.

Also, I have tried another power supply (from PC), I have tried different print speeds and different stepper currents, I have tried to remove X-0.20 Y-0.98 from M665 command. All without success.

None of this issues available in latest version of Repetier firmware for Arduino+RAMPS shield, so I am sure this is not mechanics-related problem.

I can provide models, g-code files and slicer settings for all this prints.

Can anyone help me explain what is happening and how to fix it?

Edited 1 time(s). Last edit at 08/18/2015 09:57AM by roboprint.

I have attached some of source files for print

Printing....

Forgot to turn my outline speed up so it's more like 30mm/s.

I can definitely see some micropauses though.

But once it finished I could see no blobs or deformation like the ones in the pictures.

I will do a new run at higher speed.

Edited 1 time(s). Last edit at 08/18/2015 12:29PM by Koenig.

Thanks for the sample gcode files. I find that slic3r 1.2.9 is unable to slice a cylinder for me in spiral vase mode, so I'll start from your gcode. I'm tied up right now with shipping some large orders for IR sensor boards, but when that is out of the way I'll see if I can reproduce the problem.

My guess is that it's related to what would be the layer change gcode that slic3r generates at what I presume is the seam position. Here is an excerpt from your gcode file:

G1 Z3.295 X21.872 Y11.691 E151.38588
G1 Z3.297 X21.272 Y12.750 E151.43683
G1 Z3.300 X20.452 Y14.018 E151.50004
G1 Z3.3 F4800.000
G1 X20.452 Y14.018 F4800.000
G1 Z3.302 X19.920 Y14.773 E151.53873 F2400.000
G1 Z3.304 X19.171 Y15.733 E151.58968
G1 Z3.306 X18.376 Y16.655 E151.64063

This pattern is repeated every 0.3mm, always at X20.452 Y14.018. Does this XY position correspond to the position of the seam in your print? There are 2 null moves, which the firmware should be throwing away, but perhaps something else is happening.

One useful thing you could do is connect with Pronterface and send M111 S1 P4 to enable Move module debugging. Then start the print from the SD card however you normally do it, and see if any diagnostics are reported to Pronterface.

Edited 1 time(s). Last edit at 08/18/2015 12:03PM 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].

For some reason I cant get S3D to output anything more than 10mm/s when slicing in vase mode.....
Guessing a bug there.

Edited 1 time(s). Last edit at 08/18/2015 01:20PM by Koenig.

Quote
dc42
This pattern is repeated every 0.3mm, always at X20.452 Y14.018. Does this XY position correspond to the position of the seam in your print? There are 2 null moves, which the firmware should be throwing away, but perhaps something else is happening.

XY position of "seam" on cylinder-25-200-1024_03_noauto.gcode is in opposite (diagonal) side of this null moves, don't remember exactly, about X-20 Y10. But this "seams" appears in different quantities and at different positions. Even more, this seams can appear at some print height and disappear at another height.

This, for example, cylinder-25-30-1024_03_noauto.gcode:

Seam marked as "very big" (closer to Z tower) is clearly visible, rest of seams is less visible. But this "very big" seam appearing at the middle of cylinder.

This cylinder is sliced using Cura:


This cylinder is sliced by Slic3r, 200 mm height, but I cancelled print at ~50 mm height, filename is cylinder-25-200-1024_03_noauto.gcode:



David, you say here [forums.reprap.org] that there is bug in movements with small Z-change. In vase mode Z changes for 0.01-0.03 mm per segment, can this affect print quality?

Quote
dc42
One useful thing you could do is connect with Pronterface and send M111 S1 P4 to enable Move module debugging. Then start the print from the SD card however you normally do it, and see if any diagnostics are reported to Pronterface.

Last time I tried this my board just rebooted, but that was long ago, when I was still commissioning board. I will try again today, I need to move my printer closer to computer.

Quote
dc42
One useful thing you could do is connect with Pronterface and send M111 S1 P4 to enable Move module debugging. Then start the print from the SD card however you normally do it, and see if any diagnostics are reported to Pronterface.

There is log:

Connecting...
Printer is now online.
>>> M111 S1 P4
SENDING:M111 S1 P4
Debugging enabled for modules: Move
Class Move spinning.
>>> G28
SENDING:G28
File Calibration/cylinder-25-200-1024_03_noauto.gcode selected for printing
Class Move spinning.
Printing paused
Class Move spinning.

I paused printing after ~6 mm (height) is printed.

Then I moved hotend nozzle very close to most-visible seam in cylinder-25-200-1024_03_noauto.gcode, right position is X-21.27 Y11.42, but there is other less-visible seams.

This is sample code of this seam in cylinder-25-200-1024_03_noauto.gcode:

G1 Z4.306 X-0.000 Y24.800 E173.36486
G1 Z4.308 X-1.217 Y24.770 E173.41582
G1 Z4.310 X-2.431 Y24.681 E173.46677
G1 Z4.313 X-3.639 Y24.532 E173.51772
G1 Z4.315 X-4.838 Y24.323 E173.56868
G1 Z4.317 X-6.026 Y24.057 E173.61963
G1 Z4.320 X-7.199 Y23.732 E173.67059
G1 Z4.322 X-8.355 Y23.350 E173.72154
G1 Z4.325 X-9.491 Y22.912 E173.77249
G1 Z4.327 X-10.603 Y22.419 E173.82345
G1 Z4.329 X-11.691 Y21.872 E173.87440
G1 Z4.332 X-12.750 Y21.272 E173.92536
G1 Z4.334 X-13.778 Y20.620 E173.97631
G1 Z4.336 X-14.773 Y19.920 E174.02727
G1 Z4.339 X-15.733 Y19.171 E174.07822
G1 Z4.341 X-16.655 Y18.376 E174.12917
G1 Z4.343 X-17.536 Y17.536 E174.18013
G1 Z4.346 X-18.376 Y16.655 E174.23108
G1 Z4.348 X-19.171 Y15.733 E174.28204
G1 Z4.350 X-19.920 Y14.773 E174.33299
G1 Z4.353 X-20.620 Y13.778 E174.38394
G1 Z4.355 X-21.272 Y12.750 E174.43490
G1 Z4.357 X-21.872 Y11.691 E174.48585
G1 Z4.360 X-22.419 Y10.603 E174.53681
G1 Z4.362 X-22.912 Y9.491 E174.58776
G1 Z4.364 X-23.350 Y8.355 E174.63871
G1 Z4.367 X-23.732 Y7.199 E174.68967
G1 Z4.369 X-24.057 Y6.026 E174.74062
G1 Z4.371 X-24.323 Y4.838 E174.79158
G1 Z4.374 X-24.532 Y3.639 E174.84253
G1 Z4.376 X-24.681 Y2.431 E174.89349
G1 Z4.378 X-24.770 Y1.217 E174.94444
G1 Z4.381 X-24.800 Y0.000 E174.99539

Cannot see anything strange near X-21.27 Y11.42

There seems to be a hiccup every time one of the steppers changes direction. Are you sure there is no difference in acceleration/speed settings between marlin and duet board? Duet bord has slightly more aggressive settings and causes these backlash pattern?

Just thinking out loud...
-Olaf

Trying out your Gcode "cylinder-25-30-1024_03_noauto.gcode", just changed the temps, printing with PETG.

I have tried manually edited g-code file with all null-moves and F-parameters removed, nothing changed. Now I will try to set exactly the same accelerations and jerk settings as in Repetier firmware

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

I just tried printing your cylinder-25-200-1024_03_noauto.gcode. For the first 18mm of height, there is a single very faint seam at 5 o'clock. For the remainder of the print there are seams at 12 o'clock, 2 o'clock, half past three, and a very faint one at 10 o'clock.

I had Move debugging enabled throughout the print, and no aborted moves were reported. So I don't think it is related to the other issue.

I'm going to look at the other issue first (by plugging the details of the bad moves into the simulator). When I have fixed that, I'll check that this issue is still reproducible and investigate it. It would be helpful to me if you could run the following tests:

1. Run the slic3r version again and see whether the seams come out at exactly the same positions and heights as last time.

2. Re-slice it using the same slic3r settings, but check the "Relative extrusions" box and include command M83 in your start gcode.

Thanks for your patience - David

---

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 can definitely reproduce the behaviour:


That bump is right in between the X and Z-tower.

Higher res for those who want: [someimage.com]

Quote
Koenig
I can definitely reproduce the behaviour:
That bump is right in between the X and Z-tower.
Higher res for those who want: [someimage.com]

Thank you very much! So I am not alone!

I have tried to change acceleration and jerk speeds exactly to Repetier settings - also without success.

Also then I touch by finger my X and Z carets, I feel clicks (micropauses) at this seam blob. At Y caret clicks are felt less.

I've just run the print again, and I can hear when the seams occur. It's at the inflexion points of the carriages. I suspect it is caused by numerical error causing the transition between different phases of motion to be not entirely smooth - which is also the main suspect for the other issue. I hope to have more news tomorrow.

---

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
I've just run the print again, and I can hear when the seams occur. It's at the inflexion points of the carriages. I suspect it is caused by numerical error causing the transition between different phases of motion to be not entirely smooth - which is also the main suspect for the other issue. I hope to have more news tomorrow.

So it looks like 6 symmetrical points with these errors?
1) At Z tower
2) between Z and Y
3) at Y tower
4) between Y and X
5) at X tower
6) between X and Z.

Almost all of this issues appears in my prints near this six points.

Thank you, David. I'm waiting good news from you

_{P.S. Your forum signature is broken, bb-code tag at the end.}

Will that seam only occur with cylinders or is it visible with a hexagon as well? A hexagon would cause less load on the processor.
-Olaf

Quote
o_lampe
Will that seam only occur with cylinders or is it visible with a hexagon as well? A hexagon would cause less load on the processor.
-Olaf

Did you read first post? This blobs and seams occurs on almost every complex models.

I've made some progress on this. The simulator has shown that a 0.03% rounding error in a calculation is resulting in missed microsteps at the ends of some moves. Now I am working out how to do the calculation differently so that it is less sensitive to that rounding error.

---

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 believe this problem and a couple of others reported are fixed in the binary I have put at [dl.dropboxusercontent.com]. Specifically:

1. In non-delta moves (e.g.homing moves), the feed rate specified in the G1 command is now used as the feed rate of the tower that is moving the greatest distance. In consequence, you may need to reduce the feed rate in the initial G1 command in homedelta.g. I have reduced mine to 3000.

2. Fixed a rounding issue that occasionally resulted in aborted moves, in particular on moves with a large XY component and a small Z component.

3. Fixed a rounding issue that sometimes caused the final step in a move that decelerated a tower to zero speed to be delayed, which in turn delayed the start of the following move, causing print quality issues. This is the one that affected the spiral vase cylinder.

I will wait for feedback from the users who were experiencing problems, before I release this version formally.

---

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!

Print quality is now much better!

I tried to print small vase (stl file attached in this thread), and two cylinders (0.1 and 0.3 mm layer height for Slicer and 0.1 mm height for Cura). Vase is awesome.

I still see a moire on 0.1mm layer cylinder with model sliced with Slic3r, but now it is almost not visible. I think this because of slicing using Slic3r.

0.1 mm layer cylinder sliced with Cura is awesome too and have much more smoother surface (but printed with lower speed). I will examine slicing quality between Slic3r and Cura later.

Also, it seemed to me that printing became slightly softer and quieter, but it's probably just a placebo effect

Also, printer is slightly weird after I press pause, cancel and then print another model without printer reboot using web ui.

First time:
1) print cylinder
2) press pause after 3-5 mm of height printed, press cancel
3) enter T0 in console to select tool
4) press home to home printer
5) start printing vase
6) click pause button after 3-5 mm of height printed
7) printer is hang up and restart (by watchdog or something like this)

Second time:
1) print cylinder
2) press pause after 3-5 mm of height printed, press cancel
3) enter T0 in console to select tool
4) press home to home printer
5) start printing second cylinder
6) click pause button after 3-5 mm of height printed
7) printer is hang up with ALL heaters enabled (LEDs is ON on board), I rebooted in this case manually clicking on hardware reset button on board.

Third time:
1) print cylinder
2) press pause after 3-5 mm of height printed, press cancel
3) enter T0 in console to select tool
4) press home to home printer
5) start printing another cylinder
6) printer start heating (initial head temperature before print was slightly higher than selected for second print (215 and 210 degrees)) and printer just entered while (1) loop, so it still working (heating of hotend and hotbed working), but nothing printing. Looks like printer waiting for heating complete, but nothing happens.


So I think I need to reboot printer after each print.

Strange, I frequently pause and cancel prints. One thing I noticed with your prints is that you are using absolute extrusion. So if you are using my original pause.g and resume.g files, you will need to add M83 commands before the G1 E commands in those files. Otherwise the printer will attempt to unload all the filament consumed when you pause. Relative extrusion is recommended with RepRapFirmware, but I am aware that Cura doesn't support it.

I had a watchdog reset happen a couple of times tonight while doing high speed movement tests, because the step ISR was shutting out the tick ISR for too long. I've resolved this by changing the interrupt priorities. I've just uploaded a modified binary to the same location, with that change and some other small changes. You might want to try it.

If the printer resets itself again, please run M122 before you power it down or reset it again and see what reset reason is reported. Also, if the printer appears to hang, please give it at least 20 seconds to see if the software watchdog kicks in. If it does, running M122 after it resets itself will tell you what the machine was doing when the software watchdog kicked in.

The segments generated by slic3r for that cylinder are about 1.2mm long, which may explain the moire patterns you see. I used to see very faint moire patterns on my Kossel prints until I moved to 0.9deg stepper motors. See [miscsolutions.wordpress.com] for before-and-after pictures.

---

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

Bravo to all contributors in this thread!

This forum and their members really make the world a better place ( no sarcasm)

I`ve been around in other forums and in many cases the thread starter would have ended in a flamewar when he tried to point out problems.
Keep up the good work
-Olaf

Edited 1 time(s). Last edit at 08/22/2015 03:34AM by o_lampe.

David, your first version of fixed firmware hangs up completely on attached file printing (first ~11 KB of gcode) after 5-10 seconds of print.

I have tried this 3 times.

M122 output says about hang up in move class:

latform Diagnostics:
Memory usage:
Program static ram used: 41428
Dynamic ram used: 43436
Recycled dynamic ram: 1152
Current stack ram used: 2872
Maximum stack ram used: 4244
Never used ram: 8044
Last reset 00:00:33 ago, cause: software
Last software reset code & available RAM: 0x1004, 6948
Spinning module during software reset: Move
Last message before reset: File Roses/Rose-cura.gcode selected for printing
Error status: 0
Bed probe heights: 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Free file entries: 10
Longest block write time: 0.0ms
Slowest main loop (seconds): 0.005907; fastest: 0.000048
Move Diagnostics:
MaxReps: 0, StepErrors: 0
Heat Diagnostics:
Heater 1: I-accumulator = 2.0
GCodes Diagnostics:
Move available? no
Network Diagnostics:
Free connections: 15 of 16
Free transactions: 23 of 24
Free send buffers: 19 of 20
Webserver Diagnostics:

Platform Diagnostics:
Memory usage:
Program static ram used: 41428
Dynamic ram used: 43436
Recycled dynamic ram: 1152
Current stack ram used: 2872
Maximum stack ram used: 4276
Never used ram: 8012
Last reset 00:00:34 ago, cause: software
Last software reset code & available RAM: 0x1004, 6948
Spinning module during software reset: Move
Last message before reset: File Roses/Rose-cura.gcode selected for printing
Error status: 0
Bed probe heights: 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Free file entries: 10
Longest block write time: 0.0ms
Slowest main loop (seconds): 0.010330; fastest: 0.000046
Move Diagnostics:
MaxReps: 0, StepErrors: 0
Heat Diagnostics:
Heater 1: I-accumulator = 2.0
GCodes Diagnostics:
Move available? no
Network Diagnostics:
Free connections: 14 of 16
Free transactions: 23 of 24
Free send buffers: 19 of 20
Webserver Diagnostics:

Firmware version I downloaded today is also hangs up completely after first ~5 seconds of printing:

Platform Diagnostics:
Memory usage:
Program static ram used: 41492
Dynamic ram used: 43436
Recycled dynamic ram: 1088
Current stack ram used: 2872
Maximum stack ram used: 4252
Never used ram: 8036
Last reset 00:00:33 ago, cause: software
Last software reset code & available RAM: 0x1004, 6904
Spinning module during software reset: Move
Last message before reset: File Roses/rose-test-hang-cura.gcode selected for printing
Error status: 0
Bed probe heights: 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Free file entries: 10
Longest block write time: 0.0ms
Slowest main loop (seconds): 0.010323; fastest: 0.000048
Move Diagnostics:
MaxReps: 0, StepErrors: 0
Heat Diagnostics:
Heater 1: I-accumulator = 2.0
GCodes Diagnostics:
Move available? no
Network Diagnostics:
Free connections: 15 of 16
Free transactions: 23 of 24
Free send buffers: 19 of 20
Webserver Diagnostics:

I'm sorry you are still having problems. Unfortunately, I can't reproduce that problem using the file fragment you attached. It completes on my delta.

Please can you do the following:

1. Follow this link [github.com] and press the Raw button to download that firmware, then try your print with that. I don't expect it to fix the problem, but it is what I am using.

2. Please zip up and attach the whole gcode file, in case a later portion of that file triggers the problem on my machine.

3. If possible, connect via Pronterface and send M111S1P4 before starting the print, then see if there are any diagnostics printed.

If none of that helps, I'll do a special firmware build that records more precisely where in Move it has got stuck. Meanwhile, I'll review the code in case I can spot something.

Which time zone are you in?

---

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

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.

---

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

Thank you, my timezone is UTC+02:00. My time is 12:22 now (24-hour format). I will do everything that you offer me in your post, connecting laptop to printer now.

None of this help me.

I have uploaded your latest firmware from github (with bossac firmware verification after upload), firmware md5 is dd71620df73758f94c963a49d29dc9ee

My full printer config and g-code files is here: [link-removed]

I provided full g-code version and short (~11KB ) version. My short version is able to hang up printer in the same position every time.

M111 isn't help. Output from proterface:

Connecting...
Printer is now online.
Debugging enabled for modules: Move(4)
Debugging disabled for modules: Platform(0) Network(1) Webserver(2) GCodes(3) Heat(5) DDA(6) PrintMonitor(7)
File Roses/rose-test-hang-cura.gcode selected for printing

Output from WebUI:

13:32:03 Connection established!
13:31:55 Disconnected.
13:29:48 M32 Roses/rose-test-hang-cura.gcode File Roses/rose-test-hang-cura.gcode selected for printing
13:29:04 M111 S1 P4 Debugging disabled for modules: Platform(0) Network(1) Webserver(2) GCodes(3) Heat(5) DDA(6) PrintMonitor(7)
13:28:54 Connection established!
13:28:53 Page Load complete!

Output from M122:

Platform Diagnostics:
Memory usage:
Program static ram used: 41492
Dynamic ram used: 43436
Recycled dynamic ram: 1088
Current stack ram used: 2872
Maximum stack ram used: 4196
Never used ram: 8092
Last reset 00:00:22 ago, cause: software
Last software reset code & available RAM: 0x1004, 7036
Spinning module during software reset: Move
Last message before reset: File Roses/rose-test-hang-cura.gcode selected for printing
Error status: 0
Bed probe heights: 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Free file entries: 10
Longest block write time: 0.0ms
Slowest main loop (seconds): 0.006498; fastest: 0.000048
Move Diagnostics:
MaxReps: 0, StepErrors: 0
Heat Diagnostics:
Heater 1: I-accumulator = 2.0
GCodes Diagnostics:
Move available? no
Network Diagnostics:
Free connections: 15 of 16
Free transactions: 23 of 24
Free send buffers: 19 of 20
Webserver Diagnostics:

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

I have attached freeze position (green arrow), this position is always the same: