Sensorless Homing oddness

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

klcjr89

@mhackney True, but I do not see that as a shortcoming if you're designing a printer from scratch. I got a chinese clone speed demon and did a 10,000 cycle gcode test that was approximately 12 miles of movement, they wore out and there was surface rust and grit falling off the rails. The centerline of the three bearings weren't even in the same plane; poor quality!

I did the same gcode cycle test on a genuine LM76 one and there was zero wear!

This was the smallest version and the 3 roller block with one eccentric.