Genuine BLTouch v3.0 weirdness with RFF >= 3.3

Schmart

Tested now with RRF 3.4.0 beta 4 as well. I'm seeing the same issues; I perform the upgrade from 3.2.2 stable to 3.4.0 beta 4, power off and power on the printer and then the BLTouch stays dark. After communication with the BLTouch, such as a reset or when done homing, the BLTouch goes into 80% duty cycle blink mode. So all firmwares from 3.3 stable to the 3.4.0 betas show the same issue with the BLTouch connected to my printer (Duet 2 Maestro).

Rolling back to 3.2.2 stable fixes the issue again.

@dc42 Do you know if more people reported issues with a genuine BLTouch 3.0 probe? I'm fairly sure that this isn't a VCC issue because the probe is faultless on the 3.2.2 firmware and the issues are 100% consistently occurring on later firmwares.

Schmart

I'm not at my printer right now to post the full config.g

This is the full config.g, superfluous comments removed:

; General preferences
G90                                                                     ; Use absolute X and Y coordinates
M83                                                                     ; Use relative extruder moves
M550 P"CR20PRO"                                                         ; Set printer name
M912 P0 S-4.2                                                           ; Set MCU temperature deviation
M918 P2 E4 F2000000 R3 C60                                              ; Configure ST7565-based LCD display with one menu item per encoder click, contrast ratio 80%

; Network settings
M552 P0.0.0.0 S1                                                        ; Enable network and acquire dynamic address via DHCP
M586 P0 S1 T0                                                           ; Enable HTTP (without TLS support)
M586 P1 S1 T0                                                           ; Enable FTP (without TLS support)
M586 P2 S0                                                              ; Disable Telnet

; Define drives
M569 P0 S0                                                              ; Driver 0 (X) goes backwards
M569 P1 S0                                                              ; Driver 1 (Y) goes backwards
M569 P2 S0                                                              ; Driver 2 (Z) goes backwards
M569 P3 S0                                                              ; Driver 3 (E) goes backwards
M584 X0 Y1 Z2 E3                                                        ; Set drive mapping
M92 X160 Y160 Z800 E409 S16                                             ; Set steps per mm specified with 1/16 microsteps (Hemera default, 0.9 degree steppers on XYZ axis)
M350 X16 Y16 Z16 I1                                                     ; Configure X Y Z driver microstepping mode with interpolation (NOTE: steps/mm need no adjustment)
M350 E16 I1                                                             ; Configure E driver microstepping mode with no interpolation (NOTE: steps/mm need no adjustment)
M203 X9000 Y9000 Z600 E3600 I6                                          ; Set maximum speeds (mm/min) (X150 Y150 Z10 E60 mm/s) and minimum overall speed (0.1mm/s)
M201 X500.00 Y500.00 Z100.00 E5000.00                                   ; Set per-axis accelerations (mm/s^2)
M204 P500.000 T1000.00                                                  ; Set printing and travel acceleration
M566 X600.00 Y600.00 Z30.00 E300.00 P1                                  ; Set maximum instantaneous speed changes (mm/min) (X10 Y10 Z0.5 E5 mm/s) with jerk policy between any pair of moves
; NOTE: This is peak current, not RMS current. The setting on the Duet Maestro is in steps of 50mA and rounded down.
M906 X800 Y950 Z800 E800 I30                                            ; Set motor peak currents (mA) and motor idle factor in percent (60% of Hemera motor current of 1.33A is 800mA)
M84 S30                                                                 ; Set idle timeout
;M917 X60 Y60 Z60 E60                                                    ; Set motor current reduction (percentage) for standstill or very low speeds

; Set axis Limits
M208 X-117.5:117.5 Y-128.2:107.0 Z0:250                                 ; Set axis limits and make (0,0) the bed center; the Y-axis is slightly limited due to the tensioner bracket (3DFused)

; Define endstops
M574 X1 S1 P"xstop"                                                     ; Configure microswitch endstop for low end on X-axis using active high pin 'xstop'
M574 Y1 S1 P"ystop"                                                     ; Configure microswitch endstop for low end on Y-axis using active high pin 'ystop'
M574 Z0                                                                 ; Use a Z probe to home the Z-axis

