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.19k stars 19.22k forks source link

[BUG] BLTouch v3.1 randomly fails to deploy #17337

Closed basti128 closed 4 years ago

basti128 commented 4 years ago

Bug Description

Sometimes my BLTouch won't deploy the push PIN on the Z Home command. It just stays up and the hotend crashes into the Heatbed. When i manually run a self test (M280 P0 S120) I haven't had a a problem jetzt. Also when running G29 the Problem never occured. For some reason the problem occures mor often in combination with a print job. When i manually run a G28 command it appears less often.

My Configurations

Controller : SKR PRO V1.1 BLTouch: V3.1 connected to the BLTouch ports with a zmin pin change to PA2 Slicer start code:

M190 S70 ; set bed temperature and wait for it to be reached M104 S210 ; set temperature M280 P0 S160;

G4 P500; G28 ; home all axes G29; M420 S1;Enable Bedleveling G1 Z5 F5000 ; lift nozzle M109 S210 ; set temperature and wait for it to be reached

Expected behavior: deploy push pin on z home

Actual behavior: random no push pin deployment Marlin.zip

pmjdebruijn commented 4 years ago

Did you try adjusting the magnet inside the BLTouch using the hexnut located in device's top center?

basti128 commented 4 years ago

I tried loosening the screw. As I understand this should reduce the magnetic force and therefore the pin shouldn't ned as much force to deploy. Or did i understand that wrong ? The behavior didn't change until the point where the probe fails

randellhodges commented 4 years ago

Ever since I've moved to the SKR PRO 1.1 board today, I've been having random BLTouch issues as well. I'm not 100% sure it's not a hardware problem, but everything was working fine with the SKR 1.4 Turbo.

I don't know if the pin failed to deploy, or it just failed to read the trigger. I am using the Z-MIN (not the dedicated port). I will try and pay more attention when the error happens.

I have had failures in G29/G28 and G34. Might be noise with the heater because I think I encountered the issue more when I had a heater on. Not sure about that one.

My latest configs may be found at:

https://github.com/randellhodges/Marlin/tree/dc21d2e2b764e99fda49cab45e343630efbce3bd/Marlin

I am using the latest bugfix as of 178ca2bcdffcdd185cd38ba77627ee6e64cbec0b

Edit: About 1.5 hours into a print, inside a heated chamber at 50C I noticed the BLTouch light is flashing. The pin hasn't dropped so that is good. Not sure if there is a mechanical issue/temperature issue, or something with the firmware...

Edit 2: After the print was finished, I did a M280 P0 S160 and it kept blinking, but slower and I could see the little blue light. I had to completely power cycle the printer to get it "back to normal".

I replaced the cable going to the bltouch and made sure it was twisted to help prevent noise. I double checked connections and everything was tight.

I started another print and again, about 1.5 hours into this print it is blinking again.

I think this was the reason I stopped using the SKR PRO 1.1 in the first place. Various BLTouch problems.

Edit 3: I might have a different issue. I looked at my pin and it is bent. So it dropped during a print, got bent and triggered the alarm.

randellhodges commented 4 years ago

@basti128 What version/git commit of Marlin are you seeing this on? I might have solved, or narrowing down a related (or maybe the same root cause) issue and I'm curious about something.

basti128 commented 4 years ago

@randellhodges I pulled my version at 10:24 onMarch 30. CONFIGURATION_H_VERSION 020005

randellhodges commented 4 years ago

@basti128 I had an issue where the pin was dropping and it seemed there was some issues with PWM. Talking on discord, it was confirmed the servo library used by this HAL does not need/use hardware PWM pins.

buildroot/share/PlatformIO/variants/BIGTREE_SKR_PRO_1v1/PeripheralPins.c

Try commenting out:

line 136
{PA_1,  TIM5,   STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF2_TIM5, 2, 0)}, // TIM5_CH2    BL-TOUCH-SERVO

line 155
{PA_1,  TIM2,   STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF1_TIM2, 2, 0)}, // TIM2_CH2 is bltouch analog?

line 156
{PA_2,  TIM2,   STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF1_TIM2, 3, 0)}, // TIM2_CH3 is bltouch analog?

maybe also

line 144
{PA_2,  TIM5,   STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF2_TIM5, 3, 0)}, // TIM5_CH3    BL-TOUCH port. Available if Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

I see you are using PA_2 for the endstop. I don't so I'm not sure if you need line 144. I don't think you would need it, you shouldn't need PWM on that pin when just using it for an endstop pin.

