oh you're using the gantry component not the joint axes master branch... never mind. If you were using the joint axes I'd copy you a working config...
JT On 9/5/2016 4:14 PM, Danny Miller wrote: > On 9/5/2016 9:24 AM, John Thornton wrote: >> Sounds like your home switches for the gantry are not connected >> correctly in hal. You do have one switch for each joint right? >> >> JT > Yep my HAL's right there. And I've watched switches-x1 and switches-x2 > on the HAL monitor while I triggered them. They respond. > > At one point I switched the connection for gantry.0.joint.00.home and > gantry.0.joint.01.home, just in case I was using the switch for X1 on > what was actually the drive for X2. It was a good theory, but it didn't > change anything. > > Danny > >> >> >> On 9/5/2016 7:34 AM, Danny Miller wrote: >>> On 9/2/2016 9:45 AM, Charles Steinkuehler wrote: >>>> On 9/1/2016 9:28 PM, dan...@austin.rr.com wrote: >>>>> Well, wait- just rechecked the gantry man page: "When the system is >>>>> homing and a joint home switch activates, the command value sent to >>>>> that joint is "frozen" and the joint offset value is updated >>>>> instead" >>>>> >>>>> It unambiguously DOES say it's per-axis homing, but I saw it stop >>>>> both when X1's limit tripped and X2 never went into seek, and if X2 >>>>> was in front of X1, went over the homing switch with no effect >>>>> until X1 tripped. >>>>> >>>>> Here's what's in my HAL that should be relevant, did I screw >>>>> something up? >>>>> >>>>> loadrt gantry count=1 personality=2 >>>>> net switches-x1 <= hm2_[HOSTMOT2](BOARD).0.gpio.005.in_not >>>>> net switches-x2 <= hm2_[HOSTMOT2](BOARD).0.gpio.003.in_not >>>>> net switches-x1 => gantry.0.joint.00.home >>>>> net switches-x2 => gantry.0.joint.01.home >>>>> net home-x <= gantry.0.home >>>>> net home-x => axis.0.home-sw-in >>>> That looks OK, but it's not enough to verify your HAL file is correct. >>>> >>>> The behavior you describe could happen if the search-vel input is >>>> incorrect, if you're using the limit output instead of the home output >>>> to feed to motion, or if your home switch signals have the wrong >>>> polarity (they should be high if the switch is "tripped"). >>> There is ONLY a homing switch. No limit. >>> >>> Polarity is correct. >>> >>> I didn't have an [Axis3] section at all in my ini, since nothing seemed >>> to use it, all references for axis3 functions go back to axis0. I did >>> copy Axis0 section into an Axis3 though, so search-vel does exist now >>> for axis3. >>> >>> Didn't help. >>> >>> I did see this: when it homes, if X1 is ahead of X2, it stops both on >>> X1. However if X2 is ahead of X1, it ignores BOTH homing switches. It >>> just drives both into the stops and grinds forever. The sensors are far >>> enough from the stops now that there's room to go far enough to pass the >>> switches which does create an awkward case where it may start already >>> past it and grind on the endstop without ever seeing the sensor. >>> >>> Danny >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Emc-users mailing list >>> Emc-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/emc-users >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Emc-users mailing list >> Emc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-users >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
