Slic3r 0.8.2 and new randomize starting points feature

Slic3r 0.8.2 seems to be great so far for me.

One slight thing - I though the new option to "randomize starting points" might help improve edges where the layers always start at the same point and cause a "notch" in a corner.

However, when I tick this option in Slic3r it doesn't seem to change the point at which the perimeters start.

The screenshot below shows the gcode for a 20mm box sliced with Slic3r 0.8.2 with this "randomize starting points" option ticked.



Is this a bug or have I misinterpreted the "randomize starting points" feature?

Randomized start points work for me, not sure why it's not for you.

Ah I think I understand the problem, it works in reverse. ie. if ticked then it does not randomize and if unticked then it does randomize.

I have raised an issue
[github.com]

It's working for me - I check the box and it starts in a random place.

Chris_NZL - you sure it works? Windows, OS X or Linux?

Windows XP here and yes I'm quite sure, however, I just resliced the stl I printed earlier and looking at the gcode displayed in Repetier-Host it appears that all corners are broken segments and I could not see by looking at the gcode display where each layer actually started so I guess the only way to confirm that would be to look at the actual gcode generated. But I did male a point of watching it print to see that feature working. I didn't take much notice of how random it was, only that it didn't start in the same place on any 2 consecutive layers.

Is the support material working for you?

To see the layer start points you need to zoom right in.

I think if you were to slice something simple, like a 20mm box (see screenshot above), then you'd see that that the randomize layer start points is not in fact working. It may be the object you are printing changes shape over Z layers and so perhaps the layer start points would be different anyway, so this feature would not have much effect.

If you are still 100% sure it works for you, I'd be convinced if you could post your STL and I will slice it and inspect it myself in repetier.

This feature is probably most useful to minimise the effect of identical XY layer start points on each layer which is probably most easily spotted on simple objects that don't change shape in the Z plane.

I haven't tested support material, sorry. I'm not sure how to test that but will see if I can learn about it.

another_reprapper Wrote:
-------------------------------------------------------
> To see the layer start points you need to zoom
> right in.
>
> I think if you were to slice something simple,
> like a 20mm box (see screenshot above), then you'd
> see that that the randomize layer start points is
> not in fact working. It may be the object you are
> printing changes shape over Z layers and so
> perhaps the layer start points would be different
> anyway, so this feature would not have much
> effect.
>
> If you are still 100% sure it works for you, I'd
> be convinced if you could post your STL and I will
> slice it and inspect it myself in repetier.
>
As I said in my previous post inspecting it in Repetier-Host won't necessary confirm or deny the random start points as I have already tried that. I'm not here to convince you, I'm just stating what I saw happen.
>
> I haven't tested support material, sorry. I'm not
> sure how to test that but will see if I can learn
> about it.
You can check the box and see the result in Repetier-Host

Chris_NZL Wrote:

> As I said in my previous post inspecting it in
> Repetier-Host won't necessary confirm or deny the
> random start points as I have already tried that.
> I'm not here to convince you, I'm just stating
> what I saw happen.

I apologise as I used the word convince in a way that was inappropriate.

What I meant to say was the following:
In your previous post you mentioned that you could not see from looking at the gcode display in repetier where each layer started. However I was able to do this - see my screenshot above. My screenshot shows clearly that the layers start at the same point my point and are not randomized. I wonder - are you aware of the layer visualization tab in repetier and the pan/rotate/zoom functions in the gcode view with a mouse? Sorry if you are.

I chose the box as it does not change shape on different z layers and so this is a good test of the randomize start points feature. I do understand that you said you observed random start points but I don't know if your object changed shape over z layers. If it did change shape then it would be reasonable enough for layers to start at what might look like random points but might in fact be based on the standard slicing algorithm. Whereas an object like a 20mm box will be a simple but easy test to see if the start points are random or not. You almost certainly have this already but just in case, here is an STL
[www.thingiverse.com]

My suggestion was that you could upload your STL and I would inspect it myself. I was only suggesting that I do this as a way to further explore this issue with a view to providing the developers with more information if your STL does in fact produce random layer starting points.


