Moai 130 large file error

Sliced in Cura I generated a 4gb file and saved it on the card. Using Firmware 1.20 it successfully printed, mostly. For some reason there was a giant shift on the x/y axis making this wave pattern before it compensated. I am unsure why this happened and am investigating if it is a Cura error or Firmware error. It’s a bit upsetting, as the 1.20 firmware has improved prints so far and I have successfully printed 1.5gb files.
I’ll investigate more and include improving the memory of my computer to 32gb as that improves Cura functionality.

this shift happened due to the weak support
please try again with thicker supports and a little bigger tip size

I can understand why you would think that, but this is not the case.
First, the supports are very, very dense. The number of supports generated are still holding strong and I cannot pull the piece off of the supports.
Second, the piece does not move in the X or Y direction showing no print drifting. Especially to that degree.
Third, the shift is not random which is the key element of print drifting as you described.
Fourth, this only happens in the X direction towards the Z motor and is perfectly level on the Y.
All of the clues suggest this is galvo drift, and firmware related.
I’m going to use the same file and slice it at a lower resolution and test.

@TMcCaine by “weak” here i meant the supports in the back are long and thin, not about the support’s density. You can easily visualize this as it would be similar to a long steel wire, the support may printed out hard, but during it’s being printed it’s partially soft. So the peel motion will affect the support structure a t some point
This is usually seen in long and thin support, i suggest to delete some support in a few tall areas and replace them with a bigger support

I understand the instructions. I’m going to test using the 80um profile which generated a 2gb gcode file and see what happens. If it fails in the same area it would suggest you are correct and I will be moving forward with your suggestion.

Here is the update. Printed at a higher resolution to decrease the gcode file size. Same file, no changes. I did have a catastrophic failure of the plate adhesion, but the density and nature of the supports kept everything in line. The print is perfectly in line with the model and there is no galvo drift on the X axis.

It does verify that at high file sizes the firmware is still having some issues. On the plus side, it seems around 2.75gb is where the error occurs. I’ll find time to verify that value, but it’s an improvement over the 1.25gb limit from before. No more crashing too!

I’m enjoying the firmware release, I just want to get it dialed in and improved further.

1 Like

This is rather a lucky print, although there’s no confirmation, we can add “gcode size limit” into the possibilities
Was this done in Asura? have you tried the same file in Cura?

This was tested in both Asura and Cura.
The print recovery isn’t lucky, it’s part of the lattice work in Asura. It’s why I love to build supports in Asura because they recover well. When I use B9 creator I will create an A frame for the same reasons. Though there are some flaws in this, it was because of setup issues and this was a test print so I’m not worried about it succeeding.
While I’m trying to push the boundaries of the Moai I do discover limitations and it helps me understand how to make better prints. Also, this is a large print on the FEP and not the PDMS. This is because of the Z lift on the new firmware so I want to thank all of those involved in making that an option.
Now, if I can convince Peopoly to make a cursery position change on the firmware so I can input 650 on the Z reset instead of turning the nob fro 1800 to 650.

1 Like