RRF3 Homing Issues

dc42

@Danal, thanks for that. I'll test it on my bench setup - I don't yet have a luxury of a real printer running Duet 3 due to lack of space, although others in Duet3D do.

gtj0

@dc42 Yes still having problems...

CoreXY
X endstop is actually one of your IR probes (I was testing various types to see if any worked better)
Y endstop is an optical interrupter.
Z endstop is a piezo Orion.

No stall detection.

Individual axes will home ok IF the axis doesn't have to travel far for the first move. I.E. If the X axis is at +10 it will home OK. If it's at +50, the initial move (coarse) will complete but the fine move won't and the axis will be left in an unhomed state. Same for Y and Z. If I add an M400 after the coarse move, it increases the chance that the homing will complete but there's still about a 10% failure rate. If I add an M400 after every move in the macro, it's about 99% successful. However, about 10% of the time (even when homing is successful), either X or Y will be left at some position between -1.0 and +1.0 but not equal to 0.0.

homex.g
homey.g
homez.g

I also have a homexy.g that homes both X and Y together but oddly enough, I don't need to do the M400's. Maybe because it's executed as a generic macro not a special homing file? This got me thinking so I ran my homex.g and homey.g files as macros with M98 and without the M400s and sure enough they worked fine.

homexy.g

As for homeall.g, when it simply runs homexy.g and homez.g with M98, it works fine. If I copy all the raw GCode commands into homeall.g, I need copious M400s.

homeall.g

dc42

@Danal, is your machine a Cartesian, CoreXY, or something else? What is the purpose of the final G1 command in homex.g? The X axis should be at X=0 already.

@gtj0, thanks. The only difference I am aware of between sending G28 X vs. running homex.g is that G28 flags the axes as unhomed to start with. So for a fair comparison, use M18 or M84 to turn the motors off (which flags the axes as not homed) before running a homing file using M98.

M400 commands should have no effect after G1 H1 or G1 H2 commands, because those G1 commands force a stop after they are executed already.

gtj0

@dc42 OK here's some more info... It appears it fails only when run from DWC.
@chrishamm Is there some timeout that may cause the homing sequences to be aborted?

Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Processing G28 X
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Sent G28 X, remaining space 740 (4068 total), needed 28
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Executing nested macro file '/opt/dsf/sd/sys/homex.g' on channel HTTP
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Processing ; homex.g
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Processing G91
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Processing G1 H1 X-500 F6000
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Processing G1 X4 F600
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Processing G1 H1 X-10
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Processing G1 H2 Z-2 F200
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Processing G1 H2 Z2 F200
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Completed ; homex.g
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Sent G91, remaining space 748 (4076 total), needed 20
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Sent G1 H2 Z2 F200, remaining space 704 (4032 total), needed 44
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Sent G1 H1 X-500 F6000, remaining space 660 (3988 total), needed 44
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Sent G1 X4 F600, remaining space 624 (3952 total), needed 36
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Sent G1 H1 X-10, remaining space 588 (3916 total), needed 36
Oct 29 10:40:01 duet3j.f5.int DuetControlServer[24860]: [info] Sent G1 H2 Z-2 F200, remaining space 544 (3872 total), needed 44
Oct 29 10:40:02 duet3j.f5.int DuetControlServer[24860]: [info] Completed G91
Oct 29 10:40:02 duet3j.f5.int DuetControlServer[24860]: [info] Completed G1 H2 Z2 F200
Oct 29 10:40:05 duet3j.f5.int DuetControlServer[24860]: [info] Received file abort request on channel HTTP for all files
Oct 29 10:40:05 duet3j.f5.int DuetControlServer[24860]: [info] Aborted macro file '/opt/dsf/sd/sys/homex.g'
Oct 29 10:40:05 duet3j.f5.int DuetControlServer[24860]: [info] Completed G1 H1 X-500 F6000
Oct 29 10:40:05 duet3j.f5.int DuetControlServer[24860]: [info] Cancelled G1 H1 X-10
Oct 29 10:40:05 duet3j.f5.int DuetControlServer[24860]: [info] Completed G1 H1 X-10
Oct 29 10:40:05 duet3j.f5.int DuetControlServer[24860]: [info] Cancelled G1 X4 F600
Oct 29 10:40:05 duet3j.f5.int DuetControlServer[24860]: [info] Completed G1 X4 F600
Oct 29 10:40:05 duet3j.f5.int DuetControlServer[24860]: [info] Cancelled G1 H2 Z-2 F200
Oct 29 10:40:05 duet3j.f5.int DuetControlServer[24860]: [info] Completed G1 H2 Z-2 F200
Oct 29 10:40:05 duet3j.f5.int DuetControlServer[24860]: [info] Completed G28 X
Oct 29 10:40:05 duet3j.f5.int DuetControlServer[24860]: [err] G0/G1: insufficient axes homed

If I run "G28 X" from the DSF CodeConsole, it works every time without the M400s.

gtj0

OK so my homexy macro fails 100% of the time if either X or Y is marked as unhomed.
So It's back to homing individually.

And now I'm thoroughly confused. I just tried this from CodeConsole

