Another freeze problem...

Hi,

I just experienced a new freeze problem.

I tried to print a larger object with a gcode file of 9.101KB. My printer is equipped with ferrit cores both on the USB and the mains cable. I run the most recent firmware version 059. The object I tried to print is 100*100*84 but stops at line 23260. All the time.
After the print stopped I can't connect to the printer - it looks like it's frozen. I have to reset the printer by disconnecting the USB cable to get the printer responding again.

Those are the lines before the print stopped from the debugging window:

file: G1 F1500.000 E-0.20000
file: G1 X101.740 Y89.751 F3600.000
file: G1 E4.00000 F1500.000
file: G1 X101.002 Y90.098 E0.04067 F1200
file: G1 X100.201 Y90.251 E0.04067
file: G1 X99.388 Y90.200 E0.04067
file: G1 X98.613 Y89.948 E0.04067
file: G1 X97.924 Y89.511 E0.04067
file: G1 X97.366 Y88.917 E0.04067
file: G1 X96.974 Y88.202 E0.04067
file: G1 X96.819 Y87.600 E0.03100
file: G1 X96.771 Y87.413 E0.00967
file: G1 X96.771 Y86.598 E0.04067
file: G1 X96.983 Y85.770 E0.04261
file: G1 X97.366 Y85.094 E0.03880
file: G1 X97.924 Y84.499 E0.04067
file: G1 X98.613 Y84.063 E0.04067
file: G1 X99.204 Y83.871 E0.03100
file: G1 X99.388 Y83.811 E0.00967

and those are some lines of code that follows in the original g-code file (and of course much more lines to follow):

G1 X100.201 Y83.760 E0.04067
G1 X101.002 Y83.912 E0.04067
G1 X101.740 Y84.259 E0.04067
G1 X102.368 Y84.779 E0.04067
G1 X102.847 Y85.439 E0.04067
G1 X103.147 Y86.196 E0.04067
G1 X103.249 Y87.005 E0.04067
G1 X103.147 Y87.814 E0.04067
G1 X102.847 Y88.572 E0.04067
G1 X102.368 Y89.231 E0.04067
G1 X101.797 Y89.703 E0.03693
G1 X101.740 Y90.251 F3600.000
G1 X102.010 Y90.176 F3600.000
G1 X101.158 Y90.577 E0.04697 F1200
G1 X100.233 Y90.754 E0.04697
G1 X99.293 Y90.695 E0.04697
G1 X98.398 Y90.404 E0.04697
G1 X97.603 Y89.899 E0.04697
G1 X96.959 Y89.213 E0.04697
G1 X96.505 Y88.388 E0.04697
G1 X96.335 Y87.725 E0.03415
G1 X96.271 Y87.476 E0.01282
G1 X96.271 Y86.534 E0.04697
G1 X96.595 Y85.270 E0.06511
G1 X96.699 Y85.270 E0.00515
G1 X96.959 Y84.797 E0.02693
G1 X97.603 Y84.111 E0.04697
G1 X98.398 Y83.607 E0.04697
G1 X99.049 Y83.395 E0.03415
G1 X99.293 Y83.316 E0.01282
G1 X100.233 Y83.257 E0.04697
G1 X101.158 Y83.433 E0.04697
G1 X102.010 Y83.834 E0.04697
G1 X102.735 Y84.434 E0.04697
G1 X103.289 Y85.196 E0.04697
G1 X103.635 Y86.071 E0.04697
G1 X103.753 Y87.005 E0.04697
G1 X103.635 Y87.939 E0.04697
G1 X103.289 Y88.815 E0.04697
G1 X102.735 Y89.576 E0.04697
G1 X102.068 Y90.129 E0.04323
G1 X101.158 Y90.577 F2880.000 E-0.50187

The gcode looks ok for me, but even if there was an error with the code, would the printer freeze at all? I already checked the memory usage in the debugging window but the values seemed to change at no time.

And a photo which shows that the print stopped exactly at the same point:



Perplexed.

Markus

Edited 1 time(s). Last edit at 01/16/2014 07:39AM by markbee.

---

XBee & electronics blog: [lookmanowire.blogspot.com]

@Markus, this must be firmware surely? What else could stop at exactly the same point. Sounds like an array, count limit, memory limit....
Print looks good to that point though!

---

Ormerod #007 (shaken but not stirred!)

markus, I'm guessing that you had "wipe on retract" on - nothing else looks odd to me other than the two extruder moves at the top, but these would be normal if you're wiping on retract (it retracts in stages as it moves x and y, then moves forwards by the sum of these small steps in one go as it continues printing). Do you get the same halt if you send the file over USB instead? (I'm interpreting the "file:" at the beginning of each line to mean the file is coming from SD currently).

Ray

It looks like a firmware issue to me. If you are printing over USB and the debug window is showing lines sent (rather then echoing lines received), then the problem could be quite a lot earlier in the file because of the buffering in the USB subsystem. You could try truncating the file around that point and then appending the end-of-print stuff. By this means you could track down exactly where in the file the problem is.

Bear in mind that the Duet branch of the firmware is experimental and contains some changes to the velocity management that are flagged as incomplete. It might be worth trying the 056 057 firmware, or this firmware which contains all the latest changes except for the velocity management changes.

Edited 1 time(s). Last edit at 01/16/2014 04:48AM 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].

