Bl-Touch self extended
-
I think I have a problem with my Bl-Touch. It just extended while printing. Result pin skew. But could save him. 10 minutes after the end of printing, the pin is simply extended again without being requested.
What could that be?
How can you prevent that?How can i write my config in a Box here?
-
there is a grub screw at the top. you can adjust it. try it a bit higher
-
Ok ill test it. But he run 12 month in a another Printer without any problems.
I hope is not a Firmware issue ore my board has an issue
-
Unless you have a rogue command to extend the pin in your gcode it's probably a problem with the probe. As Veti says it could be the grub screw that adjusts the position of the magnet isn't in the right place.
You can copy and paste the text of your config.g into a post window if you want to share it, but I don't think there could be anything in it to cause the pin to fall during a print.
-
This screw is on max high. The pin is not fall from alone. I stand by the printer and the bl touch make "klick"
This make the pl touch to when i heat the hotend and bed at same time.
-
does your voltage drop when your heat both?
-
No, 24.3v and 12.1v constant. But when I heat the hotend and bed together, it says Toolchange for a long time at the top of DCW. DCW then takes a very long time to react to a setting, such as changing the temperature.
-
post your M122 of both the duet and the toolchanger when that happens
-
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (SBC mode) Board ID: 08DJM-956L2-G43S8-6JTDG-3SJ6P-KB0UG Used output buffers: 1 of 40 (10 max) === RTOS === Static ram: 154604 Dynamic ram: 163292 of which 136 recycled Exception stack ram used: 224 Never used ram: 74960 Tasks: NETWORK(ready,1972) HEAT(blocked,1188) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,204) MAIN(running,4944) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:50:37 ago, cause: software Last software reset at 2020-12-20 06:24, reason: User, spinning module LinuxInterface, available RAM 75036 bytes (slot 2) Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN Error status: 0 MCU temperature: min 28.9, current 29.5, max 29.8 Supply voltage: min 24.7, current 24.7, max 24.8, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0 Driver 0: standstill, reads 24546, writes 21 timeouts 0, SG min/max 0/0 Driver 1: standstill, reads 24546, writes 21 timeouts 0, SG min/max 0/0 Driver 2: standstill, reads 24547, writes 21 timeouts 0, SG min/max 0/0 Driver 3: standstill, reads 24547, writes 21 timeouts 0, SG min/max 0/0 Driver 4: standstill, reads 24547, writes 21 timeouts 0, SG min/max 0/0 Driver 5: standstill, reads 24548, writes 21 timeouts 0, SG min/max 0/0 Date/time: 2020-12-20 07:15:34 Slowest loop: 3.99ms; fastest: 0.14ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 2 -1 -1 -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Movement lock held by null HTTP* is ready with "M122" in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger* is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon* is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 0.88ms; fastest: 0.01ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions HTTP sessions: 0 of 8 - Ethernet - State: disabled Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages sent 12121, longest wait 0ms for type 0 === Linux interface === State: 0, failed transfers: 0 Last transfer: 16ms ago RX/TX seq numbers: 31465/31467 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.1.1 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 32.00 -
are you using usb to connect to your duet?
see https://duet3d.dozuki.com/Wiki/USB_ground_loops -
Only raspberry with spi. I doun't use Usb
-
This is my wiring
-
normally when someone post the diagnostics without newlines, its because it was not copied from the web console and they used usb.
-
I have copy with my smartphone.
But I think now my bl-touch is damaged. I have make a g32 and the bed drive in the nozzel. Bl-touch was red but nothing stop
-
check the extension wire, that is know to make bad contact and cause issues.
-
Have make new connections last week bevor i have it install in the HevORT
-
Found the bug. It was due to the contact resistance at the on-board connection. I thank you for the help and patience
-
ok now i'm confused. Since I no longer trusted the old Bl-touch, I installed a new one. It's the same problem that it just goes in and out without me triggering it. The connection on the board is new. That happens when you print or afterwards. If I had the printer off, that didn't happen for days.
-
The Bl-Touch doesn't seem to be the problem, nor does the wiring. If the pin is inside or outside, DCW says "not stopped" When I have the BL-Touch off, the board tells me "at min stop" I measure 4-10mV at pin outside with pin inside 3.3V on the white cable to ground
-
Please post your full config.g and homeall.g as well as the results of M98 P"config.g"
