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. > > -Curt > > On Thu, Jun 25, 2015 at 3:05 PM, Moses McKnight <mo...@texband.net> > wrote: > >> Hi Curtis, >> >> I think the branch has not seen much activity for a while - everyone >> is >> working >> on other projects. But, I have a definite interest and hope to get >> some >> time to >> look at it soon. >> >> I believe what has been normally happening instead of merging is >> that the >> joints_axisN branch has been duplicated into a new branch named >> joints_axisN+1, >> and that branch is then rebased on master. I'm not sure I >> understand all >> the >> reasoning behind that right now, but someone else can explain I'm >> sure. >> >> I don't know of a list of issues, but one is that there needs to be >> support for >> gantry homing to two home switches. >> >> You might ask on IRC in the #linuxcnc-devel channel as well. >> >> Moses >> >> On 06/25/2015 01:39 PM, Curtis Dutton wrote: >> > I'm not sure why it was not building for myself. >> > >> > Either way I did successfully merge master into joint_axis7 and am >> running >> > without any issues. >> > >> > Is there a list of issues that need fixed with the joint axis >> work? Is it >> > being considered for mainline integration eventually? Is there a >> list of >> > issues here that needs addressed prior to integration? I've tried >> to >> reach >> > out here to see who wants some help with it, but I get >> crickets.... >> > >> > On Thu, Jun 25, 2015 at 12:25 PM, Sebastian Kuzminsky >> <s...@highlab.com> >> > wrote: >> > >> >> On 06/25/2015 08:21 AM, Curtis Dutton wrote: >> >>> Ok so I was able to build and run master correctly. That is >> sorted out! >> >>> >> >>> But the rub is I'm running joints_axis7 since I have a gantry >> machine >> >> with >> >>> dual motors. So I decided to merge master into joints_axis7. >> >> >> >> joints_axes7 builds fine on Wheezy. No merge needed.
------------------------------------------------------------------------------ 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
