Weird striping effect


So I printed my stress test. It is indeed terrible, but I need to refactor it a little. It’s too hard to spot the glitches. Bad news is that slic3r preview is not 100% what you get. It gives you some idea but we are still far from it.

What I noticed is that the effect is stronger if the resolution is higher.


is the lines in the object same as where it is at in the Slic3r preview?


no they are not (not completely at least).

more testing is needed. I will proceed by examining the gcode line by line… wish me luck


@matt3o I would suggest to have the same file for anyone willing to test. Since we’re looking for a slicer error, some people’s results could prove misleading by artifacts introduced by their moai setup, but if anyone manages to print it at an angle without artifacts… well that would be interesting.

The line artifact is pretty irrelevant to layer height.

So far, @matt3o @Joseph and I, have posted pictures of this line artifact along raised details.

It does happen on organic forms too, it is just more pronounced in hard surface models because of the flatness. In organic surfaces it just fades ( e.g. along the support contact ), but it’s there.


the problem is so easily repeatable that any “pin” on flat surface would do, but if you want to use my test file I shared it here

The problem is that supports trigger this problem on “organic” models too. For some reason it wasn’t so bad few months ago, or maybe now I have a more critic eye. Anyway it needs to be solved because it is pretty bad.

This is the latest version of my test file. Wet the surface to enhance the issue.


Just to reiterate on the issue. Each and every support pillar creates the same kind of glitches.

the problem is that the stripes generates often deformation along the whole layer (not just near the pillar)

I found a model I printed many months ago, it is actually one of the first I printed and you can see the same issue. So it’s not something introduced by recent firmwares. At the time I thought it was layer misalignment, but now I understand it’s something different.

I’m still not 100% sold that it’s a slicer issue, but I’m trying to print on Simplify3D (it always failed so far) to see if the issue persists there.


Okay I was able to print with Simplify3D. Unfortunately I have to report the same issue.

it’s a freaking mess.

What I noticed is that the banding goes always in one direction (I suspect it follows the toolpath direction).

I consider myself defeated. Unless you guys have other ideas I believe we just hit a machine+software limit and there’s nothing we can do about it (apart from trying to orient the model differently and use as little support as possible).

@peopoly any other suggestion?


I took a shot at printing the sample test model that @matt3o kindly provided.

We know it likes to inflate with banding on raised details and supports, we know it likes to depress on indented detail…

Seems like we found a way to make grills without needing to model them beforehand. And it is 100% repeatable!


A good control would be if someone could print this on a different SLA machine with a different slicer.

