PFW-1536: Reprint function implemented for MK3S/MK3S+

[jfestrada]

This PR is a the same than #3071 but using the current repository of my fork of your firmware

To support this functionality I have added a extern bool variable which can be read/set from cmdqueue.cpp and ultralcd.cpp so when the card reader reaches the EOF the variable isPrintFinished will be set to true and the main menu will show the REPRINT option.
How do I know which file we need to reprint? All the information needed to perform the reprint was stored on the EEPROM in case of a power panic and the fw recover this information in order to start the print from SD again, so using that information the function reprint_from_eeprom() has been implemented.

Translations:

• 🇨🇿 same as buddy firmware
• 🇩🇪 same as buddy firmware
• 🇪🇸 same as buddy firmware
• 🇫🇷 same as buddy firmware
• 🇮🇹 same as buddy firmware
• 🇵🇱 same as buddy firmware
• 🇳🇱 by @3d-gussner @vintagepc please check Firmware_nl.po
• 🇭🇷 @Prime1910 please check Firmware_hr.po
• 🇭🇺 @AttilaSVK please check Firmware_hu.po
• 🇳🇴 @OS-kar and @trondkla please check Firmware_no.po
• 🇷🇴 @leptun and @Hauzman please check Firmware_ro.po
• 🇸🇰 @ingbrzy and @shatter136 please check Firmware_sk.po
• 🇸🇪 @Painkiller56 please check Firmware_sv.po

[github-actions]

All values in bytes. Δ Delta to base

Target	ΔFlash	ΔSRAM	Used Flash	Used SRAM	Free Flash	Free SRAM
MK3S_MULTILANG	-72	-21	246686	5635	7266	2557
MK3_MULTILANG	-68	-19	245972	5644	7980	2548

[jfestrada]

@3d-gussner could you share an example of the // action:reprint?

[3d-gussner]

The language Firmware.pot and Firmware_xx.po have to be update with the scripts update-pot.py and update.po.py.
I will change it for you if that is okay.

Submenu can be 18 character long and NEED to have same c= values in the .po files as it is in .pot file.

[3d-gussner]

The SD card print from the LCD screen is saved to eeprom, but what about the SD card prints started from a host using M23 and M24 these aren't covered, or are they?

[3d-gussner]

After a USB/Host print (which is streaming the gcode over serial line) the Reprint menu should send a serial message // action:reprint to the host. Then the host has to do/run its own sequence depending on this action.

We can use the existing M118 A1 action:reprint to send the message // action:reprint via serial line.

So the Reprint menu on LCD should:

• restart the SD print
  • When the previous print was a SD print that has been selected via LCD menu before ✔️
    • We save already the information in eeprom and this PR uses this. That enables the option to reprint also after reset or power cycle
      • I think in this case it would be useful to show which file will be reprinted with an yes/no option to continue with yes if times out
  • When the previous print was a SD print that has been started via M23 and M24 gcode commands from USB/host system before 🚧
    • We don't save this information to eeprom, and not sure if we should do that as well like selecting from LCD screen.
      • We could read from the memory only.
      • If not implemented the reprint after a reset or power cycle would start the last LCD selected print and not the last via gcode started SD print.
• When the previous print was an USB/Host streamed print send // action:reprint. 🚧

[jfestrada]

The SD card print from the LCD screen is saved to eeprom, but what about the SD card prints started from a host using M23 and M24 these aren't covered, or are they?

Only if the print is launched from the remote host but with a local SD file, in other case I doubt it should be covered, I mean, when you are printing from SD the main user input is using the LCD, there is where the Reprint function make sense because the user does not need to search the file again on the SD using the LCD menu. When the user is printing from a remote host, their main input is made through that host, so make sense that should be that host which take the control of the Reprint action, usually in octoprint you just need to hit the print button again. Is similar than in mainsail or fluid interfaces and I suppose than in prusaconnect will be the same.

Anyway in the case that you are executing the printing from the SD but from a remote host (octoprint, prusaconnect, ...), that should show the reprint menu in the LCD because is similar to execute it from the printer directly, and the enableReprint variable becomes to true when the cmdqueue became empty and the card report the EOF.

