Sensorless Homing oddness

[mhackney]

I read through the wiki and read the posts here on setting up Sensorless Homing on a CoreXY running RRF 1.21 release. I thought I had working it but I am seeing odd sporadic behavior. This machine was running fine with endstop switches but I wanted to try this feature out.

Basically, after a Duet reboot, if I Home All, the carriage moves the wrong way in X (away from X=0 which is at the left on this printer.) However, if I Home X individually, it homes correctly. Then Home Y individually, it homes Y correctly and then if I Home All, that works correctly! Note that if I only Home X but not Y and then Home All, it homes towards +Y and stalls undetected.

If after a successful Home X, Home Y, Home All I attempt to Home All again later, it sometimes works, sometimes goes towards X+.

Here is my config.g:
M574 X1 Y1 S3 ; set endstop to use motor stall

Here is homex.g

; Sensorless Homing for X axis
; BL Touch prep
M280 P3 S160 I1			; alarm release and push-pin up
M402				; retract probe in case its down
 
M400                    	; make sure everything has stopped before we make changes
M913 X50             		; reduce motor current to 50% to prevent belts slipping
M915 X S3 R0 F0			; X sensitivity to 3, do nothing when stall, unfiltered
 
G91                   	 	; use relative positioning
G1 S1 X-270 F4000    		; move to home position
G1 X25 F2000          		; back off to edge of bed
	
G90            			; back to absolute positioning
M913 X100        		; motor currents back to normal

and here is homeall.g

; homeall with BL Touch probe
M400				; make sure everything has stopped moving
M913 X50 Y50
 
; BL Touch prep
M280 P3 S160 I1			; alarm release and push-pin up
G4 S1
M402				; retract probe in case its down
G4 S0.5
 
; home XY for Z homing
G91            			; relative mode
G1 Z5 F200 S2			; lower bed 5mm
G1 S1 X-270 F4000		; home X
G1 S1 Y-270 F4000		; home Y
 
; Z homing
G1 X135 Y135 F4000		; move to bed center
 
; slow down for probing Z
M566 Z10			; max instantaneous speed change (mm/min) (jerk)
M203 Z400			; max speed (mm/min)
M201 Z100			; max acceleration (mm/s^2)
 
; probe
M558 A1 F400			; set single probe at faster feed rate
G30				; probe
M558 A10 F100			; set single probe at slower feed rate (more accurate)
G30				; probe to get a more accurate postion
 
; set normal speeds
M566 Z60			; max instantaneous speed change (mm/min) (jerk)
M203 Z900			; max speed (mm/min)
M201 Z20			; max acceleration (mm/s^2)
 
G90				; back to absolute mode
M400
M913 X100 Y100

Note that I am using a BL Touch for probing and have deployprobe.g defined as:
M280 P3 S10 I1

and retractprobe.g:
M280 P3 S90 I1

[dc42]

You haven't posted your homing files so this is just a guess. If the motors are initially reporting stalled status because they were at standstill then the first G1 S1 move will be terminated immediately. So you may need to insert a short move away from the endstops first. For a CoreXY I think something like G1 S2 X1 Y-1 may work, if both axes home to the low end.

[mhackney]

David, the code above is my homex,g and homeall.g

Both axis do home to the low end - left front corner.

Is there a way to show code in this new forum? I didn't find that feature so my home files are just in line in the post.

[mhackney]

I noticed that there is a 2-3 second delay before it starts a Home All. I don't recall that happening with endstop switches.

[dc42]

I'm sorry, this new forum is a pig to use on a tablet, I can usually see on!y half a line of what I am typing (often I can't see it at all) and none of the message I am replying to. Anyway, moving the head a short distance away from the endstops may fix the problem.

[mhackney]

@dc42 thanks David, I'll give that a shot.

[norbs12]

I've gotten sensorless homing down pretty well.

First off, I've found that just calling your home(x,y,z,).g with a M98 P<filename> from your homeall.g is the best what to go about things. Yes it will take a bit longer but at least you're not editing multiple files.

Example:

G1 Z15 F6000 S2
M98 Phomex.g
M98 Phomey.g
M98 Phomez.g
 
G1 X5 Y5 Z5 F6000

Next for each axis I do a double home. First I'll home an axis then move away from home then home again but slower. This seems to be a bit more reliable because if you're too close to begin with, you can get grinding as well as can be mid acceleration so you can get different results. I also adjust motor current to a constant that doesn't depend on any setting from my config.g. This lets me change motor settings and not break sensorless homing.

Here is an example of how I home X:

; homex.g
; called to home the X axis
M400                    ; make sure everything has stopped before we make changes
 
;Here I set motor settings before homing, it makes sure they are consistent even if I change settings for my motors for regular printing, it wont break my homing (the settings are corrected at the end of homing)
M203 X8000				; Set maximum speeds (mm/min)
M906 X900				; Set motor currents (mA) and motor idle factor in percent
M201 X200				; Set accelerations (mm/s^2)
 
M913 X30		; drop motor currents to 30%
G91			; use relative positioning
G1 S1 X-305  F8000	; move X all the way left and stop at end
G1 X40  F2700	; move X all the way left and stop at end
G92 X50
G1 S1 X-60  F2700	; move X all the way left and stop at end
G90			; back to absolute positioning
M400			; make sure everything has stopped before we reset the motor currents
M913 X100		; motor currents back to 100%
G1 X10			; move to parking point
M98 Pmotorspeeds.g      ;I moved all motor settings from config.g into motorspeeds.g file so that I can set the back to normal after any changes during homing.

[T3P3Tony]

@mhackney said in Sensorless Homing oddness:

David, the code above is my homex,g and homeall.g

Both axis do home to the low end - left front corner.

Is there a way to show code in this new forum? I didn't find that feature so my home files are just in line in the post.

