Hi @dc42 ,

I thought maybe, given how old this thread is, this had already been implemented, so I updated firmware. But alas no. I just tested and it does not. Hence my print ends with the hot end sitting against my print, still hot for 2 hours until I wake up.

Adding M0 manually to the end of the gcode via the slicer is a poor implementation.
M0 is a STOP or Unconditional STOP. Which that's exactly what it should do. STOP. Not, oh run this other gcode now.
In addition, I print from multiple printers and often use different slicers. Not only do I not want to apply this change to every slicer, I have different requirements for the end of a print for each machine. Therefore, it makes vastly more sense for the firmware to have a machine specific end.g to be appended to the end of each job. This way, I can customise the end print for each machine and don't have to have multiple machine profiles (so much) for each slicer.

I vote this UP. Please provide the facility to append the content of an end.g file to the end of every job.

Thanks
Adrian

Hi @dc42 ,

I thought maybe, given how old this thread is, this had already been implemented, so I updated firmware. But alas no. I just tested and it does not. Hence my print ends with the hot end sitting against my print, still hot for 2 hours until I wake up.

Adding M0 manually to the end of the gcode via the slicer is a poor implementation.
M0 is a STOP or Unconditional STOP. Which that's exactly what it should do. STOP. Not, oh run this other gcode now.
In addition, I print from multiple printers and often use different slicers. Not only do I not want to apply this change to every slicer, I have different requirements for the end of a print for each machine. Therefore, it makes vastly more sense for the firmware to have a machine specific end.g to be appended to the end of each job. This way, I can customise the end print for each machine and don't have to have multiple machine profiles (so much) for each slicer.

I vote this UP. Please provide the facility to append the content of an end.g file to the end of every job.

Thanks
Adrian

Solved!

It turns out the config gen tool creates a homeall.g file with a series of G1 commands instead of a simple G30. When I converted it to use G30, I also left a "G92 Z0" command behind thinking it was correct. It is not when the G30 is used to home the axis. It caused a Z offset that resulted in following G29 and G32 commands to fail on probing.

I am not sure if this is a similar issue or not. Unfortunately I can no longer edit the references to it in my post.

My updated homeall.g now looks like this.
[0_1609398857654_homeall.g](Uploading 100%)

FYI, my M115...
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.1.1 ELECTRONICS: Duet WiFi 1.0 or 1.01 + DueX5 FIRMWARE_DATE: 2020-05-19b2

ABear

Hi @Phaedrux ,

My post no longer makes sense now you have moved it. The title is also no longer accurate.
The new Title "Z probe not triggered during homing move", would be better as "Z probe reports error during a G29 or G32 move"

Unless the problem is truly not the same, I feel it belongs back where I had it.

Thanks
A Bear

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

Therefore

Hi @dc42 ,

Is there an ETA on the proper fix for the issue in this thread?
https://forum.duet3d.com/topic/17313/rrf3-z-probe-was-not-triggered-during-probing-move

I think am experiencing the same problem with RRF3, but on my Duet Wifi (V1.0) and Duex5 (V0.6).
I'm upgrading a largish cartesian printer from Rumba to Duet and have not yet finished the config/calibration (its been 4 days of tedium now). I haven't even extruded anything yet. My goal has been to get true "Auto" Bed Leveling, with the 3 z-axis motors correcting the bed tilt's.

X, Y an E are all connected to the main board, but 3xZ motors are connected to the Duex and the BL touch is connected to both (3 wire line connected to PWM_5).

Home All works without reporting an error, but I notice it lowers the bed about 5mm and reports the z position as 0.

From that point onward G29 and G32 both report "Z probe was not triggered during probing move" even if the bed does actually touch the BL Touch probe. G29 aborts, where's as G32 continues to measure all 3 points, but does not adjust the z-axis screws.

My G files are
homeall.g
deployprobe.g
config.g
bed.g
retractprobe.g

My V1 Printer

She looks a bit rough at the moment having her guts ripped out.

Any help appreciated.

Thanks
A Bear

@abear said in RRF3 BL Touch setup on Duet WiFi v1.0 + Duex5:

he config tool you g

I'm not sure what "he config tool you g" means

@Phaedrux said in RRF3 BL Touch setup on Duet WiFi v1.0 + Duex5:

he config tool you g

Thanks Phaedrux and Veti,

Phaedrux, you were on the right track. My probe up and down scripts (all of them) referred to the pin number (i.e. 7) instead of the port number defined by the M950 command (i.e. 0).
A problem caused by mashing together the defaults from the RRF3 config tool and the BeTrue3D how to article which used RRF2 (or earlier).
My BLTouch working config.g and probe up and down scripts are attached (with my comments included) for anyone else that may need to reference this info. Just note, I have not yet finished configuring everything else, only the BL Touch in these scripts.
Also, I did need to update the homex and homeall commands to use G30 instead of G1

deployprobe.g
homeall.g
homez.g
retractprobe.g
config.g

Thanks for your help

Now onto the next configuration challenge.....The actual Auto-Bed Level test, with 3 z-axis motors doing the levelling for me, wahoo

Hi All,

I have a "BeastV1" from Cultivate3d (a large DIY cartesian 3D printer), that I am upgrading from a Rumba 8bit board to Duet WiFi (v1.0) and Duex5 boards I have had sitting in the draw (for this very purpose) for 3 years. The main reason for ugrade is to get real "auto-bed levelling" with a separate motor driving each of the 3 z-axis lead screws. And because its fun to tinker.

I have almost everything setup except the BL Touch.
(a bit of a hiccup with a dodgy FAN0 pin that sits at 10.3 V no matter what I do, but got past it by using FAN1 instead).

I have followed BeTrue3D's wiring setup
https://betrue3d.dk/bltouch-on-duet-wifi-configuratio-and-usage/
and most of his config.g setup, with the some exceptions to support Mode 9.

I have cut the 3.3 V strip on the BL Touch (its genuine but a few years old).

It runs its self test, no problems and worked flawlessly with the Rumba board.

X and Y end stops are working as expected, the z end stop is not connected in leu of using the BL Touch (similar to my previous setup with the Rumba).

My config.g is attached
config.g

The probe's deploy and retract just won't do anything. Neither the deploy.g/retract.g scripts from the config gen tool, the PinUp.g/Pin Down.g scripts BeTrue or the M401/M402 commands will have any effect.

And obviously homing the Z axis just crashes the bed into the nozzle.

Any help would be greatly appreciated.

Thanks