Strange thing happening homing using stall detection.

fcwilt

If this is not the right category please move as needed.

After a very long hiatus I have returned to work on my E3D Motion System printer.

I was looking through the configuration files to see where I left off.

I found a couple of minor problems with the homing files for X and Y and now they seem to home fine using stall detection.

With one small problem.

Every homing of X results in Y being displayed in the DWC as +0.5 from it's previous location.

So, starting with Y=0 and home X, now Y=0.5. Home X again and Y=1.0.

Any ideas why that might be happening?

Thanks much.

Frederick

gloomyandy

@fcwilt I think you will need to post your files for anyone to be able to help.

fcwilt

@gloomyandy

I used information I found on the Duet sites for most of the relevant values.

As I mentioned, homing seems to be working fine EXCEPT for the odd Y axis increment as appears on the DWC. I suppose I could do enough X homing to get the change to be enough so I could measure it with some accuracy to determine if it is an actual change or just a displayed change.

Here are the relevant parts of config.g

; === X Y ===

M92  X100   Y100   ; steps per mm (80 for 20 tooth, 100 for 16 tooth)
M350 X16    Y16 I1 ; 16x micro-stepping with interpolation

M203 X35000 Y35000 ; max speed (mm/min) 
M201 X2000  Y2000  ; acceleration (mm/s^2) 
M566 X300   Y300   ; max instant speed change (jerk) (mm/min)
M906 X1600  Y1600  ; motor current (mA) (stepper rating 2A) 

M574 X1 S3             ; configure Xmin using stall detection
M574 Y1 S3             ; configure Ymin using stall detection

; this line also appeared in the homing files - I kept them as I found them.

M915 X Y S3 F0 H200 R0 ; set X & Y sensitivity (S), do nothing when stall (R), unfiltered (F) minimum motor full steps per second for stall detection to be considered reliable (H)

Here is homeX.g - this is based on an example I found - with a change to how the logical/physical positions are synced

G91                      ; relative positioning
G1 H2 X0.5 Y-0.5 F10000  ; tiny moves to energize motors to ensure they are not stalled
M400                     ; wait for any moves to complete
M913 X31 Y31             ; drop motor currents to 25% of 2000mA or 31% of 1600mA yielding 500mA
M915 X Y S3 F0 H200 R0   ; (S) set X and Y to sensitivity 3 (F) unfiltered (R) do nothing on stall
G1 H1 X-400 F3000        ; move left 400mm, stalling at the physical endstop (end of travel) - we hope
G1 X185 F2000            ; backoff to center of bed - move determined by testing
G92 X0                   ; sync physical and logical positions
M400                     ; wait for any moves to complete
M913 X100 Y100           ; motor currents back to 100%
G90                      ; absolute positioning

Here is all of homeY.g - this is based on an example I found - with a change to how the logical/physical positions are synced

G91                      ; relative positioning
G1 H2 X0.5 Y-0.5 F10000  ; tiny moves to energize motors to ensure they are not stalled
M400                     ; wait for any moves to complete
M913 X31 Y31             ; drop motor currents to 25% of 2000mA or 31% of 1600mA yielding 500mA
M915 X Y S3 F0 H200 R0   ; (S) set X and Y to sensitivity 3 (F) unfiltered (R) do nothing on stall
G1 H1 Y-300 F3000        ; move to the front, stalling at the physical endstop (adjustable studs) - we hope
G1 Y120 F2000            ; backoff to center of bed - move determined by testing
G92 Y0                   ; sync physical and logical positions
M400                     ; wait for any moves to complete
M913 X100 Y100           ; motor currents back to 100%

jay_s_uk

@fcwilt its probably that G1 H2 move at the beginning of your homing file

dc42

@jay_s_uk said in Strange thing happening homing using stall detection.:

@fcwilt its probably that G1 H2 move at the beginning of your homing file

Well spotted! @fcwilt you are using the same G1 H2 move in both homex.g and homey.g:

G1 H2 X0.5 Y-0.5 F10000 ; tiny moves to energized motors to ensure they are not stalled

G1 H2 moves are raw motor moves. From https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_coreXY#testing-motor-movement:

For a CoreXY or H-Bot machine, RepRapFirmware assumes that the motor connected to the X motor output moves the head in the +X and +Y directions when it runs forwards, and that the Y motor moves the head in +X and -Y directions when it runs forwards.

So that G1 H2 move will change the Y position but not the X position. In your homex.g file you want to move X but not Y, so use this instead:

G1 H2 X0.5 Y0.5 F10000 ; tiny moves to energized motors to ensure they are not stalled

fcwilt

@dc42 @jay_s_uk

Thanks very much to you both.

I appear to have overlooked the obvious - once again.

Frederick

fcwilt

@dc42

Sorry to bother you but I'm trying to understand the reason for the G1 H2 moves.

I saw the comment about being sure the motors are not stalled - that is clear.

But what does the G1 H2 approach achieve that the following wouldn't (just talking X axis here)

G1 H1 X0.5

or

M564 H0 
G1 X0.5 
M564 H1

As I understand it the G1 H2 allows movement when the axis is not homed, which I believe my two examples also achieve.

But does the G1 H2 do something unique that the others I listed don't do.

Thanks for the education.

Frederick

dc42

@fcwilt I think both of those would work too.