BL Touch doesn't deploy after moving U axis

[Ant1]

Hello,

I am experiencing a weird issue with my Duet3D. I have a setup with a BL touch to home the Z axis, and two additional U and V axes that are used to actuate other tools.

The first home that I send to the machine works properly, and the BL touch deploys. Then, as soon as I send a command to move the U or V axes, subsequent homes fail to deploy the BL touch.

I have tried to debug why moving the U axis somehow changes the homing behaviour in the firmware by analyzing the state model using the output from M409, but I couldn't find anything...

Do you have an idea where this could come from ? Could it be a hardware issue ? Or is it a firmware issue ?

Here is my config.g file so that you can see my configuration.

Thank you for your help and have a great day !

Antoine

[Phaedrux]

Please share your homing files include your deploy and retract macros.
Also please share the results of M122 and M98 P"config.g"

[Ant1]

@Phaedrux Thanks for your quick reply ! Here are the files you requested:
config.g
deployprobe.g retractprobe.g
homez.g homey.g homex.g homeu.g homev.g homeall.g
M98.txt M122.txt

[Phaedrux]

@Ant1 said in BL Touch doesn't deploy after moving U axis:

The first home that I send to the machine works properly

How are you homing? Are you homing all, or just a specific axis?

as soon as I send a command to move the U or V axes, subsequent homes fail to deploy the BL touch.

How are you homing the second time? When in this state can you test manually deploying the pin by sending M401 and M402?

[Ant1]

@Phaedrux

How are you homing? Are you homing all, or just a specific axis?

Homing all the axes, or just Z both reproduce the issue.

How are you homing the second time? When in this state can you test manually deploying the pin by sending M401 and M402 ?

Again, the second time homing all axes or just Z both reproduce the issue. Once I move the U axis, neither M401 or M402 have an effect, indeed.

[Phaedrux]

Is there something physical about moving the U axis that is disrupting the BLtouch cabling? Do the wires for the BLtouch and the U axis motor run near each other?

[Ant1]

@Phaedrux No there isn't anything physical. The U axis motor doesn't interfere with the BL touch. Also, when restarting the machine, it works, which points to the fact that the issue comes from the firmware, I think.

[Phaedrux]

Firmware 3.5 is officially released now. Can you please try updating?

Sudo apt update && sudo apt upgrade from the pi terminal.

[Ant1]

@Phaedrux I updated to version 3.5 but it doesn't make any difference unfortunately

[gloomyandy]

@Ant1 Can you add the following line to your deployprobe.g file:

echo "deploy called"

Then restart your printer and run your test sequence again. You should see that "deploy called" message should appear in the console when you try to home Z. Please try homing Z two or three times and check that the probe deploys. Then move U and try homing Z again, does the "deploy called" message appear when you run G28 Z after moving U?

[Ant1]

@gloomyandy I did that and it worked. So now the setup is working on this machine ! I don't know why adding a comment to the file changed something though...

[Ant1]

@Ant1 We realized that after putting the U axis under tension using M17 U, there is an interference between the BL Touch's ground and the U motor phases... So we are now investigating this issue. So I think that the issue doesn't come from the firmware, so I guess we can close this topic and we will test our setup on our side... Thank you very much for your help !!