0.7.0 Feedback
Posted by droftarts
|
0.7.0 Feedback February 27, 2012 05:08AM |
Registered: 12 years ago Posts: 1,611 |
Wow, what can I say, THANK YOU Alessandro! 
I've tried 0.7.0 out on a few stls I was having trouble with in 0.6.0, and they sliced quickly and without issue. And looking at the paths in pronterface, they look fine, and perhaps with less non-printing moves than before - have you done some path optimisations in this version too? And I now finally have a reason to fit a fan, as you have included sensible fan control!
Anyway, once again, many thanks for your continued work, it is much appreciated.
I would encourage everyone who uses Slic3r to make a donation to Alex, whatever you think is appropriate and can afford. I did! There is a link on [slic3r.org]
I've tried 0.7.0 out on a few stls I was having trouble with in 0.6.0, and they sliced quickly and without issue. And looking at the paths in pronterface, they look fine, and perhaps with less non-printing moves than before - have you done some path optimisations in this version too? And I now finally have a reason to fit a fan, as you have included sensible fan control!
Anyway, once again, many thanks for your continued work, it is much appreciated.
I would encourage everyone who uses Slic3r to make a donation to Alex, whatever you think is appropriate and can afford. I did! There is a link on [slic3r.org]
|
Re: 0.7.0 Feedback February 29, 2012 06:50AM |
Admin Registered: 12 years ago Posts: 2,569 |
No need to open a new thread for that, but I think there is a bug in Slic3r 0.7.0 :
There is an uncommented line "_BRIDGE_FAN_END" somewhere in the gcode output sometimes.
It leads my print to interrupt.
Luckily the post process scripts feature allows for a quick workaround
Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
There is an uncommented line "_BRIDGE_FAN_END" somewhere in the gcode output sometimes.
It leads my print to interrupt.
Luckily the post process scripts feature allows for a quick workaround
Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
|
Re: 0.7.0 Feedback February 29, 2012 02:30PM |
Registered: 13 years ago Posts: 228 |
|
Re: 0.7.0 Feedback February 29, 2012 11:14PM |
Registered: 12 years ago Posts: 4 |
|
Re: 0.7.0 Feedback March 01, 2012 03:47AM |
Admin Registered: 12 years ago Posts: 2,569 |
Sound Wrote:
-------------------------------------------------------
> @DeuxVis, sure it's a bug. I wasn't able to
> reproduce it. Can you please post a STL file and a
> config.ini to reproduce it?
Yes sure, here you are. Machine is a 32 bits linux (old ubuntu version).
Attaching the gcode too, I'm not 100% sure this is not machine specific, will try to reproduce on another PC later.
Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
-------------------------------------------------------
> @DeuxVis, sure it's a bug. I wasn't able to
> reproduce it. Can you please post a STL file and a
> config.ini to reproduce it?
Yes sure, here you are. Machine is a 32 bits linux (old ubuntu version).
Attaching the gcode too, I'm not 100% sure this is not machine specific, will try to reproduce on another PC later.
Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
|
Re: 0.7.0 Feedback March 01, 2012 07:18AM |
Registered: 14 years ago Posts: 689 |
Version 0.7.0 produces beautiful gcode, as always, but I've encountered something weird. After filling in a bridge area (top right hole in the gregstruder body) it did a very long retraction move, messing up some of the perimeter for the next layer. I've tried to decipher the gcode, but can't find the error. It happened at or very near the end of layer Z6.6 (close to layer Z6.9).
I tried using skeinforges skeinlayer to visualize the paths, but it doesn't seem to process the gcode at all.
Files attached.
--
-Nudel
Blog with RepRap Comic
I tried using skeinforges skeinlayer to visualize the paths, but it doesn't seem to process the gcode at all.
Files attached.
--
-Nudel
Blog with RepRap Comic
|
Re: 0.7.0 Feedback March 01, 2012 11:57AM |
Registered: 12 years ago Posts: 58 |
Nudel, I just had the same thing happen. It did a very long retraction about 85% of the way through a long print. I had to pause the print, re-seat the filament, and then resume the print. The G-code is too large to attach here, but I can e-mail it somewhere if one of the devs wants to take a look at it.
Edited 1 time(s). Last edit at 03/01/2012 12:33PM by gtg252b.
Edited 1 time(s). Last edit at 03/01/2012 12:33PM by gtg252b.
|
Re: 0.7.0 Feedback March 01, 2012 01:49PM |
Registered: 13 years ago Posts: 2,947 |
@Nudel
To use Skeinlayer you need to enable Draw extruder off and set the extruder off travel to 2-3 pixels wide.
(skeinlayer needs M101 M103 to draw the colored lines)
To use Skeinlayer you need to enable Draw extruder off and set the extruder off travel to 2-3 pixels wide.
(skeinlayer needs M101 M103 to draw the colored lines)
| FFF Settings Calculator | Gcode post processors | Geometric Object Deposition Tool Blog |
| Tantillus.org | Mini Printable Lathe | How NOT to install a Pololu driver |
|
Re: 0.7.0 Feedback March 01, 2012 02:04PM |
Registered: 14 years ago Posts: 689 |
Thanks Sublime, that worked perfectly!
The tick box in my sf is "Go Around Extruder Off Travel", I'll look into it to try and find the exact place where if retracted excessively.
--
-Nudel
Blog with RepRap Comic
The tick box in my sf is "Go Around Extruder Off Travel", I'll look into it to try and find the exact place where if retracted excessively.
--
-Nudel
Blog with RepRap Comic
|
Re: 0.7.0 Feedback March 01, 2012 02:37PM |
Registered: 13 years ago Posts: 2,947 |
I just had a thought on this. If it is a really long retract it is more likely a missing G92 E0 which is even more reason to use Relative E (I use it on Marlin too).
| FFF Settings Calculator | Gcode post processors | Geometric Object Deposition Tool Blog |
| Tantillus.org | Mini Printable Lathe | How NOT to install a Pololu driver |
|
Re: 0.7.0 Feedback March 02, 2012 01:38PM |
Admin Registered: 12 years ago Posts: 2,569 |
DeuxVis Wrote:
> Attaching the gcode too, I'm not 100% sure this is
> not machine specific, will try to reproduce on
> another PC later.
Tested on a 64 bits uptodate Ubuntu 10.04 and reproduced.
Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
> Attaching the gcode too, I'm not 100% sure this is
> not machine specific, will try to reproduce on
> another PC later.
Tested on a 64 bits uptodate Ubuntu 10.04 and reproduced.
Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
|
Re: 0.7.0 Feedback March 02, 2012 06:02PM |
Registered: 12 years ago Posts: 58 |
|
Re: 0.7.0 Feedback March 02, 2012 08:02PM |
Registered: 14 years ago Posts: 36 |
I have found a bug!
Slice the attached STL with the attached profile. Slices just fine. Then change the first layer height ratio to 3 and it claims that the model has self intersecting blah blah blah.
Seems to be regardless of STL.
Makes life hard if you are heading down below 0.1mm.
Slice the attached STL with the attached profile. Slices just fine. Then change the first layer height ratio to 3 and it claims that the model has self intersecting blah blah blah.
Seems to be regardless of STL.
Makes life hard if you are heading down below 0.1mm.
|
Louisnorwood
Retraction Bug March 09, 2012 05:58AM |
gtg252b Wrote:
-------------------------------------------------------
> I just had another weird bug. I was printing a
> 2x1 array of a part, and on every layer when it
> moves from the first part to the second, it's not
> retracting the filament. All of the other moves
> do fine except for that one.
I am having the same bug. Quite a few hours of retraction calibration, before I figured out that it was not trying to retract on any model where there were two parts next to each other, All single parts print smoothly.
The same print settings work perfectly for 0.6.0.
This happens on all models I have tried.
-------------------------------------------------------
> I just had another weird bug. I was printing a
> 2x1 array of a part, and on every layer when it
> moves from the first part to the second, it's not
> retracting the filament. All of the other moves
> do fine except for that one.
I am having the same bug. Quite a few hours of retraction calibration, before I figured out that it was not trying to retract on any model where there were two parts next to each other, All single parts print smoothly.
The same print settings work perfectly for 0.6.0.
This happens on all models I have tried.
|
Louisnorwood
Re: Retraction Bug March 09, 2012 06:16AM |
The Fix has been found, can't wait for the new Windows version to get rid of that bug.
See this thread
[forums.reprap.org]
See this thread
[forums.reprap.org]
|
Re: 0.7.0 Feedback March 11, 2012 09:55AM |
Registered: 13 years ago Posts: 228 |
Nudel Wrote:
-------------------------------------------------------
> Version 0.7.0 produces beautiful gcode, as always,
> but I've encountered something weird. After
> filling in a bridge area (top right hole in the
> gregstruder body) it did a very long retraction
> move, messing up some of the perimeter for the
> next layer. I've tried to decipher the gcode, but
> can't find the error. It happened at or very near
> the end of layer Z6.6 (close to layer Z6.9).
Hi, I looked at your G-code file but I couldn't find any long retraction where you said it happened. I'd be very happy to fix any issue, but I need the bug to be reproducible.
-------------------------------------------------------
> Version 0.7.0 produces beautiful gcode, as always,
> but I've encountered something weird. After
> filling in a bridge area (top right hole in the
> gregstruder body) it did a very long retraction
> move, messing up some of the perimeter for the
> next layer. I've tried to decipher the gcode, but
> can't find the error. It happened at or very near
> the end of layer Z6.6 (close to layer Z6.9).
Hi, I looked at your G-code file but I couldn't find any long retraction where you said it happened. I'd be very happy to fix any issue, but I need the bug to be reproducible.
|
Re: 0.7.0 Feedback March 11, 2012 11:04AM |
Registered: 13 years ago Posts: 228 |
TheRuttmeister Wrote:
-------------------------------------------------------
> Slice the attached STL with the attached profile.
> Slices just fine. Then change the first layer
> height ratio to 3 and it claims that the model has
> self intersecting blah blah blah.
Thank you for the bug report, I can confirm there was an issue with certain values of first layer height ratio. I fixed it now, and it will be included in the next release.
-------------------------------------------------------
> Slice the attached STL with the attached profile.
> Slices just fine. Then change the first layer
> height ratio to 3 and it claims that the model has
> self intersecting blah blah blah.
Thank you for the bug report, I can confirm there was an issue with certain values of first layer height ratio. I fixed it now, and it will be included in the next release.
Sorry, only registered users may post in this forum.