[BUG] Dangerous behavior when homing

[yrabbit]

Did you test the latest release build?

Yes, and the problem still exists.

Bug Description

Selecting the Auto Home menu item should result in relatively slow axis positioning. Instead, the motors are switched on at full power so that they hit the limit switches at high speed.
Apparently the switches do trip as the movement stops, but I fear that the printer frame will not survive this for long.

It's not just a menu item, it's any homing command.

I can tell you that this behavior is not observed on the commit 1485e78

But it's already present in full on the commit
7b8fb6a

The unmodified file in the video
Aquila_427_UBL-ProUI-EX-IS-MPC-09-19.bin

bad.mp4

Printer Model

Voxelab Aquila

Model Type

No response

Your Mainboard

Creality v4.2.7/4.2.2 F103RET6

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

[classicrocker883]

@Mik-S-UMS someone else has brought this to my attention. im not sure whats caused this because when it first flashes it homes normally, but upon restarting it does the same thing.

this was something that was supposed to be fixed, and after reviewing what was changed and then reverted, I'm not sure what code can be causing it.

[jake5253]

Same problem here. Additionally, sometimes the steppers (I'm not sure which one(s)) are locked at boot so when trying to home, Z moves up perfectly fine, and then when XY tries to move it makes an awful noise and makes me manually turn the machine off and on again. It's hit or miss. I haven't determined what makes it go into locked steppers mode vs homing perfectly fine. Not sure if its related to this, even.

[yrabbit]

@Mik-S-UMS someone else has brought this to my attention. im not sure whats caused this because when it first flashes it homes normally, but upon restarting it does the same thing.

You are right, I just forgot to note the fact that you first need to turn off the printer and only then watch with horror as the carriage crashes into the frame. :(

Since I needed to print the part urgently anyway, I started the print without rebooting and noticed that the progress bar was gone. This may be due to me pressing "Don't show GCode preview" or something else in the menu. I won't report it as a bug, just keep in mind that there are other weird side effects.

screen.mp4

[classicrocker883]

yes there are a couple things going on which were not presernt before at one time. for instance if you try a PID tune Confirm button does nothing and is stuck on that popup screen. doesn't seem frozen though, but only remedy is a restart.

after looking through the code so far and the changes from the past month or so, the things that made most sense to me I reverted and tested out to no avail. like the functions axis_should_home/ axes_should_home had a small change which made it seem like to be the one, but that wasn't it, still had the homing problem.

I even flashes the latest MarlinFirmware bugfix-2.1.x, that had no problem with homing whatsoever.

so as of this moment I suspect it might be having to do with compatibility with the mriscoc libproui.a ProUI-EX library inside the lib folder, or it can even be something with settings.cpp - the main EEPROM file.

---

as of now I have been priorizing this and of course if anyone wished to help out I can start a discussion looking to check some of the code or testing some new firmware.

[jake5253]

I'd be willing to be a guinea pig and run some testing firmwares. I have an Aquila V1.0.1 (N32) with a generic BLTouch.

[yrabbit]

My Aquila with Creality 4.2.7 is also at your disposal.

I have spare timing belts, I will also look for a spare motherboard 4.2.7 on the flea market just in case :)

There may be delays for a day when I print something, but the rest of the time - please.

[classicrocker883]

I've been testing a lot trying to see what the **** is going on. so I reverted back to Sept 9, what was said "last known good" and for some odd reason movements are completely disabled. steppers do get energized but Homing or manual moving does nothing.

another thing I noticed is in the release build when first flashing it will say "settings stored" - that technically shouldnt say anything.

which leads me to believe this has something to do with EEPROM / settings.cpp.

so before I let anyone risk test their machine I'd like to at least get to a good baseline, then we can move from there.

I have used the latest Marlin bugfix-2.1.x and ran into zero issues (actually I believe UBL still doesn't work w/ProUI since the conversion to EXTENSIBLE_UI).

so I'm not sure if this has to do with ProUI-EX compatibility or just some bad line of code

[jake5253]

I can't seem to install firmware on mine now. I f***ed around for a few hours last night and finally got it to install the stock firmware from Voxelabs website, I cannot get my board to take any Marlin version I build -- from your repo or official MarlinFW repo. I thought it maybe had to do with the rom size, because the binary was 257.8KB, so I turned off a few "nice-to-haves" and got down around ~240KB and still can't install. It removes the .bin from the SD card but it doesn't actually install. I have no idea what I did to finally install the stock FW, I was right on the verge of my head exploding and it was like 3am. I don't think I did anything except threaten it's life maybe. But I've tried that again and didn't work. I'm temporarily using an H32-based board I had laying around. With that said, I'm still willing to test things, provided I can get it to install. Any idea how to use the ISCP header? I have a blue pill converted to an STLink debugger. Supposedly, somehow, one can then convert that into a jlink..which I believe works with N32s, no?

[classicrocker883]

@jake5253 you should be able to upload firmware as jlink / or STlink. but I would not use this default repo from September or August - because well August extended into September. I would stick with July if needed.

I actually had that same issue where it would not install firmware for some odd reason.

you can try flashing an older firmware version.

What I did was use MarlinFirmware latest bugfix-2.1.x and that flashed correctly, then I was able to reflash to something else.

you can always bypass the bootloader and flash using UPLOAD instead of BUILD in VSCode, however you may need to change a few settings if you're using Marlin bugfix-2.1.x

in stm32f1-maple.ini you may need to change the UPLOAD protocol to stlink

and if you use bugfix-2.1.x you'll have to change somethings, copy the configuration files over - UBL may not work so use Bilinear - search for "315" in Configuration.h it is heater0maxtemp change to 275 to stop that warning, and I think in MarlinCore.cpp look for dwininitscreen(), change the #if to DWIN_LCD_PROUI instead of creality, and in src/lcd/e3v2/common/dwin_api.h (I think) change ICON to 9 instead of 7.

[classicrocker883]

oh N32 boards will not take firmware over ~228k. that's why it would not install, same with G32, and H32 cannot flash over 208K