Hi Ray & dc42,

yes I had wipe on retract set to enabled. Would this make a difference in freezing the printer at some time? The print was printed both times from SD card.
I will now try to print the file from USB, wipe on retract disabled (with which I made some other prints before and had no freezing problems).

After that I wil try older firmware as suggested by dc42.

Markus

Edited 2 time(s). Last edit at 01/16/2014 04:43AM by markbee.

---

XBee & electronics blog: [lookmanowire.blogspot.com]

I wasn't suggesting that wipe on retract was to blame( though of course it might be), just that if it isn't enabled then the E move before the E4.0 should have been E-4.0 (retraction), and (if it wasn't enabled, and the E4.0 wasn't preceded by E-4.0 and a Z move), it would have suggested that some lines had gone missing.
I'd change one thing at a time if I were you - try from USB with the PC master copy of the file that you originally copied to SD, if that fails, then try reslicing and printing without the wipe on retract maybe, or just try one of dc42's suggested firmware versions on the current file you have on SD.

Ray

Edited 1 time(s). Last edit at 01/16/2014 04:50AM by rayhicks.

As you were printing from SD, can you provide a few more lines before the point of the hang? There is a 20-entry lookahead buffer, so the problem may be a little earlier than the lines you have already listed.

---

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

Did some tests with a truncated file (attached as laser1.g).

Tested fw versions 054, 057 and 059 all froze at the exact same point both via SD card and USB.

I have also attached the debugging window output both from a SD card print as from a print over USB (see attached).

Markus

---

XBee & electronics blog: [lookmanowire.blogspot.com]

From the SD debug output, it looks to me that it is failing at or just after a wipe-before-retracting. Have you tried turning that setting off?

---

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

Thx dc42,

recompiled gcode from .stl this time w/o any change to the slic3r settings (except retraction length) from the ormerod.ini file.

Now printing...

Markus

---

XBee & electronics blog: [lookmanowire.blogspot.com]

