RRF3 Homing Issues

gtj0

So now I have XY and Z homing OK (kinda).
Occasionally, either X or Y get reported as being slightly off from expected...

dc42

@gtj0 said in RRF3 Homing Issues:

So now I have XY and Z homing OK (kinda).
Occasionally, either X or Y get reported as being slightly off from expected...

What was expected?

gtj0

@dc42 said in RRF3 Homing Issues:

What was expected?

Sorry. @T3P3Tony's homing macros (above) move the tool to X2 Y2 after homing to keep the tool off the endstops so the final position should be X2.0 Y2.0. Sometime's it's a little more than 2 and sometimes a little less.

gtj0

Just a little update on this... I'm finding that the use of M400 and/or nested macros in the homing cycle casues weird issues where moves will complete only partially and leave axes unhomed and the firmware in a permanent "Busy" state. I'm going to try and create some specific failure scenarios this afternoon.

Also, am I imagining this or didn't the firmware used to run home*.g files if the G28 axes matched? For instance, If I call G28 XY didn't the firmware used to automatically call homexy.g instead of homex.g + homey.g?

T3P3Tony

@gtj0 said in RRF3 Homing Issues:

For instance, If I call G28 XY didn't the firmware used to automatically call homexy.g instead of homex.g + homey.g?

If it did its a feature i never heard of. The only combined homing files I know of are homeall and homedelta. That said @dc42 might have snuck the feature in without me noticing

Nuramori

yeah, there's still something up. With beta 11, my gantry decided to just ignore the endstop randomly, and snapped the endstop mount as it plowed through it. ugh.

I'm gonna move to an optical endstop and see if it helps. Mechanical switch checks out - not that, and not the wiring. signal trips properly, as in the lights toggle with the switch action.

dc42

@gtj0, I am working through bugs that have been reported in RRF3. Are you still having trouble when endstops are already triggered when you try to home the printer? If so:

Please try the latest firmware build at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0 and see if it still happens
If it does, please report the type of endstop switch you are using, what type of printer you have (Cartesian, CoreXY etc.), and whether this issue occurs when you home individual axes or only when you homeall. I appreciate that you may have provided some of this information already, but this thread is quite long now.

When using stall detection endstops, it's a known issue that homing will fail if the motor is already flagged as stalled. The remedy is to move each axis a tiny bit away from the endstop before executing the first homing move. One full motor step is enough.

Danal

Running dropbox beta11+1, home (still) fails when axis on switch at time of G28. My X axis is configured to use a physical microswitch, wired NC, and to allow 5mm from switch to 0,0.

M208 X-5:305
M558 P5 C"io3.in" H5 A5 T6000  S0.02

Demonstration of failure:

G28 X
10/29/2019, 10:03:25 AM	G28 X (in green; succeded)
G1 X-5 (also green; this places axis in physical contact with switch)
G28 X
10/29/2019, 10:03:37 AM	Error: G0/G1: insufficient axes homed (in red)
G1 X5
10/29/2019, 10:03:37 AM	G1 X5  (in red)
                        Error: Code has been cancelled

Content of homex.g:

; Home X Axis
G91                     ; Set relative mode
G1 X-330 F6000 H1       ; Big negative move to search for endstop
G1 X4 F600              ; Back off the endstop
G1 X-10 F600 H1         ; Find endstop again slowly
G90                     ; Set absolute mode
G1 X0 F6000

Releases installed:

10/29/2019, 10:01:27 AM	M115 B0
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_VERSION: 3.0beta11+1 ELECTRONICS: Duet 3 MB6HC FIRMWARE_DATE: 2019-10-27b1

10/29/2019, 10:01:23 AM	M115 B1
Board EXP3HC firmware 3.0beta1 2019-10-27b4

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?