; Z-Probe definitions
; WARNING: M558 statement always before any G31 statement!
; NOTE: newer versions of BLTouch need a pull-up resistor enabled (using the '^' symbol) on the 'zprobe.in' pin
M558 P9 C"^zprobe.in" H5 F120 T6000 R0.0 A5 S0.02 B1                    ; Set BLTouch type, 5mm dive height, probing speed 2mm/s, travel between probes 100mm/s, 0.0s settle time, maximum 5 probes, 0.02mm precision, heaters off while probing
M950 S0 C"zprobe.mod"                                                   ; Create servo 0 on pin 'zprobe.mod' for BLTouch PWM control channel
G31 P25 X-37.0 Y0.0 Z1.38                                               ; Set Z probe offset and trigger height (3DFused BLTouch mount)
; WARNING: Define the mesh grid so that collision of the nozzle with bed clamps and such is avoided!
M557 X-107.5:107.5 Y-97.5:62.5 P5:5                                     ; Define mesh grid (with E3D Hemera with (0,0) as bed center)
;M376 H4                                                                 ; Mesh compensation fade height at 4mm (commented out for now; do this in the slicer)

; Define bed leveling screw positions
;M671 X32.5:202.5:32.5:202.5 Y32.5:32.5:202.5:202.5 P0.7                 ; Thread pitch of 0.7mm is for M4 (M3 is 0.5mm pitch)

; Define heaters and temperature sensors
M308 S0 P"bedtemp" Y"thermistor" A"Bed" T100000 B4092 R2200             ; Create sensor 0 as a thermistor type on pin 'bedtemp' (Creality bed thermistor)
M950 H0 C"bedheat" T0                                                   ; Create heater 0 using pin 'bedheat' and monitor the heater through sensor 0
M140 P0 H0                                                              ; Configure bed heater 0 to use heater 0; M140 must be between M950 and M143
M143 H0 S90                                                             ; Set temperature limit for heater 0 to 90C
M307 H0 B0 S1.00                                                        ; Disable bang-bang mode for the heater and set PWM limit
M308 S1 P"e0temp" Y"thermistor" A"Hotend" T100000 B4725 C7.06e-8 R2200  ; Create sensor 1 as a thermistor on pin 'e0temp' (Semitec 104-GT2)
M950 H1 C"e0heat" T1                                                    ; Create heater 1 using pin 'e0heat' and monitor the heater through sensor 1
M143 H1 S285                                                            ; Set temperature limit for heater 1 to 285C
M307 H1 B0 S1.00                                                        ; Disable bang-bang mode for the heater and set PWM limit

;M308 S2 P"ctemp" Y"mcu-temp" A"MCU"                                    ; Create virtual sensor 2 on pin 'ctemp'
M308 S31 Y"mcu-temp" A"MCU"                                             ; Create virtual sensor 31 on pin 'ctemp'
M308 S30 Y"drivers" A"Drivers"                                          ; Create virtual sensor 30 on pin 'drivers'

; Fans
M950 F0 C"fan0" Q50                                                     ; Create fan 0 on pin 'fan0' and set the PWM frequency
M106 P0 C"Part Fan" S0.0 H-1                                            ; Configure fan 0, thermostatic control is turned off
M950 F1 C"fan1" Q55                                                     ; Create fan 1 on pin 'fan1' and set the PWM frequency
M106 P1 C"Hotend Fan" S1.0 H1:0 T45                                     ; Configure fan 1, thermostatic control is turned on (Sunon MagLev KDE2404PFV2 24V 1.4W)
M950 F2 C"fan2" Q50                                                     ; Create fan 2 on pin 'fan2' and set the PWM frequency
M106 P2 C"Case Fan" S1.0 H31:30 T20:50                                  ; Configure fan 2, thermostatic control is turned on, activate when MCU temp is 20+, full speed at 50+ or at driver overheat

; Tools
M563 P0 S"Hemera" D0 H1 F0                                              ; Define tool 0
G10 P0 X0 Y0 Z0                                                         ; Set tool 0 axis offsets
G10 P0 R0 S0                                                            ; Set initial tool 0 active and standby temperatures to 0C

; Miscellaneous
M501                                                                    ; Load saved parameters from non-volatile memory
M911 S21 R23 P"M913 X0 Y0 G91 M83 G1 Z3 E-1 F1000"                      ; Set voltage thresholds and actions to run on power loss
T0                                                                      ; Select first tool

T3P3Tony

@schmart thanks for the report. I checked the config too as you mentioned it and it generates the following for a BL touch on a Maestro with RRF set to 3.3:

