SD card destroyed again.

Si3

The onboard micro sd on my duet wifi has just been destroyed for the second time. I was updating the config.g file and the sd card was wiped and is now not detected by my computer when plugged in. This first happened with the supplied card and now the replacement. Surely this must be a fault with the board.

A Former User

The last incident was in 2018?

Si3

Yes it was.

A Former User

They do get worn out, not sure what the life expectancy is. Afaik they get written to on each print so if in frequent use maybe thats par for the course.

Hopefully some will have some empirical data for this.

PuterPro

@bearer said in SD card destroyed again.:

They do get worn out,

This is totally true, SD cards (and USB sticks) die when they like, rarely with any warning. Some live forever, others quit within months.

They're popped out of the factories with only a quick check, even the expensive ones, since they're made by the millions.

Annoying to be sure, but I'd replace and move on, they're not that expensive. Pretty unlikely the Duet is causing this, possible, but very low likelihood.

JamesM

Also, I don't know how reprap firmware handles this but in Marlin firmware if you run power loss recovery it is constantly writing to the SD card during a print and that wears them out much faster.

PuterPro

@JamesM
Yeah, that would do it. Haven't set that up on my machine since I run a 1500VA UPS and don't have power loss issues. Now that you mention this, don't know that I will.

Still, most cards will take a LOT of writes these days, it was more a problem on older designs, so if you're using some old card you had laying in a drawer since 2001 ...

arhi

A hint for sd cards to last longer, don't delete / overwrite files, always create new ones till you fill the card, then delete all and again don't delete till you fill the card. That will make card use evenly and last longer. Problem with this is at some point just too many jobs on the card so hard to find stuff

A Former User

I think i read somewhere that RRF or DWC updates the gcode files on each print? That could contribute if in frequent use if still valid.

dc42

@bearer said in SD card destroyed again.:

I think i read somewhere that RRF or DWC updates the gcode files on each print? That could contribute if in frequent use if still valid.

Several different things here:

When you simulate a file, RRF writes the simulated time to the end of the file.
Whenever you pause a print, RRF writes resurrect.g
If you have logging enabled, RRF appends a log entry at each significant event

Also, I don't know how SD cards behave if you remove the power while a write is in progress. A digital camera can control the power down, but RRF has limited options.

I have a dashcam in my car and the manufacturer recommends that I replace the SD card every few weeks.

bot

@dc42 said in SD card destroyed again.:

@bearer said in SD card destroyed again.:

I think i read somewhere that RRF or DWC updates the gcode files on each print? That could contribute if in frequent use if still valid.

[...]

I have a dashcam in my car and the manufacturer recommends that I replace the SD card every few weeks.

Wow! I did not know SD cards could need replacing so often. That makes sense with a dashcam looping the recording. Those industrial grade SD cards don't seem so expensive in retrospect!

How much more resistant to wear are those industrial cards?

arhi

@dc42 said in SD card destroyed again.:

I replace the SD card every few weeks.

you sure? I have some dashcam and they say "every few months" ? it records 2min segments and when card is full it erases the oldest ones to replace so it operates with full card non stop

SD cards behave if you remove the power while a write is in progress

can corrupt the filesystem and in theory could corrupt block allocation table but that's almost impossible as only high end cards have block allocation table (when a block is damaged it is relinked with a new block from "spare blocks") but those high end cards also feature a capacitor on the card itself so it can finish writing if power goes off

arhi

I just killed FS on mine .. doing some testing and did ~30 M112 in past hour (or whatever red "emergency stop" button on the DWC does) and it now won't boot, SD card issue

RepRapFirmware for Duet 2 WiFi/Ethernet Version 3.01-RC12 dated 2020-05-06b1
Cannot mount SD card 0: no FAT filesystem found on card (EXFAT is not supported)
Network disabled.
RepRapFirmware for Duet 2 WiFi/Ethernet is up and running.

SD card does not appear dead, just unreadable. Formatting now ("full format" so if there are messed up parts they get marked), hopefully it's not dead.

Danal

@arhi said in SD card destroyed again.:

red "emergency stop" button on the DWC does

M112 then M999. I don't know what SD writes that triggers.

arhi

@Danal no clue, I was doing around 30 (maybe more)
edit bed.g directly trough DWC
G32 from console
home x, home y, try to home z but Z motor stalls (that's what I'm testing)
during motor stall I click red button in DWC, whole thing restarts, I do it all over again ... and after few hours of this it didn't boot, connected to console (that isolator and usb is still attached from earlier) and seen no fat blah blah ... (interesting, not sure why duet don't support exfat, fatfs library support it for a while now)

sd card formated "not quickly"

zapta

@dc42 said in SD card destroyed again.:

I have a dashcam in my car and the manufacturer recommends that I replace the SD card every few weeks.

That sounds way too conservative (and impractical). Either the manufacturer does something very bad (hard to believe) or it just wants to cover itself. Do you indeed replace the SD every few weeks?