this branch is now rebased on top of joints_axes4, a linear 18 commits. No surprises or conflicts. Comments as per below apply unchanged.
Please give this a try. The more I play with this, the more I think jog velocity should be a standalone immediate command so motion has the notion of 'current jog velocity'; and actual jog commands just carry the action, but not velocity. Besides being more robust, this would allow jog velocity without stopping the jog per se. - Michael Am 11.10.2013 um 11:31 schrieb Michael Haberler <[email protected]>: > I rebased and cleaned the jwp work onto joints_axes3 with no surprises > (thanks, Seb!) > > http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/keyboard-jog-while-pause-joints-axes3 > an ubc3 merge without surprises is here: > http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/keyboard-jog-while-pause-joints-axes3-ubc3 > > this is now good for actually trying out and review, I found it robust so far. > > test config: configs/sim/axis/ja3-jog-while-paused-rdelta.ini (x,z touchoff > required) > > there are beginnings of documentation in the motion manpage. > the motion.jog-while-paused-enable must be set for jwp to work. > the last commit needs to be reverted, I didnt apply or try Jeff's axis patch > yet > the HAL pin jog support is gone > scripts for experimentation with unmodified UI's are in > emc/motion/jwp-python-examples > I suggest to run emc/motion/jwp-python-examples/trackjogs.py , pause and jog > around; this gives a pretty good idea how the pause state machine works. > > the following areas need consideration: > > - limit override on jog (nothing there) > - motion/command.c:find_jog_endpoint() is.. unorthodox but robust; it finds a > valid jog endpoint both within joint or axis limits. Maybe there is a better > way. > - the reentry move is done at the last jog velocity > > general observations: > > I dont see a good reason to limit a jog to a single axis (or joint for that > matter). Why not diagonal if two axes/joints? > The EMC_JOG_* messages do not discriminate mode, i.e. it can mean a joint or > axis jog depending on motion mode. > > Currently motion has no idea of current jog vel, which requires a hack - > using the last jog vel for the return move. This is potentially troublesome > here: user jogs fast, stops, reduces jog speed, hits step or resume for 'slow > reentry', but the reentry will still be fast. > > Separating changes of jog velocity from the actual jog command might make > sense. However, this will impact the API, in particular the braindead usage > of a positive increment combined with a negative velocity if doing a > 'decrement jog'. > > - Michael > > > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