If having both line 156 and 144 commented out fails to detect endstop being trigger, try leaving 144 commented out and uncomment 156.

Basically this leaving TIM5 completely free (which is being used by the servo library)

Here is a link to my file with everything PA_1 and PA_2 commented out

https://github.com/randellhodges/Marlin/commit/3f73660ac667a7567ee72ecfe15d0b06d5483849#diff-443a5c5717b9a729419a33c4a3ded66a

boriss3110 commented 4 years ago

basti128,

I had the same problem with BLTouch as you did with my SKR Pro + TMC5160. This problem comes from a too important step rate which saturates the SKR Pro card. Once the card is saturated, there is a variation in the PWM signal (Pin PA1) sent to the BLTouch that causes the probe to deploy during printing. (problem observed at the oscilloscope) . On my printer:

If you print at low speed, the problem disappears.? In your configuration, the "DEFAULT_AXIS_STEPS_PER_UNIT" is to much (X: 640, Y640, Z12800 E3220) you should change the TMC test configuration so as not to exceed 320 step/mm for the X and Y axes. Also, such large values for the Z axis and the extrusion will not give you anything but problems.

sjasonsmith commented 4 years ago

@boriss3110, do you have pictures from the oscilloscope you can post?

Your explanation makes sense, because the Servo PWM relies on interrupts to perform output changes. Changes may be needed to make the PWM interrupts higher priority than step interrupts.

boriss3110 commented 4 years ago

No, I didn't save anything, but I can easily retake the test if anyone's interested.

basti128 commented 4 years ago

@randellhodges sadly commenting out these lines don't change the behavior @boriss3110 I haven't had random drops so far, but i haven't been printing much with my bltouch problem

randellhodges commented 4 years ago

Yeah, I thought it was working for me but then I had another drop last night. I guess it was just coincidence.

I have more moderate steps/mm: #define DEFAULT_AXIS_STEPS_PER_UNIT { 161.0, 161.0, 1600, 830 }

And I was printing at 50mm or 60mm with travels speeds of 100mm and I was getting what I was assumed a random drop, didn't actually see the pin down, but saw it was up but bent and blinking light.

I'm guessing there isn't a way to use the hardware pwm or would that even be possible or even wanted?

basti128 commented 4 years ago

Any other suggestions ? I also tried a other BLTouch but i experienced an identical behavior.

DroneMang commented 4 years ago

I am having the same error of BLTouch randomly not deploying while homing with G28. It can be diagnosed in Octoprint before homing by going to the control tab and doing a deploy and retract using the bltouch plugin. If that does not work, I turn the power off the the SKR Pro and back on and reconnect then it usually works. Strangely, I saw this behavior before with an 8-bit Rumba while homing for a very long Z-distance of 600+mm on a C3D Beast V2. It seems something is timing out. FYI, the very newest bugfix would error out after 2 retract deploy cycles with code M999. I posted this issue here: https://github.com/MarlinFirmware/Marlin/issues/17628. I have the largest mesh of 15x15 set, and after setting it to 5V mode, it disconnected halfway through, on second try, it made it all the way to the end. The firmware I have posted here does appear to work, though intermittently.

I have an SKR Pro V1.1 with TCM 5160 V1.2 on an FT-6, BLTouch 3.1 in 5V mode, sensorless homing. Sensorless homing works fine.

I saw some config files for an Ender 5 with BLTouch set to 5V mode, which is why I tried it: Config_Ender5-BLTouch31.zip

Here are my configs: Marlin-2.0.x-5160.zip

I have the BLTouch set to 5V mode and SW mode, and I made some firmware with

define BLTOUCH_FORCE_MODE_SET

on to have Marlin write to the BLTouch EEPROM, then I turned that off as it is set in the attached file, but I saw the same behavior at startup when power is applied to the SKR Pro. The lights will flash as if Marlin is writing to the BLTouch, then retract deploy more than usual, then the light blinks solid.

boelle commented 4 years ago

@basti128 is the issue still there?

basti128 commented 4 years ago

sadly yes

boelle commented 4 years ago

Please test the bugfix-2.0.x branch to see where it stands.

boelle commented 4 years ago

Lack of Activity This issue is being closed due to lack of activity. If you have solved the issue, please let us know how you solved it. If you haven't, please tell us what else you've tried in the meantime, and possibly this issue will be reopened.