Pause at layer resume failed

[Plays2Hardball 0]

I finally decided to upgrade from trusty Cura 4.8 to 4.10. I don't remember having to reconnect all my Octoprint printers with previous upgrades but I managed it.

 

I have a model that I want to do a filament change on and decided to try the pause at layer height (Extensions - Post Processing - Modify G-Code). The print was looking great and I was quite happy when the printer paused allowing me to change the filament. I couldn't find a resume option on the LCD but I did notice the Cura Monitor was showing the print was paused. So far so good right?

 

When I selected resume in Cura the print head crashed into the print. It was making so much noise I was busy aborting the print before something got broken and didn't notice what the LCD display said. It was almost as if the Z axis went to zero on the way to resuming the print.

 

Here's the settings for the Pause at Height script:

 

Here are my specs.

Printer: Ender 3 with V4.2.7 Silent Board

Marlin: Shipped Version w/Silent Board

Send: M115
Recv: FIRMWARE_NAME:Marlin Creality 3D SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:V1.0 MACHINE_TYPE:Ender-3 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:BINARY_FILE_TRANSFER:0
Recv: Cap:EEPROM:1
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:0
Recv: Cap:Z_PROBE:0
Recv: Cap:LEVELING_DATA:0
Recv: Cap:BUILD_PERCENT:0
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:0
Recv: Cap:PROMPT_SUPPORT:0
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:THERMAL_PROTECTION:1
Recv: Cap:MOTION_MODES:0
Recv: Cap:CHAMBER_TEMPERATURE:0
Recv: ok

Octoprint: 1.6.1

 

Did I forget anything? Any ideas if I did something wrong or is just not supported with my configuration?

Edited August 11, 2021 by Plays2Hardball

[GregValiant 1,112]

When Creality released the 4.2.x boards there was a conflict on the boards between commands that send messages to the the LCD (M0, M1 and M117) and the LCD itself.  Because the TFT style LCD doesn't understand the "message" part of the command, the command is simply ignored.  In short - the normal failure is that the print should not have paused.

If you look through the gcode you will see the M0 followed by the resumption of the print.  There should be no "dive" in the Z.  (Your only PauseAtHeight setting I would question is your standby temp of 25°.  I typically don't allow the hot end to cool but I'm also generally close to the printer to catch the pause.)

I think you need to look at what Octoprint is doing with the M0 command.  The normal function of M0 is "unconditional stop" and a message "Click to Resume" is sent to the LCD indicating that a button click will get the printer going again.  If you don't see "Click to Resume" then maybe you have the issue described above.  A way to check is to send an "M117 BLAH BLAH" to the printer and see if the message appears on the LCD.  If it doesn't, then you have the glitch and maybe Octoprint is passing it's own M0 command routine to the printer which might include a homing move.