My Print Grew a Head... A Moai Head Actually


#1

I started a 2400+ layer print yesterday (0.05mm layer height) and when I went into the workshop to check on it this afternoon, found that it had failed in a particularly unusual way. See the photo below:-

It appears that at about 85% completion, the printer switched to printing the 4-moai-test.gcode file instead, resulting in the Frankenstein creation that you see.

The 4-moai-test.gcode file was sitting in the same folder on the SD card as my print Gcode file.

The only logical possibility that I can come up with at this stage as to why it did this was due to a power fluctuation corrupting the print process as we did have a brief thunderstorm around 10:30 p.m. last night. I’ve cleaned up the build plate and re-started the print job this afternoon so will see how it goes when I get to the office in the morning. I’ve also deleted the other Gcode files from the folder so tha tthe only file there is the one I want. That may be a good or bad thing depending on what happens…

Note that the little blobs of resin in the front corner of the build plate in the photo aren’t attached to the build palte - they are the remains of the other 3 Moai heads that I picked off the bottom of the vat and just sat on the plate before I took the photo - these never formed properly as the locations that they started printing in were away from my print and thus were un-supported.

If the print runs to completion successfully overnight, then perhaps a small UPS may be warranted on large print jobs.

Regards,

Glenn


#2

Did you delete and add other files before the Moai invasion? This seems to be a file fragmentation problem.
Here is a link to a wiki page about this.
http://wiki.peopoly.net/doku.php?id=moai-sdcard


#3

Ah - good spotting there. This possibly is a file fragmentation issue - I simply overwrote my previous version of the file in the gcode directory on the SD card (copied it from a network share where I had saved it out of Cura).

One wrinkle was that my previous gcode file was considerably smaller as it had been sliced at 0.1 mm layer height vs this file where I had changed the support structure as well as increasing the resolution to 0.05 mm layer height.

If it fails again tonight, I’ll re-format the card and copy the file onto it fresh as suggested.

Thanks,

Glenn


#4

If that still doesn’t fix the problem, you may be experiencing an issue with bad solder joints on your SD card reader. Intermittent contact due to bad joints and vibration can cause these sorts of issues as well.


#5

The print I ran last night did fail with the same problem - it was busy printing more Moai heads on it this morning, but that looks to be expected based on reading other peoples posts about this issue, so I’m formatting the SD card with the overwrite option right now.

Yeah - I just spotted posts about the dry solder joint issue as I was preparing my modified file for printing so I went and took out the SD Card interface PCB and checked the joints although they look good under a magnifying glass. I also checked continuity with a multimeter just to be sure (all the bottom row of pins are on a common bus on the PCB) and they were all solid.

The format is nearly done so I’ll load up the gcode file and start the print again.


Moai printing old prints even when not saved on SD card help!
#6

Hmm - failure again. This one simply stopped halfway though and backed the Z axis off as if it had finished the print. Bit of a problem now.

It might still be the SD card reader perhaps. There were also other problems though as well - part of the support structure didn’t print in one zone and the raft of pads on the built plate was an uneven thickness which means I’ve got a leveling issue.

The tank PDMS layer is getting a bit damaged from all the attempts so I’ll need to put in a new tank and re-level and then I’ll try reducing the file size by changing the profile in Cura back to the 0.1mm slice height to see if I can just get a successful print again.


#7

I would recommend checking the solder joints before doing other tests.


#8

there is file fragmentation issue.

For large print at the moment, it is best to use SD formater using quick format and just print one file. Always copy directly to the gcode. We are working on firmware fix as well as ways to make sure the SD card reader pins do not get broken off from usage.


#9

Thanks for the replies - @Lyndondr - yes, I pulled out the SD card socket PCB and checked the pins visually and electrically with a multimeter before trying that last print and it did check out OK.

A more definitive electrical test of the assembly would only be possible with an SD card extender cable, which I could make up with a little custom PCB and some ribbon cable.

It could also still be a file fragmentation issue as well - however, I did re-format the SD card using the SD card utility that came on the SD card with the printer with the overwrite option prior to copying across the gcode file into a gcode folder. It was also the only file on the SD card at the time of printing.

