@owend @Alex-cr Thanks both for the instructions. Just what I was looking for. I already have a thermistor in the chamber and I'm runing 3.3.

I've been uprgrading my railcore and I was suprised how well it holds heat. 45c chamber with 75c bed temperature.

Hello Everyone

The problem is finally solved!!🙌 🎊

I checked yesterday if the machine compensates the bed deviation correctly with a dial gauge attached to the z-axis. The result was at 3 corners very good (better than 0.02mm). At one corner around 0.05mm.

So I checked again the linear rails from the x-axis. I find out that the rails aren't aligned perfectly to each other. The result was that the bltouch get tilted and the offset isn't consistent over the hole travel length.

I aligned both rails and the issue is gone.

Thanks everyone who was helping me 🙂

@frnknstn I have that G31 in config.g to make sure a G29 doesn't send the bltouch off the bed.

@rjenkinsgb
Yes, is not essential. i didn't realize that you were going on in the other thread and that it is more related to the FW.
With RRF3 I have gotten into the habit of not doing beta FW updates......unless they are absolutely necessary.

@ibash another option is just to use the M569 V parameter to switch the changeover speed between a very low speed and a very high speed. Then there will be no need to turn motors off and re-home, if you homed in stealthChop mode originally. Just pause the print before changing mode.

@ibash Wow! Thank you very much for your detailed explanation. It exceeds my expectations and I believe it sets me in the right direction to tune my delta. By the way and seeing that LDO 0.9 seems to not get along very well with TMC2209, I have ordered 3 OMC 17HM19-2004S1 for replacing them...I will report with my findings

Thanks for setting me straight.

A follow up question regarding our observations when we ran G30 P0 X175 Y175 Z0 from the web interface. We saw no movement, but I expected that the print head would move and probe to "collect" P0.

Seeing this line in the G30 wiki in the "with a P parameter section" makes me see our error.

If a "normal" Z parameter is given instead of -9999 or lower, then the bed is not probed, but instead that value is used as if the Z probe had triggered at that height.

What we actually did with this command was to tell the Duet to set Z=0 to the current Z position of the bed.

What we should have done is G30 P0 X175 Y175 Z-9999*. This would have moved to the probe to the (175,175) and captured the height.

It's tricksy, this gcode business.

I've just finished rebuilding the hot end on to the older smart effector board that came with the Kossel frame.

I've used the exact same parts as I did on the brand new V3 one.
These are the results of the first test G30 S-1 probes, with default sensitivity:

Smart_effector_Sensitivity.jpg

Fantastic!
I think it is safe to say the other one did have a serious problem!
I'll return that in the next few days.

Thanks.

Haha yes I did... I was probably to tired when reading because I can't remember the last paragraph about "Setting up the sys/resurrect-prologue.g file" 🤦
Works like a charm now!

@dc42 Unfortunately, adding a daemon.g file with a loop didn't fix it for me. I have a music macro called from my S3D ending script. If I run the macro while no job is running it works fine. But almost always, at the end of a print, the third note doesn't sound. Not a big deal, but I don't know why it does this.

@engikeneer Thank you, it makes sense!
I got it to probe successfully now. And trying to figure out why it not compensation well. I see the Z motor moving tho. But still a bed corner got squished wide line and another corner is too thin.

@arnold_r_clark
That was it exactly, thank you!

12/19/2021, 2:29:38 PM G32 Leadscrew adjustments made: 0.001 0.005, points used 2, (mean, deviation) before (0.003, 0.001) after (0.000, 0.000) 12/19/2021, 2:29:02 PM G32 Leadscrew adjustments made: 0.008 -0.005, points used 2, (mean, deviation) before (0.002, 0.004) after (-0.000, 0.000) 12/19/2021, 2:28:28 PM G32 Leadscrew adjustments made: 0.015 -0.016, points used 2, (mean, deviation) before (0.001, 0.011) after (-0.000, 0.000) 12/19/2021, 2:27:56 PM G32 Leadscrew adjustments made: -0.023 -0.281, points used 2, (mean, deviation) before (-0.140, 0.089) after (0.000, 0.000)

I had the same problem. My bed is stationary but the XY gantry moves up and down. I have 4 stepper. I went the counterweight route. I melted 4x1 kg lead blocks.

I wanted to use some springs but the strength change with the position in z.

alt text

@typqxq
If I understood it right, the multi-gcode streaming feature has the goal to extend look-ahead and allow better temp control for toolchangers. (mainly switching the heaters ON, before toolchange is due)
I guess, this would also help you with your problem?

Unfortunately it'll be RRF3.5 until we see this feature.

@phaedrux That's the one I used but it is limited to 16 points.
According to the wiki it's possible to have 32 point. My delta is quite large so I thought that running the calibration with more points should be better but maybe 16 is enough? However it's not a big deal to add them manually.

@falkia No probs, obviously change the pin name to that of the Duet 2 should have said that :).

What do you have in your load and unload macros?
What firmware? Share config?

@too said in Z probe Trigger value has no effect:

M558 P5 C"^io4.in" F1500 T12000

You're calling the full M558 line here in homez. I'm not sure, but I think this may be resetting your g31 to default values. If you only want to have two speeds for the G30 it would be easier to simply use two values for F in your M558 in config.g.

Ex: M558 P5 C"^io4.in" F1500:120 T12000

Otherwise, if you just want to alter a value in M558, just call it with the parameter you want to change.

Ex M558 F1500

The other thing that I notice is that your Z motors appear to be spread across the mainboard and expansion.

M584 X0.3 Y0.4 Z0.0:0.1:0.2:1.1

This may run into a limitation in RRF and it would be better to have all Z axis motors on the mainboard where the z probe connects.

https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations#Section_Temporary_limitations

Due to CAN latency the motors connected to expansion boards may slightly overshoot the position at which the endstop or Z probe was triggered. This would not usually matter for an endstop switch, but it does mean that if the Z motor(s) is/are connected to an expansion board then repeated probing with a Z probe (e.g. for mesh bed compensation) is not advisable. This will be fixed in a future release

@phaedrux said in Which emulation to use with PE Slic3r:

@captain_sq said in Which emulation to use with PE Slic3r:

Does the M555 command affect anything at all in this scenario?

No. It's often misunderstood.

Thanks for clarifying that. /T

I have a tool changing system on one of my machines.

In that, I reference and level without a tool loaded, then have Z offset for each tool in the tool configs.

Once set, they should never need changing, or at least until you replace a nozzle.

To calibrate them, I just set the Z at zero in the tool initially, pick it up and measure the height the nozzle touches the bed, then put that value in the tool Z offset; done.
Check it prints OK and adjust the offset fractionally if it's not perfect.

Accurately calibrating the X & Y offsets to be able to do multi-material prints is much harder - I've not done that so far, I'm still doing other tweaks on the machine.