Probe does not work with 2.02a + DWC 2.0.0 RC3

Phaedrux

@garv3 how did you obtain the trigger height?

GaRv3

Oh, you were talking about the trigger height - not the dive height. Believe me, the trigger height is perfect.
This is not an issue at all. The problem is that the probe triggers (I can see the LEDs on the probe and the PCB light up) but G29 ignores it and does not stop moving down.
G30 S-1 crashed into the bed as well! LEDs light up but Z keeps moving down.
Btw: G31 always reports 0 - no matter if the probe is active or not.

GaRv3

Went back to:
Firmware Version: 2.02RC2(RTOS) (2018-09-07b2)
WiFi Server Version: 1.22
Web Interface Version: 1.22.3
=> Bed leveling works just fine!

So this has to be a firmware issue

dc42

Please check that you don't have any other M558 commands anywhere, for example elsewhere in config.g, config-override.g. or homing files.
With firmware 2.02 running, send M558 without parameters. Check that it reports probe type 4 and input 3.
Then do the static test described at https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probe#Section_Static_test_of_the_Z_probe. [I guess you've already done that because you reported "G31 always reports 0 - no matter if the probe is active or not."]

GaRv3

@dc42 said in Probe does not work with 2.02a + DWC 2.0.0 RC3:

M558 is only present in the config.g at this single line.

I put the this version back on the sd card:
Duet Web Control 2.0.0-RC3
Electronics: Duet WiFi 1.02 or later
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 2.02(RTOS) (2018-12-24b1)
Duet WiFi Server Version: 1.22

Now everything got even worse.
When homing Z crashes into lower limits pushing against the endstop!

M119 reports the correct values though.
When the Z endstop is not triggered:
Endstops - X: not stopped, Y: at min stop, Z: not stopped, U: at min stop, V: at min stop, Z probe: not stopped
When it is:
Endstops - X: not stopped, Y: at min stop, Z: at min stop, U: at min stop, V: at min stop, Z probe: not stopped

M558 reports this:
Z Probe type 4, input 3, invert yes, dive height 7.0mm, probe speed 120mm/min, travel speed 6000mm/min, recovery time 0.00 sec, heaters suspended, max taps 1, max diff 0.03

G31
Will always report 0. No matter if the probe is close to the bed and the LEDs are on or not.

This is becoming really strange...

EDIT:
Manually replaced all firmware binaries on the SD card and now homing works again.
But the problems with the probe persist. G31 reports 0 - no matter what.

GaRv3

So no idea what causes this?

Firmware: 2.02RC2(RTOS) (2018-09-07b2)
WiFi: 1.22
DWC: 1.22.3
-> everything works as expected

Firmware: 2.02(RTOS) (2018-12-24b1)
WiFi: 1.22
DWC 2.0.0-RC3
-> probe ignored

This must be a firmware issue. No one interested in fixing it?

dc42

My guess is that the output of your capacitive sensor isn't pulling the E0 endstop input low enough to trigger the probe reliably. The processor's internal pullup resistor is enabled for the endstop inputs in 2.02, and possibly it wasn't in RC2.

Is the output of the capacitive sensor connected to the E0- input directly, or though a diode? If it is through a diode, is it a Schottky diode? Some users have found that only Schottky diodes work with their NPN-output sensors.

It may be better to connect the probe output to the IN pin of the Z probe connector instead of the E0 endstop input, and to use P5 in the M558 command. That will give a slightly higher trigger threshold.

GaRv3

It's connected using one of these diodes:
https://www.amazon.de/gp/product/B01COV7LCC/ref=oh_aui_search_asin_title?ie=UTF8&psc=1

I will try using the z probe connector input. Will I have to change anything but the M558 after doing so?

Btw: It worked with all previous firmware versions.

dc42

@garv3 said in Probe does not work with 2.02a + DWC 2.0.0 RC3:

It's connected using one of these diodes:
https://www.amazon.de/gp/product/B01COV7LCC/ref=oh_aui_search_asin_title?ie=UTF8&psc=1

I will try using the z probe connector input. Will I have to change anything but the M558 after doing so?

Btw: It worked with all previous firmware versions.

That's not a Schottky diode, so I think my hypothesis was correct. Using a BAT43 or BAT85 diode instead of the 1N4148 would probably fix it.

You don't need to change anything other than the M558 command if you use the Z probe connector instead. There is a chance that the sensor may have too much leakage and show as permanently triggered, but it's unlikely.

GaRv3

@dc42 said in Probe does not work with 2.02a + DWC 2.0.0 RC3:

That's not a Schottky diode, so I think my hypothesis was correct. Using a BAT43 or BAT85 diode instead of the 1N4148 would probably fix it.

But why does it work with all other FW versions?

Using the z probe connector does not change anything.

dc42

Can you confirm that when you use M558 P5 (or P8), if you connect the Z probe In pin to ground it makes the Z probe reading change for 0 to 1000? Similarly if you use M558 P4 and connect the E0 endstop STP pin to ground.

The difference between firmware versions is because on some firmware versions, the pullup resistors were not enabled on the endstop inputs. Enabling them improves noise immunity in the high state, but worsens it in the low state. It's arguable which is better.

GaRv3

Yes, when I short z probe IN and z probe GND, the value changes to 1000.

Wouldn't it be possible to allow us to (de)activate the pullup resistors for individual ports in config.g?

GaRv3

Wouldn't this be a solution?

dc42

@garv3 said in Probe does not work with 2.02a + DWC 2.0.0 RC3:

Wouldn't this be a solution?

Maybe, but it's an an extra complication. Had you used a Schottky diode as we recommend, or alternatively no diode at all if your Duet is revision 1.04. then it would work anyway.

GaRv3

It is revision 1.03
I will try to get the diode and test ist.

dc42

I have it on my list to check the noise margin of the endstop inputs with and without the pull up resistor enabled, to see which is better overall.