Print complete confirmation dialog interrupts automation scripts

[EEParker]

Description

Steps to Reproduce

1. Use automation plugins for OctoPI or 3DQue Quinly.
2. LCD confirmation dialog will pop up asking for confirm when print is complete.
3. This blocks the automation or part looping scripts from continuing, causing automation to fail

Additional Information

The Draw_Print_confirm(); line triggers the confirm dialog.

https://github.com/Jyers/Marlin/blob/918ae4893fd0fb0a4d953c9b9e858048d85245cb/Marlin/src/lcd/dwin/creality_dwin.cpp#L5180-L5188

To be able to use any of these automation tools, this confirmation dialog must not be shown. Please consider removing it, or adding a config option to disable it. Thank you for your time.

[Jyers]

As @tititopher68-dev, the confirm screen doesn't do anything at all, it's just visual. It does not stop prints from being executed or gcode from running. I'd look for the bug either with the plugin itself or with the main Marlin repo.

[BinaryConstruct]

When looping, the firmware gets stuck on the dialog and does not go back to the "printing from host" screen.

[BinaryConstruct]

Please consider a configuration item, such as:

#define SUPPRESS_COMPLETE_DIALOG 
[...]

void CrealityDWINClass::Stop_Print() {
  printing = false;
  sdprint = false;
  thermalManager.zero_fan_speeds();
  thermalManager.disable_all_heaters();
  ui.set_progress(100 * (PROGRESS_SCALE));
  ui.set_remaining_time(0);

#if ENABLE(SUPPRESS_COMPLETE_DIALOG)
  // emulate click confirm
  popup = Complete;
  Draw_Main_Menu();
  DWIN_UpdateLCD();
#else
  Draw_Print_confirm();
#endif

}

[Jyers]

@BinaryConstruct The issue is not with the firmware getting "stuck" as you say. If you call an M75 while the print confirm dialog is up, I can assure you it will go right back to the print screen. The firmware does not "loop" it simply has different states which can be freely transitioned between without any need for actual user input. So you are still able to call M75 and change it back to printing. My guess is you don't have your host configured correctly. It should be calling M75 before every print to restart the print timer and return the screen to normal. Hopefully this makes sense.

[BinaryConstruct]

@BinaryConstruct The issue is not with the firmware getting "stuck" as you say. If you call an M75 while the print confirm dialog is up, I can assure you it will go right back to the print screen. The firmware does not "loop" it simply has different states which can be freely transitioned between without any need for actual user input. So you are still able to call M75 and change it back to printing. My guess is you don't have your host configured correctly. It should be calling M75 before every print to restart the print timer and return the screen to normal. Hopefully this makes sense.

Thank you for the feedback!