I also think that this is a compound problem, as there are a lot of prints posted here and on FB, that aren`t affected and also there are some artifacts that show on the model but not in cura.


The “other guys” have seen this kind of thing, too:


that seems to be a problem with the 3d model (co-planar entities), I don’t think it’s the same issue we are having.


The form1 had it much worse, and on the form2 it looks similar… But the guy in the post says the artifact went away after cleaning the model. He had used sketchup for modeling, which is fine, but is prone to geo glitches.

When I started printing with the moai in february, I thought the lines I saw on the model at the support contacts were odd, so I preped a the same model with the same supports topologically merged with the model, all clean geometry, one solid surface. And the result was the same, same lines.


This has been printed with the form2, if you look at the rivets they don’t have this kind of problems. It doesn’t look like a limit of the technology.

The next step would be to (semi)manually generate the gcode of a very simple surface and see if it’s really the slicer. That requires quite some dedication though…


I believe the problem in our case has to do with the high frequency damping of the galvo mirrors, affected by the mechanical inertia, that is, when they have to turn abruptly to follow a specific detail, while they operate at high speed. The laser path creates a trail as it tries to return to the coordinates given by the g code.

The absence of an f-theta lens inside the device also plays a role in this. The f-theta works not only by minimizing the barrel distortion of the galvo system, but also corrects for small discrepancies and inaccuracies of the galvo mirror rotation. The galvo mirror has a small rotation angle, 20 degrees, and with this minimal rotation angle it covers the span of the build plate. You need to have a hell of a lot of accurate rotation to always hit the same spot every time in each slice. The galvo motor is bound to have some loss in accuracy of rotation, depending on build quality, signal quality and the fact that it has to compensate for mechanical inertia of the mirror because it rotates at high speed, and it gets worse as speed increases i.e. faster scanning . Add to this that there is a posibility that the mirror is not balanced even by a tiny amount, the motor would have to adjust it’s rotation to compensate for that inertial force against it, which I don’t think is happening, and most systems that go for reliability use the f-theta lens. The lens provides a tolerance for small changes of the beam angle and position as it hits each mirror. In contrast, plain mirrors bouncing a beam around at a distance of 20cm makes for even bigger error and requires more precise galvo motors and geometricaly accurate placement of mirrors in the housing of the apparatus.

Now, think of the model being printed, and one slice being drawn by the laser, and the laser following a rather smooth path with no abrupt changes (buddha’s belly). Then slice after slice, they are drawn quite uniformely, then suddenly, some raised detail starts to appear at the slice… a rivet, a bolt, a hole, the support contact… and the laser has to start following this abrupt change in direction, so the galvo mirrors have to rotate abruptly to get that line, but it’s not that simple, the inertial forces move against the motor. And then the mirrors have to rotate back, to follow the previous contour line… but here’s the thing, they don’t , so it follows the contour, but with a slight offset. After a couple of slices, once it passed the detail/support contact point, it has to work with the smooth part of the model again, the galvos don’t have to do drastically abrupt angle changes and the surface produced is smooth again.

That’s why it happens on small raised details and abrupt changes in geometry. If there was an f-theta lens inside, it would compensate for that minor glitch in the angle offset produced by abrupt changes in galvo rotation.

A more hands on solution, would be to attempt to correct the inertia problem with adjusting the high frequency damping on the driver board. But we need peopoly for that.

Also, since the problem exacerbates with high frequency scanning, i.e. fast moving laser, then slowing the speed of the laser should significantly improve our situation. That means all speed values in cura and laser power settings need to be reconfigured. The prints will take longer, but I can live with that.

Galvanometer mirror systems are used in many fields and the available literature is extensive, covering function, the flaws and advantages, and on compensation of said flaws.


“This” is very pretty. Want Dat Mech


you might be onto something. it might be more related to acceleration than speed. I guess the acceleration is hardcoded into the firmware but Cura seems to support acceleration control. Inspecting the gcode it just passes the acceleration value via M204 gcode and I feel like the Moai wouldn’t honor that value, but it’s mere speculation.

I also noticed that the “Number of slow Layers” is not the number of layers run at the “Initial Layer Speed” (5mm/s) but it increments linearly until it reaches the final speed. This is interesting but I am derailing now.

Anyhoo. I’m now printing two more tests (with very slow layers and with very slow acceleration). I want my resin back! :stuck_out_tongue:


Basically we are screwed by the hardware and if it isn’t corrected by Peopoly we are also screwed by the closed source. Am I getting something wrong and there is something we can do?

Sadly this doesn’t explain the banding issue some people experience on completely featureless surfaces.


I’m pretty sure the problem is in the slicing – I get the same sorts of lines on FDM prints from Cura.


Okay I printed at 60 mm/s and it made little to no effect. Tomorrow I’ll try at 30mm/s with a very small acceleration (that won’t probably be applied), but at this point I have very little hope it is going to make any difference.


I must be doing something “wrong”. I am not getting anything close to the results you guys are showing with this banding, I can kind of see a miniscule layer line but nothing as exaggerated as the ruts and hills you guys are showing in your pictures. I also tried scaling the model to twice its size to maybe increase the effect but still nothing even remotely like the pics here.

What resolution are you using to print in cura? 50um? The model’s format imported into cura? STL?