Markus, I just printed your original snippet fine (I did comment out the temperature changes at the beginning since I'm using ABS, but left the movement and extrusion commands untouched)

after the first run I added a "G1 X10" just to maake sure it was actually completing, and ran it again and it reached that command for sure.

I printed over USB

Ray

It printed well beyond the point now, where it stopped before. Hope the print gets finished.

It's still funny it printed on rayhicks printer, who supplies 5V from the 12V PSU and not on my - my board only runs on 5V from USB. Maybe that is the reason for stopping?

[EDIT] I will run the test gcode-file with 5V supplied from the PC ATX PSU later to see if it makes a difference.

Markus

Edited 1 time(s). Last edit at 01/16/2014 09:28AM by markbee.

---

XBee & electronics blog: [lookmanowire.blogspot.com]

If the Slic3r settings are different and its fixed then this looks like a Firmware bug.

I will have a look into it.

Tony

---

DuetWifi.: advanced 3d printing electronics

I've been dealing with this same problem today. The print hangs up at the same point in many different attempts, just like markbee. I took the 100 or so lines of code around the spot where it freezes and put the snippet in its own file. I was able to replicate the freezing this way, repeatedly. I finally isolated the freezing spot to the second line in the three wipe-while-retracting lines. So i deleted all three of the wipe lines and lo and behold, it ran thru the whole file.

Here's where it gets weird, i put the wipe lines BACK in the code, but I cut the feedrate on those lines only, in half. AND IT WORKED. It wiped slowly, moved on, and did not freeze.

I ended up just turning off "Wipe While Retracting" so I could continue printing today, but I'm worried that this may be indicating an underlying issue with power management on the board or something like that. I haven't had the printer very long so I know nothing about any overload settings. My gcode is attached in the original "freezing" state. It froze on line 120 of this file.

Hi jordanD85

Thanks for the example. I will pass it on to Adrian Bowyer, to see if he can replicate this. What firmware version are you on?

Ian
RepRapPro tech support

Hi Ian,
I'm on version 0.50. I'll update to the latest right now and see if there's any effect.

Jordan

I doubt it will, but do it anyway! 'master' firmware branch, or 'duet' (asks Adrian)?

Ian
RepRapPro tech support

Edited 1 time(s). Last edit at 01/21/2014 06:55PM by droftarts.

Ian,
Master firmware I believe it was. And I was doubtful that it would help as well, but it seemingly HAS helped! I followed the firmware update instructions here

[www.reprappro.com]

which I believe directs me to download the master firmware. In any case, the same g file posted above is now no longer freezing! Note that I did run two small print jobs between the freezing I described earlier and updating the firmware.

My day is nearly done here but tomorrow I'd like to actually roll back to the old 0.50 firmware version I had previously, to confirm that this is the solution. Where can I find former builds of the firmware?

Thanks,
Jordan

I printed 2 filament reel holder yesterday, both printed via SD card. It halted halfway. Pronterface ( print run actually , Reprap Pro Pronterface won't work in my new Imac. , still crack my head to find a solution to make it work ) shows USB connection lost, I disconnect and connect back, and the printer start continue where it stop. It happened virtually every larger prints ( anything larger than the snowman test print file. ) .

Sill no clue what happened. Maybe Reprap Pro version of pronterface will cure this , still try hard to find a solution to install it in my Mac.


Ew

I can also confirm that I cannot complete a print with the "Wipe While Retracting" selected.

@Jordan: Great! Thanks for checking. I'm not sure what will have changed between the two firmwares to change this behaviour, though. I've passed your comment on to Adrian to investigate. Old downloads can be accessed by going to the 'Release' folder on Github, then clicking 'History' at the top of the page, then choosing a date you want and clicking 'browse code' on the right-handside of that line. This shows the 'Release' folder on that date. You can download the individual file by clicking on it, then download the 'RAW' version of the file - if you don't do this you get an file with the correct filename, but is actually an html file! 050 is here: [github.com]

@Ew: Is this printing from SD card, or over USB? If it's restarting after you disconnect and reconnect, it's not the same bug as reported in this thread. If you're printing from SD, it's more likely that the printer is sending debug information back to your computer over USB, but then doesn't get a response (if, say, your computer goes to sleep), so stops. If you're printing over USB, I'm surprised it survives being unplugged and plugged back in again. Either way, it would seem to be a different issue, and not relevant to this thread!

@johneato: which firmware?

Ian
RepRapPro tech support

Edited 1 time(s). Last edit at 01/22/2014 05:35AM by droftarts.

Ian
From the horses mouth

FIRMWARE_NAME:RepRapFirmware
FIRMWARE_VERSION:0.57 ELECTRONICS:
Duet DATE:2014-01-13
John
Ormerod 096

Yeah, I'm printing from SD card. sorry for hijacking this thread, just mention this and see if anyone having the same problem.

Ew

To follow up on my testing, today I got a chance to roll my firmware back to the 050 version. I ran my bit of code which previously cause a freeze (see above) and IT FROZE. I was very surprised but it seems that some change in the latest firmware has fixed my problem. Re-flashed the new firmware and ran the same code, no freeze!

I'm running a longer print now, we'll see if I have any additional freezes.

Jordan

After 3 duff prints cos a part of the print broke away, the machine got upset and stopped in its tracks....

Froze solid part way through a print...

Firmware 57.. From SD card...

Edited 1 time(s). Last edit at 01/23/2014 08:48PM by KimBrown.

Sorry to hear that. I list the known and speculated causes of random print hangs, along with solutions, in my unofficial Ormerod troubleshooting guide at [forums.reprap.org].

---

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

Well, things seemed great for a while after my firmware update as mentioned above. But then just today I had another freeze up.

I went and turned "Wipe While Retracting" off and that fixed the problem for me. This is unfortunate cause I really like having that feature on. I still think this is a power management issue, although I cant prove it. When the machine freezes it seems to start the retraction, and then just sort of give up.

-Jordan

Quote
jordanD85
Well, things seemed great for a while after my firmware update as mentioned above. But then just today I had another freeze up.

I went and turned "Wipe While Retracting" off and that fixed the problem for me. This is unfortunate cause I really like having that feature on. I still think this is a power management issue, although I cant prove it. When the machine freezes it seems to start the retraction, and then just sort of give up.

-Jordan

If you have a file that reliably causes the printer to freeze, please post it and I will try to find time to investigate.

---

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

Hello,
I have a similar issue, but at the moment I'm using DC42's latest firmware in combination with iamburny's web interface (looks really great!). This issue happens as well when using RepRap's official firmware. Several prints froze at exactly the same point, however, using the new firmware and web frontend my Ormerod does not freeze completely. Using the web frontend, I can still see temperature changes and the heated bed turning on and off (which was not the case using the official RepRap firmware) but it does not respond to any commands. A simple way to reproduce this problem seems to be printing a relatively big part (in my case 170x85 mm) and changing the following settings in Slic3r:

Infill
Top/bottom fill pattern: hilbertcurve (slow)
Only retract when crossing perimeters: OFF

Extruder 1 -> Retraction
Lift Z: 0.1

I used a different fill pattern first (rectilinear), but when using the settings above, my Ormerod froze right at the first layer after about 30 minutes. The debug log only echoes G1 moves as reported by markbee, but after it freezes, I cannot interact with my Ormerod any more - only a hard reset helps.

Every time my Ormerod freezes it seems to happen just before it lifts the print head, but I don't know how to investigate this problem any further. For now, I'll enable "Only retract when crossing perimeters" again and report whether this setting affects my Ormerod freezing. Any help is greatly appreciated!

Since you have "Lift Z" in there, my guess is that it's the problem with combined XZ, YZ and XYZ moves that's the culprit. Adrian at RRP is working on this, so I've left that area alone.

---

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