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

CR3D

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.

CR3D

@dc42

Thank you david for your answer, that appears after a correct solution. But only as a counter question, why does a "single probe with G30" work very reliably with the Z probe on the mainboard and the motors on the expansion board?
I did repeat tests and had results of about 0.01mm with single probing ...

but no matter ... it makes sense to connect both on the same board!

Yes I know this limitation... I swapped the Z-motors to the expansion board, because some days ago we had following problem, and there was no other solution to swap the Y-motors to the main board.

https://forum.duet3d.com/topic/17153/duet3-expansion-board-3hc-no-can-connection/50?_=1594149269971

With this problem at the time, I even had the endstops on the 3HC board and it still didn't work.

That is why the three Z-axes are now on the expansion board. This made me forget to put the Z-probe from the main board onto the expansion board.

I just tried to test it, hoping to find the solution here. I put the Z-probe on the PIN C "^! 1.io5.in".

; Z-Probe 
M558 K0 P5 C"^!1.io5.in" H5 F400 T10000 ; Z probe type -> Induktiv

As soon as I plug in the z-probe here and adjust the config, the Z-probe disappears from the dashboard and with a probe command the error message appears that the Z-probe could not be found.

As soon as I plug it back into the main board, it appears again!

what can be the problem here?

Plugging the Z motors onto the mainboard is not an option due to the homing error mentioned above for the Y axis.

Or would it be possible to have one motor (i.e. 1x Y and 1x Z) on the main board and the others on the expansion board?

@Skimmy special thanks for the detailed examination of the code the last days

@Karma : I use NEMA 23 motors at the y-axis and they need this current

many thanks for the numerous answers! I hope, we find a solution

Regards Christian (CR-3D)

Karma

@CR3D Ahh, that makes perfect sense now. Thank you for that answer.

I would live to get my hands on a Duet 3, but my wife would kick my rear end if I spent anymore money on my printer right now. The Duet 3 board has so many more options then any board I have every seen. It's truly a work of art.

CR3D

@dc42

I even tested it now to always place at least one motor on the respective axis (i.e. a motor with the 3 z-axes on the mainboard and one of the two Y-axes on the expansion board) and map it correctly in the config. But this didn't work at all, not all axles drive clean here!

Why doesn't the Z-Probe work on the expansion board? That would be the easiest way ...?

dc42

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

As soon as I plug in the z-probe here and adjust the config, the Z-probe disappears from the dashboard and with a probe command the error message appears that the Z-probe could not be found.

One of the listed limitations is that a Z probe connected to an expansion board must be type 8 or type 9. So change the P parameter in your M558 command from P5 to P8.