Firmware bug

I've just had a print (of the extruder housing) stop at the same place 3 times in a row. As I have seen other people reporting the same thing, it seems that there is definitely a bug in the firmware. I had Slic3r set to "wipe after retract" which is perhaps what is creating the problem G code, though I have printed other parts successfully with the same setting, so it appears to be part-dependant. I will now re-slice the part without "wipe on retract" and see whether that gets further.

Dave
(#106)

I was wrong - it's not the firmware. The issue with that one seemed to be Slic3r. The re-sliced file was much bigger than the problem file, so I sliced again with the original settings and it made a bigger file than it had at first. Looking into the problem file, it ends in the middle of a move, so it was truncated. I've noticed that slic3r sometimes stalls on my system (W8), so perhaps that's what happened the first time. I'll check the files in future to ensure they always end with the "park & turn off" code.

Quote
dmould
I've noticed that slic3r sometimes stalls on my system (W8), so perhaps that's what happened the first time.

Mine stalled twice on the same spot ina print today, too. What I saw was that slic3r was flahing when it reported that it was done converting the file. Might that have something todo with it? Or indicate that slic3r actually crashes?

---

RS Ormerod #374

I've noticed that slic3r sometimes takes an AGE to export the gcode file (I don't recall this happening before I updates to version 1.0 rc2) - I normally invoke slic3r from inside repetier host, and wait for the gcode to appear in the preview window, but yesterday tested to see if the delay was due to repetier or slic3r, and found that slic3r does the same thing in standalone mode (slices quite happily and fast, but takes ages to export the gcode) - it IS though still possible to open the partially exported file in another program (which I did for the hell of it in repetier while I waited), maybe this is what you guys have hit against? I use a mac, and it may be that the exports slow down is mac specific (or maybe just on my laptop for all I know).

Ray

I found that slic3r exports a lot faster if i uncheck "Avoid crossing perimeters"

this bug may be the cause [github.com]
edited: link description added

Edited 1 time(s). Last edit at 01/20/2014 02:39PM by auser.

In the case in question, I started slicing the problem code while my fan duct was printing, so Slic3r had been working for over an hour (even big STLs only take a few minutes to slice on this PC). I must confess I did not check to ensure it had finished, just assumed it must have completed after all that time, closed it down and copied the G file to the SD card. Sometimes Windoze brings up the "program has stopped responding" message with Slic3r, and I have to end the program and do it again - usually works fine the second time.

Quote
Kilpikonna

Quote
dmould
I've noticed that slic3r sometimes stalls on my system (W8), so perhaps that's what happened the first time.

Mine stalled twice on the same spot ina print today, too. What I saw was that slic3r was flahing when it reported that it was done converting the file. Might that have something todo with it? Or indicate that slic3r actually crashes?

