probe will not deploy BLTouch & very loud steppers

[whitefiretiger]

tried the latest GD32-UBL5x5-BLTouch.bin and found the touch probe will not deploy so it will just ram nozzle into the bed/ also the steppers are extremally loud.

[CreeperPookie]

I am experiencing this as well; Also my 3D Touch shows absolutely no lights if I pull the probe down, instead of the usual blue light.

[TekToy]

Similar issue to whitefiretiger on my N32 Aquila using the BLTouch build, did get my 3DTouch working briefly using the CRTouch build, but it stopped working for some reason, also causing the nozzle/bed crashes on homing.

Also Autobedmesh only got up to 21 of 25 test points before 'just' finishing with no evidence it ever generated a bed mesh, any thing that touches the bedmesh seems to generate an error.

Would really like it if Z-homing could also check for Z-home microswitch triggering to avoid the nozzle crashes, and also adding it and touch probe status to the home switch status page!

Currently unusable as is, will have to revert to prior firmware.

[classicrocker883]

this is unfortunate I'm sorry to hear about this. as for the bed Mesh u may have to change the mesh settings to maximize the area.

for everything else I cannot explain why it is so and has Mr more reason to believe it revolves around the BL touch

@CreeperPookie @whitefiretiger @TekToy if u can simply unplug your Touch and let me know if the stepper motor noise goes away, and is it only during homing or moving or printing or any time.

ive tested with cr touch and haven't had issues. I've only heard from using a bl touch that there is. so I'll look more into it and see what I can find. the main library source belongs to Mriscoc and would have to relay anything I find over at his repo.

[Tucker1800]

I am also having this issue. Thought my machine was broken, but seems to be the firmware.

[CreeperPookie]

@CreeperPookie @whitefiretiger @TekToy if u can simply unplug your Touch and let me know if the stepper motor noise goes away, and is it only during homing or moving or printing or any time.

I tried moving and homing with my 3D Touch disconnected but the steppers are still louder than usual, when homing and moving. Unfortunately, after I got my 3D Touch I removed the z-min endstop, and now the 3D Touch is the only way I can home the Z-Axis. Besides that though, everything else seems to work fine.

Edit: The first time I tried the firmware today, the probe interestingly worked fine; however, after I restarted the printer it stopped working again. One thing is that the blue light turned off only after once the main home UI appeared, but it was lit after the probe initialization sequence.

[classicrocker883]

@CreeperPookie it's a very interesting issue that seems to stem directly with the probe. I'll try comparing older files that are known to work. if I can replicate the issue that may help, I mean I held a stepper not connected to anything and held it against the frame while it was moving. dead silent. I can actually feel the motor and slightly hear it when it's 'free floating', but once I press it to the frame there is nothing. no vibration and no noise.

theres a possibility that the wiring could be switched and that is causing the noise... I mean in the firmware. that is when I was wiring a motor, it was apparent I had two wires swapped. the result wasnt really any movement, all it did was energize and try moving a step.

when you experience the motor noise, are they actually moving? or are the motors not moving and just making a noise?

[TekToy]

The motors definitely move, they just make the most horrible noise when doing so. I tried reducing speed and acceleration values via the control panel, but even if moving slower it still seems to find some hideous resonate frequency that vibrates the whole machine horribly.

I still also have the z-limit switch connected, but it seems all touch probe firmware builds just ignore the switch, leading to nozzle crashes on Z-homes if the touch probe is not connected or working correctly.

[CreeperPookie]

when you experience the motor noise, are they actually moving? or are the motors not moving and just making a noise?

All motors do move correctly, and the X and Y axes home normally. Also, not only the volume; for me the steppers make a different kind of sound compared to travel moves with Alex's firmware. The X-axis kind of sounds more like a louder buzz, the Y-axis kind of sounds more like a tone, and the Z-axis is actually audible. The E-axis mostly just sounded a little louder, but it's hard to tell without the ability to home Z and start a print.

