Weird striping effect


#61

50um is fine. wet the surface with some water and look at the piece from above. And post pictures! If it doesn’t do that for you, well at least @Thanasis and I have a defective moai.


#62

This is printed at 30 mm/s with an insanely slow acceleration (also reducing laser power). It took hours to print

Honestly I can’t see much of a difference. So at this point I don’t think speed is a factor.

I’ll try to check the moai calibration again but it could be a slicer issue as @ccox says.


#63

I dunno; I printed the glitch stl at 100um and there were no ghost lines at all. I printed it at 50um, and there are only the slightest hints of ghost lines.


Looks more like the rounding error lines from the non-optimal 50-micron layers, and they are virtually invisible to the naked eye. My 50um result looks nothing like what @Thanasis showed yesterday.


#64

You have to print it rotated only on the X axis. Remember this is a test model designed to trigger the issue, not an orientation optimization exercise. BTW, you can already spot the glitches in your print, they will be accentuated once you change the orientation.


#65

The whole idea of orienting a model is to get the best results within the limitations of the system.

We know there is a limitation in either the slicer or the hardware that causes these ghosts when a model is printed in a certain way. Good job in identifying the problem. The immediate countermeasure is to print that model in a more optimal orientation and maybe use some sandpaper on the stubborn areas. The long-term solution is either a better method of slicing and generating the machine instruction, or more advanced hardware. I’ll leave that up to Peopoly to figure out. I’m just happy my Moai is back to printing notmally after two months of oddball problems.


#66

unfortunately, you do not always have the luxury. Sometimes you just can’t print in a specific orientation or you have features on multiple sides so optimizing one side makes the other wrong. Not to mention the waste of resin and time.

we are trying to pinpoint a problem of the printer, hopefully we can fix it. if we can’t we’ll call it a machine limit but @peopoly has not been very clear on this point so I’ll keep digging


#67

@matt3o Thank you for taking the time to check the speed out. I don’t consider printing tests trivial matter, it takes time, and I wasted some of yours.

@ccox you are right it could be slicer issue. But in the preview of the g code path, it’s just numbers being plotted, there is no real world factor interference. The final print has too large of a deviation, it should show in the slicer preview.

But why can’t we find a slicer that effectively recreates the effect it in the preview? Because it’s not in the path of the piece, it’s the travel paths. The travel path is the culprit here. Let’s say the laser spot moves at 150mm/s while drawing the outer wall or the infill as it it crosshatches. When it reaches details, it doens’t always crosshatch them one by one, but continues with the generic hatching pattern, and the laser turns on and off intermittently… now say the gcode-firmware-processor combo has a slight delay add to that the delay of the laser module… the laser can’t turn on/off that fast. So it goes on curing resin all along the travel path line. Another reason that points to the infill: If you display only the infill in cura you will see that the produced stripe artifact on the print is about the same height as the infill pattern. I dont’ think the laser can blink with a delay less than 100msec, so, for that small amount of time, a spot moving at 150mm/s gets the chance to move 15mm… still firing, curing everything in it’s path, which also happens to be outside the printed object, hence our artifact…

It can very well be that the travels from wall path to wall path also cause this effect.

If you check the supports of models you will see the same line artifact.

These paths that cura generates were designed to work with FDM, and this is something similar to filament retraction issues. But seems this approach causes problems in Resin, because LASER.

So, if we tweak the travels (by changing wall thickness for example) , or if the delay in the laser response can be lowered, we can fix this - once we first know what is the on/off delay in the laser module. I’m gonna try some tests with thicker walls trying to minimize the infill and see which other settings modify the travel.

Also, on my print test and on @matt3o print there are some lines that look like overcuring/layer shifting. That is also most likely the travel path, check this.


#68

I don’t know if that is the case, @Thanasis. My “slow” print should have been at least slightly better if it were speed related. I also drastically reduced travel speed but the result as you can see is as bad as before. But you gave me a couple of more ideas.

Look at this image…

look at how awfully close it is to this

I need to make another print to check I’m not hallucinating .


#69

What I’m saying is that it’s curing along the travel path when it shouldn’t, hence the artifacts. And it’s either cause the laser can’t stop firing fast enough, or the firmware causes the delay. I checked older models that I printed, and the artifacts appear exactly at the travel lines.


#70

yes but drastically slower speeds should reduce the effect, but they don’t. Of course travel speed could be hardcoded in the firmware and we would be pretty much screwed…

