Formware3D for Moai - what is the best print logic / speeds?


#21

Elegoo white Moai power 52
Formware. 50 micron layers.
Speed 120 print 120 travel.
Infill 85.

Some other parts on the plate stuck to FEP vat. Normally that means I need more exposure, but this seems exposed, so maybe if the 85% infill was 100% infill, it would make the core stronger?

Why do we use less than 100% infill anyway? It doesn’t save material like it does on FDM.


#22

So when I import models that were designed for Cura, Asura, or Preform, they import into Formware at 90 degrees. The side of a part that is supposed to point to the Moai or FormLabs printer door instead points to the left. This makes is so that test parts that measure X/YU issues need manual intervention. Just a thought.


#23

is there any kind of distortion compensation for the Moai in Formware3D? I would be very interested to try it but dimensional accuracy is essential for me.


#24

I just came here to say the same thing,

Need an STL to print and measure and put the result back in to correct X and Y scale. It is not linear so ideally it would have about 10 points on each axis, and you would fit a polynomial curve to them.


#25

@rsilvers you want to avoid printing at 0.05mm layers. The stepper driver that the moai uses doesn’t actually have microstepping enabled on the Z axis so by going at a layer height that isn’t a multiple of 0.02, you’re going to get skipped steps and fucked up layers since you’re trying to hold the Z at a place that lands between poles on the motor.

Ideally, you’d want to do 0.06mm layers to get best results.

To add, I believe we use 70% as the base value for infill because while the spot is 0.067mm (IIRC), there will be some small ambient curing that will go over the sides so 100% will potentially cause more harm than good (dependant on the resin obviously. BlueCast for example performs best at 100% infill).


#26

First of all, the firmware with extended command set for modifying will be here soon. We have been testing it and we will release as soon as it is consider stable. Standard Asura/Curaengine will still work for obvious reasons. This is designed as additional command.

Infill is 70% because light is not filament. you cannot tell light to go from a point to another point and stop at precisely fixed diameter size. That is not how light works. And colors of resin can cause scattering of lights as well as the density of photoiniators. It took a lot of testings to arrive at 70%. for harder to printer resins like tough and castable, you can up the % if you like for a even stronger print.

I cannot help much with corner logics since we did not write Curaengine. That code is open so you should check it online. Matterhackers made a special version of Curaengine very different path strategy and utilize GPU to slice and it is open source on github so you could dig into that. I encourage to take Asura profiles for Curaengine and study it in details as it is quite revealing of how Cura plans its path. For what it is worth, its performance was much better than slic3r, ice, kiss, s3d and multiple much smaller slicers. I guess Curaengine isn’t that bad after all eh? @matt3o

and let me clarify what I meant without editing my previous comment. I think by continuing the conversation with Formware here and even pointing them to sources that can provide clues to improve slicing for Moai on Formware, our intents are clear and it is to help any slicers that can provide better prints on Moai since we don’t have the resources to do so at the moment.

The comment about Curaengine is just to point out even it has problems, it was not easy to reach to what they have accomplished so more works are needed. And without Curaengine, Moai proejct would not reach to this stage. Calling out Matteo was my clumsy attempt to be funny since we discussed this topic many times privately.


#27

honestly I don’t understand if you are mocking me or what.

yes, Mark, Cura is a great piece of software made for FDM printers. We extensively talked about it. You might be happy with it and for many applications it is more than enough, but if you need really high quality, detailed and small models it just doesn’t work, and it’s alarming that you don’t acknowledge that.

This is what happens if you print with the Moai small geometric models.

It’s not my machine, others have printed that model with the same results. Using different slicers yields different results, so it’s definitely something happening at the slicer level. We printed the same model with formware too and the issue is still there just slightly better. I feel the problem is a combination of slicer rounding up error and the moai controller which has a 12bit DAC. Would be nice to know how many decimals the moai supports, being 12bit I suspect it only supports 2 decimal precision. So possibly no matter how hard we try we will always hit a wall at the controller level.

You are clearly more interested in bigger prints (moai 200) than in improving the quality. That is totally fine, it’s your machine, your business model. But totally ignoring the problem and saying that Cura is “good enough” is rather irritating… Also considering that the little quality boost all the community is experiencing today it is become @Keowa and I (ie: users, not peopoly) put time and effort in optimizing Curaengine. Gosh, if it wasn’t for the hours of testing I put in the moai we would still be printing at 50um layer height that the stepper drivers on the moai don’t support! @Iakouben and I (again community, not peopoly) recently found out that the drivers can’t do microstepping, so we are limited to whatever the motor (1.9°) and the leadscrew can do (which is 0.02 steps).

Since we are at it. Let’s talk about the Z-axis. Please, release an updated version with dual rail, possibly a ballscrew, but that would be marginal since the controller can’t do microstepping. The community has clearly demostrated that we need better stability to get decent layer consistency.


#28

