RepRapFirmware 3.0beta 11 released

JoergS5

This post is deleted!

JoergS5

If G1 X325 Y325 F1800 H1 reaches X immediately, M208 defines X/Y position as 302/305, but in reality Y may be at -100. So it will not reach the endstop with the following Y move, even when the first line reached an endstop. So better 500 for the following two lines also.

fma

The min values are wrong; I didn't noticed it because I home on max values. Anyway, total travel for X and Y is < 325mm, so the endstops are always reached (I'm using relative positionning). And in my tests, I'm close to the max positions, so carriage travels only a few mm before hitting the endstops.

And it was working fine with 2.02/2.03 firmwares; I just changed the S param to H param in the G1 moves.

fma

I confirm it is totally random.

Say I'm on the max position, both endstops X/Y activated. If I hit the homing button several times, I can see the machine homing X then fail, or Y, the fail, or none, or successfully home all axis.

But I find a workaround: I changed

G1 X-5 Y-5 F6000       ; move away from the endstops

to

G1 X-5 Y-5 F6000 H2    ; move away from the endstops

and it now works fine. If it can helps to find the problem...

Danal

This may or may not be related, I didn't completely follow all above... if it helps:

I have noticed that RepRap 3 on Duet 3 hardware gets "stuck" if the endstop is already triggered (physically) when a G28 is issued. Stuck meaning it won't successfully show as homed, and therefore won't G0/G1 (to move off the switch). Just won't move at all.

I've had to either manually back it off (forcing the steppers) or add something like an M564 (to allow unhomed movement) and a G0 back off of a millimeter or two (and then turn M564 back to normal), or similar, to my home... files. Of course, this back off would be problematic if the axis happened to be a physical max when the home... file was invoked.

Anyway, one of those two things is required to get that axis to move again. Not even a reboot will help.

fma

I though it was the case here, but even when I was not on the endstops, the problem occured (again, not all the time). And I was able to successfully homed even when starting from endstops position.

With the H2 param added on the mov away, it works all the time.

Danal

@fma said in RepRapFirmware 3.0beta 11 released:

I was able to successfully homed even when starting from endstops position.

Interesting. Mine fails every time when already triggered.

Board: Duet 3 version v0.6 (MB6HC)
Firmware: RepRapFirmware for Duet 3 v0.6 3.0beta11 (2019-10-22b1)

fma

I'm using a Duet2...

Danal

@fma said in RepRapFirmware 3.0beta 11 released:

I'm using a Duet2...

Aha! Yes, I am on 3 HW (and of course SW). Therefore, my data point not relevant at all.

gtj0

One other thing to try is adding M400's to your homing scripts to make sure that
moves finish before the start of the next move or the macro finishes.

fma

Ok, but the problem occurs inside the homexy.g macro. I will try to add M400 before moving back...

gtj0

@fma said in RepRapFirmware 3.0beta 11 released:

Ok, but the problem occurs inside the homexy.g macro. I will try to add M400 before moving back...

Yeah I understand that. The issue I was having (and still do to some extent) was that the moves to home both axes weren't actually finishing before the macro execution ended. When macro ends, it resets state so it was doing that before the moves completed and left things in a very weird and unpredictable state. The M400's inside the homing files helped (but haven't sovled the issue completely).

fma

I tried to add M400, but it didn't help...