G-code Bed Mesh Compensate

Warped build plates are the quiet killer of first layers. Most slicers have a bed-mesh leveling probe that compensates live on the printer, but if your workflow is generating or post-processing g-code in ComfyUI - which is exactly what the pack's G-code lane exists for - you want that compensation baked into the toolpath, not left to whatever firmware happens to be running. MKRGCodeBedMeshCompensate does that: it takes a G-code plan, samples a bed mesh, and adjusts the Z of every move accordingly.

It's the "make the print physically work" step in a pipeline where the g-code is a living document inside your graph rather than a file a slicer spat out once. Think of it as software-level mesh leveling that happens before the file ever leaves ComfyUI.

How it works

Inputs:

• plan (MKR_GCODE_PLAN) - the toolpath plan, typically from one of the pack's G-code generator or analyzer nodes. The node reads its moves, computes bounds, and rewrites each move's Z.
• mesh_json - the mesh, a JSON object with bed_width_mm, bed_depth_mm, and a 2D offsets array of Z corrections. The default is a small 3×3 example so you can test without a real probe.
• max_compensation_mm (default 0.5) - hard clamp on any applied Z correction.
• warn_if_over_mm (default 0.4) - if compensation exceeds this, the node flags it in the report.
• fade_height_mm (default 3) - fades the correction out over the first few mm of Z, so it doesn't fight the print once the nozzle is well clear of the plate.
• use_profile_bed_size (default true) - when on, uses the printer profile's bed dimensions and placement offset to map the mesh; with the optional profile (MKR_GCODE_PROFILE) input, that's where the size comes from.

The math per move: map the move's X/Y into the mesh grid, sample the correction, apply the fade, clamp to max_compensation_mm, and write the adjusted Z. Because it works on the plan (the structured move list) rather than raw g-code text, it can be much smarter than a text-regex approach - it knows the toolpath, not just the lines.

Outputs: plan (the corrected plan, with Z-adjusted moves and a bed_mesh_compensation metadata block), report_json (mesh size, bed size used, max raw and applied compensation, warning count), and summary.

The gotcha that will bite you

The mesh must be sampled over the correct bed coordinates, or your compensation will be applied at the wrong places. If use_profile_bed_size is on but no profile is connected, the node uses the mesh's own bed size - so check report_json's mesh_bed_size_mm against your actual printer if prints come out inconsistent. And if the raw mesh requests more than max_compensation_mm, the node clamps (and warns) rather than silently over-correcting - that's a feature, but it means an extreme mesh will be partially ignored.

Installing

Part of MKRShift Nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/criskb/MKRShift_Nodes

Restart ComfyUI, or ComfyUI Manager search "MKRShift_Nodes". No extra Python deps - the g-code lane is pure Python. It's designed to pair with the pack's other G-code nodes (MKRGCodePrinterProfile, the generators, MKRGCodeExport).

The honest framing: this is a genuinely useful idea - real mesh compensation folded into a structured toolpath plan - and the author's own docs ship a worked mesh format example, which is more than most young nodes bother with. But it's a young, niche lane with no community signal yet, so treat report_json as your only ground truth and verify the applied Z on a test print before you trust it with a production file.