@Proschi78 Thank you so much !

It seem my problem was about the zoffset of tool 1, but only on firmware issue, i don't understand why, physicly my 2 nozzle a straight, i think this is about the probe offset maybe but the value it's not the same...

Now trying my first print in dual. ;op

Please try sending this command sequence and report back what you get from each

M552 S-1
M552 S0
M552 S1
M997 S1

@dc42 thank you, that was exactly the reason!

It's not really possible to just use someone else's config unless the printer is literally identical. You may be better off going through the config tool and getting a set of config files of your own to work with and going through the commissioning guide to help get it all setup.

https://configtool.reprapfirmware.org/Start

https://docs.duet3d.com/en/How_to_guides/Commissioning

You can still use the config files from others as examples.

The homing moves are controlled by the homex.g homeyg. homez.g and homeall.g macro files in combination with the M574 command in your config.g

You can find the documentation on stall detection and sensorless homing here: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_stall_detection

The heater error means you haven't tuned the heater yet. You need to do this for the bed and hotend heater.

You can get info on heater tuning here: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Heaters_tuning

@T3P3Tony
yes, I think cura is the main source. Playing around with resolution etc in cura with 5.0 is always fine. Also when printing with with very high resolution.
I´m not sure, if I do anything wrong with cura 5.3.
Cura 5.0 is running fine for this project.

@Norder
thank you, gcode style is enabled. I just took a wrong command from youtube ;/ latenight.

I mean in general the printers are working very good since 3.5 - especially closed loop steppers. They make me happy! 🙂

See here: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_stall_detection

@Phaedrux Yes, the problem was there.

For those reading this, I solved it like this:

; homeall.g ; called to home all axes ; ; generated by RepRapFirmware Configuration Tool v3.3.15 on Fri Mar 17 2023 09:18:48 GMT+0100 (Ora standard dell’Europa centrale) G91 ; relative positioning G1 H1 X-395 F3000 ; move quickly to X and stop there (first pass) G1 H1 Y-345 F3000 ; move quickly to Y and stop there (first pass) G1 X5 F1800 ; go back a few mm G1 Y5 F1800 ; go back a few mm G1 H1 X-395 F360 ; move slowly to X and Y axis endstop once more (second pass) G1 H1 Y-345 F360 ; move slowly to X and Y axis endstop once more (second pass) ;G92 X0 Y0 G1 H1 Z410 F1800 ; move Z up until the endstop is triggered G92 Z410 ; set Z position to axis maximum (you may want to adjust this) G1 Z-5 F1800 ; go back a few mm G1 H1 Z410 F1800 ; move slowly to X and Y axis endstop once more (second pass) G92 Z410 ; set Z position to axis maximum (you may want to adjust this) G90 ; absolute position

The single code are then reported in the single axes home files.

@T3P3Tony ill try thank you

@Reine the result is the outcome of the last command.

I wanted to say thank you that solved my extrusion issue. Thank you very much!

@chrishamm That was the issue, when setting the static IP for the printer, it had been set up for a different network originally, then when moved to a different network only the subnet for the static ip for the pi was updated to the 60 and not the router. THANK YOU

See here for reference: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Z_probe_testing

It's assumed that your printer will be using a right handed coordinate system because that's what CAD and slicing software uses.

+X to the right, - X to the left, +Y to the back, -Y to the front.

You should only really be using H2 when you want to move an axis that hasn't been homed. If the axis has been homed (or should have been homed) you should do a normal move. That way if the axis homing has failed for some reason it will give you an error about trying to move an unhomed axis, which is more helpful that forcing a move, and then having it fail the next time you try to move it.

@o_lampe
I could live without "colour mixing" code. It was an interesting feature a few years ago, but who's still using it?

@dc42 Good point, I'll be sure to do that. Thanks.

@Phaedrux thank you! resolved

@biga12 pretty sure the issue was caused because i use a fan output to control an SSR that supplies 120 power to the PSU on the machine so i can have the machine shut itself off after a print to conserve power use and adds a piece of mind i was originally going to set up so some sort of error could shut the machine down in the case or a bad thermistor or something, so when it reboot to flash the firmware it lost power and caused errors in the firmware next time ill lock power on maybe a programming switch or something, idk

@droftarts said in Endstop documentation clarification:

@curtisb1986 on the I/O Mapping tab, you need to choose an I/O connector for the Z axis. For the endstop wiring, I guess your micro switch boards are like the Makerbot Mechanical endstops, so look a little further down the page: https://docs.duet3d.com/User_manual/Connecting_hardware/Sensors_endstops#makerbot-mechanical-endstop-v12

Ian

Yep, there's that simple solution. Maybe I'm too tired lol

Thanks @droftarts

I'd be wary of including any commands that cause motion on startup without at least wrapping it in a M291 prompt that the user has to acknowledge.

Imagine a power loss and restore during a long print. Do you really want it automatically trying to probe the bed with a print still on it?

@Phaedrux
I believe I'm back in business... Thanks