[classicrocker883]

@CreeperPookie @TekToy @Tucker1800 I since uploaded newer changed files. I was able to recreate the issue with the motors being noisy. what you can do to test is right after turning on the printer, go to Move Axis and tell it to move any axis any distance. the motors should act normally and with normal sound.

after homing any 1 axis, or all. then the noise begins and remains until reboot. u can test this with the older file.

but the newer firmware I just uploaded should not have this problem. I tested them and could not reproduce the issue.

if at all you do find the issue is still there or anything else please let me know here.

the BL touch should be working as well. u can test this by going into Probe settings under Level menu, and deploy probe. it should deploy and stow at the commands. if it does not please let me know as well.

[whitefiretiger]

@classicrocker883 Thanks for the quick work, ill try it tomorrow as I have about 18 hours left on my current print and will report back here. So looking forward to having a working newer version of marlin, any chance of a release with a higher hotend max temp? I know it gets mad at me printing at 160 and I'd like to do other hotter filaments as well (have a microswiss all metal hotend so good there and 70W heaters)

[TekToy]

It seems you've fixed the probe and the aweful stepper motor noise, so thanks for that.

Just a couple points though, the stepper noise is still noticeably louder than the stock firmware. On stock firmware the steppers are practically silent, the fan noise typically drowns them out, is this firmware build over-current driving the steppers or something versus stock?, could this be made into a user option so we can choose how aggressively the stepper motors are being driven?

Also the auto mesh build option still aborts on the 21ist probe point instead of the whole 25, and it still writes a corrupt mesh to memory which means IE the mesh viewer complains with a corrupt mesh error message rather than display any mesh data.

But hey, it's usable now, so thanks for the work you've been putting in.

[classicrocker883]

@TekToy can you give some more details about the motor noise? because the only thing I can think of is the moving rate is faster and that makes it a bit louder. otherwise it seems alright on my end. I can lower it back if you'd like to give it a try.

as for the probe points, under Level settings, in Mesh settings, look for mesh inset. for some reason I haven't yet figured out is it sets back the mesh by a factor of the Probe X distance. if u can max it out and probe again.

but maxing it out would be the size of the bed from 0-220. technically the inset is supposed to be 10, to account for the bed clips so it doesn't hit them. so it should be for the X/Y minimum: 10, and the X/Y max: 210.

u can adjust it if you need to.

[classicrocker883]

@whitefiretiger do you mean a higher temp of 260 or more? yes it is set to 300. it's actually to 315, but the firmware subtracts 15° for safety.

[whitefiretiger]

@classicrocker883 Thanks I haven't been able to try printing yet with your firmware as every flash had been an issue and I'm currently in the process of doing 14 identical prints at 18 hours each and will be waiting to try your latest till I'm done with the project just to ensure consistency. But yes 260 was what I meant is the normal hotend limit and I've had issues where I'm set to 255 or 260 on Alex marlin and the temp will momentarily waver and cause an error because I'm already basically at the limit. That 300 should fix the issue thanks.

[TekToy]

@classicrocker883 > Oops, just went to do a print after turning the printer off the night before and the horrible stepper noise is back and the probe no longer works again, so is there some possibility of firmware / saving settings to flash memory corruption issues at play?

As regards to stepper noise when the firmware was working, I can only say it's something like the difference between stepper drivers that have silent stepping mode enabled and drivers that have no such feature, not the worst noise in the world, but I sure miss the silent stepping when it's gone. :-(

But looks like I'm going to have to re-flash to older marlin anyways just to print so... Back to square one.

[CreeperPookie]

Oops, just went to do a print after turning the printer off the night before and the horrible stepper noise is back and the probe no longer works again, so is there some possibility of firmware / saving settings to flash memory corruption issues at play?

I also can confirm this - after flashing the chip, the probe did work correctly, and although the steppers were a little quieter, they weren't quite as quiet as Alex's. However, after a restart, the probe still fails in the same way it did before and the sound of the steppers increased again. One notable thing is that the X-axis is actually louder for me than the last version, but the Y and Z axes are about the same.

It might be possible that this probe issue could be somehow related to something that happens when the main home screen loads, as the probe's blue light (which is only lit when the probe is working) turns off right as it loads.

[classicrocker883]

@CreeperPookie @TekToy @whitefiretiger i uploaded some newer files. I had to disable Input Shaping because its still not compatible with Mriscoc's ProUI for now. try it out and let me know if anything changes or remains the same. thanks again!

[CreeperPookie]

Just tested your new firmware, and it still has the same issue; fine on the first flash but not after a restart.

[classicrocker883]

hm... this may be out of my reach. the proui library is protected and I'm unable to access for any changes or even looking to see what it may be. so it is just the X axis, and the probe failing? it's strange when I test on a creality 4.2.7 board I don't get any issue. and for the G32 board either the problem isn't there or its triggered randomly. that's why it's hard to pin down what it exactly is.

I'm sorry I can't be of more help.

A possibility is this chip isn't an exact clone of the stm32, and some thing or value may be conflicting. have you noticed that when it first flashes the firmware the screen is white and has artifacts? but then is fine after it reboots?

if I had to guess, that has something to do with it and fixing that would need to take someone who has experience or knowledge about HAL or whatever. and because it is an open source project, it will take time (someone's free time) to figure out.

that's my rant and I'll keep up the searching and trial and error.

[whitefiretiger]

@classicrocker883 hey I ended up getting a Creality V4.2.7 main board given to me and just tried the 427 ubl version and when it goes to probe for mesh it will probe 2 times then push the nozzle into the bed. Switched to e3v2prouibltubl and while the display knob is backwards the bed probing isn't doing what yours does

[maikolscripts]

Having the same issue where the bltouch probe doesn't deploy/isn't read, and it will slam into the bed during homing.

Along with loud stepper motors, sadly had to go back to alex fw, did notice a couple goodies on this firmware but couldn't get to enjoy them.

[oloendithas]

I had the same problem with 3D Touch running Aquila S2 N32 and finally have set it up working. The whole procedure is:

1. Connected sensor to the BLTouch port IN and OUT, not the ZMIN port.
2. In file Marlin/src/HAL/STM32F1/timers.h in the line 80 added VOXELAB_AQUILA into the condition:

   -#if MB(BTT_SKR_MINI_E3_V1_0, BTT_SKR_E3_DIP, BTT_SKR_MINI_E3_V1_2, MKS_ROBIN_LITE, MKS_ROBIN_E3D, MKS_ROBIN_E3)
   +#if MB(BTT_SKR_MINI_E3_V1_0, BTT_SKR_E3_DIP, BTT_SKR_MINI_E3_V1_2, MKS_ROBIN_LITE, MKS_ROBIN_E3D, MKS_ROBIN_E3, VOXELAB_AQUILA)

3. Edited the Marlin/Configuration.h:

   //#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
   #define USE_PROBE_FOR_Z_HOMING
   //#define PROBE_MANUALLY
   #define Z_PROBE_SERVO_NR 0
   #define Z_SERVO_ANGLES { 10, 90 }
   #define BLTOUCH
   #define Z_CLEARANCE_DEPLOY_PROBE    5
   #define AUTO_BED_LEVELING_BILINEAR
   //#define MESH_BED_LEVELING
   #define Z_SAFE_HOMING
   #define NUM_SERVOS 1

4. Edited the Marlin/Configuration_adv.h:

   #define BLTOUCH_DELAY 500
   //#define BLTOUCH_FORCE_SW_MODE
   //#define BLTOUCH_SET_5V_MODE
   //#define BLTOUCH_FORCE_MODE_SET
   #define BLTOUCH_HS_MODE true

   That's it. Now it's working.

[kagebarton]

Sorry to bump this classicrocker883, I was wondering what changes did you make to quiet the steppers?

[classicrocker883]

I had the same problem with 3D Touch running Aquila S2 N32 and finally have set it up working. The whole procedure is:

1. Connected sensor to the BLTouch port IN and OUT, not the ZMIN port.
2. In file Marlin/src/HAL/STM32F1/timers.h in the line 80 added VOXELAB_AQUILA into the condition:

-#if MB(BTT_SKR_MINI_E3_V1_0, BTT_SKR_E3_DIP, BTT_SKR_MINI_E3_V1_2, MKS_ROBIN_LITE, MKS_ROBIN_E3D, MKS_ROBIN_E3)
+#if MB(BTT_SKR_MINI_E3_V1_0, BTT_SKR_E3_DIP, BTT_SKR_MINI_E3_V1_2, MKS_ROBIN_LITE, MKS_ROBIN_E3D, MKS_ROBIN_E3, VOXELAB_AQUILA)

3. Edited the Marlin/Configuration.h:

//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define USE_PROBE_FOR_Z_HOMING
//#define PROBE_MANUALLY
#define Z_PROBE_SERVO_NR 0
#define Z_SERVO_ANGLES { 10, 90 }
#define BLTOUCH
#define Z_CLEARANCE_DEPLOY_PROBE    5
#define AUTO_BED_LEVELING_BILINEAR
//#define MESH_BED_LEVELING
#define Z_SAFE_HOMING
#define NUM_SERVOS 1

4. Edited the Marlin/Configuration_adv.h:

#define BLTOUCH_DELAY 500
//#define BLTOUCH_FORCE_SW_MODE
//#define BLTOUCH_SET_5V_MODE
//#define BLTOUCH_FORCE_MODE_SET
#define BLTOUCH_HS_MODE true

That's it. Now it's working.

@kagebarton I think these were the changes that fixed it. also it could have been the Mriscoc new year update.

[kagebarton]

Yep that did fix it. Steppers are slightly louder than Alex's firmware but not too awful. I'm pretty new to compiling Marlin so didn't think any of those changes could relate to stepper noise. Thanks!

[classicrocker883]

are you able to compile your own firmware? because I saw in the newest update to Marlin there were changes to linear advance and to the extruder in the code. I just updated the 2023-Feb branch and it compiles fine.

[kagebarton]

Just merged your Feb branch to mine and it breaks dwin for MPC, no errors for anything else.

Marlin\src\lcd\e3v2\proui\dwin.cpp:3563:50: error: no matching function for call to 'Temperature::MPC_autotune()' Marlin\src\lcd\e3v2\proui\dwin.cpp:3569:128: error: 'hotend_info_t {aka struct MPCHeaterInfo}' has no member named 'constants' (quite a few of this one)

[classicrocker883]

im not exactly sure why it is doing this even though it should be enabled and working, I was able to compile without error using Mriscoc-2023 branch, and the original fork Ender3v2Released (which doesn't have all the changes I made).

im guessing because of all the changes made in the Feb branch which has many updates from Marlin, it became incompatible. So whatever edits you made in the Feb branch just revert back to the Mrisoc-2023 branch and you should be ok such as adding the MPC menu option under Draw_Temperature_Menu in dwin.cpp.

I know the original author Mriscoc said he will be posting an update with the newer marlin updates in some time.

[classicrocker883]

@kagebarton hello I have recently updated the files. MPCTEMP should work fine in the Mriscoc-Feb branch.

[classicrocker883]

even more recently, i published a new branch Mriscoc-March, havent done any testing but there was successful compiling.

[kagebarton]

Thanks! Taking my time finishing up kevinakasam's belted Z mod then I'll get around to testing the new code.

[classicrocker883]

I just realized that Mriscoc has special configurations made up here

I haven't looked through or compared just yet, but I will recommend checking these files out. I don't know if V2.0 or V3.0 or V3.0.1 make a difference.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.