@tkln I guess, that's not doable right now, but you could try sensorless homing for one of the motors on each tower.

I do not think your ideas help. I tested them but they did not improve anything...

but I found the mistake!

You know....in programming you are often start counting with 0....not with 1. So my x Stepper is not P0.1 but P0.0....

Oh my gosh...works now.

@dc42 Yes, that is what I thought as well.

Do you have any idea why timing is so far off? Like I mentioned above, I successfully tested these motors with the same power supplies and a MKS SGEN controller board with timings of 3:3:6:6. The MKS SGEN board provided 3.3V logic, so if anything I would have assumed it would need more time to activate the opto-isolators due to the underpowered signal.

One concern I have is these motors are supposed to run at a maximum pulse frequency of 250 kHz. Is there a way for me to set that for the Duet board?

@3dyorick Another way of doing it without upgrading or using conditional gcode is add commands to heat the nozzle at the start of your homeZ moves. (That's what I do because I use the nozzle as a probe).

So for example you can have....

T0 ; select tool zero M104 S140; heat to 140 (use whatever temperature you decide on) M116 P0 ; wait for it to reach temperature G1 H1 Z-nnn .....etc

One slight caveat is that if the nozzle is already at say 180 deg C, the above code will wait for the nozzle to cool to 140. So pick an appropriate temperature to sit you usage case. (although it would be unusual to have the hot end heated fully to print temperature before commencing any homing moves).

Ok I will check that, thanks!

Oh ok. Thank you for clearing that up for me. I completely missed that. I will give that a try tonight.

Thanks,

Andy

@gloomyandy OUTPUT.txt

@Phaedrux
Thanks a lot for the help.
I actually went through that tutorial before.. but, now it just works.
Didn't have to change a line and was few hours on that already,
I have no clue what happened... but happy o/

Yes, that's what I have on my Tronxy printer.

It has dual independent Z motors, and I probe via G32 near the screws and it relevels the bed properly.

Nice find, and great that it is working now.

@MauriceM It's fine to leave it if you home Z using G30. But if, by mistake, you try using (or your homing.g files contain) a G1 H1 (ie a homing move) on Z, it will try to use the non-existant endstop, rather than the probe, to home Z, resulting in a crash. Better to remove the chance!

Ian

@Danal said in Homing procedure in firmware:

Yeah, to repeat: Homing is absolutely critical for Delta/Kossel. It directly sets nozzle-to-bed at Z0. And it needs to set it accurately enough to get a good first layer. Most homing (switches) are not anywhere near accurate enough for this.

In fact, in my opinion, this has been the #1 barrier to wider adoption of Deltas, that is, getting Z height set initially, and keeping it set to within 1/10 or so of a layer for print after print.

The smart effector largely solves this, because you can probe before every print.

Even with perfect microswitches, you would still need to do a single probe to set the Z=0 height, to allow for the expansion of the frame with temperature.

what i´m asking for is that the mashine finds the bed center itself
I think of it measuring its axis travel dividing it in half and setting that as zero

Unless your printer is changing size, there's no reason to keep on recalculating this each time the printer homes; it just means that each time, especially using sensorless homing that can take up to 4 full motor steps to register, the results may be different. Just set it up once in config.g, and you don't have to worry about it. And homing won't take as long as it only has to go to one end of each axis, not both.

I seem to remember Marlin does have the functionality to have min and max homing, and it works out the axis length from this and the steps per mm, but I don't think it deduces axis home from this other than putting it at the axis minimum, and then offsetting with and M206. And I can't remember offhand the gcodes to do this, or if it's implemented in Duet firmware. The other problem would be that printers are rarely symmetrical in the X and Y axes, so even if you find the centre point for the axis travel, it's unlikely to be over the centre of the bed, so you'll still need an offset.

Ian

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.

(Or alternatively keep the spacing so that acceleration limit will prevent you from reaching too high a velocity)

@phaedrux

Awesome!!!

While my other printers (not CoreXY) have the homing position and the 0,0 origin at the back/right of the printer...front left works for me too, kinda the same thing if you rotate the whole printer 180 degrees.

Following the directions from the link that you gave me determined that my motors were swapped.

Homing now positions the carriage at the rear/left or X0, Y300 which is where it needs to be for Home, sending the carriage to the origin at 0,0 places it at the Front / Left where it needs to be!

Thanks for pointing me in the right direction and helping me sort this out.

J

@dc42

Hello!

Checked what you said and it solved my problem.

For some reason the cables on the endstops were ALL wired incorrectly (and all were different in the way they were connected) so I checked everything with a multi meter and everything is no correct.

Also i needed to set them to normally open instead of normally closed.

Everything is now homing perfectly as it should. On to the next bump!

Thank you for your help!

As @carlosspr says. For stall detection to work, the feed rate in your G1 S1 commands must be at least (60 * m915-h-value / full-steps-per-mm) . If your printer has 80 steps/mm @ x16 microstepping, that's 5 full steps/mm. You are using H200 in M915, so the minimum G1 S1 feed rate would be (200 * 60)/5 = 2400.

Cool, I will try your macros (should be easier for me using just a pen) to see how far off I am from the actual values.

Hi @Gary,
I forgot to upload my solution to this thread, because luckily I've been able to solve it.
It turned out to be simpler then I first assumed. Basically, the error occurred due to another error in the measurements in calibration. This was then stored in the override.g file. I was suspecting that there might have been an error there, but each time I tried deleting it, it was already stored in the machines RAM.
Here is a step by step guide, explaining how I fixed it:

Temporarily delete/comment out the M500 command in the bed.g file. (It causes the machine to store the new values after calibration) Delete the config-override.g file and do an emergency stop of the machine. Restart it, (hopefully there shouldn;t be a config-override.g file) and add the M500 command back in, then perform a delta calibration.

This should have: removed your previously stored values in config-override.g for good --> allowing for new values to replace them, so the printer will home properly.

Also, you don't need the G92 command, it was only a temporary fix