I’m just leveling up a new tank at the moment and I’ve simplified the support structure on the 3D model to reduce the file size. I’ve manged to knock over a GB (halved the file size) from the original file at the same layer height setting (50um) . I’ll try running that today once the new tank is leveled.

I’ve also got another SD card that I could try, although the chances of it being a dodgy SD card are slim.


#10

The 100um layer height settings with a Quick Format of the SD card before printing seems to have produced a successful print. Just have to deal with model/resin issues, but these are unrelated to this post so will leave them out.


#11

Was the quick format on the same card you were using when you were having troubles?


#12

Yes - it was on the same SD card. I’ve used the card that came with the printer ever since I got it a few weeks ago.


#13

How much space was used on the sd card and how big was the print’s file size?


#14

@deanan - do you want to know the SD card space usage/print file size for the successful print or the failures?


#15

If the format utility gives you any of the technical data on the card, e.g. controller, reported size, volume info, then you might check to see if it matches manufacturer specs. There are a lot of counterfeit SD cards out there, even from “reliable” vendors.


#16

The format utility indicates that the card is ‘as labelled’ - the label states that it is a 16GB card and this is what the utility reports after a Quick Format:-

snip_20180625100826

@deanan - The prints that failed were with a 2.9GB size gcode file. The first failure was with a mix of files on the card (all the files that are on the SD card when you receive the printer from Peopoly) as I was unaware that this would be a problem at the time (ah, the naivety!). The card was less than 50% I would guess - can’t remember as I keep the card very clean now - only the file to be printed in a gcode folder and that is all.

Anyway, after the first failure, I then retried after a full format (overwrite option) and had another failure.

It was only after this that I took more drastic action:-

  1. Downloaded the latest Cura profiles from Peopoly.
  2. Switched back to 100um layer height from 50um to reduce the file size
  3. Drastically reduced the amount of support structure in an attempt to reduce file size (later discovering that I’d gone too far in this…).
  4. Reformatted the SD card before every print using the Quick Format option as recommended by Peopoly here in the forum.

The file size was drastically slashed by the above measures, ending up at around ~650MB. But, while the prints didn’t fail due to file reading issues anymore, I found that there were now really big problems with distortion, edges collapsing due to lack of support and warping of large flat surfaces (of which there are many in this print).

I also had problems with ambient temperature control - the Incukit heater that I installed was struggling to keep the printer up to temperature when the exterior temperature dropped to below 10°C overnight. This was easily overcome by insulating the printer with 3 layers of bubble wrap (crude but effective).

I also ended up re-adding a lot of support to the print to try and overcome the distortion issues, which has succeeded in all but one problem zone, which I will attempt to overcome by adjusting the PM motor speed.

After 7 failed prints, I have now managed to print two consecutive successful versions at 100um layer height with a gcode file size of 860MB. I still have some problems with warping on one edge, but that should be for another post possibly if I can’t resolve it by tweaking PM motor speed and adjustments to support (which I have just made and am about to print). Here’s the latest version highlighting the remaining issue:-


#17

you can also further reduce file size by reducing the wall line count (thickness) in Cura. This simplifies the path.

image

Another way to reduce gcode significantly is to convert all the non zero E value into 1. This would require a script that we are looking for help to develop it. So it is WIP.


#18

Thanks for those tips.

You need a script to convert all the non-zero E values into 1? Could be done with Powershell/Regular Expressions perhaps. I’ll look into it.


#19

OK - just took a look at one of the gcode files generated by Cura and can see the E values that you mentioned in your post.

You simply want to find/replace all the E values >0 with 1 (no decimal places after the 1 I’m guessing?).

I could do that fairly easily in a Powershell script perhaps using .NET StreamReader/StreamWriter classes (more efficient large file handling) and some simple logic?

I need to read up a bit on the gcode syntax first though as I don’t want to generate garbage gcode. Doesn’t look too complicated (yeah, I know - famous last words eh).


#20

laser is fired based on a non-zero E value. And E value only happens on G1 command in Cura generated Gcode. That can save a lot of space as you can see there are a lot of trailing digit.

image