Welcome! Log In Create A New Profile

Advanced

slic3r bugs (dev revision)

Posted by mag00 
slic3r bugs (dev revision)
November 01, 2017 07:36AM
Hello all.

I'm using dev revision of slic3r and I noticed that last 5 dev revisions that I used had/have two bugs.

I don't know where I can post it for developer team, so I will post it here.

Bug one:
I configured slic3r with screen shortcuts to make most common settings (for me) easy to change.

One of these settings is the layer height parameter. So, as you can see on below image it has a door holder with previewed Z slices of 0.35 mm.



When I change any setting the preview disappear and the tab go to the first one (3D) showing the model and I need to press preview again to it recalculate the slices.

But when I change the layer height (being inside preview mode) I can't see the preview again. Even when I press the Preview tab, it give me only the bed on screen and nothing else, as you can see below again:



If I export G-Code, then it save the file correctly and after that the preview is restored.

Bug two:
When I change the print settings with popup on top right corner it recalculate all slices with new settings but the layer height.

So, if I was using a Print setting with 0.2 mm of layer height and change print settings to other one with layer height of 0.3, for example, when I press preview tab it give me slices with all new setting, like perimeters, top layers and bottom layers correctly, but the layer height will maintain the 0.2 mm even showing on screen the 0.3 mm. See on image below the layer height of 0.40 on slider bar (near volume label right bottom corner) and the setting on middle right showing 0.24.



Gerson - Voolt 3D print services - Brasil
Attachments:
open | download - ScreenShot 11-01-17 at 11.48.01 AM.png (214.1 KB)
Re: slic3r bugs (dev revision)
November 02, 2017 12:42AM
Are you talking about the original slic3r or the Prusa-edition slic3r branch? I'm using the Prusa branch for a while now and I'm pretty happy with it.
Re: slic3r bugs (dev revision)
November 02, 2017 05:57AM
I'm talking about the original slic3r.


Gerson - Voolt 3D print services - Brasil
Re: slic3r bugs (dev revision)
November 02, 2017 04:54PM
I'll add one more request for a long-standing "bug" to be fixed...

If I've started saving a file, don't let me exit the program until it's done. Currently, when generating a gcode file, if I'm not thinking and not watching the little progress bar, I sometimes exit Slic3r before the gcode has been fully written to the file. Of course, this is more likely to happen with a big and complex model being sliced. What seems to happen is that the file just gets closed wherever it has got up to. When I print that gcode file, the printer will just stop at the end of the gcode, with the hot-end still on.

I realise this isn't *really* a bug in Slic3r, but it would be nice if Slic3r saved me from doing something stupid and wasteful of time and filament.
Re: slic3r bugs (dev revision)
November 02, 2017 05:09PM
I don't know if it's been fixed in recent releases, but sort of long the same line as FrankVDH's comment, I have seen Slic3r report that it saved the gcode to an SD card that didn't have sufficient space for the file. You don't realize that until your print suddenly stops and you pull the SD card and take a look at it. It seems to write the gcode directly to the SD card as it is generated. To me, a non-programmer, it would make more sense to generate the gcode in memory then transfer the completed gcode file to the SD card. You might then have an opportunity to test the remaining capacity of the card before transferring the file.


Son of MegaMax 3D printer: [www.instructables.com]
Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]
Re: slic3r bugs (dev revision)
November 07, 2017 05:07AM
This issue with SD card can be solved if you save the file in your HD first and then transfer it to SD card. If it is out of space the system will inform you and you can free space and make the copy again.

The solution that you proposed, to put the code in memory and then transfer to SD card could make the system too slow. Some G-Codes can be too large to be just in float memory. (my opinion as a non-programmer guy too).

But obviously they can put a space check before trying to write the code to card too. I believe that this is not too hard to do.


Gerson - Voolt 3D print services - Brasil
Sorry, only registered users may post in this forum.

Click here to login