For XY, it's homing the machine coords. For Z, I know touching off the Z and homing the z coord are different, but I never really saw the need to home the Z. It doesn't prevent work table crashing in a manual TC situation. It prevents excessive Z+ that hits the stops, but I have a LOT of Z-height and it never really comes up whether I home or not.
touch-off, whether it's to the table or top of the stock, has to be done every time. Homing the Z might be essential as a part of the XY home. If you just seek XY from the current Z, if someone goofed and didn't lift the Z, it could run the spindle through the stock. If you lift the Z at all to be more foolproof, the Z+ homing switch would be the only spot that makes sense to stop at. So, really I'm looking at a deadman Z-XY home, and a deadman Z touchoff. Danny ---- Sebastian Kuzminsky <s...@highlab.com> wrote: > On 04/13/2016 12:29 PM, dan...@austin.rr.com wrote: > > Z-homing upwards for machine coordinate zeroing doesn't serve a lot > > of point for manual toolchangers. It can't prevent crashing into the > > table because you don't know how far the tool tip is from the nut. > > Zeroing the work coordinates to the table or top of the material is > > essential for almost all ops, though. > > All my machines use manual tool changing, and they all home Z upwards > (away from the table). > > Remember, "homing" means finding the machine's position within the work > envelope (ie, finding the actual machine coordinates of the controlled > point), and "touch-off" means finding the controlled point's position > relative to the work or fixture. They're different operations with > different requirements. > > Homing happens only once, at machine startup (plus each time your joint > motors lose power, if you are using VOLATILE_HOME). > > Touch-off happens once for each tool change and each new setup. > > I'm thinking now that you're asking about touch-off, not homing. > > > >> 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 > > > > I'm not sure I follow these "enable" solutions. I don't want it to > > be NOT enabled for other purposes if the button isn't true. Does NOT > > motion.enable being true render axis.2.homing false, so it will end > > the homing, make homing FALSE, so motion.enable subsequently becomes > > TRUE while the homing button is still FALSE? > > That second line reads like this: > > motion.enable is True if either: > 1. axis.2.homing is False, or > 2. axis.2.homing is True and the z-home button on the pendant is pushed > > Otherwise motion.enable is False. > > > -- > 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
