On 04/08/2017 01:38 PM, Kurt Jacobson wrote: > Thats interesting. I am currently trying to overhaul my custom UI to > support joins/axes. I have got most of it converted by am having trouble > with the homing indicators, thats why I was looking at that code, but it > turns out that the code is not used any longer. I better do some more > reading.
If i recall correctly, we decided that after the big Joints/Axes cleanup, homing should be handled this way: Joints can be homed or unhomed. You can ask LinuxCNC to home an unhomed joint, or to home all joints together (according to their [JOINT_*]HOME_SEQUENCE). If any joint is unhomed, the whole machine is considered unhomed. If all joints are homed, the whole machine is considered homed. If the whole machine is unhomed, the Motion controller must be in Free mode: http://linuxcnc.org/docs/devel/html/code/code-notes.html#_free If the whole machine is homed, Motion may be in any of the three modes (Free, Teleop, and Coord): http://linuxcnc.org/docs/devel/html/code/code-notes.html#_free http://linuxcnc.org/docs/devel/html/code/code-notes.html#_teleop http://linuxcnc.org/docs/devel/html/code/code-notes.html#_coord Dewey, does my hazy memory match all the awesome work you did here? Now, what this means for GUIs I think is this: First, let's sort all possible machines into two categories: the ones with "trivial kinematics" (sometimes called "trivkins") and the ones with "nontrivial kinematics" ("non-trivkins"). On trivkins machines the motion of travel of each joint corresponds to movement along an axis (think of a mill or a lathe), on non-trivkins machines the correspondence between joint movement and axis movement is more complicated (think of a robot arm or a delta printer). Now lets sort the trivkins machines into two categories: the ones where there's a "1 joint equals 1 axis" mapping and the ones where the mapping is more complicated (think of a dual-motor gantry). All three of these categories are represented the same way inside LinuxCNC. Each one has a list of joints, homed or not, and a list of axes, and so on. If a GUI wants to work with all three kinds of machines, it could just treat everything as the hardest-to-handle kind, the non-trivkins machine. When the machine first starts, it's in E-stop, the machine is Off, Motion is in Free mode, and all joints are unhomed. The GUI at this point can display a Free-mode, joint-oriented view of the machine where the joints are shown and the axes are not, and per-joint homing indicators show the joints are all unhomed. The operator can jog the joints individually (not what you want on a gantry!) and request homing. When the final joint finishes homing, Motion automatically switches to Teleop mode. The GUI at this point can switch to a Teleop-mode, axis-oriented view of the machine where the axes are shown and the joints are not shown. Homing indicators in this state are superfluous: the machine *must* be all homed to even be here, by design. This is pretty much what the Axis GUI does on non-trivkins machines, and on trivkins machines that do not have a 1:1 mapping between joints and axes (like gantry machines). On 1:1-mapped trivkins machines Axis takes a different approach, and does not make such a big deal of Free mode at the beginning. Since on 1:1 trivkins machines there *is* a simple mapping between joints and axes, Axis just pretends in Free mode that the joints actually *are* the axes they're mapped to, and make it look that way to the user. Well that got long winded. Hope it helps explain homing indicators somewhat in the brave new Joints/Axes world we live in now. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
