[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

[jake5253]

Ohhh! That makes sense... There is a bootloader there using some space. And the N32 (on my board at least) isn't actually 512 of flash, despite the (misleading) warning marlin shows during compile time.
I didn't know STLink actually worked, I thought it had to be a jlink but that's good to know. I'd probably better leave the bootloader intact though. Lol
I'll see about getting another version to compile and install later today when I have some time. I recall at one point I installed the 7-24 version of your FW and it did not do the turbo honing, so you're probably right about going back to a July version.

[classicrocker883]

I have solved the Homing issue I found what the mistake was

- feedRate_t max_feedrate_mm_s[DISTINCT_AXES];   // (mm/s) M203 XYZE - Max speeds
      float acceleration,                       // (mm/s^2) M204 S - Normal acceleration. DEFAULT ACCELERATION for all printing moves.
            retract_acceleration,               // (mm/s^2) M204 R - Retract acceleration. Filament pull-back and push-forward while standing still in the other axes
            travel_acceleration;                // (mm/s^2) M204 T - Travel acceleration. DEFAULT ACCELERATION for all NON printing moves.
- feedRate_t min_feedrate_mm_s,                  // (mm/s) M205 S - Minimum linear feedrate
-            min_travel_feedrate_mm_s;           // (mm/s) M205 T - Minimum travel feedrate
} planner_settings_t;



+ feedRate_t max_feedrate_mm_s[DISTINCT_AXES],   // (mm/s) M203 XYZE - Max speeds
+            min_feedrate_mm_s,                  // (mm/s) M205 S - Minimum linear feedrate
+            min_travel_feedrate_mm_s;           // (mm/s) M205 T - Minimum travel feedrate
      float acceleration,                       // (mm/s^2) M204 S - Normal acceleration. DEFAULT ACCELERATION for all printing moves.
            retract_acceleration,               // (mm/s^2) M204 R - Retract acceleration. Filament pull-back and push-forward while standing still in the other axes
            travel_acceleration;                // (mm/s^2) M204 T - Travel acceleration. DEFAULT ACCELERATION for all NON printing moves.
} planner_settings_t;

I thought to organize/simplify some code, and this should have given me a warning or error but didn't

feedRate_t max_feedrate_mm_s[DISTINCT_AXES] <--- this basically breaks how the rest are defined. I simply reverted back and jumped from August to October, abandoning September.

got a few tweaks to make and will have a new release soon!

[yrabbit]

I wonder how the rearrangement could break? max_feedRate_t is float. All fields are of the same type ... hmm.

[classicrocker883]

I wonder how the rearrangement could break? max_feedRate_t is float. All fields are of the same type ... hmm.

¯\_(ツ)_/¯

even the first part of this struct has

   uint32_t max_acceleration_mm_per_s2[DISTINCT_AXES], // (mm/s^2) M201 XYZE
            min_segment_time_us;                // (µs) M205 B

it is probably better to just defined these explicitly just incase

[yrabbit]

Mmm ... do not like it, but okay.

Will the MarlinFirmware/Marlin#27416 (comment) be included the new release?
This corrects another wild and dangerous behavior when the extruder accelerates to unthinkable speeds and clogs the nozzle.

[yrabbit]

Excellent! 👍
Version 2.1.3f-10 on Aquila-427 does homing without problems:)

Enabling FT Motion doesn't cause any disasters either, although its Linear Advance is broken - whatever coefficient you specify in M493 S1 P1 K???? still prints as if K==0. Apparently, they've done something wrong somewhere.

[classicrocker883]

thanks for bringing that to my attention maybe I can look into it, I know some changes to Linear Advance were made.

so youre saying Linear Advance is broken only with FT Motion?? but it did work before, or Linear Advance works without FT Motion?

[yrabbit]

Motion and is activated with the M493 S1 P1.
The normal one worked and works without any problems.
Just to clarify - I was referring to the Linear Advance that is part of FT

And in your builds FT_MOTION is switched off even for powerful boards:

MRiscoCProUI/configurations/Voxelab Aquila 427/UBL/Configuration_adv.h

Line 1137 in 676b2cc

//#define FT_MOTION

I can confirm that enabling it in the config (!) does not cause any trouble and currently does not prevent the machine from operating in normal mode.

I'm rebuilding with this option enabled because I expect an increase in print quality in the long run, at least due to the presence of various Input Shapers instead of one standard ZV.

However, there is no point in experimenting with new Shapers if Linear Advance is not set up - the resulting models will have over- and under-extrusion in all possible places.

If you still think it makes sense to waste your precious time on this thing, here's the gist of my comment:

It used to be (at least before MarlinFirmware/Marlin#27416 (comment)) that calibration went like this:

I give the command M493 S1 P1 K0, print the model, the result is so-so.

I give the command M493 S1 P1 K0.22 (as stated at the very bottom of https://marlinfw.org/docs/gcode/M493.html), try to print, the extruder goes crazy and clogged the nozzle. Because apparently “As reported by users, linearadvance value in FT_MOTION is a 10E-6 value.” (MarlinFirmware/Marlin#26785).

In the latest version, whatever I specify (K=0, K=0.22, K=0.9, K=1, K=2) does not differ in any way on printing. Yes, the nozzle is not clogged, but I can't calibrate it because the result is equally bad and does not depend on K - as if they just somehow write 0 there, or change the type to integer, or in the process of arithmetic always get 0.

This is just a hypothesis, there's always the possibility that it's just that the range of K is now from 100 to 999 - I haven't checked that :)

I would like to hear what value of K other users use, but I don't see many experimenters so far:)

[classicrocker883]

@yrabbit if you'd like to move this to the Discussions tab, others may be able to give their input. Also, perhaps try the MarlinFirmware Discord.

I'm not familiar with FT Motion, as it is an experimental thing anyway. Unfortunately, some boards are already at their limit regarding flash size, so that's why they're not enabled in builds.

if Linear Advance w/FT Motion worked before, then from one of the links, this change could be it

-#define FTM_LINEAR_ADV_DEFAULT_K 0
+#define FTM_LINEAR_ADV_DEFAULT_K 0.0f

I think it is more of a Marlin type of issue rather than ProUI related. Have you tried disabling PROUI_EX with FT Motion if that makes any difference? if so, then there may be a compatibility problem.

[yrabbit]

That's reasonable. I'll give it a shot.

And I'll probably start a thread in Discussions, as for Discord, requiring a phone number when registering is not the brightest idea especially if you can't send test SMS for some reason:).

[classicrocker883]

looking around the code, in ft_motion.h I get this error:
static constexpr uint32_t PROP_BATCHES = CEIL((FTM_WINDOW_SIZE) / (FTM_BATCH_SIZE)) - 1;

expression must have a constant value
ft_motion.h(161, 46): cannot call non-constexpr function "ceilf" 

even though it compiles correctly, strange, but can always arbitrarily make PROP_BATCHES = 0; to stop the error to see if that makes any difference.

[yrabbit]

Okay, I'm moving the discussion
#164