After homing X and Y, can I auto move to a non 0,0 location?

Switches shared on one input isn't the issue.

I'm trying to determine where the switches are in relation to the table movement so we can make sure that everything moves the correct direction during homing, and if need be move back to a position you want after homing is complete.

See how you go with the position.

Regards shared himing switches, there is a pin joint.n.is_homing ot similar (check man motion).
If you and2 that with your physical limit switch and use the output to your homing input, the non homing joint will ignore the switch input.

Okay, I think a picture will help.

Homing on 0 works, as in the upper diagram.  But it leaves the bed far from me.  In the title of the thread, I asked whether there's a way to automatically move after homing, so that I end up as in the lower diagram.  I haven't yet tested whether simply setting "HOME" to 12, rather than 0, would accomplish this.  That's because since homing (and even rapids, on my mill) are very slow, I'd really rather skip the extra bed travel, and have it home directly to 12, and stayed there.



 

OP-

Thank you, that helps.

Would you like the table to be as close to the operator as possible (max Y) as well as centered on X when the homing routine is complete?  This is how I've configured my moving-table mill.

That would be great -- but I'd also be happy with simply max-X and max-Y.

I've now tested my original homing-at-0 config, with HOME=12, and it does indeed home as usual, and then set the current position to 12. So the question asked in the thread title is answered.

I'd still like to home-at-12, instead.

pgf wrote:

I've now tested my original homing-at-0 config, with HOME=12, and it does indeed home as usual, and then set the current position to 12. So the question asked in the thread title is answered.

I'd still like to home-at-12, instead.
 

If you'd like the table to home all the way to the operator's left (X-max), and your two X limit switches are on the same input, you can change your INI config so that the search direction is positive. I think the following is what you want:

MIN_LIMIT = -0.001
MAX_LIMIT = 12.001
HOME_IS_SHARED = 1
HOME = 12
HOME_OFFSET = 12 
HOME_SEARCH_VEL = .2
HOME_LATCH_VEL = -0.015
HOME_FINAL_VEL = 0
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_SEQUENCE = 2

This will result in an X homing sequence as such:

• Table moves left (searching X-pos) at speed 0.2
• Limit switch reached
• Table moves right (X-neg) until limit switch clears at speed 0.015
• Table stops, homing complete, DRO will be set to "12"

The reason for the "12.001" MAX_LIMIT value is that if you set it the same as HOME, then when you are finished homing the axis will be on the max soft limit.

If you would like the table to finish the sequence in the middle of travel, you can change the above as follows:

HOME = 6
HOME_FINAL_VEL = -.2

Same behavior as above, except after the limit switch is cleared the table will move right (X-neg) to the middle of travel and stop with the DRO at "6"

Similar edits can be made to the Y-axis to have the table finish close to the operator.

Thanks for thinking so hard about this. I appreciate it.

Two things: first, because of how my switches are set up, I believe both HOME_SEARCH_VEL and HOME_LATCH_VEL need to be positive. The backoff movement is added automatically in between them. Second, HOME_FINAL_VEL isn't a signed velocity. I realized that yesterday while trying various combinations. It would probably be better if the homing code threw an error, since it implies a slight misunderstanding of the config, but instead it seems to simply use abs(HOME_FINAL_VAL).

In the end, the difference between what you propose and what I tried yesterday is the value of HOME_OFFSET. That could well make the difference. I'll try it later today.

Thanks again!

If the HOME_SEARCH_VEL and HOME_LATCH_VEL are positive, the axis will move to the switch, back off it, and re-engage it at LATCH_VEL until the signal changes state (again).

If the HOME_LATCH_VEL is negative, the axis will move off the switch and stop as soon as the signal changes state.  No 2nd move back on to the switch, so potentially done slightly faster if your LATCH velocities are really slow.

I think one of the contributing reasons LCNC's homing is so confusing is simply the terminology selected by the developers years ago.  The terms made sense to them, of course, but I think more differentiation in terms would make homing configuration more intuitive.

Such as changing HOME_OFFSET to HOME_SWITCH_LOCATION or similar.

And of course, the current terms make sense to some people so changes would make things confusing to them.  There's no perfect answer when it comes to preferences.

Thank you very much. Homing works just the way I want it now.

I agree completely about naming -- it's very important. I didn't realize HOME_OFFSET was an absolute location until I got this working -- the word "offset" implies "delta" to me, not "location".  

As for the sign of HOME_SEARCH_VEL and HOME_LATCH_VEL, I've decided to try them with different signs, to eliminate the backoff step, as you suggest.  There may be (probably is) a difference between where the switch closes and where it opens, but for my mill I'm sure it won't matter, for homing purposes.

My final X config is this.  Y is identical, except HOME is 0, not 6, to keep the bed at maximum extension toward me.