Resuming a print

Hi all,

So I made a resume.g file that looks like this:

M104 T1 S190.00
M190 S70.00
M140 T1 S190.00
G28 XY
M106 S0
G92 E0
G1 E13.5 F F150
G92 E24.81
G1 X319.449 Y176.961 F4000
G92 Z0.400
M23 Tube-Flanged-PLA-R-0,8-ITOMEC.gcode
M26 S32396

When I execute all these commands manually by using the Arduino serial monitor it works fine and it does actually resume the correct way. When I let the printer execute the resume.g file by itself, it fails miserably. I think it has something to do with starting a file while already running a file. I'm not with the printer now but the next thing I'm going to change the M24 command to:
case 24: //M24 - Start SD print
Maybe the sd.stopPrint will help. If not, then I'm open for suggestions :)


  • Maybe the sd.stopPrint will help. If not, then I'm open for suggestions :)
    Nope didn't work :(
  • You can only run one print from sd card, so starting one from sd card is not planned to work. You need to send them from a host to start.
  • But it must be possible right? Because I have seen it work on other machines that run repetier without the need for a host.
  • M23 closes the currently running file and opens the new one at position 0. Everything after that will not be executed. No idea how they did it then.
  • Well, actually nothing happens at all when I run M23 from a gcode file. The printer just sits there and the serial monitor says print finished
  • Yes, opening a file sets sdmode=0 which is print finished, but with next file for M24 selected. So send M24 to start next print or first M26 to set start position. As I already said M23 selects next file closing current one, so why so surprised it tells you it is finished.
  • I fixed it. I've added an entry to the display that will call this function:

     * Anteino 2-2-2018:  This function reads the resume.g file and prints it to the screen
     * before executing the contents. It is needed to have this as a function on the LCD
     * because you can't open another GCode file while currently having one opened. This
     * function will also be called upon sending M50024. This function will however only read
     * the first 1024 characters of the file, which should be enough for any resume.g
    void SDCard::resumeG_resume()
    	SdBaseFile parent;
    	parent = *fat.vwd();
    	float file_open =, "resume.g", O_READ);
      Com::printFLN(PSTR("file_open_success: "), file_open);
    	Serial.println("Resuming print.");
        char buffer_[1024];
, 1024);
    	  Serial.println("Opening resume.g failed");
  • Looks like you run it on a due since
    is not possible if PSTR has a meaning to read from flash.
    Otherwise the solution is good for your use case.
  • Cool, thanks :)

    However I run into some problem now. All seems to works fine and dandy. After stopping a print, the resume.g file gets created and can be started through the newly introduced menu entry. However the printer freezes after that. It prints to the UI display that is it homing itself and then just stops. On the serial monitor it says busy:processing. At first I thought it had something to do with the heaters since I use M109 and M190 and that the printer can't do anything until temperatures are reached and for testing/time purposes I am not going to wait 5 minutes before stopping a print. I found that it cannot be the temperatures since this even goes on after the printer reached its desired temperatures. I started isolating the error by putting Serial.println("Alive."); in different locations and found that the culprit was setHoming(true); in printer.cpp at line 1153. This function is properly executed but the code after that isn't executed, not even a serial.println:

    Note that the Serial.println("Alive.") after setHoming(true) has already been removed.

    After waiting for forever, the printer actually finishes its stopping procedure. Could it be that since it wasn't printing yet the printing speed is still (close to) zero and that it moves so slow that you couldn't notice it? I'd assume that homing should always work since there is a fixed speed for that. Also, this wouldn't explain why the code fails at setHoming(true);
  • I noticed, these problems only occur when I pause before the actual printing has started.
  • Right, so I have two printheads and at boot I tell the printer it has tool 1 selected and then make it select tool 0. I temporarily disabled the select tool 0 command because it takes 20 seconds to do and this is a pain with debugging. Re-enabling this piece of code somehow seems to fix the problem.
  • Maybe you need to stop printing before calling your function. You want to start a print and a pause could be why it does not start. But debugging such things is always hard. Many prints to check what is going on, i know.
  • I got it to work now though. Should I make a pull request to the repetier github to implement this functionality?
Sign In or Register to comment.