search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.24k stars 19.22k forks source link

[BUG] CR Touch Probe does NOT deploy on 4th G28 during print #26473

Closed alfondehesa closed 9 months ago

alfondehesa commented 10 months ago

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

During a print, if there have been more than 3 homing sequences, the fourth will cause the probe to not extend and the nozzle to drive itself into the bed.

What I've tried: (and combinations thereof)

Bug Timeline

2 Weeks Ago

Expected behavior

The printer will reliably home itself without need for hard resets.

Actual behavior

On the 4th homing procedure, the printer will try to home Z without first releasing the probe, driving itself into the bed.

Steps to Reproduce

  1. Start a print
  2. Start GCODE has 2 x G28.
  3. Cancel the print.
  4. Start the same print again.
  5. Sure enough, 4th G28 causes the probe to not extend (does not give off errors), and thus gantry to smash into the bed.
  6. This 4 counter seems to reset when power-cycling the printer.

Version of Marlin Firmware

2.1.2.1

Printer model

CR 10 V2

Electronics

SKR Mini E3 V3

LCD/Controller

BTT TFT35

Other add-ons

CR Touch

Bed Leveling

ABL Bilinear mesh

Your Slicer

Prusa Slicer

Host Software

OctoPrint

Don't forget to include

Additional information & file uploads

Marlin_config.zip

Start GCODE:


; layer_height = {layer_height}

M220 S100 ;Reset Feedrate
M221 S100 ;Reset Flowrate

​;------------------------------------------
;*** Start Dual Nozzle/Bed Preheating ***
M140 S{first_layer_bed_temperature[0]}
M104 S{first_layer_temperature[0]}  T0
M109 S{first_layer_temperature[0]}  T0 ; start preheating hotend
G28 ; Home
G91 ; Relative mode
G1 Z10 ; Go up a bit
G1 E-10 ; Retract
G90 ; Absolute
M190 S{first_layer_bed_temperature[0]} ; start preheating the bed

;PRE-BED LEVELING NOZZLE CLEANING
G1 X300 Y150 ; Go to start Position
G0 X330
G0 X305
G0 X330
G0 X305
G0 X330
G0 X305

; BED LEVELING
M420 S0  ; deactivate leveling for probing  <----- I WILL USUALLY CANCEL THE PRINT RIGHT HERE TO STRESS TEST 2 G28 PER PRINT
G28 ; home  
M117 Probing bed... ; display message while probing bed
M155 S30; reduce temperature reporting rate to reduce output pollution
@BEDVISUALIZER ; Tell the plugin to watch for reported mesh
G29 ; Do automated probing of the bed.
M420 S1 T0        ; Activate the UBL System.
M155 S3 ; Reset Temperature Reporting
M500          ; Save current setup. WARNING - UBL will be active at power up, before any G28.

;*** End Preheating ***

; NOZZLE CLEANING AND PRIMING
G91 ; Relative
G1 E10 ; Unretract
G90 ; Absolute
G92 E0 ; Reset extruder
G12 ; Clean Nozzle