I’m printing another test now. It might not come perfect but IF the artifacts change in any way then we will have something to work on. We are getting there, dude!


#71

Squash that bug!

I’ll see if I can print something tonight.


#72

Ignore this post. I was shooting in the dark, and didn’t get wumpus.
Missed the part in the gcode that doesn’t have the E value.

I took a look at the g code for a print, and noticed this. The E value which controls whether the laser fires or not, is included in all lines, and we know that E > 0 fires the laser. So the laser never stops firing during the layer So why would someone expect it not to cure the travel path and only cure the walls/infill? Simple.

Note the high start acceleration so as not to cure while it positions the spot.

Now jerking the beam here and there hoping it won’t cure cause the spot travels too fast is not a viable solution.

Since we got only cura to work with, maybe we can test a quick fix. Can the retraction value which is used to, well, retract filament so as not to goop around the printed part as it travels, can this value be used in the g code to control the laser firing or not? And maybe then there is no need for such high acceleration values, that might reduce galvo inertia and have them pointing more accurately?

@peopoly, how feasible or time consuming would it be to have a firmware fix for this?


#73

The laser can turn on and off much, much faster than the galvos can move. Also, the laser staying on for a small fraction of a second would not cause lines all the way across the print. Also, the laser/galvo is not raster scanning empty space, it only covers exactly where the gcode says to cover (the edges and infill).

With the laser and FDM prints, we see the outer shells being offset slightly due to other geometry on the outside of the object. Sometimes the effect is an outset, sometimes an inset. To me, this looks like a problem with the floating point math used in the slicer (could be rounding, could be limited precision issues, could be a voxelization scan conversion issue, etc.).


#74

As I have seen many prints from other people that aren’t showing these problems here in the forum and FB group, I’m really perplexed as to why. It really seems that these problems are showing up more and more in the last few months or maybe just for peopole that bought the moai in the last few months, I don’t know, but anything had to be changed to bring out these problems.

Also there are photos of prints that look much better with worse "tilt"settings.


#75

Okay I made another bunch of tests, I tried to move as much as possible the travel paths to the back of the model, reduced laser movements by removing the infill, even played with coasting.

Nothing changes the final result. It’s incredibly frustrating.

This is either a problem with the firmware or simply FDM slicers are not good enough for galvo (S3D, Slic3r and Cura they all have the same result).

@Giddi the issue was always there, we sometimes associate it to layer shifting or simply don’t notice it, but it was there even in prints I made last year. Just now I was able to pin point.


#76

@ccox I’m no expert and got passing grades in advanced math courses at uni (and it’s been a long time since uni) so I’m quite ill equipped to address this from a deep -or any- mathematical perspective. Just shooting here and there see what comes up. If it does have to do with interpolation and rounding, and core slicer functionalities, we’re in trouble. But apart from this, something has to be done to provide a fix and first it has to be identified. I got more than a few prints from day one, with this issue, which I accepted at first based on the forums as “layer shifting cause of vat misalignment”, and this topic here has plenty of examples to the opposite.


#77

Can we have an acknowledgement from @peopoly? A simple “we are working on it” or “won’t fix” or “get lost” :slight_smile:


#78

Fortunately, I’m pretty good with math (theoretical and digital), and computer science (theoretical and practical). Unfortunately, the Cura codebase is just a few steps away from spaghetti.
I’ll keep looking into what it might be on the software side, and see if I can get the Cura codebase to build.


#79

I don’t think that the effect is caused by the slicer. The following pictures show the moai_glitches.stl sliced by Cura Moai Edtion 3.2.8, visualized in Blender 2.7 with this addon: ioImportGcode.py. Set self.xOoze = 0.67 (spotsize/layer height) in the addon.

As you can see the “sausages” are all in order, there is no offset of the layer lines at the protrusions and indentations.
IMHO this imperfections are caused by partially uncured resin, which get’s disturbed by the tilt move. This happens because the walls are getting printed last (after the infill) and right before the tilt move. So there are areas on the surface which have a much shorter cure time before the separation happens. I’m currently working with formlabs castable resin, where this effect (last printed segments of layers get disturbed by tilt move) is very strong. I’ll post some pictures of my prints and workaround (add pause before tilt) tonight or in the following days.

@ccox If you still want to build Cura have a look at my thread about Cura Moai Edition for Linux, i can post updated notes for the 3.3 build if you want. But as you said, it takes some time to understand that code …


#80

if that were the case, changing orientation should yield to the same result (ie: partially uncured resin), but it’s not