It was a friendly gesture as I know how near and dear that topic is to your heart. But if that comes out wrong and offends you, I apologize. As we move forward with newer firmware and updating hardware which we always have been doing despite having a very bare-bone crew, we could always mail it in and never try to implement any changes. I think our track record speaks for itself when compared to many brands. Of course, I would like to have everything being done right the way with no push back from programmers, no worries about potential clones, no worry about taking care user who are having printing problems and not worrying about paying a living salary for those made the printers. But I cannot do it all at once and I have to look at survival, inventory level, and available resource. We will continue to bring new developments and add ways for users to enjoy their Moai as we have been. I care less about who gets the credits and more about users getting a good printer and a strong community while the team behind me whose livelihood depending on my balancing act.
I may not post as much as I used to but rest assured I read everything and try to figure out a way to work improvements. Now I think I still owe you some electronics so we gonna have to do some overtime this weekend.


#29

Thanks on the 050u layer tip. I say the same thing whenever someone posts that they printed at 025u on Photon.


#30

Well, now at least all profiles have the correct layer heights so if people dont mess with the settings the proper layer height will be used


#31

Yeah. That is good. But I used Formware and it lets me pick any.


#32

You take care of the needs of your customer base, keep innovating, making things “better” in a timely schedule… you wont have to worry about survival! If you start to see key members of your community looking at other options because they are frustrated by a myriad of different issues… THATS when you have to worry about survival!


#33

Hi all,

I’ve created the 2 functions i wrote earlier about with the extra loops in the walls and hatching in an attempt to create extra sharp corners. (see 2 screenshots below; installer will be uploaded in couple of min.)

Additionally i’ve inserted the horizontal size compensation (XY) also in the GCode export. This is a variable under DLP settings, to scale only in XY with a couple of microns/millimeters if you want to quick adjust. (idea from @rsilvers couple weeks ago)

We are very curious if these changes will make the corners sharper and the machine run smoother.

A quick analysis with GWizard tool (free trial version) of print time showed that it will have a negative effect of course.
But when you add in the acceleration into the calculation (GWizard can show you that) you see that the effect on print time gets less compared to the one without arches because of more smooth curves.
Still it’s a bit longer (25% in the cube i tested) but it could hopefully result in sharper corners and less vibration.
Needless to say; a big unknown is how fast the laser turns on/off in these corners…

To chip in into the discussion about Cura and slice quality/performance.

I’ve looked into the cura source code as well and compared heavily and tuned our code accordingly.
The challenge with Cura or modifying it, is that it’s a large code base with many steps of which many are tuned and perfected for FDM. The SLA printing process is somewhat easier since you can just turn ON/OFF your laser and don’t have a dripping hot extruder to account for. We had the slicing already in place for SLC exports so it was an easier step for me to write a path planning than dive into cura.

The speed difference that is left is purely from the fact that Cura uses C++ and we use C# (we have our reasons).
The step that usually takes most time is unioning cross sections and offsetting. Both Cura and Formware use the free Clipper library for this. Since this is a clean copy between C++ and C# it must be the language difference.

@Peopoly, thanks for the opportunity to chat here. Hope the tests bring everybody something of value.

Elco

image


#34

HI,
In posts in FB group somebody mentioned formware already have x/y compensation of the galvo like ASURA
As far I am after printing mechanical stuff I got interested and just purchased . Spent an hour to review and I think that statement is not true at least for now.
Since I dailed in calibration file settings in asura I am getting prints in the 0.03 deviation
are you planing to implement something like that. This made the difference for me and my field of use of MOAI
I am putting here the compensation instruction link for asura.
http://wiki.peopoly.net/doku.php?id=moai:asura


#35

Posted the correct location of the setting in the DB feed. Its also listed in the post above yours.


#36

Ah , ok
but this is only scale factor for x/y
With the galvo system , what works is the mesh adjust approach , what asura does and what is inside formlabs firmware too.
Form machines do not have expensive F-theta lens too.
Simple scale would work for small objects in the center of the table.
From my initial impression it overdo automatic supports , but it can be a good thing
Also good algorithm for auto position .
But for now not a solution for me until mesh type X/y adjustment is implemented.
I do 50% of my prints , solid on the plate , because of the geometry


#37

Hi Martin,

Currently it has only XY scaling. Of course if there should be another correction we can write it.

This light correction you are talking about, is this applied directly on the final GCode coordinates? (guess so)

What is the algoritm for this correction?

Elco

Elco


#38

Hi,
read this
http://wiki.peopoly.net/doku.php?id=moai:asura
I am not quite sure if they do it the gcode or with corrected stl.
I think I read somewhere that there is a corrected stl somewhere in the asura temp dirs.
The thing is that this was the feature , that gave me a good geometrical tolerances, after a few iteration of calibrating
Thank you Martin


#39

I am just wondering how acurate are the print time calculations ?


#40

Asura applies this correction to the stl before it is sent to curaengine, see here.

In openfl this correction is applied to the flp-data (flp is formlabs version of gcode), look at the mm_to_galvo and mm_to_galvo_approx functions in Printer.py. An example of the grid table used in mm_to_galvo is defined in the DummyPrinter class.

Edit: Here you can see a picture of the actual distortion.