@Steppenleguan said in Independent dual z axis with endstops - z homing not working:

@knuxvomica no they don´t.
Current state: G28 homing failed , and nothing happens
Before with a homez.g: The axis lifts 5mm, moves down then passes! the endstops and hits my frame when I don´t emergency stop...

As you can see I am using the M564 command to test the axis movements in advance (which works fine) but obviously I don´t have any homing , i.e. no printing possible

M564 H0 ;move without homing

@Phaedrux said in Independent dual z axis with endstops - z homing not working:

Please post your full config.g
Homing Z should be as simple as a G1 H1 Z move to move the z axis such that the endstops are hit.

You need G1 H1 Z-700 at the end of your homeall.g to home the Z axis. The same would be needed in homez.g

@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

Thanks everyone for your input!
I think I got it.
I removed the Z-Probe pin, and it now works completely.
4734c54a-89d9-47e9-8183-dace09afcd7c-image.png

@phaedrux It seems to be working at this moment. I printed the STL that you sent over and seems to be behaving, although I'm still seeing very very slight variations in layer width across the bed, it's good enough for the time being to move forward and work on pinpointing some of these issues in getting my Z=0 datum set correctly.

@Stephen6309 said in z probe offest:

@way2lo2 Not sure, but I do know the firmware won't go below Z0, if you have your M208 set Z minimum to 0.

That's right. So on the first layer the most you can baby step down by is the first layer height.

For best results the probe trigger height must be accurate. Set it at the same point you use for homing. And use that same point for setting Z0 before generating a heightmap or after doing tilt correction.

If you do need to baby step down consistently you can use the amount used to modify the G31 trigger height to make it permanent.

Setting the M208 Z minima to -0.5 would let you go a bit lower, but use that with caution.

Okay, so I did small research and I think all problems are solved. A bit of information, maybe someone else will also struggle with similar problem.

1. Using buck/boost converters near signal wires (like probes) might induce noise and cause problems
2. If you struggle with unstable printer work/your voltage readings (in DWC) vary under load (even if PSU ratings are higher than requirements of your setup) check your PSU in diffrent position (horizontal/vertical), if it makes diffrence you probably have problem with cold solder joints - if you are familiar with soldering and electronics - redo solder joints in your PSU - if not, better not to do it yourself.

I did small research for my printer, decided to do some tests with opened enclosure of PSU to measure some things and noticed, when I test it laying flat, there is no problem (in printer PSU is mounted vertically), as soon as I mount it back, problem occured again.
Decided to redo all solder joints on PCB (I couldn't find anything that looked really suspicious) with special attention for filtering sections, added also some lead-solder. After that I don't have any problems like before.
I think problem is solved.

@dc42 said in PINDA Z-Probe Configuration:

The reading needs to be around 0 when not triggered (no metal under the probe) and 1000 when triggered. Try removing the i1 parameter from your M558 command in config.g.

well, that did the trick. Thanks a lot.

It's not as easy to work with Duet, being used to Marlin for years...

sorry i just realized how the setup is one.

are the switches NO or NC?

i would try to wire them in parallel and use M558 P5

they will need to be connected to the z probe port.

but a construct would allow the printhead to move. this would not be beneficial for the print quality.

Thanks, @oliof !

I got a document today detailing the setup on Duet today from hotends.fr. I will see whether I can extract the pertinent information and add it to the wiki.

If the problem occurs only while the fan is powered (not when it is spinning down), you could try setting Z probe type P9 in your M558 command, as if you were using a bltouch. That will cause the firmware to run deployprobe.g and retractprobe.g for each individual probe move. You could turn the fan off in deployprobe.g and on again in retractprobe.g.

The Smart Effector only "hijacks the fan power" to power the illumination LEDs.

You may also find these wiki pages useful:

https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe#Section_BLTouch
https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probe
https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCartesianPrinter#Section_Homing_Z_using_a_Z_probe

I tested it within several ways, which with bed compensation and it works great.
Thank you to @dc42.

You can mark it as solved.