Creality Print LAN print path appears to bypass/break KAMP adaptive bed mesh on K1

[JZNine]

Is there an existing issue for this problem?

• I have searched the existing issues

CrealityPrint Version

7.1.0.4414

Operating System (OS)

Windows

OS Version

Win 11

Additional system information

No response

Printer

K1

How to reproduce

When I start a print using Creality Print → Send to LAN Printer, KAMP does not use adaptive bed mesh correctly. The print falls back to the full/default bed mesh.

When I start the same gcode file from Fluidd/Moonraker on port 4408, KAMP works correctly and uses an adaptive mesh matching the actual object bounds.

What I verified:

KAMP is installed and enabled
Moonraker object processing is enabled
EXCLUDE_OBJECT_DEFINE is present in the gcode
START_PRINT is being called
test object was a single 20 mm cube
object bounds were approximately 100,100 to 120,120

Actual results

Started from Creality Print LAN: active bed mesh remained default, with full-bed bounds roughly 5,5 to 215,215
Started from Fluidd/Moonraker: active bed mesh became adaptive, with bounds 100,100 to 120,120

Expected results

The LAN print path in Creality Print should preserve the same KAMP/Moonraker adaptive meshing behaviour as starting the identical file from Fluidd.

Project file & Debug log uploads

Creality.zip

Block20XY.zip

Checklist of files to include

• Log file
• Project file

Anything else?

This appears to be specific to the Creality Print LAN print/start workflow, not the gcode itself.