Sensorless Homing oddness
@dc42, adding the move away from endstops did not work. The behavior appears to be identical.
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.
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
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 last edited by 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.
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
; 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.
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.
Makes sense. I know my Z linear rail carriages are gritty - they occasionally make a grinding noise that "just ain't right".
klcjr89 last edited by
@mhackney How did the LM76 speed demon linear rails work out? Any cons? I want to do a build based around them.
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 last edited by
@mhackney The speed demon guides do seem like a better choice than the Hiwin style, less points of failure and no grit ingestion.
@klcjr89 the only downside is they do not have a model as compact as a 12mm hiwin
klcjr89 last edited by 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.