G0 X290; Travel back to starting position
G28;
M420 S1      ; Activate the UBL System.```
thisiskeithb commented 10 months ago

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information:

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

ThomasToka commented 10 months ago

You have GRID_MAX_POINTS 7 and BLTOUCH_HS_MODE True. This does not work. Reduce to GRID_MAX_POINTS 5 or disable HS_MODE. Also you have 0 y offset configured. Set y offset testwise to 25. How is your PROBING_MARGIN?

thisiskeithb commented 10 months ago

You have GRID_MAX_POINTS 7 and BLTOUCH_HS_MODE True. This does not work. Reduce to GRID_MAX_POINTS 5 or disable HS_MODE.

You can use whatever number of points you want with BLTOUCH_HS_MODE, but the CRTouch is known to fault with BLTOUCH_HS_MODE enabled (no matter the number of grid points).

Also you have 0 y offset configured

That is a perfectly valid probe offset.

How is your PROBING_MARGIN?

It is set to 10 in their config: #define PROBING_MARGIN 10

alfondehesa commented 10 months ago

@ThomasToka @thisiskeithb The CR Touch is wired to the SKR using the BLTouch port instead of the Z limit switch, not sure if this is important.

From my testing, whether I have BLTOUCH_HS_MODE on or off does not seem to impact this issue (the issue is still repeatable), so I left it on since it's nice and probing really never fails during leveling (even with 7 grid points or more).

In terms of offsets, probing margins and mesh boundaries:

1) Y OFFSET is 0 because my probe is aligned with my nozzle along the Y axis.

2) PROBING_MARGIN is set to 10 by default, but I actually changed it in the adv. configuration for each edge based on my bed clips and how big my bed actually is.

3) Mesh boundaries are adjusted either right on the bed's edge or very close to it, so that I can probe all points besides the left X row (which I can't anyway because of my probe offset), the top row (because of clips) and the bottom row (also because of clips). I still want mesh points there even though they are not reachable, so then I just interpolate using G29 P3.1 and I still get somewhat accurate Z offsets across the entirety of my bed (at least in theory).

The weirdest part of it all is that it seems that probing itself is not the issue, but something in the homing sequence. Not sure if Marlin being overloaded could cause the board to skip telling the sensor to extend the probe? Otherwise, repeated tests and numerous bed levels with numerous points works 100% reliably.

@thisiskeithb I gotta find the time to port my 2.1.2.1 configs to the 2.1.bugfix branch to self-compile, although I think (not sure at all) I might have pinned it down to the serial baud rate (which I previously had at 500000, but since brought it waaay down, and it seems to have helped other issues, gotta do more testing). If this is the case, could serial communication take too many resources and cause Marlin to miss that? Not sure if it would work that way.

ThomasToka commented 10 months ago

You have GRID_MAX_POINTS 7 and BLTOUCH_HS_MODE True. This does not work. Reduce to GRID_MAX_POINTS 5 or disable HS_MODE.

You can use whatever number of points you want with BLTOUCH_HS_MODE, but the CRTouch is known to fault with BLTOUCH_HS_MODE enabled (no matter the number of grid points).

Also you have 0 y offset configured

That is a perfectly valid probe offset.

How is your PROBING_MARGIN?

It is set to 10 in their config: #define PROBING_MARGIN 10

I can Tell you the 5x5 with cr touch works always 100% reliable with hs mode. As of 7x7 not. 100% reproducable. I have it default on since ever and hundreds of users approved it works.

I know exactly what the TO has. Had some Testers with this constellation.

Do 5x5 with hs mode. Set margin testweise to 45. I spend hours in the development of my fork and all work 100% reliable with crtouch. If 5x5 7x7 or 10x10.

classicrocker883 commented 10 months ago

I use MRiscoC's ProUI, being able to adjust the bed grid on the fly. I use 7x7 and HS mode with a CR touch and havent had any issues normally. There was one hiccup using HS mode with MULTIPLE_PROBING.

try changing your MULTIPLE_PROBING, I do not have EXTRA_PROBING enabled, I believe you can just add the number you want to the end of MULTIPLE_PROBING, try 2 or 3 or completely disable it.

thisiskeithb commented 10 months ago

I'll say it again: BLTOUCH_HS_MODE should not be used with a CRTouch since the probe is not designed for it and is known to fault. It might "work" in some instances, but the probe is recovering before a fault.

Disable BLTOUCH_HS_MODE when using BLTouch clones to eliminate a probing variable.

Anyway, this isn't the place to debate whether the feature works or not.

@alfondehesa: Please follow my request in https://github.com/MarlinFirmware/Marlin/issues/26473#issuecomment-1828885658 and post a log once you get a chance.

alfondehesa commented 10 months ago

@classicrocker883 I have MULTIPLE_PROBING and EXTRA_PROBING disabled (I have found that the accuracy gains of this in my machine are minimal enough that I can't justify the time spent at the start time of every print, especially seeing how I like to ABL (or UBL) on every single print). Though the CR Touch might have issues with HS mode, disabling or enabling it does not seem to have an impact, nor does ABL or UBL, as this seems strictly related to homing.

@thisiskeithb Can you share how usual faults with CR Touch + BLTOUCH_HS_MODE manifest themselves? Have not found yet to have an impact during UBL, but if this is dangerous to do or there are failures I am missing then I would buy a BL Touch instead, just need to check if their pin layout is exactly the same/which wires I would need to swap. I will get you the serial logs this weekend.

classicrocker883 commented 10 months ago

@alfondehesa to be frank, I do not see reason having to redo the auto bed level mesh before every print. it should be done just once, no? once the bed is level and you have a correct Z offset, technically the points in the mesh should not change. if they are changing so drastically, there may be an issue with the probe's repeatability (what are the results for your M48 - Z_MIN_PROBE_REPEATABILITY_TEST?)

I know someone who experience this kind of issue, where the probe's M48 test would vary. meaning there could be some issue with the hardware being loose, or perhaps it can be the probe shaft sticking. I did have this happen to me with my CR touch, the probe wouldn't extend down. it was stuck. some electrical safe CRC 2-26 lube helped that.

so i would then suggest either disregard using the ABL/ UBL auto bed level mesh during printing and see how that goes. (if the variance between the min/max of points is less than +/-0.10mm you should be fine), also try the M48 test, if your results are more than 0.001 then theres an issue with either the probe/gantry/bed mounting or the probe shaft.

robherc commented 10 months ago

Though the CR Touch might have issues with HS mode, disabling or enabling it does not seem to have an impact, nor does ABL or UBL, as this seems strictly related to homing.

I've seen many references to CR Touch not working with HS_MODE, but haven't seen someone with an actual CR Touch have a problem directly related to HS_MODE yet myself, and the creality firmwares most definitely do use HS_MODE, so I use it with mine & it works great.

...more on-topic, however: I am using a CR-Touch probe on my Ender5 with stock board & have a homing move in my start-g-code. I have several times had 4+cancelled prints in a row when sorting bed adhesion problems, and even more times printed more than 4 parts in a row between printer shut-downs...all with 0 times that the probe failed to deploy for a homing. (using bugfix2.1.x from 2-3wks ago). Are you having this issue only when printing from SD, only when printing over serial, or both ways?

thisiskeithb Can you share how usual faults with CR Touch + BLTOUCH_HS_MODE manifest themselves? ... then I would buy a BL Touch instead...

In my limited experience, almost nobody seems to have had accuracy issues with a CR Touch, but BL-Touch & BL-Touch clones seem to be quite literally PLAGUED with randomly having the metal slug move internally & destroy accuracy & repeatability of masurements.

thisiskeithb commented 10 months ago

DEBUG_LEVELING_FEATURE was just patched, so you'll need to grab a fresh copy of bugfix-2.1.x for Marlin to successfully compile with it enabled. 😄

alfondehesa commented 10 months ago

Okay @thisiskeithb , sorry for the wait! I did all the steps above and got the serial log. This is an instance (which didn't use to happen before) where the probe does not extend and thus fails during the ABL procedure. This didn't use to happen before during ABL, before updating to the bugfix, but the MO seems to be somewhat similar as to when it fails while homing. The probe will just not extend, and Marlin won't care, until I cancel the print and then it seems as though the probe extends perfectly and self tests with no problem.

This might be enough, though I will try to get a log file making it fail while homing to see if it is similar. Seems to do with the probing sequence.

It seems Marlin correctly request deployment of the probe:

2023-12-05 16:30:06,176 - Recv: BLTouch DEPLOY requested
2023-12-05 16:30:06,177 - Recv: BLTouch from 90 to 10
2023-12-05 16:30:06,972 - Recv: bltouch.deploy_proc() end

Then in the middle of a slow probe, it asks to deploy it again...

2023-12-05 16:30:07,495 - Recv: BLTouch DEPLOY requested
2023-12-05 16:30:07,496 - Recv: BLTouch from 10 to 10
2023-12-05 16:30:07,497 - Recv: bltouch.deploy_proc() end

Then sees that there has been no trigger, so raises an error:

2023-12-05 16:30:08,665 - Recv:  Probe fail! - No trigger.

Then it requests for it to be stowed...

2023-12-05 16:30:09,182 - Recv: BLTouch STOW requested
2023-12-05 16:30:09,182 - Recv: BLTouch from 10 to 90
2023-12-05 16:30:09,974 - Recv: bltouch.stow_proc() end

Finally coming back with:

2023-12-05 16:30:10,020 - Recv: Error:Probing Failed

The strangest part of all of this is that the probe itself is not in an error state, LED is purple throughout the whole procedure. Self tests and otherwise probe extend and probe retract commands work perfectly as soon as I cancel the print. I can home and ABL manually through the LCD as much as I please, yet while printing, it's almost as if the probe wasn't receiving any commands to extend.

I wonder if Marlin set the probe to 160 instead of 90 if it would work any better...

serial.txt

@classicrocker883 probe repeatability standard deviation is around 0.0005, probe works well otherwise. I like to level my bed before each print because I have a lot of different beds, each warped in different amounts, different ways. I technically could do one for each bed and then run a tilt adjustment and then try to remember the orientation of the bed etc but I just really enjoy the convenience of "throwing" any bed in there and my first layers coming out acceptable without extra work.

@robherc I am having issues both over serial and SD.

scabana commented 9 months ago

@alfondehesa I got something similar but on an Ender 3 pro(4.2.2 board) + sprite extruder + cr touch. The extruder would crash onto the bed because the probe would not deploy. I did try with latest bugfix-2.1.x from a week or two ago. I tried with Klipper today and I'm starting to think it's a problem with the probe itself. With Klipper, it doesn't does crash, but it shows those messages in the console: 

4:58 PM
BLTouch failed to verify sensor state
4:58 PM
BLTouch failed to verify sensor state; retrying.

What's weirder: I can still manually deploy and retract the probe when in that state.

alfondehesa commented 9 months ago

@scabana Did the same thing with Klipper and got the same result!! I'm planning to replace the probe for a BL Touch after the new year and see how it goes with that. I'll update once I have some results!

classicrocker883 commented 9 months ago

as long as I've had my CR touch I never had an issue. the only kind of thing that happened was using High Speed mode and doing something with multiple probing like M48. I don't think its to do with the probe itself. maybe they manufactured CR touches with variant boards? I am just not experiencing any issues here. maybe it has to do with the board (creality 4.2.7), I do know that they have changed something with a (C7 ?) capacitor or resistor on the boards

also, check this site out
it goes into detail about how to wire it up, basically there are two kinds of ways, and how I wire mine is all in a row, you'll see the 5 pin in a row, some have it split 3+2. I wonder if changing the CR touch to that 3+2 has any effect (benefit).

it also says you may have to swap the orange and yellow wires?

alfondehesa commented 9 months ago

@classicrocker883 In terms of wiring and board, the strange thing is it used to work perfectly and only failed over time. I think you might be describing a different issue from what @scabana and I are experiencing.

classicrocker883 commented 9 months ago

what is so funny is I haven't had any issue with my probe, now all of a sudden the plunger isnt extending. I would manually tell it to deploy/stow, and sometimes it will, but when homing it will not.

it used to click, like the plunger/probe would have a snap to it. now it is slow and quiet. almost like its gummed up. I tried adding some electric safe lube, but that didnt really help. so I removed the case and have it soaking in some alcohol.

if that little solenoid was something I could find/replace that'd be great, but looks like I might have to get a new one if this doesnt work.

DjoleeX commented 9 months ago

Did you manage to solve this problem? I have the same issue.

alfondehesa commented 9 months ago

Did you manage to solve this problem? I have the same issue.

Yes, though I am not sure what the fix was:

  1. I first moved to Klipper, and it too gave me the same results, so it wasn't firmware-related.
  2. Thinking it had to be the CR Touch, I tossed it in the garbage and got myself a genuine BL Touch V3.1. But it seemed to hesitate to deploy the probe (though it managed to do it every time, it just took a bit longer then expected) but Klipper would not recognize the probe was extended, weird, and leveling/homing never worked, even after flashing the BL Touch to open drain mode.
  3. I figured I had a defective BL Touch, so I replaced it. Same exact issue with the replacement.
  4. Finally, I jumpered the pins on my SKR E3 V3 board so that the board would deliver 5V instead of 3.3V to the BL Touch. What's funny, is that the BL Touch still was on Open Drain, I never changed it to 5V mode. This worked! BL Touch in Open Drain + 5V seemed to make it work. Since I threw out the CR Touch, I never was able to tell if this would have fixed it too, but it seems like it was related, seeing how I had issues with both probes.

This was not firmware related.

DjoleeX commented 9 months ago

Okay, thank you for the info i have Creality 4.2.2 board and Sprite Pro Extruder with CR touch, and i'm suspecting it has to do with short cable connecting directly to Sprite Extruder, so i'll try with standard cable directly to the board connected.

scabana commented 9 months ago

@DjoleeX eager to see your result!

Lutzj71 commented 8 months ago

@DjoleeX eager to see your result too! I have exactly same HW config (MB 4.2.2, Sprite Pro and CR-Touch) and it fails during Homing, while does function when operated from menu.

classicrocker883 commented 8 months ago

mines right to the board, never had an issue. @Lutzj71 what UI are you using? because I suspect this can be related to how it starts to home - depending on the UI. maybe the code needs to be updated to perform a test, or tell the probe to "stow" or "deploy" before homing. BLTouch::clear()

I want to say try a couple tests. in a terminal do G28. if it fails, try M401 (deploy), and M402 (stow). i think there are other probe specific commands, offhand I dont remember exactly what they are. like it issues reset and what not.

#define STOW_ALARM            true
#define BLTOUCH_DEPLOY          10
#define BLTOUCH_STOW            90
#define BLTOUCH_SW_MODE         60
#define BLTOUCH_SELFTEST       120
#define BLTOUCH_MODE_STORE     130
#define BLTOUCH_5V_MODE        140
#define BLTOUCH_OD_MODE        150
#define BLTOUCH_RESET          160
Lutzj71 commented 8 months ago

Hi. The firmware is in my case not the most fresh, 2.0.1.9 (?). Problem is that homing fails also when requested by G codes for example prior to leveling. I believe it is NOT SW-related. It started with me tampering with cables after failure to my hotend (managed to nreak nozle, too much torque). Prior to that all worked just fine for over a year. The issue disappeared for a short moment, but then... I bought Sprite. And now it is hopeless. I managed to pinpoint it to the short cable connecting Sprite's pcb with CR-T./ connector on CR-T. Some lack of contact/deffective soldering, cold soldering/ crappy faux copper in the cable... I did not find out what ecactly. But NOT software. In fact the use of PWM to send commands is at least... Unfortunate... Facepalm. But I do not know all rationale behind though.

Regards Luke

wt., 30 sty 2024, 14:36 użytkownik Andrew @.***> napisał:

mines right to the board, never had an issue. @Lutzj71 https://github.com/Lutzj71 what UI are you using? because I suspect this can be related to how it starts to home - depending on the UI. maybe the code needs to be updated to perform a test, or tell the probe to "stow" or "deploy" before homing.

I want to say try a couple tests. in a terminal do G28. if it fails, try M401 (deploy), and M402 (stow). i think there are other probe specific commands, offhand I dont remember exactly what they are. like it issues reset and what not.

define STOW_ALARM true

define BLTOUCH_DEPLOY 10

define BLTOUCH_STOW 90

define BLTOUCH_SW_MODE 60

define BLTOUCH_SELFTEST 120

define BLTOUCH_MODE_STORE 130

define BLTOUCH_5V_MODE 140

define BLTOUCH_OD_MODE 150

define BLTOUCH_RESET 160

— Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/26473#issuecomment-1916865823, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMNLMQDEJIRDBBEEX3IZMQDYRDZPRAVCNFSM6AAAAAA743JOAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJWHA3DKOBSGM . You are receiving this because you were mentioned.Message ID: @.***>

github-actions[bot] commented 6 months ago

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.