› ›

Print from SD / Save to SD ... to keep all security features from 3d printer

mr_cgmr_cg
in Feature Requests
Please implement the feature to also print the gcode which is stored on the SD card from the printer.
Beside this it should be also possible to store the gcode also from Repetier Server to SD card from printer (feature called "print to SD").
Both features are also available in Octoprint by default.

It's absolutely mandatory feature for me to move from Octoprint to Repetier Server!
BECAUSE ......
Only with printing from SD card (from 3d printer) all security features (e.g. Power Panic, Filament Sensor, Loss of steps) from 3d printer are guaranteed to work 100% properly. More and more printer are providing such features and it's an important selling point. Without printing from SD card feature it's not guaranteed that the security features will work (especially the power panic feature).
On large and huge prints i am always printing from SD because of mentioned reason.

The sources from Octoprint should help to implement such basic feature also to Repetier Server.

Comments

  • RepetierRepetier
    The idea of repetier-server is not to use sd card any more. This allows us better analysis and gcode view, excluding failed regions, timelapse per layer and more. With sd card this all would just reduce to a percentage view and void all these functions.

    Filament sensor can also work with server. Firmware just needs to tell about that. Power loss may be a problem as pi would then also loose power. 

    What is the solution to loss of steps if detected while printing from sd card? Could firmware not fix it the same way when printing over serial? I guess it would just rehome the axis to get correct position again?
  • mr_cgmr_cg
    I guess filament sensor and loss of steps should work if printer triggers normal pause gcode.
    The power loss will definetely not work as the print server does not know if and where (line number) the power loss happened.

    The implementation of the requested feature is really pretty simple and i think it's worth to implement it.
    It's few M-Godes to be implemented:
    Lot of new printers (Prusa pushed this feature!) have the power panic feature and the people want to use it ... just in case.

    If you follow the 3d printing scene (E.g. Tom's and Joels Youtube channel) than you should know that such features are "state of the art" and will become standard in the near future. The printers in 3-4 years will anyhow have print server on board ... no doubt. It's the time from now until than where the people buy new printers with new features and want to use them.

    The "print to SD" i really do not need. But the "print from SD" would be mandator.
    Currently we have lot of summer storms which can easily lead to short power loss.
    For prints >8h i am always printing from SD to have the security which my Prusa MK3 is providing to me.
    A lot of other users are talking about external printing server (octoprint) exactly because of this reason.

    Repetier Server is GREAT but unfortunately still lacking same important features which octoprint is providing.

  • mr_cgmr_cg
    Coming back on this feature request.
    The implementation could be very simple.
    I do not need to have the SD files in the same location als the local files.
    Also no rendering or additional information needed.

    For implementation i would recommend to have seperate tab only for "print from SD" in order to keep this seperately from normal local printing process and make implementation easier.
    The most challenging issue is to implement the monitoring control (printing time, remaining time, temp, etc.) while printing from SD is ongoing and start/stop timelapse. Print to SD would be also nice but it's not that important because transfer is anyhow very low.

    This would be the minimum M-Code requirements:

    M20 ===> list SD card

    18:11:55.280: Begin file list
    18:11:55.583: /CR-10C~1/6 ~1/JG-HU~1.GCO 534333
    18:11:55.612: /CR-10C~1/6 ~1/ ~1/JIGUAN~1.GCO 1627889
    18:11:55.612: /CR-10C~1/6 ~1/ ~1/JIGUAN~2.GCO 433969
    18:11:55.916: /CR-10E~1/47ACB~1.MOD/YAXISW~1/CR-10~1.GCO 2653383
    18:11:55.932: SCHRAU~1.GCO 8563406
    18:11:55.932: CAT~1.GCO 20681570
    18:11:56.003: 3DBENC~1.GCO 2944671
    18:11:56.003: FLASHY~1.GCO 558560
    18:11:56.003: CUBE_2~1.GCO 55796
    18:11:56.003: CUBE_2~2.GCO 55810
    18:11:56.004: CUBE_2~3.GCO 55810
    18:11:56.004: CUBE_2~4.GCO 55814
    18:11:56.004: CUB39E~1.GCO 55814
    18:11:56.004: CUB9E7~1.GCO 55818
    18:11:56.004: 3DBENC~2.GCO 7743337
    18:11:56.004: LITHOP~1.GCO 19524862
    18:11:56.004: RICOH_~1.GCO 12003445
    18:11:56.005: LOUBIE~1.GCO 17061611
    18:11:56.005: ULTIMA~1.GCO 11332715
    18:11:56.005: TENSIO~1.GCO 1851078
    18:11:56.005: TENSIO~2.GCO 1099190
    18:11:56.005: CR10_2~1.GCO 8150
    18:11:56.005: CLIMBI~1.GCO 1627416
    18:11:56.005: THE_UL~1.GCO 6484048
    18:11:56.005: PITFT3~1.GCO 4001633
    18:11:56.006: PITFT3~2.GCO 3470089
    18:11:56.006: SC_LPT~1.GCO 820974
    18:11:56.006: End file list


    M32 CR10_2~1.GCO ===> select file "CR10_2~1.GCO" from SD card

    18:13:23.555: echo:Now fresh file: CR10_2~1.GCO
    18:13:23.569: File opened: CR10_2~1.GCO Size: 8150
    18:13:23.570: File selected

    M24 => Start/Resume SD Print

    M25 => Pause SD Print

    M0 => Stop

  • RepetierRepetier
    The problem is not the few gcodes. I would require a complete redesign of everything showing running print in server structure. We have no time estimate any more as that is not delivered from firmware. So we need to change it to %done without eta.

    At the moment I'm more thinking about adding a server side support to continue a print. If I log lines printed I could resume print at that position at least if printer homes to z max or moves z without z homing and we know z does not move when unpowered. We could then simple rehome xy, set temperatures and continue. Would also work if connection was lost for some reason.
  • mr_cgmr_cg
    This sounds very interesting and useful for lot of other users where the printer does not support power panic. I think this would be really amazing feature. The only concern i have is storing continously on the SD card would result in early damage. To prevent this Prusa has small power buffer to write all relevent information to memory short time after power loss has been detected. Prusa does only xy rehoming and proceed with saved temp/fan/line-no information. On github more information could be available.

    But your idea is really great and lot of people will like it !!!
  • RepetierRepetier
    Wear out of sd card is in deed a problem. So I'm not allowed to flush every write - that would in deed destroy the sd card quickly. I think about writing a continous file without flush, so os will flush every 4kb. Now I have to write enough that 4kb is not a very long time span for a power loss. For connection lost is is less critical as I can close the file. Maybe flush on new Z level so Z is safely stored. There are still some points to think about. So I#d like the firmware e.g. to move to save pause position on connection lost to prevent causing a big drop.

    BTW: How does Prusa solve the fat drop and burning in on power loss? I mean saving position when voltage drops it one thing, but doe sit have enough power to move also outside of print?

  • cdburgesscdburgess
    It doesn't move outside of print. So you could get pooling. Once it powers up it will raise and home, reheat, then resume printing.
  • mr_cgmr_cg
    They use a capacitor which has enough power to write all relevant data immediately after power loss happened.
    Josef Prusa was also talking about this in one of his Youtube interview to prevent flash memory damage.
    Prusa has really very unique features which i really like.

    Description from Prusa Research Homepage:

    The printer can fully recover from a complete loss of power without the 
need for batteries or a UPS. A special sensor detects mains voltage, and
 in case of an interruption, it immediately shuts down the heatbed and 
extruder heating, leaving enough power in the capacitors to store the 
position and lift the print head away from the print. In case of a very 
short power failure, the printer will attempt to continue printing 
immediately without waiting for user interaction.
    Source:


  • mr_cgmr_cg
    I have met now several Prusa MK3 owners and the majority of them are not using RS because of the missing "Print from USB" functionality. Main reason is the loss of in-built power recovery feature which are only available when printing from SD. Just wanted to let you know to re-think about later potential availability.
  • lexiluna83lexiluna83

    Printing from and saving to SD cards in 3D printing preserves essential security features. This approach minimizes the reliance on external connections, reducing vulnerability to potential cyber threats. It's a prudent measure to ensure the integrity and confidentiality of 3D printing projects, aligning with best practices for secure manufacturing processes.


  • lexiluna83lexiluna83
    edited January 27
    mr_cg said:
    I have met now several Prusa MK3 owners and the majority of them are not using RS because of the missing "Print from USB" functionality. Main reason is the loss of in-built power recovery feature which are only available when printing from SD. Just wanted to let you know to re-think about later potential availability. 
    Thank you for sharing your experience. It's valuable feedback for Prusa, highlighting the importance of "Print from USB" functionality and the need for power recovery features. Your input will likely influence future product development.




Sign In or Register to comment.