Genuine BLTouch v3.0 weirdness with RFF >= 3.3

[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.4.0 beta 4:

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:

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?

[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:

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.