Formatting is done in "Markdown" ( see the compose ?) Link http://commonmark.org/help

Code blocks:

Inline code with backticks

# code block
print '3 backticks or'
print 'indent 4 spaces'

[mhackney]

@dc42, adding the move away from endstops did not work. The behavior appears to be identical.

[mhackney]

@norbs12 and @dc42 - this is driving me sane!

norbs12, I refactored my homeall.g to call the individual macros per your suggestion. I then ran it 5 times in a row successfully. Went to get a cup of coffee and re-ran when I got back (5 minutes). This time, the printer homed incorrectly to X+ again (just like the original symptom).

When it starts to home, if it moves in the correct direction, homing will complete correctly but for some reason, it wants to home in the wrong direction and that, of course, fails.

[mhackney]

I do see an error in the console:

Error: Attempt to seek on a non-open file.

Here is my firmware install:

Firmware Name:	RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics:	Duet WiFi 1.02 or later
Firmware Version:	1.21 (2018-03-21)
WiFi Server Version:	1.21
Web Interface Version:	1.21-RC4

[mhackney]

I noticed something else, when I run Home X by itself, most of the time it works correctly. But in 6-10 runs, it will also move in the wrong direction and stop the "back off to edge of bed" (see in code) distance. So, the behavior is, none of movement code above that line is run but the G1 X25 F2000 is executed and the carriage moves 25mm in the +X direction on occasion.

; Sensorless Homing for X axis
; BL Touch prep
M280 P3 S160 I1			; alarm release and push-pin up
M402				; retract probe in case its down    
 
M400                    	; make sure everything has stopped before we make changes
M913 X50             		; reduce motor current to 50% to prevent belts slipping
M915 X S3 R0 F0			; X sensitivity to 3, do nothing when stall, unfiltered
 
G91                   	 	; use relative positioning
G1 S1 X-270 F4000    		; move to home position
G1 X25 F2000          		; back off to edge of bed
	
G90            			; back to absolute positioning
M913 X100        		; motor currents back to normal

[mhackney]

Here's a CoreXY question! In my homex.g script above, I reduce the current for the X stepper. However, CoreXY movements in X use both the X and Y steppers. The M913 command sets motor current % for the MOTOR not the axis, correct? So all of us with CoreXYs need to reduce current on both X and Y motors when we use senseless homing. I'll try this now. Don't think it will affect my issue but I think this is the correct configuration for CoreXY right?

And this would apply to M915 motor stall detection too wouldn't it.

[mhackney]

Ok, I think I have a handle on things. It required understanding the M913 and M915 behavior - they apply to drives no axes (I had to use the M915 P0:1, the X Y did not provide consistent behavior) AND an issue with my printer. First, code:

Simple homeall execute individual homing scripts

; homeall by executing individual axes homing macros
M98 Phomex.g
M98 Phomey.g
M98 Phomez.g 

homex.g

; home X with BL Touch
 
; Sensorless Homing for X axis
; BL Touch prep
M280 P3 S160 I1			; alarm release and push-pin up
M402				; retract probe in case its down
 
M400                    	; make sure everything has stopped before we make changes
M913 X30 Y30             	; reduce motor current to 50% to prevent belts slipping unfiltered
M915 P0:1 S3 R0 F0
 
G91                   	 	; use relative positioning
G1 S1 X-270 F4000    		; move to home position
G1 X25 F2000          		; back off to edge of bed
	
G90            			; back to absolute positioning
M400
M913 X100 Y100        		; motor currents back to normal

homey.g is the similar to above

homez.g uses BL Touch probe

; BL Touch prep
M280 P3 S160 I1			; alarm release and push-pin up
G4 S1
M402				; retract probe in case its down
G4 S0.5
 
; lower bed for travel
G91				; relative moves
G1 Z5 F200 S2			; lower bed 5mm
 
; move probe into position
G90
G1 X135 Y135 F4000		; move to bed center
 
M400
; slow down for probing
M566 Z10			; max instantaneous speed change (mm/min) (jerk)
M203 Z400			; max speed (mm/min)
M201 Z100			; max acceleration (mm/s^2)
 
; probe
M558 A1 F400			; set single probe at faster feed rate
G30				; probe
M558 A10 F100			; set single probe at slower feed rate (more accurate)
G30				; probe to get a more accurate postion
 
M400
; set normal speeds
M566 Z60			; max instantaneous speed change (mm/min) (jerk)
M203 Z900			; max speed (mm/min)
M201 Z20			; max acceleration (mm/s^2) 

Now for my problem - the X linear rail carriage bearings are horrible and bind slightly. Not noticeable (except the grating noise) at normal current but turning the current down to 30% creates sporadic issues with slight binding.

I have new bearings to pack these carriages and in fact was planning to do that after I got senseless homing working. I'll claim victory (pending any recommendations from @dc42 on the code above) and take the rails off to R&R.

[dc42]

That's correct, M913 and M915 on a CoreXY machine relate to drives not axes.

If an axis sometimes moves the wrong way when homing, then it could be that you have reduced the motor currents too much to overcome friction, and one motor + friction in one axis is driving the other motor backwards.

[mhackney]

Makes sense. I know my Z linear rail carriages are gritty - they occasionally make a grinding noise that "just ain't right".

[klcjr89]

@mhackney How did the LM76 speed demon linear rails work out? Any cons? I want to do a build based around them.

[mhackney]

I like them a lot. I do still need to complete the big CoreXY they are on but I got them moving plus I had them operational on a delta 2 years ago.

[klcjr89]

@mhackney The speed demon guides do seem like a better choice than the Hiwin style, less points of failure and no grit ingestion.

[mhackney]

@klcjr89 the only downside is they do not have a model as compact as a 12mm hiwin