Feedback and Requests

[Luke321]

Hey there, my dad bought your software because he has an M2, and I played around today in combination with my Rostock mini.

First of all I really like the the whole visualization process and the editable support, also slicing is extremely fast which is a big plus.
My first print was exceptionally well, no blobs, perfect outer shell.

One thing that would be nice for Rostock printers is a round build table, with home position in the center, when you currently position a part in the corner with the home position you only get infill in the sections which overlaps with the build table, so currently I can only use 1/4 of the whole build surface for my printer.

Feature requests and suggestions:

• mm/s instead of mm/min because the other slic3rs use it too

• Z offset

• start with inner perimeters first so the outer perimeter has something to hang on to for overhangs

some other things where already requested so you could add those to my list

I really hope you can add those features so I could use your software for my Rostock mini without the need of modifying the xy offset in my firmware.

[Simplify3D]

Hey Luke,

I'm not super familiar with the Rostock family of printers since I've never had the pleasure of using one. When you talk about wanting to home the build in the center, are you looking for Creator to modify the homing routine or the G-Code itself? I know the infill is constrained to the build table like you said, but I imagine you could use the software as is, making a part at 100mm,100mm for example. Then home the rostock at the center of the table and send a G92 X100 Y100. That would set the center of the table to (100, 100) instead of (0, 0). Does that make sense? I'm guessing you're looking for an easier solution, but it wouldn't be hard to add something like that in your starting gcode.

Are you wanting to use the Z offset to compensate for some slightly out of place Z-axis endstops? Or is it for multi color printing? Just curious

And we've actually tested the perimeter directions (inside out vs outside in) and actually got better results using what's in there now. That's an easy switch to add though if people want the option to go the other way.

[tomlombardi]

On the Mac OS, after selecting a model to process, that folder should be persistant for the save operation, really annoying to hunt for a folder I just used.

It would be great to have an option to go straight to print from the currently processed model without having to preview first, maybe a new icon on the right side?

[Luke321]

The for your reply, I forgot about the G92 command, so for my 150x150 build space I should use G92 X75 Y75. thats actually a nice solution
What I'd like to see would be an option that Creator sets the 000 point in the center of the bed, instead of the corner but I will use G92 for now.

I'am using a wood glue water mixture for better adhesion of the first layer, after some prints I get a layer of tha mixture high enough so that I need to change the Zoffset.
And sometimes I have to change the Zoffset when I change the first layer height for better adhesion.

Did you test your perimeter settings with 45% degree overhangs? I think there could be some problems with that.
I will try to print the hollow calibraton pyramid which I already printed fine with skeinforge and slic3r.
http://www.thingiverse.com/thing:21303
If this prints as good as my first test I'll probably stick with creator, the coast feature give perfect outer perimeter which I can't achieve with slic3r or skeinforge.

[Simplify3D]

tomlombardi - the path remembering is already fixed and will be available in the next release. I think we will eventually add a magic slice-to-print button, but for right now it's not a bad idea to encourage people to preview their G-Code before sending it to the machine. We can help save a lot of wasted plastic that way, so really we're just trying to be environmentally friendly

Luke - we did try a few overhang prints and didn't really notice anything alarming when comparing the two. Depending on your width/height ratio, you can do pretty severe overhangs without a lot of issues. Either way, I think we will add an option to change the direction so you can have the best of both worlds. Oh and that hollow calibration pyramid was LITERALLY the exact part we were testing on when we finally made the decision to stick with the outside-in perimeters. We probably printed 15 of them before we finally made up our minds. I'll see if I can rummage up some pictures of the whole set...

And coasting is a really neat feature that I don't think a lot of people use. If you start to get good results with it, let us know what settings are working well so we can compare notes.

[Simplify3D]

Found it! We were messing with a lot of settings so some of them don't look so great. But check out the pyramid on the far right. That was literally one of the best calibration pyramids I have ever seen.

testing2.jpg (111.49 KiB) Viewed 7305 times

And sorry for the grainy iPhone pic

[Luke321]

I am currently using coast with 1mm path and 5.5 mm retraction on my bowden extruder. I get perfect prints to the point were you can't see where the perimeter hast started.

I tried the G92 command but it doesn't work, I suspect it is setting the values for the linear axes instead of the print head, so it's a repetier firmware fail.
It would be really nice if you could add an option to set the corrdinate system origin in the center of the build area!

nice calibration pyramids

[Luke321]

G92 E0
G1 E5.50000 F6000.00
G92 E0

At the beginning of my skirt the printer is trying to extrude the retraction length with full retraction speed.
I think this is for making an anchor but should be done with a much slower speed of 200

[Luke321]

I successfully printed the lattice calibration pyramid.
The print look pretty good but there are some blobs on the inner corner because sometimes the perimeter started at that point and so the printer extruder in thin air.
Maybe you could optimize your code to not start perimeter in overhangs if possible?

[Luke321]

I found the problem with the G92 command,
the firmware calculates the delta coordinates directly from the g92 command, so if it gets a G1 X80 Y80 there is an exception thrown because it's is a none reachable position.
So the only fix is that the created gcode is modified, maybe you could X,Y,Z offset in the options which moves the origin of coordinates?