RRF3 -> Z-Probe was not triggered during probing move

JoergS5

This post is deleted!

Phaedrux

; Z-Probe
M558 P5 I1 C"!io5.in" H5 F500 T12000 ; Z probe type -> Induktiv
G31 P100 X0.0 Y0.0 Z2.0

Can you try enabling the pullup resistor by adding a ^ to the C value?

M558 P5 C"^!io5.in"

CR3D

@Phaedrux said in RRF3 -> Z-Probe was not triggered during probing move:

Can you try enabling the pullup resistor by adding a ^ to the C value?

I think that will definitely work (I will test it when I am back home). but what should it do? the Z-probe itself works with homing e.g. or at the first measuring point at G29. It is rather the problem that the z-axis in g29 moves too far from the Z-probe.

JoergS5

@CR3D I am not sure ^ will work because you use Duet 3 with pullup already installed: https://duet3d.dozuki.com/Wiki/Connecting_endstop_switches#Section_Duet_3_endstop_inputs
But I don't have an idea what's wrong, so please try ^.

I wonder why you don't get an error message in homeall with
G1 X270 Y170 U600 F20000
because U is outside your M208 limits. If this command is ignored, you would make the G30 z probe at the XY endstop positions.

(deleted a comment about CoreXY, as it is a Cartesian printer)

CR3D

@JoergS5

Ok i will try it Of course .. .:-)

I use the same inductive sensors as endstops in X,Y and U... so thats why I am wondering...

The printer is a Cartesian IDEX System... till now I get no error message at homeall.g

The printer at itself is running... homing, move axis ....

JoergS5

@CR3D could be that the Duet 2 and Duet 3 have different pullup default values and your probe makes a different. If ^ does not work, I am sure a solution to add some external pullup resistor to the endstop would be also possible to set the same resitance comparable to the Duet 2 was.

I visited your homepage, you have interesting and good quality printers!

A Former User

@JoergS5 said in RRF3 -> Z-Probe was not triggered during probing move:

could be that the Duet 2 and Duet 3 have different pullup default values and your probe makes a different.

1k vs 27k hardware pull up

CR3D

@JoergS5

Thank you! Yes we want to build high performance Printers with High performance Electronics!

@bearer
Thank you -> is that difference a problem for the sensor or the result? because the sensor at itself triggers ...

the question is still why he moves the z-axis too far after probing ..?

CR3D

Ok i made every changes you said and nothing was the solution!

; Z-Probe 
M558 P5 C"^!io5.in" H1 F500 T12000 ; Z probe type -> Induktiv
G31 P100 X0.0 Y0.0 Z1.95

I activated the Pull-Up Resistor and i changed again the DIVE Heigth ("H-Parameter").

@dc42

it must be a bug in the firmware, it only moves the bed with the G29 by twice the dive height without knowing this. Then, of course, the distance to the Z-Probe is too great and it gives the error message "Z-Probe was not triggered during probing move"

the inductive sensor itself works wonderfully -> I also use it on the X, Y and U axis. So it is not a problem with the signal evaluation in my opinion!

CR3D

@dc42 do you have any idea? Please help me...!

JoergS5

@CR3D if you start G29, is the first mesh testing point over the bed? The first point is at 50,0 and your offset setting is 0,0 which is strange (same position like nozzle?) But mesh ignores G31 setting anyway and starts at 0,50. I would try starting eg at 100,100

Other ideas are whether Ir is reflected correctly by print bed.

Third idea is the prebuilt pullups may be too weak. The Duet Ir Sensor mentions the smoothieboard 1k pullups being too weak eg. Maybe this hereis a similar problem. But I am no pullup expert.
Article with section smoothieware: https://miscsolutions.wordpress.com/mini-height-sensor-board/

One more idea, I miss the M574 Z endstop saying that the z endstop is a probe:
"When using the Z probe to home Z, M574 Z0 should be used."

One additional idea is that LEDs are mentioned in the config, maybe the light disturbs the IR sensor. Maybe they emit IR wavelengths partly.

CR3D

@JoergS5 said in RRF3 -> Z-Probe was not triggered during probing move:

Thank you for the many suggestions, but unfortunately all the points mentioned are given.
The first rehearsal point is over the bed! That fits.

the funny thing is that he sometimes brings the error message right after the first probe point and sometimes right in the middle or once it had worked completely to execute the G29 command, but then the complete heightmap had an offset of 5mm (see image above).

And by the way I use an inductive sensor and no longer the IR probe -> I've had too many problems with this in the past ...

deckingman

@CR3D This is a long shot because I don't use a probe, but try reducing the feed rate in your M558. e.g. try 300 instead of 500 just to see if that helps.

MacNite

If looked through your code and could not find any mistakes. I had some Problems in my beginngs with RRF3 too.

Maybe @dc42 has another Idea.

Greets
Max

Phaedrux

Just to eliminate the probe entirely can you test using M558 P0 to use the manual probing option? That will prompt you to job the Z axis down. Then we can see if everything software side is working with the homing heightmap etc.

Maybe the probe itself is failing. Do you have another to test with?

CR3D

I have already exchanged the z-probe a few times. I have already made 20 repetitions with the homez.g and measured the trigger height, so the sensor triggers wonderfully and works very precisely (approx. 0.01mm).

It only occurs with the G29 command.

Again I have observed that with G29 it not only moves the dive height down, but the double dive height. In the dashboard, however, the "simple" dive height is shown as the Z value. that's why i think it moves twice its height and doesn't notice it.
as soon as he then carries out a test point in the G29, he has to cover twice without knowing that he drove this height before, so he claims that the z-probe does not trigger.

Another dive height does not change anything, because it then moves twice without knowing it.

Skimmy

I did an extensive code-check and talk with CR3D and also didn't come to a solution.

For example: a 5-point bed-calibration works fine (a G32 (call to execute bed.g with 5x G30 in it)

Every G30 command works, but as soon as you start a G29, things start getting weird.

dc42

In your config.g file I see these lines:

M584 X0.2 Y0.0:0.1 U0.3 Z1.0:1.1:1.2 E0.4:0.5 ; set drive mapping

and:

M558 P5 I1 C"!io5.in" H5 F500 T12000 ; Z probe type -> Induktiv

So your Z motors are connected to the expansion board and your Z probe is connected to the main board. Unfortunately, it is a limitation of the current firmware that an endstop switch or Z probe connected to the main board cannot stop a stepper motor connected to an expansion board unless a motor connected to the main board is also moving. This was documented for endstops some time ago (at https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations and also in the RRF 3.0 release notes at https://github.com/Duet3D/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md), but unfortunately I omitted to include Z probes in those documents until recently. I apologise for that.

Possible workarounds include:

Connect the three Z motors to stepper outputs on the main board. This is the preferred solution.
Connect the inductive sensor to the expansion board instead of to the main board.
Configure a 4th dummy Z motor on the main board.

T3P3Tony

looking at your motor use, it looks like you are using all the drivers on the mainboard so I think you need to swap Z to the main board or the sensor to the expansion board.

Karma

@CR3D I was looking at your config.g file and I noticed that you have your Y-axis current set to 4200. I am not second guessing you, I was just wondering if that was correct.