> >
> > I haven't tested support material, sorry. I'm
> not
> > sure how to test that but will see if I can
> learn
> > about it.
> You can check the box and see the result in
> Repetier-Host

Again I failed to explain what I meant, this is a terrible habit. I have read that Slic3r support is still at the early experimental stage and I have not yet had chance to learn about what I might kind of results I might reasonably expect when testing support material. So I have no idea what kind of objects would be good test the existing support material functionality.

The randomize starting points option seems to work the wrong way round for me as well. When ticked is seems to start in the same corner each layer. When not ticked it seems to alternate between two corners. That looks much better as there seems to be a cumulative effect when each layer starts in the same place. I wouldn't describe either option as random though.

---

[www.hydraraptor.blogspot.com]

First I would like to say I think this is an excellent piece of software, it has some quirks, sure, but it is only version 0.8.2

To go back to your questions, I was printing the idle end from thing 15492. This has a flat plate a few mm high before it changes shape, however when I printed the clamp part which also has a flat plate a few mm high (after my last post) the outer primeter didnot apear to start in random places (but I did not watch the whole print only the first 10 layers or so) but the inner perimeters did (mostly - print head moving to fast to be totally sure of every hole on every layer). It wasn't clear to me where the perimeter started by looking at the visual 3D gcode model generated as some perimeters were in several sections. Of course this would not matter with a simple outline like your cube but for a more complex shape the display does not appear to be exactually how the plastic would be layed down - sharpe angles apear to be broken - but of course they are printed continious. I don't have the gcode anymore so can't go back and look at it.

I sliced your cube, and looking at the actual gcode I don't think the layers start in a random place. If you look at the gcode it's self you can see where it starts on each layer. If you need info on gcode try this Gcode codes This is from line 231 in the gcode "G1 Z0.360 F5400.000" this is the z axis going to the next layer. Following this, the X and Y coordinates are given - and they are always the same at the beginning of each layer.

So, to conclude,
1) I think you are correct when you say it's not working.
2) The only way to be certain where the layer starts is to look at the actual gcode and not rely on the visual 3D display
3) I have observed working examples of random place starts and examples of were it doesnot work or only partly works.

So, I guess this feature is not fully working yet, but thats OK, the author is still doing a great job in my view.

nophead Wrote:
-------------------------------------------------------
> The randomize starting points option seems to work
> the wrong way round for me as well. When ticked is
> seems to start in the same corner each layer. When
> not ticked it seems to alternate between two
> corners. That looks much better as there seems to
> be a cumulative effect when each layer starts in
> the same place. I wouldn't describe either option
> as random though.

Well, perhaps the only random thing here then, is that it operates randomly

Uhm. Having the option unchecked doesn't mean it will start always at the same point. It just means it won't shuffle the starting point explicitely. However, the starting point could be slightly randomized because of other reasons. Perhaps I should add the reverse logic to make it start always at the same point if the option is unchecked? It looks quite useless (...pointless ) but perhaps it would produce more clear results and cause less confusion.

What should not happen is that the starting point is always the same one even if the option is checked. This needs inspection.

Sound Wrote:
-------------------------------------------------------

> What should not happen is that the starting point
> is always the same one even if the option is
> checked. This needs inspection.

Well when I have it checked I get the result in the pic. Each time the shape changes it moves to a new starting point and starts incrementing from there.

Another interesting point is that the infil is missing along the top of the wall.

Another very un interesting point is the general state of the print, but if you saw what I started with you would understand the process I'm going through currently

trying the 8.3 version randomize starting point tiked
with the attached stl I got the attached Gcode
the perimeter printing start always at the same place resulting in a blob blocking the head and making the glass to slip (explaination for the non alignement seen in the pict.)

other wise work fine

little pb with the dispariion of the rotation control in the setting I need to slice manualy and feed pronterface with the gcode instead or adjust the setting and load the stl from pronterface, not a big deal anyway