G1 X150 Y410 Z10
G28

and got this...

Oct 29 11:09:07 duet3j.f5.int DuetControlServer[24860]: [info] Sent G1 H2 Z-2 F200, remaining space 544 (3872 total), needed 44
Oct 29 11:09:07 duet3j.f5.int DuetControlServer[24860]: [info] Completed G91
Oct 29 11:09:08 duet3j.f5.int DuetControlServer[24860]: [info] Completed G1 H2 Z2 F200
Oct 29 11:09:28 duet3j.f5.int DuetControlServer[24860]: [info] Received file abort request on channel SPI for all files
Oct 29 11:09:28 duet3j.f5.int DuetControlServer[24860]: [info] Aborted macro file '/opt/dsf/sd/sys/homey.g'

homez.g
homey.g
homexy.g
homex.g
homeall.g

Danal

@dc42 said in RRF3 Homing Issues:

@Danal, is your machine a Cartesian, CoreXY, or something else? What is the purpose of the final G1 command in homex.g? The X axis should be at X=0 already.

This one is a Core XY on Duet 3 6HC and software releases shown above.

The final G1 command is because the axis is defined as -5:305. Therefore, the switch is at -5.

Iif not for that final command, X would be sitting at X-5 when the G1 X-10 F600 H1 finishes. Example (already sorted to be readable top down):

10/29/2019, 12:17:19 PM	G1 X15
10/29/2019, 12:17:36 PM	G1 X-100 F600 H1
10/29/2019, 12:18:13 PM	M114
X:-5.000 

10/29/2019, 12:18:22 PM	G1 X0
10/29/2019, 12:18:28 PM	M114
X:0.000

fma

A temporary workaround for the G1 issue is to add H2 to the back off commands...

dc42

I have reproduced the following problem: If I try to home X with the X endstop initially not triggered, it mostly works. If I try to home X with the X endstop triggered at the start, it mostly fails with "Error: insufficient axes homed".

If I reconfigure the machine as a Cartesian, it works every time whether or not the endstop is triggered initially.

dc42

I think I've now found the cause - and a workaround. When preparing for the G1 H1 move, the code isn't waiting for the previous move to complete before priming the endstops. It works if I change homex.g to this:

; homex.g
G91
G1 H2 Z2 F200
M400     ; <========= added
G1 H1 X-500 F6000
G1 X4 F600
G1 H1 X-10
G1 H2 Z-2 F200

A similar change will be needed to homey.g.

I'll fix this in the next build.

dc42

I've put new RRF3 binaries at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. The problem was wider than I originally thought, so the workaround I suggested earlier can't be guaranteed to work always. Please try the new firmware.

Danal

Board: Duet 3 MB6HC (MB6HC)
Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.0beta11+1 (2019-10-30b3)

This does seem to have fixed it. My previous test case, "G1 X-5" followed by "G28 X" now works. Also, "home all" was failing on x quite a bit of the time, and it now runs over and over, cleanly.

gtj0

@dc42 said in RRF3 Homing Issues:

I've put new RRF3 binaries at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. The problem was wider than I originally thought, so the workaround I suggested earlier can't be guaranteed to work always. Please try the new firmware.

@dc42 Are those changes all pushed to github?

dc42

@gtj0 said in RRF3 Homing Issues:

@dc42 said in RRF3 Homing Issues:

I've put new RRF3 binaries at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. The problem was wider than I originally thought, so the workaround I suggested earlier can't be guaranteed to work always. Please try the new firmware.

@dc42 Are those changes all pushed to github?

yes.

dc42

@Danal said in RRF3 Homing Issues:

Board: Duet 3 MB6HC (MB6HC)
Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.0beta11+1 (2019-10-30b3)

This does seem to have fixed it. My previous test case, "G1 X-5" followed by "G28 X" now works. Also, "home all" was failing on x quite a bit of the time, and it now runs over and over, cleanly.

Thanks for the confirmation.

dc42

@dc42 said in RRF3 Homing Issues:

@gtj0 said in RRF3 Homing Issues:

@dc42 said in RRF3 Homing Issues:

I've put new RRF3 binaries at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. The problem was wider than I originally thought, so the workaround I suggested earlier can't be guaranteed to work always. Please try the new firmware.

@dc42 Are those changes all pushed to github?

yes.

PS- if you haven't built RRF for a while, be sure to pick up the changes in CoreNG, FreeRTOS and RRFlibraries projects too.

gtj0

@dc42 said in RRF3 Homing Issues:

@dc42 said in RRF3 Homing Issues:

@gtj0 said in RRF3 Homing Issues:

@dc42 said in RRF3 Homing Issues:

I've put new RRF3 binaries at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. The problem was wider than I originally thought, so the workaround I suggested earlier can't be guaranteed to work always. Please try the new firmware.

@dc42 Are those changes all pushed to github?

yes.

PS- if you haven't built RRF for a while, be sure to pick up the changes in CoreNG, FreeRTOS and RRFlibraries projects too.

Yeah I've been keeping up and I can confirm that the fixes fixed the homing issues!

dc42

Thanks, I'll mark this as solved.

Nuramori

This post is deleted!