; Z-Probe
M950 S0 C"^zprobe.mod"                         ; create servo pin 0 for BLTouch
M558 P9 C"^zprobe.in" H5 F120 T6000            ; set Z probe type to bltouch and the dive height + speeds

the same is generated for 3.0 to 3.2. Its worth trying that change in case thats the reason for your 80% duty cycle led flashing.

Schmart

@t3p3tony Hi Tony, thanks for responding!

I tried with the pull-up resistor enabled on the pin (^zprobe.mod) as well, but unfortunately no change. Electrically, that's not what I would expect anyway, but I'm open to try any suggestions.

Note that my original settings were compliant with recommendations from this article which recommends to use the pin without the pull-up resistor activated (zprobe.mod).

It could be that the generator is right and the article is wrong, but fact is, my BLTouch works demonstrably fine on 3.2.2 with the settings from the article and doesn't work properly anymore with either the pull-up activated or deactivated in RRF 3.3 and the 3.4 betas.

So what I intend to do is hook up a logic analyzer to the zprobe.mod pin and see if I can spot subtle differences in output between RRF 3.2.2 and 3.4 beta 4, but I won't be able to do this tonight.

dc42

@schmart does it make any difference if after the M950 S0 command you run M42 P0 S0 ?

T3P3Tony

@schmart said in Genuine BLTouch v3.0 weirdness with RFF >= 3.3:

I tried with the pull-up resistor enabled on the pin (^zprobe.mod) as well, but unfortunately no change. Electrically, that's not what I would expect anyway, but I'm open to try any suggestions.

yes, thanks. we have asked the config tool to be updated to reflect this.

Schmart

@dc42 said in Genuine BLTouch v3.0 weirdness with RFF >= 3.3:

@schmart does it make any difference if after the M950 S0 command you run M42 P0 S0 ?

Ah, that's clever troubleshooting! I tried this: it doesn't do anything when the M42 P0 S0 is put right after the M950 line in the config.g. Then the BLTouch stays dark like with all post-3.2.2 firmwares.

However, once the BLTouch is in its blinking state, a M42 P0 S0 sent from DWC makes the LED stop blinking. It is then 'on' continuously.

Of course, after e.g. an M280 P0 S160, M280 P0 S10 or M280 P0 S90, the BLTouch starts blinking again, which can now consistently be 'reset' by M42 P0 S0.

Note that the BLTouch does seem to execute the commands properly, it's just that it starts blinking after each command.

Schmart

@dc42 I hooked up my logic analyser to the zprobe.mod and VCC pins of the BLTouch, and tested a couple of scenarios with both RRF 3.2.2 and RRF 3.4.0 beta 4, including the startup sequence, reset and deploy.

I'm not seeing differences in the PWM generated by the M280 commands between the two firmwares.

However, I do see a significant difference between the firmwares in the time it takes from VCC fully powering the BLTouch and the zprobe.mod pin going LOW:

RRF 3.2.2 takes about 20.6ms
RRF 3.4.0 takes about 40.6ms

Here are my measurements. I performed these multiple times to verify the timings were consistent. Channel 0 is zprobe.mod and Channel 1 is VCC to the BLTouch. T0 is when I power on the printer (small power spike) and after about 1.2-1.3s it seems that the board starts initialisation.

RRF 3.2.2:

RRF 3.2.2 Startup (zprobe.mod and VCC).png

RRF 3.4.0 beta 4:

RRF 3.4.0 beta 4 Startup (zprobe.mod and VCC).png

My theory is that on startup of the Duet 2 Maestro with RRF 3.4.0, the BLTouch interrupts its self-test because zprobe.mod happens to turn LOW in the middle of that process. Once it has entered that error state, it remains there until it can successfully complete its self-test.

This effect is also described on the Antclabs site:

BLTouch Flashing 80% Duty Cycle.png

I suspect that the reason that this doesn't happen on RRF 3.2.2, is that it turns the zprobe.mod pin LOW before the BLTouch starts its self-test.

I looked at the Platform.cpp code, is there a safe way to turn zprobe.mod low earlier (UrgentInit() perhaps?) or delay the InitZProbe() by the 100ms 'non-PWM Time' that Antclabs recommends?

Signal timing

dc42

@schmart thanks for your detective work! Have you tried moving your M558 command to the start of config.g? That might make the high to low transition of the mod pin happen earlier. Alternatively, you could put a G4 P120 command before the M558 command, to delay the high-to-low transition by 120ms.