Slic3r flashes when it has finished slicing and you are in a different window (e.g your internet browser). If you are within slic3r when it finishes it does not flashes. For as long as there is still progress on the progress bar within slic3r the gcode files continues to be written into. Slic3r seems to write sequentially into the gcode file (you can see the file size increase during slicing from you file browser.
If you copy or upload a file to SD card before slic3r has finished then you only get part of the gcode file and your print will not finish.

Slic3r seems to require a fair bit of resources and when my computer is heavily loaded it takes longer to slice files.

Edited 1 time(s). Last edit at 01/20/2014 08:12PM by arnaud31.

I have given up on using 1.0RC2 because of the incredibly slow time to write the G-code file. The earlier versions of Slic3r just take a few seconds to maybe a minute on my Win-7 computer, but Slic3r 1.0RC2 can take 5 minutes for a simple model and 20 minutes for a complex one. All the settings are the same (including avoid crossing perimeters, which is a necessity for me printing with nylon).
Looking forward to a bug fix!

@dmould you might be right with your initial suspicions. I spent several hours last night wrestling with a print that stopped the printer dead at the completion of the perimeter loop every time.

I tried making changes to the source model, and to the Slic3r settings, even changed the firmware to dc42s' latest.
Nothing made any difference - until I unchecked 'wipe on retract' and I've tried several new versions this afternoon with no problems at all.

Curiously, it ran normally printing over usb, but every problem version stalled every time running from the SD card. The only way to get control back was to cycle the power and the usb - or am I missing a trick?

Dave

@epninety, do you still have that gcode file that stops the printer after completing the perimeter loop? If so then I'll take a look. Problems have been reported with "wipe on retract" before, but nobody has supplied me with a reproducible test case yet.

---

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'm pretty sure this is one of the ones that caused problems, but the printer is busy right now, so can't check it.

dropbox link

Dave

RetireeJay - it seems to me that this isn't an Ormerod issue and definitely looks like it's a slic3r problem, I have the same in MacOS X and threw a problem stl at a colleague so he could try it in Win7 and linux (I'm not sure he did the linux attempt, giving up after two hours in Win7) - the slicing itself was pretty rapid on both platforms using slic3r, but the saving is in tiny dribs and drabs. I had a go with Cura, which sliced and saved the same stl within seconds (unfortunately it seems to have no way of setting relative E distances - it may have but I didn't find it). The model I was slicing was a 155(x)x195(y)x30(x) model with fairly simple (cylinders and cubes) components- it took over 4 hours to export on my mac with quad cores, 400gigs of free space and no disc issues.

Simple models slice and export in the wink of an eye, but larger (and maybe more complex) models grind to a halt in the export phase - I guess they've changed the export algorithm in slic3r to something with an exponential or factorial order, and don't notice it in their test cases.

The only "bug" in ormerod/duet firmware that's impacting this for me is the lack of support for absolute extruder distances (since cura manages very well to slice and export "problem" files, but the firmware doesn't handle absolutes on E very well - interestingly, if it's the first thing printed, it prints OK, but if you stop the print then try running a new job sliced with absolute E distances, or try to do a second print after the first successful one, the Ormerod/duet does the infinite retraction - even if you comment out zeroing of E distances).

Nylon eh? what temperatures are you using for that - and what supplier please?

Ray

Edited 1 time(s). Last edit at 02/08/2014 04:40PM by rayhicks.

I'm sorry to use the wrong thread. I searched for Slic3r being slow, and this is what I found. I'm sure there's already a topic about it somewhere but I didn't know where to look.

I do wish that Slic3r 1.0.0 could get fixed; I like some of its new features.

I'm printing Taulman 645 nylon at 235C. I just recently learned that I can specify a very fast "retract" for the extruder when preparing for non-printing moves, and it has revolutionized my printing. I used to get lots of threads and/or blobs, but now I'm getting rather nice looking prints that need almost zero cleanup.

Quote
epninety
I'm pretty sure this is one of the ones that caused problems, but the printer is busy right now, so can't check it.

dropbox link

Dave

@epninety, the first time I tried that file, it stopped immediately after the first skirt loop. However, every time since then, it has carried on. So it looks like there is some kind of a problem, but I haven't been able to debug 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].

Some kind of timing issue maybe? Happy to try it again here - is there any kind of debug output I can capture for you?

Quote
epninety
Some kind of timing issue maybe? Happy to try it again here - is there any kind of debug output I can capture for you?

Yes. Connect Pronterface even if you are printing via the web interface. When you have homed the axes etc. and are ready to print, send M111 S1, then start the print either in the web interface or from SD card via Pronterface. When the print hangs, press the Disconnect button in Pronterface or the reset button on the printer, copy all the messages in the Pronterface log window into a text editor, and save the file.

---

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

If its of any use, here's a log taken from that file crashing, with a copy of the file. Note that it crashes only when run from SD, it worked fine printed via USB, but I don't get good prints that way, and I don't want to tie up the computer, so I don't use it that way normally.

[dl.dropboxusercontent.com]

Dave