Homing procedure for axis with multiple slaves

Hi all,

I have one axis (let's call it Z) driven by four motors, and I am starting my way to implement it's homing procedure.
The result I want to obtain includes the following steps:
- drive all motors simultaneously to a certain position at full speed (i.e. z = 10)
- drive all motors simultaneously at reduced speed (i.e. 20%) until the first limit switch is triggered
- loop through the rest of the motors and drive them one by one until the respective switch is triggered
- finally, move all the motors simultaneously to position z = 2 and home again (ideally all the switches should now be triggered at the same time)

I'm now starting some experiments and I will post here (hopefully) results and comments.

As I see it, there are two ways to get there:
1) use the same pins for all the motors (step/dir) and use the Enable/Disable pin of each drive to stop it once the switch is triggered (could lead to issues if you were homing a vertical axis and using ballscrews, but it's not my case)
2) assign each motor to an axis and slave them somehow (I am still new to the linuxCnc universe), with the inherent drawback of using 4 axis (out of 9) for just 1 DOF

I will start with strategy number 1.

One possibly relevant comment: the setup I'm using is run through mesa boards 5i25+7i76

If you have previous experience, tips or any advice you would like to share, please do so!

Pietro

if you try to setup multiple spindle heads as Z you shoudt use the spindle component to place the ofset to the given position

the most comen way if this is true you use a Coordinate system for eatch spindle

WHY 4 motors and what are they pulling as it is only one Axis you call

I think you could achieve this using 2.8 with axis and joints.

So one Z axis with 4 joints (=motors) . In the ini file make sure all the joint sequence to be the same :-

HOME = 30 where you want home to be
HOME_OFFSET = 0 use this for final position for each motor switch
HOME_SEARCH_VEL = -50 this is the speed for the search to home
HOME_LATCH_VEL = 1 speed for the latch
HOME_FINAL_VEL = 50 speed to the final home position

HOME_SEQUENCE = -1 make sure all the 4 joints have the same -ve number so that they all home together

HOME_USE_INDEX = False
HOME_IGNORE_LIMITS = True

Clive wrote:

I think you could achieve this using 2.8 with axis and joints.

So one Z axis with 4 joints (=motors) . In the ini file make sure all the joint sequence to be the same :-

HOME = 30 where you want home to be
HOME_OFFSET = 0 use this for final position for each motor switch
HOME_SEARCH_VEL = -50 this is the speed for the search to home
HOME_LATCH_VEL = 1 speed for the latch
HOME_FINAL_VEL = 50 speed to the final home position

HOME_SEQUENCE = -1 make sure all the 4 joints have the same -ve number so that they all home together

HOME_USE_INDEX = False
HOME_IGNORE_LIMITS = True

X 2. but each joint (motor) needs its own home switch. It should be all supported out of the box in V 2.8 and above. But if you had say a gantry machine with 2 motors each side, probably common one home switch to both motors on the same side. That way they should home in unison.

Actually, this will be a bit different to how you describe but it will go something like this.

All joints will have seperate stepgens from your mesa card.
All joints travel at any speed you set until the first joint hits its home switch then wait until the other joints catch up.
Move off the home switches in unison at a slower speed you set
move to the home switches in unison again at your final homing velocity which you set.
Move to the final home position.
You adjust for anything out of square using a HOME_OFFSET in the ini file on each joint and this is accounted for in that move to final home.

See homing configuration in the 2.8 and master docs.

The only thing I found homing at high speed is that the joints need room to almost coast to a stop during homing for maximum accuracy so you need to allow for this when setting your home switch position so you don't hit any limits.

Also once triggered, a home switch must stay triggered all the way to the limits so that if the machine is homed with limit switches triggered, Linuxcnc knows which way to move off the limits before the homing sequence commences.

The only thing I found homing at high speed is that the joints need room to almost coast to a stop during homing for maximum accuracy so you need to allow for this when setting your home switch position so you don't hit any limits.

Rod I think I have to disagree. I have used gantry homing on several machines. the HOME_SEARCH_VEL is there for that reason.
so you don't try to home at max speed..
.

Also once triggered, a home switch must stay triggered all the way to the limits so that if the machine is homed with limit switches triggered, Linuxcnc knows which way to move off the limits before the homing sequence commences.

The HOME_LATCH_VEL with the correct sign will back off the switch and thus be triggered but not active. I don't use any long slides to keep it active
.
I actually started a post in 2013 forum.linuxcnc.org/forum/49-basic-config...with-x-axis-2-joints before this all came into linuxcnc When I look back on it a lot has changed with linuxcnc :)

Hey, thank you all for the replies!

As suggested, I'm trying to upgrade to version 2.8, but I'm encountering some issues.
I added the repo "buildbot.linuxcnc.org/ wheezy 2.8-rt", the updates are found but linuxcnc-dev won't be installed as:
"Depends on python-serial but it is not installable"

Any advises?

It may be because Wheeay is EOL. When a release reaches end of life, Debian moves all of their repositories to archives. If you have not changed apt to point to the Debian archived repositories you will have the same problem installing or updating almost any app. Edit your /etc/apt/sources.list by commenting out all of the old Debian Wheezy repository lines (but not the Linuxcnc ones) and add these.

Clive wrote:

The only thing I found homing at high speed is that the joints need room to almost coast to a stop during homing for maximum accuracy so you need to allow for this when setting your home switch position so you don't hit any limits.

Rod I think I have to disagree. I have used gantry homing on several machines. the HOME_SEARCH_VEL is there for that reason.
so you don't try to home at max speed..
.

Also once triggered, a home switch must stay triggered all the way to the limits so that if the machine is homed with limit switches triggered, Linuxcnc knows which way to move off the limits before the homing sequence commences.

The HOME_LATCH_VEL with the correct sign will back off the switch and thus be triggered but not active. I don't use any long slides to keep it active
.
I actually started a post in 2013 forum.linuxcnc.org/forum/49-basic-config...with-x-axis-2-joints before this all came into linuxcnc When I look back on it a lot has changed with linuxcnc :)

Clive, I did not say home at maximum speed but on a larger table, you don't want to wait forever for it to home. I don't. I do it with a high HOME_SEARCH_VEL. But there is a tradeoff between speed and the distance it coasts.

You are wrong about the keeping active part 100%. If there is an isolated home switch on the axis and you travel left to right when homing everything works fine while you start homing on the left hand side of the switch. If you start homing positioned on the right side of the switch, Linuxcnc will still move left to right and crash into the limits. If the home switch remains active on the right hand side, Linuxcnc knows which way to go to get back to the home switch triggering edge before the homing sequence commences.. There are a number of posts about this on the forum where people have got into grief with this.

You are wrong about the keeping active part 100%. If there is an isolated home switch on the axis and you travel left to right when homing everything works fine while you start homing on the left hand side of the switch. If you start homing positioned on the right side of the switch, Linuxcnc will still move left to right and crash into the limits. If the home switch remains active on the right hand side, Linuxcnc knows which way to go to get back to the home switch triggering edge before the homing sequence commences.. There are a number of posts about this on the forum where people have got into grief with this.

We may be both correct with this. I don't use travelling sensors mine are fixed at each end of travel so the homing routine always knows which direction to go.

I have a feeling you do.