Homeing order change?

Chriss

Hi *,

I play with my corexy from a a bit and search for the best location of the endstops now. (Yes, I will get rid of the stall detection now).

So both switches will be at the X max and Y min (button right corner). I have now the problem that Y needs to be homed before I can home X. But the wen interface have the dependency that X needs to be homed before Y.

Is there any way to reverse that order?

Cheers, Chriss

PDBeal

Edit your homeall.g, to make it home Y before X. Something similar to what's below should work.

; homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool v3.1.3 on Tue Jun 23 2020 13:15:28 GMT-0400 (Eastern Daylight Time)
G91                    ; relative positioning
G1 H2 Z5 F6000         ; lift Z relative to current position

G1 H1 Y-215            ; home Y axis
G1 Y5 F6000            ; go back a few mm
G1 H1 Y-215            ; then move slowly to Y axis endstop

G1 H1 X235             ; home X axis
G1 X-5 F6000           ; go back a few mm
G1 H1 X235 F360        ; move slowly to X axis endstop once more (second pass)

G90                    ; absolute positioning
G1 X15 Y15 F6000       ; go to first bed probe point and home Z
G30                    ; home Z by probing the bed

; Uncomment the following lines to lift Z after probing
;G91                   ; relative positioning
;G1 Z5 F100            ; lift Z relative to current position
;G90                   ; absolute positioning

The above file will home Y before it goes to home X. You'll have to adjust your bed size parameters accordingly, but anything's possible with the homeall.g file.

If you need Y home before you home X at all times, you'd have to put something in your homex.g file.

Chriss

@PDBeal

I understand what you mean. So you simply do a "home y" before you do the actual "home x". I thought about that too, isn't that more a "hack" than a "changing the order/dependencies"?

I will try that, very pragmatic, solution, just in case that there is no solution to change the the "order".

Thanks....

Cheers, Chriss

PDBeal

As far as I know, there is no order dependency apart from X and Y have to be homed before you can probe with Z. (Even that may be a wrong assumption if you just called a G30 no matter if X and Y was homed or not. I've never tried that.)

You can make it do whatever order you like in your homeall.g file, and specify your own order.

As far as stopping homing X without homing Y, you could put

G91 ; relative positioning
G1 Y1
G90 ; absolute positioning

into your homex.g file or some standard Y axis movement at the start of your homex.g file. If your Y axis isn't home'd, you'd get a fault for "insufficient axis homed" which would prevent X from homing if Y isn't done first. I would consider this more of a hack than customizing the homeall.g file.

Chriss

@PDBeal said in Homeing order change?:

As far as I know, there is no order dependency apart from X and Y have to be homed before you can probe with Z.

I think I was not clear enough. There is a order, at least in the web ui. You get the message "insufficient axis homed" if you click on "HOME Y" with a "orange" "HOME X" button. My idea was to reverse exactly this order.

I understand that you rever the the homeall.g all the time, that is understandable from the point of a working printer. I do the initial setup, so it is a very convenient way to create smooth working homeX|Y|Z.g files before compiling the homeall.g.

So long story short, we do not have to create doctoral thesis here. I will do a full "home y" in the "homex.g" to make sure that I can hit the switch when I do the actual "home y". That is not very nice but it will work and is the pragmatic way.

And I have to do the "home y" anyway.

Cheers, Chriss

PDBeal

@Chriss said in Homeing order change?:

I think I was not clear enough. There is a order, at least in the web ui. You get the message "insufficient axis homed" if you click on "HOME Y" with a "orange" "HOME X" button. My idea was to reverse exactly this order.

I'll have to check my systems, but I could have sworn I've homed Y without homing X. Especially when I'm only interested in moving Y for some reason. I'm pretty sure I've done it from the PanelDue too.

You've peeked my curiosity now, I'll have to try it out again and see if it demonstrates the same behavior you mention.

deckingman

You should be able to (in fact "can") home any axis in any order. The most common reason for getting an "insufficient axis homed" message when homing X or Y is that the first command lifts the nozzle in relation to the bed which is a "Z" move. This Z move needs to have the appropriate "H" parameter (H2 I think) in later firmware or "Sn" in earlier firmware. (Or use M564 H0) to allow moves prior to homing).

Chriss

@deckingman @PDBeal
Bugger.... Deckingman you made my day. There is no "dependency" but I had some old lines in my homey.g which required a homed X.

Sorry, my bad!

Long version:

I used stall detection in the past, I needed to drive the head into the center of y so I had:

G90   		            ; absolute positioning
G1 X225					; Go into the middle for the endstop

I guess you get the rest... Sorry.. my bad.

Cheers, Chriss

Chriss

A bit off topic: Is there a way to call the "homey.g" from inside the "homex.g"?

I'm a so well trained monkey that I always press "HOME X" than "HOME Y" when I home them manually. I'm not sure that I can reprogram me to press "HOME Y" before "HOME X" on the webui.

PDBeal

@Chriss

M98 P"0:/sys/homey.g"

Chriss

@PDBeal

Thank you very much! I will test that tomorrow. I hate redundant code, I will split the movement into single files and execute them than from the home*.g files.