Prints to about 12% then stops

[jimstapenell 0]

Hi, printer is Anycubic Chiron, running newly downloaded Cura 5.7.1

Print gets to about 12%, printer beeps as if it had finished, but only part done. This happened twice now. After I had first failure, I formatted the SD card, did new slice, this print failed also at the same point.

Prior to installing 5.7.1, I successfully printed using Cura 5.6.0

One attached pic shows the successful 5.6.0 printed model and failed 5.7.1 print. And the other pic is zoomed in on failed print.

Note, the second failure was a fresh slice and a formatted SD card so no file fragmentation on the SD.

Any advice? Hope you can help.

Regards,

Jim Stapenell

 

[Slashee_the_Cow 480]

Unfortunately this isn't much to go on. If you could post your Cura project (.3mf, in Cura go to File > Save Project) as well as gcode files generated by 5.6 and 5.7.1 so we can see if there are any important differences.

(If you uninstalled 5.6, you can have multiple versions installed side by side with no problems at all, so you can have both 5.6 and 5.7.1 on there. I have about 5 different versions installed to try and help people who don't want to update 😠)

 

7 hours ago, jimstapenell said:

so no file fragmentation on the SD

Nitpicking (I swear it comes from good intentions 🙂, feel free to ignore my ranting): fragmentation (the kind that's bad) doesn't occur in flash memory (SD cards, SSDs, etc.).

 

Hard drives are like a vinyl record... except magnetic and on a much smaller scale: there's a spinning platter (multiple in most hard drives, besides the point) and a head that reads, and in the case of a hard drive, writes. If a song on your record is split up so you have to move the arm and needle mid-song, then that adds the time it takes to how long to listen to the song. If it's in three different places there's even more time spent moving the needle and arm.

 

Now imagine you have a one gigabyte file on your hard drive, and is split up so each ten megabyte section is in a different place on the platter. Instead of just being able to move the head to one place and keep going, it has to read a little bit (won't even get up to its maximum read speed) then move the head, repeat 100 times. When defragmented, files will take up contiguous sectors on the platter, so it can just move the head there and read straight to the end, reaching their maximum speed (because of the time it takes the drive to get to spinning at full speed, a short read won't do it).

 

*/me tries to think of a similar analogy for flash memory*

Not sure I can come up with one. But flash memory has no moving parts. It takes no time to move from one sector to another, it can call any sector up at will with no delay, even if it's on a different chip (large SSDs tend to have multiple chips of memory). So when it starts and has to move to another part, the move is instant, so it doesn't matter that it's there.

 

Flash memory actually deliberately splits up files. Each memory cell can only have its state changed a finite number of times, so you'll eventually get to the point where you can't change the value in a cell, i.e. you can't overwrite a file stored in that sector - don't worry, to actually reach this point with good quality memory you either need to be a very heavy user or deliberately do it by constantly writing random values to each part of the memory (which is is also actually the second most secure way to delete files, behind only "stick it up on a pole so it gets struck by lightning", maybe third behind "fire"). When writing new data, it will write it to the sectors which have been written to the fewest times, and it doesn't matter if those sectors are in order. It's called wear levelling, so you don't end up with storage where half of it has been written so many times it's permanently fixed but half works fine.

[GregValiant 1,409]

Post a copy of the SD card gcode file as well as a project file.