Sorry for the previous post -- having problems with my mouse. Recompiling drivers now...
Anyway, if it were me I would replace at least one of the limit switches with something which has a fine adjustment so that I can get it reasonably close. That said, crossing B(Index + N_Steps_Adj=???) = A(Index + N_Steps_Adj=0) would give you the offset between them. So, you could move both axes until you hit both Index marks and figure out the offset as part of the setup and calibration. If the Index is on a rotor encoder (ie gives you an index tick every XXX steps), then moving until you hit the first of the limits and use the above to check they are still in adjustment. In that case A_N_Steps_Adj is no longer 0. Also, if you use either limit, then the other will function as a backup in the case that you have a failure. Also if (A_adj - B_adj) is off my more than some amount you can trigger a warning to force a fisical calibration. Anyway, that is my 2c On Jun 25 2015 7:28 PM, Curtis Dutton wrote: > I remember reading some discussions about the gantry homing issue. > For me > my gantry is flexible enough just to have each joint home > simutaneously > with just a little bit of racking. I home with a limit switches and > indexes. But there is definitly some slight racking that occurs > before the > post-homing positions are reached. > > What do you imagine would be the proper way in which to home without > racking. > > Because it is very difficult to get limits and index positions > identical > there would need to be a limit_switch_offset between the two joints > and or > an index_pulse_offset for each joint as well. > > For my particular case with my gantry, it may look like this. > Probably > exaggerated. > > A ---------------------------------[INDEX]----------------[LIMIT] > > > B > > -------------[INDEX]----------------------------------------------------[LIMIT] > > Ideally both motors would turn at the same rate and work together to > find > each others limits but it would seem impossible in this case for the > lower > joint to ever reach its limit switch assuming the gantry is not > allowed to > rack. > > I think in this case it would be better to use only 1 limit switch > for > homing, and then have the gantry walk back until it hits it's first > index, > remember that location for joint_A, then continue walking until B > finds its > index, at which point they would be synced and could then continue on > to > their "HOME" location simultaneously, which when configured properly > would > not cause racking. > > Probably a similar idea to what has been discussed already. ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