Schmart

@dc42 Apologies, I neglected to mention that I had tried this, both the delay/dwell and moving around commands in the config.g. I'm confident that zprobe.mod pin going LOW happens before my config.g even gets loaded. The G4 S10 I used at the start of config.g really made this clear.

That's why I mentioned there's maybe something that can be done relatively quickly after board startup, e.g. in UrgentInit() or Platform::Init(), or perhaps even prevent the pin going HIGH in the first place (I haven't yet checked if the SAM4S8C initializes pins HIGH by default, or that this is done by a specific piece of RRF code).

As a proof of concept, I've built the latest GitHub branch 3.4-dev and modified Init() in Platform.cpp slightly with just one statement added at the beginning:

// Initialise the Platform. Note: this is the first module to be initialised, so don't call other modules from here!
void Platform::Init() noexcept
{
	// Prevent BLTouch from receiving a delayed transition to LOW on its zprobe.mod pin.
	// This confuses the self-test process and throws the BLTouch in a 80% duty cycle blinking mode.
	// DiagPin is identical to Z_PROBE_MOD_PIN on Duet 2 Maestro.
	// This statement was also present in earlier firmwares, e.g. <= 3.2.2
	pinMode(DiagPin, OUTPUT_LOW);

This has drastically reduced the time that it takes for zprobe.mod to become LOW. It now only takes 8.6ms (!) measured from the point that VCC is stable:

RRF 3.4.0 beta 4 Startup (Modified Init()).png

I can happily report that this quick fix has proven that I found the culprit and that this has solved the issue. The BLTouch is now performing its self-test completely and correctly: the pin deploys and retracts twice when powering on the printer and the red LED is on continuously now.

P.S. I had mentioned UrgentInit() and InitZProbe() before, but I was looking at an older dev branch, and things have changed considerably since then with the whole state machine in Platform::Tick(), so please forget I mentioned that.

dc42

@schmart thanks for that data. However, I can't replicate some of your results.

I checked the source code in the 3.4-dev branch, and it sets the Diag pin low right at the start of AppInit in file Tasks.cpp - well before Platform::Init is called. I can find no other paces that the pin is written, except later on in AppInit if there is a firmware CRC error, and via the pin table if pin zprobe.mod is configured.

I also attached an oscilloscope to the pin and I found that the pin initially rises with Vcc and then goes low about 45ms later. I tried adding the digitalWrite call at the start of Platform::Init as you did, and it made no difference. I even tried reinstating the UrgentInit call and setting the pin to a low output there, but it made no significant difference.

If I attach a 10K pulldown resistor to the pin, it rises to only 300mV. This confirms that the pin goes high because of the internal pullup resistor in the SAM4S microcontroller, which defaults to being enabled.

I tried firmware 3.2.2 and found that in that version, the pin goes low 25ms after Vcc rises. So there is indeed a longer delay in later versions.

Further investigation showed that the additional delay in 3.4 compared to 3.2 was caused by the larger amount of static data being cleared to zeros in the startup code. I have improved the efficiency of that startup code, and the delay is now down to 14ms.

Schmart

@dc42 Thanks for going through the trouble of checking this, and I may have the answer.

Because I was in a hurry making it to my bed before 3:00am, I pulled all dev-3.4 branches, updated the ARM Toolchain to 10-2020-q4-major, fixed the Eclipse workspace, built the dependencies, added the pinMode(DiagPin, OUTPUT_LOW) to the Platform::Init(), built RepRapFirmware too and uploaded the firmware. I assumed that modification to be the fix, since the BLTouch worked.

What I didn't do, is check the results with a firmware built from the unmodified 3.4-dev repositories.

So I removed the line I added, rebuilt, uploaded, and the BLTouch still works. This might very well be the difference between a downloaded release and a firmware I built myself?

Schmart

@dc42 The lack of supporting data from my last post bothered me, so I decided to hook up the logic analyser again.

I'm seeing it takes 13.8ms for the pin to go LOW, about 8.1ms if counted from VCC becoming a stable 5v. This is with the unmodified code (commit 9b4f401b9e9c7ce99547a0c25bf2c5ffd4e6361a).

So it seems that somehow the firmware I build myself performs that part of the startup quicker than the firmware release I can download from GitHub... I can't explain that.