Firmware 1.21 -Virtual Z axis (named U) goes to MAX between each probe
-
Before 1.21 all worked super nicely, so it's something that happened after upgrading.
My printer is using Ultimaker style XY gantry with bed moving up and down.
I have 3 seperate Z motors and use a BLTouch to probe 3 points to get true autolevel.
I have setup a virtual U axis that corresponds to Z-max, as Z-min is used for the probe.
I use M564 H0 directly in my config.g to prevent the requirment to home all axes before anything can move. Sidenote here is, that it couldn't even start the startupgcode in cura as it failed due to axes not being homed, although I had G28 in my startupgcode before any other movement….Problem is how the probing sequence is happening after upgrading to 1.21 from 1.20 as it homes XY as pr my startup code and then call G32 which executes the bed.g file as listed below.
What it does is that it startup as normal, but after each probe point it returns to U max ( I say U max as it recognize the endstop at MAX, which I guess it wouldn't do if it was Z, but I have no other way of knowing), so it probes, go to u-max, probe, u-max, probe, u-max... and then it starts printing with the bed still close to max..
[[language]] ; bed.g ; Called using G32 ; called to perform Autolevel using 3-point probe ; M561 ; clear any bed transform ; Probe 3-point M401 ; Deploy probe - deployprobe.g G30 P0 X200 Y0 Z-9999 ; Front Right G30 P1 X0 Y0 Z-9999 ; Front Left G30 P2 X100 Y165 Z-9999 S3 ; Center Rear - Made allowances for BLTouch being up to 30mm in front of nozzle. Typical is 27mm+/- M402 ; Retract Probe - retractprobe.g G28 XY -
1. Have you defined the length of your U axis in M208 commands, after the M584 command in config.g that creates the U axis?
2. When you assign the 2 motors both to Z again after homing using M584, do you hide the U axis again using the P3 parameter?
-
3ddistributed had a similar issue at MRRF but with a dual leadscrew driven X axis system with independent X +U axis homing but commonly driven for for normal motion. I did not have time at the show for very detailed debugging but in summary:
The X axis homing file was setup to split the X and U axis apart for homing, then recombine them after homing was finished. This used M584 with the P3 value to hide the U axis for normal use.
The M584 with the axis combined was what was configured in config.g, also with the P3 parameter.
The P3 parameter prevented the split apart homing from working properly. The U axis did not move when the axis were split. It did move when commoned with the X axis.
We temporarily resolved the problem by removing the P3 parameter everywhere it was present so the U axis was visible all the time. That solved the problem but of course the axis was visible all the time.
I hope shane can put up his config and home x files at some point.
-
