On 04/13/2016 10:25 AM, dan...@austin.rr.com wrote: > Homing is one of the riskier functions. You could Z-down to a touch > plate and not realize the plate's not underneath it at all and go > scrambling to stop it. Having automated process buttons that take > command away from the operator are inherently risky.
Z generally homes upwards (in the safe direction) for this reason. A switch or prox sensor is mounted on the machine and the Z carriage trips it at the top of its range of motion. > My idea would be that you would have to HOLD DOWN the Home Z button > for the process to continue. If you release the button before it's > complete, the axis just stops and it forgets about homing. That sounds like a good safety improvement over homing down without a "dead man switch". Maybe you could implement this with some hal circuitry like this (hal pseudocode): z-home-button-in => halui.joint.2.home (!axis.2.homing || z-home-button-in) => motion.enable Or this alternative, which reads cleaner to me but has the drawback of going through non-realtime halui to abort the home when the user releases the button: z-home-button-in => halui.joint.2.home (axis.2.homing && !z-home-button-in) => halui.abort Maybe that's no big deal, since the USB jog pendant already has a non-realtime hal component driving it. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
