BlTouch randomly deploys probe twice.
-
I have been trying to figure out why I keep getting z probe triggered before probe errors.I noticed that when the probe hits the bed during probing it sometimes deploys the probe on the movement upwards and hits the bed again.The weird thing is this happens randomly during mesh grid compensation and even when it hits the bed it doesn't cause an error.Te error seems to happen all on its own randomly.Here is my z probe part of the config
; Z-Probe
M307 H7 A-1 C-1 D-1 ; Disable heater on PWM channel for BLTouch
M558 P9 H7 F200 T6000 ; Set Z probe type to bltouch and the dive height + speeds
G31 P25 X-20 Y-45 Z1.727 ; Set Z probe trigger value, offset and trigger height
M557 X20:185 Y0:300 S20 ; Define mesh grid; deployprobe.g
; called to deploy a physical Z probe
;
; generated by RepRapFirmware Configuration Tool on Mon Nov 05 2018 12:42:23 GMT-0500 (Eastern Standard Time)
M280 P7 S10 i1; retractprobe.g
; called to retract a physical Z probe
;
; generated by RepRapFirmware Configuration Tool on Mon Nov 05 2018 12:42:23 GMT-0500 (Eastern Standard Time)
M280 P7 S90 i1 -
Which firmware are you using? I know older firmware this was a common and harmless occurance.
-
I am using RC4 the latest version.I can post any information someone may need to give me some helpful insight.
-
@siblues other than deploying the probe twice, does it work properly otherwise? Like I said this has been a very common occurance but it has zero effect on functionality.
@dc42 May have changed something in the latest firmware that undid the fix to keep that from happening but I would say it low priority otherwise. -
Yeah it works as it should but I am getting quite a few probe triggered before move and probing move errors.
-
What do you have in your deployprobe.g and retractprobe.g files?
-
I added both of those folders to the original post in this thread that way all of the relevant info is at the top of the thread.
-
Is it a genuine BLTouch? Most users don't have this problem.
One thing that may be worth trying is to change your deployprobe.g file to this:
M280 P7 S10 i1
G4 P200
M42 P7 S0 I1It will cause a 0.2sec pause before probing, but may solve the problem you are having. Caution: I haven't tested this, because none of my printers uses BLTouch.
-
I have edited my files like you posted and it seems to have helped but not eliminated the problem.i also wanted to ask about the speed of movement on the z axis.i wanted to know how to change the speed after it homes.the speed is fine before it triggers the sxis endstop but after triggering the endstop and before the first prode it is extremely slow.
-
@siblues said in BlTouch randomly deploys probe twice.:
i wanted to know how to change the speed after it homes.the speed is fine before it triggers the sxis endstop but after triggering the endstop and before the first prode it is extremely slow.
The travel speed between probe point is set by the T parameter of the M558 command.
-
I just started having major problems with my wifi connection the board now connects but seems to lose connection quickly maybe 30 to 90 seconds into whatever you are doing.It seems to do it no matter what you are currently doing.It will also sometimes not connect for quite a few attempts.I haven't changed anything other than modifying the lines you mentioned above?Any ideas what may be causing this I followed the Wifi disconnections and ajax errors but it continues to happen.
-
What is the RSSI in the M122 report? Have you recently acquired any new cordless devices?
-
I haven't added any wireless devices lately. The wifi led is on also. The weird thing is it happens after it initially connects.
-
@siblues, which firmware and DWC versions are you using?
-
Here is the info you needed and now the wifi led was also turning off after it disconnected.I restarted the Duet wifi to see if I could reproduce the problem and now the only led that turns on with the power supply is teh vin led but when I directly connect to the board with a usb they all light up fine.
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.02RC4(RTOS) (2018-11-18b5)
WiFi Server Version: 1.21
Web Interface Version: 1.21.1This is the result of M122 after a disconnection
8:34:34 AMM122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02RC4(RTOS) running on Duet WiFi 1.02 or later
Board ID: 08DGM-9T6BU-FG3S0-7J9FJ-3SJ6R-K86ZG
Used output buffers: 1 of 20 (9 max)
=== RTOS ===
Static ram: 27476
Dynamic ram: 98504 of which 0 recycled
Exception stack ram used: 280
Never used ram: 4812
Tasks: NETWORK(ready,464) HEAT(blocked,1232) MAIN(running,3580) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 00:03:27 ago, cause: power up
Last software reset at 2018-11-25 07:51, reason: User, spinning module GCodes, available RAM 4712 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 55.8ms, max retries 0
MCU temperature: min 35.8, current 36.2, max 36.8
Supply voltage: min 11.7, current 11.7, max 12.4, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2018-11-25 08:34:33
Cache data hit count 746636395
Slowest loop: 217.17ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.5
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by file
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "M190 S90" in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 57.61ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8- WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.21
WiFi MAC address 84:f3:eb:82:db:5b
WiFi Vcc 3.36, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 13336
WiFi IP address 192.168.1.5
WiFi signal strength -46dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
- WiFi -
-
@siblues said in BlTouch randomly deploys probe twice.:
Here is the info you needed and now the wifi led was also turning off after it disconnected.I restarted the Duet wifi to see if I could reproduce the problem and now the only led that turns on with the power supply is teh vin led but when I directly connect to the board with a usb they all light up fine.
That sounds like the on-board 5V regulator is no longer working. Is the I_5V_EN jumper still firmly in place?
-
Yes the jumper is still firmly on the terminals. I am at a loss trying to figure out why this happened.i tested the power supply and it is at 12.8v but when I test at the terminals on the board I get 2.3v. I guess the disconnections could have been that regulator? Any ideas on what may have caused this and what are my options now?
-
@siblues, is your Duet still under warranty?
-
I just got it maybe two months ago .I am in the process of setting my printer up.i haven't even printed with it yet lol.I checked it was purchased from Filastruder on October 9th.
-
In that case, ask for it to be replaced under warranty.
-
Would a bad or shorted heatbed cause something like nthis or do you have any ideas on what would cause this to happen.I know it could have been a bad regulator to start with but it seems weird that it worked fine for a few weeks and just suddenly stopped working?
-
No, a faulty heat bed might damage the bed heater mosfet but it shouldn't affect the 5V regulator. OTOH if you connected external devices to +5V then a prolonged overload might damage it.
-
The only thing that changed was I installed a larger bed. I don't have any extra items connected to the board other than the necessary items to operate the printer.
-
I do not know if this is the case, but I had this happenning to me a few months ago.
I found out that my BLTouch wire were damaged. The BLTouch would "reset" and deploys like when turned on.
IMO, you might have a damaged wire or possibly problem with your connectors.
I hope this helps.
-
I will check again to make sure but was your BlTouch working while it was doing this? Mine keeps working just fine while it is doing this. I do get quite a few the probe was triggered before move messages.