if(card.eof())
  {
      // file was fully buffered, but commands might still need to be planned!
      // do *not* clear sdprinting until all SD commands are consumed to ensure
      // SD state can be resumed from a saved printing state. sdprinting is only
      // cleared by printingHasFinished after peforming all remaining moves.
      if(!cmdqueue_calc_sd_length())
      {
          // queue is complete, but before we process EOF commands prevent
          // re-entry by disabling SD processing from any st_synchronize call
          card.closefile();
          enableReprint=true;

Also as the printer is using the SD to print the file the firmware will store the file and the line on eeprom.

[3d-gussner]

@jfestrada The "Reprint" option on LCD is for the User after clearing the bed.

1. Remove print
2. Clean sheet
3. Press Reprint on LCD as they are already there
   a. without having to go back to the computer and press the Reprint button in PrusaLink/PrusaConnect/OctoPrint/other host system.
   b. without having to select the SD again in the dirs etc.

[3d-gussner]

@jfestrada I personally prefer to print from SD and monitor with PrusaLinl/PrusaConnect or Octoprint. When anything happens to the host/network the print continues! And with the RPi port the printer doesn't restart as with USB (you can switch that off BTW) and can continue to monitor the print.

So if I had a farm:

• I would store all files on SD card
• Use PrusaLink/PrusaConnect or Octoprint as central monitoring system.
• Start these SD prints from HOST.

[jfestrada]

After a USB/Host print (which is streaming the gcode over serial line) the Reprint menu should send a serial message // action:reprint to the host. Then the host has to do/run its own sequence depending on this action.

We can use the existing M118 A1 action:reprint to send the message // action:reprint via serial line.

OK, I think that could be easy to implement and nice to have.

So the Reprint menu on LCD should:

* restart the SD print
  
  * When the previous print was a SD print that has been selected via LCD menu before ✔️
    
    * We save already the information in eeprom and this PR uses this. That enables the option to reprint also after reset or power cycle

As it is implemented currently, after a power cycle or eject of the SD the Reprint is disabled, why? because you can't be sure if the last print was OK or if the inserted SD is the same. Would be nice to have the reprint enabled after a power cycle? yes but the firmware will need to check that the last print was finished and that the file exists on the SD before to show the menu for the Reprint. Now the question is, should the reprint be enabled after a powercyle?

      * I think in this case it would be useful to show which file will be reprinted with an yes/no option to continue with `yes` if times out

Ok, I agree with that

  * When the previous print was a SD print that has been started via `M23` and `M24` gcode commands from USB/host system before 🚧
    
    * We don't save this information to eeprom, and not sure if we should do that as well like selecting from LCD screen.
      
      * We could read from the memory only.
      * If not implemented the reprint after a reset or power cycle would start the last LCD selected print and not the last via gcode started SD print.

currently that will not happen because after reset or powercycle the variable enableReprint is set to false.

Should the reprint be enabled after a powercyle?

* When the previous print was an USB/Host streamed print send `// action:reprint`. 🚧

Ok, I agree

[jfestrada]

@jfestrada I personally prefer to print from SD and monitor with PrusaLinl/PrusaConnect or Octoprint. When anything happens to the host/network the print continues! And with the RPi port the printer doesn't restart as with USB (you can switch that off BTW) and can continue to monitor the print.

So if I had a farm:

* I would store all files on SD card

* Use PrusaLink/PrusaConnect or Octoprint as central monitoring system.

* Start these SD prints from HOST.

That's also my preference, so we have the same point of view

[jfestrada]

So I will take care of:

• Update language files
• Send the action:reprint when the print has been streamed
• Implement the yes/no question with the name of the file to be reprinted in case of a SD print

My question now is, should be enabled the reprint after a power cycle?

[3d-gussner]

Implement the yes/no question with the name of the file to be reprinted in case of a SD print
My question now is, should be enabled the reprint after a power cycle?

You made a point that the reprint after power cycle isn't really needed, and so no need to add the extra message.
This was only a though as we have it in eeprom to use it, but as the bool reprint is reset after power cycle i would say no need for additional code and usage of resources.
If users ask for that we can implement it later.

[arekm]

Anyway in the case that you are executing the printing from the SD but from a remote host (octoprint, prusaconnect, ...), that should show the reprint menu

Just to be clear on this - so prints started remotely (from octoprint for example) via M23/M24 are covered and "Reprint" will show up - correct?

[jfestrada]

Anyway in the case that you are executing the printing from the SD but from a remote host (octoprint, prusaconnect, ...), that should show the reprint menu

Just to be clear on this - so prints started remotely (from octoprint for example) via M23/M24 are covered and "Reprint" will show up - correct?

Yes, those one are covered with the Reprint function through the LCD menu

[3d-gussner]

@jfestrada Do you have any update commits for this PR?

[3d-gussner]

Closing in favor of #4510

@jfestrada Thanks for this PR 😍