[BUG] Aquila x3 is not homing after flash

[afgp87]

Did you test the latest release build?

Yes, and the problem still exists.

Bug Description

Hi,

Thank you for all the hard work you're putting into this project — I really appreciate it!

I wanted to try out the firmware version Aquila_N32_IND_UBL-ProUI-EX-05-11, but for some reason, the Z-probe doesn't trigger during auto-homing. I've tried everything I can think of, but nothing seems to work.

I reverted back to the stock firmware, and the Z-probe works properly there. When I check the probe status, it shows as "open," and when I bring a piece of metal close to it, it detects and triggers correctly.

Any help or suggestions would be greatly appreciated. Thanks again!

Printer Model

Voxelab Aquila

Model Type

x3

Your Mainboard

None

Other Mainboard Type

No response

Add-ons that could be involved

No response

ProUI-EX | Extra Features?

Yes

Bed Leveling

UBL - Unified Bed Leveling

Did you include your own configuration files?

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

[Mik-S-UMS]

What exactly is it doing when homing Z? Does it only move up?
Did you use the switch diagnostic in Mriscoc to see it the sensor is being detected as triggered or was this on stock FW?
Does the same thing happen in an earlier version of the FW?

[afgp87]

Yes in the MRiscoC the probe is being detected and if I put something metal trigger the z, but when I do home z it just go up not down on the stock fw, It goes down and trigger z, do you have any idea how to fix it, hmm I will try early version, this is my first time using this, I'm more familiar with klipper, I don't know much on marlin, I'm planning to give this to a friend but I want to do the best I can

[Mik-S-UMS]

I'm not sure but could be related to #216, from what I understand it may be the offsets are not correct but from the OP of that issue it was homing but would not detect at certain spots.

Definitely try a going back a few versions to make sure there is not a bug that has crept in here recently and make sure the filename of the .bin you use contains _IND
If that suddenly works then you can move to the next release and see which one breaks.

[classicrocker883]

Could you try the NoPro test in this zip file and let me know if the issue is there?
https://github.com/user-attachments/files/20431703/ProUI_IND_UBL_Tests.zip

[afgp87]

Could you try the NoPro test in this zip file and let me know if the issue is there?
https://github.com/user-attachments/files/20431703/ProUI_IND_UBL_Tests.zip

Thank you Sir. I will try tonight and let you know

[classicrocker883]

on second thought, the probe not triggering make me think that the connection is not in the right ports. such as if you look at the BL or CR touch, one way of connecting is it has a 3pin and a 2 pin connector, and some have a single 5 pin. so this could be in a different place where it is supposed to register the trigger.

[afgp87]

on second thought, the probe not triggering make me think that the connection is not in the right ports. such as if you look at the BL or CR touch, one way of connecting is it has a 3pin and a 2 pin connector, and some have a single 5 pin. so this could be in a different place where it is supposed to register the trigger.

I'm using a 3-wire probe (black, brown, and blue wires). The probe itself appears to be functioning correctly: it lights up when open and turns off when triggered. custom fw MRiscoCProUI also recognizes the probe's status, showing 'open' in green and 'triggered' (by metal) in red. So, the probe is definitely recognized and working.
However, when I try to home the printer with the custom firmware, the print head moves to the center of the bed and then moves up instead of down. When I revert to the stock firmware, the printer homes correctly, moving the print head down until the probe is triggered

[Mik-S-UMS]

on second thought, the probe not triggering make me think that the connection is not in the right ports. such as if you look at the BL or CR touch, one way of connecting is it has a 3pin and a 2 pin connector, and some have a single 5 pin. so this could be in a different place where it is supposed to register the trigger.

The X3 has 3 wires in a 5 way plug for the BLtouch port so this will be correct, it does not need the last 2 as there is no probe to deploy. It uses the optocoupler board to convert the trigger signal from the sensor to the BLtouch port.

One thought I had was that somehow the configuration of the latest build had mixed up the trigger pin as BLtouch uses OUT but the inductive sensor only uses IN. As this was working properly for people before this is my guess guess for this version.

However if the screen diagnostic shows the probe triggering I don't know what could be at fault as otherwise the hardware is working correctly.

Maybe that for homing it is using the wrong input for Zmin.

@afgp87 did you try an earlier version?

[afgp87]

on second thought, the probe not triggering make me think that the connection is not in the right ports. such as if you look at the BL or CR touch, one way of connecting is it has a 3pin and a 2 pin connector, and some have a single 5 pin. so this could be in a different place where it is supposed to register the trigger.

The X3 has 3 wires in a 5 way plug for the BLtouch port so this will be correct, it does not need the last 2 as there is no probe to deploy. It uses the optocoupler board to convert the trigger signal from the sensor to the BLtouch port.

One thought I had was that somehow the configuration of the latest build had mixed up the trigger pin as BLtouch uses OUT but the inductive sensor only uses IN. As this was working properly for people before this is my guess guess for this version.

However if the screen diagnostic shows the probe triggering I don't know what could be at fault as otherwise the hardware is working correctly.

Maybe that for homing it is using the wrong input for Zmin.

@afgp87 did you try an earlier version?

I try all 3 files and all the versions back till November, M48 probe test failed

VID-20250530-WA0030.mp4

VID-20250530-WA0026.mp4

ssets/9f51f49d-e627-4857-ac5d-9a356d165ceb

VID-20250530-WA0025.mp4

[afgp87]

on second thought, the probe not triggering make me think that the connection is not in the right ports. such as if you look at the BL or CR touch, one way of connecting is it has a 3pin and a 2 pin connector, and some have a single 5 pin. so this could be in a different place where it is supposed to register the trigger.

The X3 has 3 wires in a 5 way plug for the BLtouch port so this will be correct, it does not need the last 2 as there is no probe to deploy. It uses the optocoupler board to convert the trigger signal from the sensor to the BLtouch port.

One thought I had was that somehow the configuration of the latest build had mixed up the trigger pin as BLtouch uses OUT but the inductive sensor only uses IN. As this was working properly for people before this is my guess guess for this version.

However if the screen diagnostic shows the probe triggering I don't know what could be at fault as otherwise the hardware is working correctly.

Maybe that for homing it is using the wrong input for Zmin.

@afgp87 did you try an earlier version?

I try all 3 files and all the versions back till November, M48 probe test failed

VID-20250530-WA0030.mp4

VID-20250530-WA0026.mp4

ssets/9f51f49d-e627-4857-ac5d-9a356d165ceb

VID-20250530-WA0025.mp4

Also my z offset is -15 may be a limitation in the firmware

[afgp87]

VID-20250530-WA0039.mp4

[afgp87]

I found this but I don't know how to do that https://reprap.org/forum/read.php?415,893383

[Mik-S-UMS]

Not quite sure if this is it but Z_probe should show it being closed (pulled low) when the sensor is not triggered then open (pulled high) when it is. I don't have an ABL so don't know if what this shows is correct.

When the Z limit switch, ABL or sensor is open this is considered as being triggered as this is normally closed so the nozzle does not drive into the bed if it is disconnected, this results it in only moving up when homing.

That thread explains the same thing that says the signal needs to be inverted for this sensor.

I also needed to revert Z_MIN_ENDSTOP_HIT_STATE and Z_MIN_PROBE_ENDSTOP_HIT_STATE to HIGH

Could you try going back to versions even earlier than November as this has been working fine for others with the same printer.

Z-offset looks to be about right from what I have seen of this sensor but not sure of the typical value.

[afgp87]

How i can do this i really don't understand how to do anything in marlin there is something like the printer.cfg? And how i access to that or if any one can do it a past me the .bin