@jens55 Thanks for letting me know. It was just a wild guess, but given that your configuration looked fine, it had to be something like that.

@jens55 for homez, you need to move to a location that takes into account the probe offsets. so if you want to probe the centre of the bed, you would move to the centre, minus the offset. e.g.

G1 X{(move.axes[0].min + move.axes[0].max)/2 - sensors.probes[0].offsets[0]} Y{(move.axes[1].min + move.axes[1].max)/2 - sensors.probes[0].offsets[1]} F3600

For G29, you need to take into account the offset when setting the mesh limits. e.g. if your probe is on the right of your nozzle by 20mm, to start probing a mesh anywhere to the left of X20, the nozzle would have to be at X0 or less. Its not the end of the world if you do get this wrong because as long as your axis limits are correct as RRF will just tell you that your probe points are unreachable and skip them.

@Phaedrux

thanks to all

Yup, confirmed!

As I replied to your other thread, the pin names can be found here: https://docs.duet3d.com/en/Duet3D_hardware/Duet_2_family/DueX2_and_DueX5#pin-names

@msugar said in Calling Separate Trigger Files:

What are the appropriate names of these pins?

https://docs.duet3d.com/en/Duet3D_hardware/Duet_2_family/DueX2_and_DueX5#pin-names

M950 is used to define the pin that M42 would control.

https://docs.duet3d.com/User_manual/Reference/Gcodes#m950-create-heater-fan-spindle-or-gpioservo-pin

https://docs.duet3d.com/User_manual/Reference/Gcodes#m42-switch-io-pin

@chrishamm, thank you, that will help tracking things down. That certainly explains why the original CF card had the warning.

@dc42 OK great thanks! I must have made an error, I'll try again.

@Phaedrux :

3.4.6 same as 3.4.4

but in 3.4.0beta3 print paused message appears first then it's overridden by 'Too little movement' pop up message.

and how i print that messages on console? any suggestions on it?

@msugar the last time we saw this error was some time ago, and it was caused by a particular antivirus program requesting very long filenames from the Duet because it assumed that the Duet might support OCSP (which it doesn't).

We changed the HTTP server in RRF 3.x some time ago to automatically return failure of the filename was longer than is sensible on a Duet. So upgrading to RRF 3.4.6 would get rid of the messages. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/Migration_RRF2_to_RRF3 for an overview of the upgrade process.

How can you do such an automatic measurement with a macro that older filmware could also interpret, e.g. 2.02(RTOS) (2018-12-24b1)!?
video1
https://www.youtube.com/watch?app=desktop&v=gvwfQ_r7xoU
video2
https://www.youtube.com/watch?app=desktop&v=00g7d2wuFAI

thanks to @droftarts for pointing me in the right direction. I had to do an additional reset of my computer and board after verifying, then it worked.

@droftarts Thank you very much for your quick feedback and good ideas. ❤

@bernas Please post your config.g and response to sending M115 in the console. Also post your homeall.g and homez.g file, and pictures of your wiring at the Duet end and at the BLTouch.

Ian

Thanks for all the input! I'm hoping to have time tonight to do some investigating finally, so I'll update my results then! Thanks again!

@Aitor The errors on printer 3 may indicate the SD card is failing, so try replacing that.

For printer 5, it may be the module is failing. Can you try reflashing the wifi firmware or even trying the new wifi beta firmware and see if it has any impact. If the SD card is old there as well, might be worth a change out.

@DariusR4 thats the SD card partition on the SD card in the pi.
What may be the case is that you're running an older version of the pi image that had logging turned on.
It may be worth backing up your config etc and flashing a new version of the image