QGL Probed points range increase

General Discussion
1

Basic Information:

Printer Model: Voron 2.4 350x350
MCU / Printerboard: M8P V2
Host / SBC CB2
klippy.log
klippy (5).log (1.1 MB)

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

I am using a Voron 2.4 for more than a year and recentrly I tried to use the BTT-EDDY for bed mesh only, probing with Voron-TAP.
Apart from rapid bed mesh wich is nice I did not found the EDDY very satisfactory so I reverted to using the Voron TAP only, but now I get stange behavior during QGL, it fails while probed points range increase.
I checked belts, did not change any wiring, homing works fine, X / Y / Z movements works fine, STEPPER_BUZZ STEPPER=stepper_Z, Z1,Z2,Z3 works fine, in the right order and right direction.
I just cannot get what is going wrong with the configuration.
homing.cfg (7.5 KB)
printer.cfg (21.4 KB)
tap_config.cfg (3.1 KB)
tmc5160.cfg (3.6 KB)

2

Does this capability use any CB2 gpio pins? I found that hardware I had successfully integrated with my rpi5 (standalone development host) gpio did not work when I tried it on the M8P v2 with CB2 host. I swapped out the CB2 with a CM4 and that fixed my problems.

3

I used GPIO pins when working with the Steathburner and EE2209 bord and it worked fine.
Now I installed a H2 V2s Revo extruder and use the EBB36 CAN V1.2 and it did worked fine too.
Only lately QGL started to missbehave.

4

How stupid of me ! I mixed up the gantry corners:

[quad_gantry_level]
gantry_corners:
  -50,  400     # rear  / left 
  400,  -50     # front / right 

instead of 

gantry_corners:
   -50,  -50     # front / left
   400,  400     # rear  / right
1 Like