Check out my config.g for my ToolChanger. It is important to note that I am using CAN toolboards, but if you adjust the extruder drive mapping, heater output, and thermistor inputs it might be helpful:

https://github.com/bdtower8/Duet3ToolboardToolChanger/blob/master/sys/config.g

Line numbers that would need to be changed:

40, 61, 62, 66, 67, 71, 72, 76, 77, 83, 86, 89, 92

@droftarts ,I try to reduce it to 16mm / s

Nice find, and great that it is working now.

I've just removed the ^ too and as expected - makes no difference.

Correct setup for analog is

M558 P1 C"zprobe.in" R0.5 H3 F360 T9000 A5 S0.03 ; P1 = Analogue mode G31 X0 Y0 Z-0.1 P530 ; X, Y, Z offsets, P530 = trigger threshold

and for digital:

M558 P8 C"^!zprobe.in" R0.5 H3 F240 T9000 A5 S0.03 ; P8 = Digital mode (unfiltered) G31 X0 Y0 Z-0.1 P100 ; X, Y, Z offsets, P100 = debounce interval

If your probe is inconsistent you could switch to using manual probing (M558 P0) which would prompt you to manually jog the nozzle to touch the bed.

The problem is that without establishing exactly where Z0 touches the bed, you are depending on the endstops to have a perfectly calibrated Z height from the bed surface, which is difficult to do.

Also, if your height map was generated without first accurately defining the bed surface, it can cause an offset to be present when you load it.

I hope that makes sense.

I know you don't want to be messing around with things at times like this. Good luck with the face shield printing.

@DIY-O-Sphere, thanks for reporting this. I have fixed it in the internal build of RRF at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

Wooo Hooo!!! Good find.

The object model DID change. 🙂

Yeah I don't get it either. I'll track it down, thanks!

Might you be in absolute extrusion mode when you run that macro? Try putting M83 at the start of it.

same topic,
I disconnected the SBC for the moment to have a more reliable environment.
hope this will be fixed soon.

Yes Duet3/SBC. No, no deployprobe. It's a Precision Piezo Orion. Even with an empty deployprobe0.g, I'm still left with the nozzle hovering above the bed and the printer in permanent "Busy" state.

@deckingman said in Firmware retraction settings per tool:

@dc42 I'm probably the only person with a mixing hot end and asymmetric Bowden tube lengths which can't easily be made symmetrical. Given how busy you always are, it probably makes no sense to do anything complex or time consuming for a single user. My preference though would be #4. But in any case, let's wait and see what happens in real world testing. It may not be an issue.

Ian, thanks for your feedback. I'll leave the implementation as #2 in RRF 3.01, but there is the option to change it to #4 in a future firmware version. Changing to #3 won't be an option.

Thank you so much! That was it.

@zerspaner_gerd said in New firmware 3.01-RC2 available:

Would have another question
Should you invert the pin on M950 or with M581 S1?

You can do either. I left the S0/S1 parameter options so that you can trigger on both the rising and falling edges of an input.

What happens to the following constellation:

M950 J1 C"!e0stop" M581 P1 T0 S1 C0

S1 triggers on an inactive-to-active transition, which for an inverted pin is a high-to-low transition.

@bondus looking the video, I think at this position the actuators need a lot of force *)because the angle at the hotend is very big, near the singularity. Precision in left-right-direction will be low also. High microstepping means low torque which may explain the 256-128 difference. If you move the hotend further away, it will be more precise imho.

I mean forces.jpg the forces need to be high for a movement from right to left.

At this point, I actually cannot reproduce the failure. I'll keep trying, and if I do, I will try the timeouts.

I redid the wiring that way and it works now. I left both the positive and negative 12cm short.Thank you.

I think passing parameters to M98 is on the to-do list, but interesting workaround while we wait. 👍

Thank you for the M569, that explains that...! I will update.

I will also try the internal build and report back, that will be this evening Central US timezone (about 10 hours from this post)