-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternatives to Micro SD cards for caching print files #139
Comments
That's a great idea! |
If you have suggestions about which memory modules to use, please post them here. As said, 128 MBit isn't too bad, but I've seen gcode which exceeds 16 MiB. (Of course, two could be combined, but then it gets expensive again). |
Unfortunately I have no experience whatsoever with this kind of memory chips. Are there cheap, ready-to-buy ESP modules with such chips onboard? Otherwise a microSD shield may be the more pragmatic (although overkill) solution for "normal users"... |
Price wise using an SD card can be very viable. Depending on how well the FTL works in them, they will last basically forever with this application. Cheap asian ones with imaginative brands might not last as long as the big vendors', but I doubt even they would ever fail. A module with the chip I mentioned costs < 2 USD and uses SPI for communication, like the MicroSD stuff (MicroSD natively supports SPI according to Wikipedia, actually). I think in the cheapest shops you can find them for even less. |
A note on longetivity: both MicroSD and volatile memory should reach long lifetimes in this application. The former uses nonvolatile storage which has drastically lower wear counts (amounts of writes before failure), but as they're pretty large, we can spread the writes in many many locations. The built-in FTL takes care of that. The volatile storage modules don't provide as much size, but volatile memory generally have really large wear counts. You can rewrite a volatile cell way more often than a nonvolatile. ¹ Technically I consider both systems suitable for this purpose. It's also less about the price. Using volatile storage is just some interesting experiment, I would say. |
Agree. One thing to consider, with the SD card we might add some web UI that would allow one to retrieve and reprint past prints, which can be very handy in some situations. |
How about using one of those "memory modules" for caching the gcode files? There's no need for nonvolatile storage; if the module is reset the data has to be resent anyway, I guess.
Using a Micro SD via SPI is more expensive (well, the modules cost the same, but you need an SD card, and you don't want to use the cheapest), and I think most gcode shouldn't exceed 128MBit (using a board with e.g., a W25Q128).
Might become obsolete when #45 is implemented.
The text was updated successfully, but these errors were encountered: