Marlin
Marlin copied to clipboard
Jyers
Bed leveling not working at all on 1.3.5b
Description
Bed leveling isn't activating at all during prints on the last 1.3.5 firmware. It was working fine on older 1.2.2.
Steps to Reproduce
- Do a bed mesh and use I M420 S1 Z2 or use G29
Expected behavior: [What you expect to happen]
The Z axis should change depending on the bed level
Actual behavior: [What actually happens]
The Z axis stays at Z offset for the whole print. No changes.
Additional Information
I did several resets/reinstallation. Nothing helps.
@JayBee-git I can assure you that this is not a firmware issue. If it did, it would be a long time since 100% of users reported it.
The Auto Bed Leveling works perfectly fine, sorry.
Can you more accurate on the firmware version used, configuration files, etc...and describe your process to calibrate your printer ?
After every flash a new firmware, do a 'good' reset is : 1/Reset to Default following by 2/ Store settings and 3/ Load settings (menu Control)...to initialize correctly the eeprom...
And did you compile your own firmware with the correct config files and the latest build and latest commit here?
The latest pre-compiled version v1.3.5b is already old and does not benefit from the latest bugfixes from the latest sources here ...
As I stated, I did a reset. And yes I know how to do a reset. I even reinstalled the older firmware, and everything works perfectly there.
I also tried M420 S1 S2 (it's actually the first thing I tried) but it didn't work either, so I first though my bed moved or something. But no, the Z offset during print isn't changing at all like it should.
I will try compiling the latest source and report how it goes, thanks.
And I know G29 is coded by Marlin, but when I asked to Marlin dev about it they told me they can't do anything about third party firmware and that I have to contact the dev, so...
I compiled your latest source with your bltouch 3x3 template config file, did a full reset, full recalibration, full bltouch mesh (with preheated bed and hotend), tested print with either G29 and M420 S1, and I still get the exact same issue.
The Z axis is always staying the same along the whole first layer, causing small but noticeable thickness inconsistencies. I suspect it's not caused by your firmware but the Marlin source itself, since all firmware I tested from 1.x source worked perfectly.
And no, I am not the only one reporting the issue, there are few other people around having similar issues (for instance on the smith3d site).
@JayBee-git Sorry to insist but if M420 S1 is not taken into account, it means that the mesh is invalid. Either it has not been saved or it is not in the correct location of the EEprom and in this case it means that the EEprom is not properly initialized. Also either the 3 operations necessary for the reset are not correctly carried out, or an EEprom problem (hardware), since the last version, it is almost used to the maximum, or a firmware which flashes badly and leads to malfunction. .. The Z-Offset (fixed distance between the nozzle and the pin (trigged) of the BLTouch) does not move during printing. It is the Z axis which makes positive or negative micro corrections ... but this cannot be seen on the screen, only by observing the Z axis coupler for example.
I understand, but with all the flashing and reset I have done, I am 100% sure I'm doing things correctly here. I checked the mesh every time, and it seems good to me. It just seems to completely ignore it, since the difference of layer thickness are exactly the same as my bed slight tilt. And again, the bed leveling does work perfectly with older firmware, both official creality firmware and your older 1.x versions. And yes, that is the Z axis that stays at the exact layer height all along. You mean the onscreen Z axis value shouldn't change even with more than 0.1mm difference? It's usually showing the proper live value normally during the print.
I already did all those calibrations as well. I am not an expert, but I am not a beginner either here ;) Grip on the bed has no issue, and extrusion is perfect.
And my bed is almost flat as well, I did a manual bed leveling few times to ensure there were no big tilt of the bed. But when printing level testing prints, I can easily see (and feel) the very small thickness differences appearing. Just for testing, I did some print without the auto leveling, and I get the exact same results as with auto leveling.
And again, the auto leveling works perfectly with older firmware versions.
@JayBee-git In the firmware, the auto bed Leveling is carried out via the call to Gcode G29 (in bilinear mode) .. this Gcode is coded by Marlin, and not by Jyers. In version 1.22 or 1.3.5b it is the same ...
That might be, but the results are still here. 1.2.2 => leveling works, 1.3.5b leveling doesn't work properly. I'm just telling you the facts, nothing less, nothing more. You do what you want with it.
How we can be sure that M420 S1 taken into account during printing start?
In your slicer add that command to your start G-CODE and it should automatically include that and any other commands you've entered. There are many examples via a Google search. I'd also recommend ensuring you use slot 0 for auto bed levelling. This alleviates many problems ppl have with this firmware and ABL.
I am having the same issue with the Z axis not being homed when I put the printer into the homing section, I would post my current setup, but I have modified my ender 3 v2 to have the 400mmx400mm bed. my printer was working fine before I tried the v1.3.5 firmware compared to my old version, and the only issue is the z axis not wanting to home.
edit: I got this resolved with a missed code line
@Failure2Society that issue is usually cause by choosing the wrong board version (4.2.2 vs 4.2.7) or not resetting eeprom after flashing.
@JayBee-git Did you end up resolving the issue? If not I'd recommend trying the latest source
@JayBee-git also interested. I seem to be having the same issue. Trying to track down the cause. Like you I have tested with and without G29 and there is no difference. Going to do some investigation of the debug output to see if I can find the cause.
I’m using the 5x5 abl options with ender 3v2. About the eeprom possibility. With just g29 it should be saved in ram and applied until power cycle or other code that resets correct? In my case I am not loading from eeprom with M420 after g29
@Failure2Society that issue is usually cause by choosing the wrong board version (4.2.2 vs 4.2.7) or not resetting eeprom after flashing.
@JayBee-git Did you end up resolving the issue? If not I'd recommend trying the latest source
I'm having similar issue as well. I have never reset eeprom after update. I have seen above the method...
"1/Reset to Default following by 2/ Store settings and 3/ Load settings (menu Control)...to initialize correctly the eeprom..."
However will this not cause settings to be lost and nothing to load back in the step 3 above? I would think resetting to default then storing settings would cause default settings to be stored in step 2 then the default settings saved in step 2 would then be loaded back in step 3.
Am I missing something?
@cmadon You are correct, this will reset all your settings. Either save them with an M503 command to be re applied from the terminal, or write them down somewhere before resetting
@cmadon You are correct, this will reset all your settings. Either save them with an M503 command to be re applied from the terminal, or write them down somewhere before resetting
Thanks! That's what I thought, just wanted to be sure I wasn't missing something.
Thanks again!
@JayBee-git also interested. I seem to be having the same issue. Trying to track down the cause. Like you I have tested with and without G29 and there is no difference. Going to do some investigation of the debug output to see if I can find the cause.
I’m using the 5x5 abl options with ender 3v2. About the eeprom possibility. With just g29 it should be saved in ram and applied until power cycle or other code that resets correct? In my case I am not loading from eeprom with M420 after g29
Gave up on it, apparently issue is from the Marlin firmware that doesn't fully corrects the bed level from the bltouch mesh in some (rare) cases. The mesh is there, it's active, loads correcly at each print, I can visualize it and it seems accurate and on point with the manual measurement I did by moving the hotend around and checking with a digital caliper. It does try to correct the bed level, it just doesn't correct it fully, even tho the bed isn't tilted so much (less than +-1mm of height difference on corners). I'm not saying it happens to everyone or is a general issue, it just did happen to me and was pretty much unfixable. Compiled several different firmwares from various sources, even made my own custom firmware, cleaned the eeprom and reset the whole thing more time than I can count, and asked the Marling team about it as well. The solution for me was just to redo a very long full manual bed leveling once again (without using the bltouch), and now it obviously works since my bed is perfectly leveled. I have no idea where the problem came from, but at this point I don't care so much anymore, wasted too much time troubleshooting already.
After weeks of experimenting with this issue on my printer, I found that: M420 S1 ; Nothing happens, ABL does not adjust Z axis while printing M420 S1 F10 ; ABL seems to be working perfectly F is the fade level; marlinfw.org indicates that it's only used for UBL, I am using bilinear leveling. Perhaps the default value for F is zero, and the ABL mesh fades to flat before the first layer is printed. I am running E3V2-BLTouch-3x3-HS-v4.2.2-v2.0.1.bin.
I advise you to take this base there (v1.3.5.b + fixes): https://github.com/Jyers/Marlin/archive/refs/heads/Deprecated-JyersUI.zip You just modify the platformio.ini file. You replace in line 16: default_envs = STM32F103RET6_creality by: default_envs = STM32F103RET6_creality_maple
My fault or what?
Compiling .pio\build\STM32F103RET6_creality_maple\src\src\lcd\e3v2\creality\creality_dwin.cpp.o In file included from C:\users\user\.platformio\packages\framework-arduinoststm32-maple\STM32F1\cores\maple/WString.h:29:0, from C:\users\user\.platformio\packages\framework-arduinoststm32-maple\STM32F1\cores\maple/wirish.h:47, from C:\users\user\.platformio\packages\framework-arduinoststm32-maple\STM32F1\cores\maple/Arduino.h:30, from c:\!3dprint\jyers\marlin-deprecated-jyersui\marlin\src\hal\shared\marduino.h:36, from Marlin\src\lcd\e3v2\creality\../../../inc/../HAL/./STM32F1/HAL.h:32, from Marlin\src\lcd\e3v2\creality\../../../inc/../HAL/HAL.h:30, from Marlin\src\lcd\e3v2\creality\../../../inc/MarlinConfig.h:31, from Marlin\src\lcd\e3v2\creality\rotary_encoder.h:32, from Marlin\src\lcd\e3v2\creality\creality_dwin.h:30, from Marlin\src\lcd\e3v2\creality\creality_dwin.cpp:32: Marlin\src\lcd\e3v2\creality\creality_dwin.cpp: In member function 'void CrealityDWINClass::Menu_Item_Handler(uint8_t, uint8_t, bool)': C:\users\user\.platformio\packages\framework-arduinoststm32-maple\STM32F1\cores\maple/avr/pgmspace.h:29:59: error: expected primary-expression before ')' token #define sprintf_P(s, f, ...) sprintf((s), (f), __VA_ARGS__) ^ Marlin\src\lcd\e3v2\creality\creality_dwin.cpp:3660:19: note: in expansion of macro 'sprintf_P' sprintf_P(cmd, PSTR("G29 J")); ^~~~~~~~~ *** [.pio\build\STM32F103RET6_creality_maple\src\src\lcd\e3v2\creality\creality_dwin.cpp.o] Error 1
I've been pulling my hair out trying to figure out what the hell is wrong. The Z does not move up until the layer height value is greater than the baby stepping value. I can adjust the Z up and down with babystepping but it never advances to the next layer. So I end up with 3 or 4 layers being printed in the same place with a z offset of -.55~ But then it also does this thing where it adds the offset in after it's moved above z0.. it's all screwed up!
Bugfix JyersUI v2.0.1 Nov5 2021 UBL Manual Probing
Seriously -- delete this release and save others from countless hours of trouble, frustration, and wasted filament.
