Hello, On the subject of Gmoccapy, I think that a REALLY important modification would be to add a jog wheel mode. This would be a configuration setting that would replace the jog increment buttons with axis selection and scaling buttons for the jog wheel. In my setup, I added five physical lighted buttons for jogging, (X, Y, Z, A, and C). The illuminated (last pressed) button is the current jog axis, and each time the illuminated button is pressed, it changes the wheel scale downward. IE: wheel x 0.01, wheel x 0.001, and wheel x 0.0001. The workflow here is press the desired axis button to move the machine near the desired position, and press again when you are close, and press again to fine tune. I have considered using a tri color led to indicate the jog scale, but I think it would be even better if the area of Gmoccapy that is used for manual jog would display and allow to be set the current jog axis and multiplier. Also, it makes sense to have on-screen axis selection buttons for those people that do not wish to use physical buttons. If this makes sense to anyone, I will code this up and submit it, or if someone else is already thinking about this, let me know and we can share notes.
Also, there needs to be some HAL pins that provide some information on which mode the machine is in. I think it would be really handy to reset the state of the physical jog buttons when the machine is changed out of manual mode. It is also handy to have these pins for the candle as well. To take this another step; I also setup my HAL configuration so that if you press more than axis button at the same time, the jog wheel jogs all of the selected axis. This is very handy when I am working with multiple fixtures. (I sometimes use the A and C axis for multiple rotary tables that are both really C axis tables.) What I would like to have are buttons to reverse the jog direction or enter an arbitrary scale between axis when multiple axis are selected. -Neil Whelchel- On Wed, Jun 22, 2016 at 12:50 PM, Niemand Sonst <[email protected]> wrote: > Hallo Dewey, > > thanks for your very detailed explanation, most of that is known, but I > still do not understand why that have been changed, as it does not > change any behavior, it just makes thinks more difficult for users, used > to have the same INI settings for several updates. > > I have the impression that someone changed that long time ago, maybe > even by mistake and it has just in there. > Sorry for my very slow understanding ;-) > > It means, that I may have to change some more code in gmoccapy files :-( > only because a known standard has changed. > > By the way, have you seen my new branch gmoccapy_JA? > I will inform as soon as it is mergable to JA. I still miss the > modification of the homing and jogging buttons. And find a way to handle > the differnt modes if a user uses Jogwheels or hardware button. > > Norbert > > Am 22.06.2016 um 18:52 schrieb Dewey Garrett: > > The specification of velocities (and accelerations) is > > confusing because of the multitude of ini settings available > > in the [TRAJ], [AXIS_ll], [JOINTS_nn], and [DISPLAY] sections > > of an ini file. Extra complications may occur because the > > interpretation of items in the [DISPLAY] section may be > > GUI-dependent. > > > > Note that default values are silently applied (typically from > > src/emc/nml_intf/emccfg.h) when not otherwise specified and > > the defaults may not be applicable to a given machine. The > > default values seem to be biased to machines with imperial units. > > > >> Imho MAX_VELOCITY is the correct nomination, as a circular > >> move may invoke several axis, is not linear > > The axis letters X,Y,Z typically specify linear coordinates > > and may be limited by trajectory planning according to > > [TRAJ]MAX_LINEAR_VELOCITY. > > > > For instance, in joints_axes branches, the velocity of a gcode > > arc move (g2/g3) using x,y coordinates obeys the F number rate > > OR is limited to the smallest value allowed by: > > > > 1) individual [AXIS_n]MAX_VELOCITY limits > > or > > 2) [TRAJ]MAX_LINEAR_VELOCITY > > or > > 3) feed override setting > > or > > 4) maybe other items i don't know about > > > > The [TRAJ]MAX_LINEAR_VELOCITY applies because a g2/g3 movement > > is for linear coordinates (x,y,z). > > > > If a rotary coordinate (typically A,B,C) is specified with g2 > > or g3, then the rotary travel is coordinated to end when the > > x,y,z motion ends. As noted in the documentation for g2/g3, > > "Lines of this sort are hardly ever programmed" It is more > > common to use inverse feed rate mode (g94) when combining > > linear and rotary moves. > > > > To my knowledge, there is currently no non-gui code that uses > > [TRAJ]MAX_ANGULAR_VELOCITY nor [TRAJ]DEFAULT_ANGULAR_VELOCITY: > > > > $ cd my_git_root/src > > $ find . -iname '*.*c' -exec grep -EH MAX_ANG\|DEFAULT_ANG {} \; > > $ (nil) > > > > The use of [TRAJ]MAX_LINEAR_VELOCITY and [TRAJ]DEFAULT_LINEAR_VELOCITY > > was implemented long ago (cdc073dc6) in the joints_axes branch (I > > suppose) as preparation for future inclusion of trajectory angular > > coordinate settings should support for these be undertaken. > > Accordingly, these future settings would be named > > [TRAJ]MAX_ANGULAR_VELOCITY and [TRAJ]DEFAULT_ANGULAR_VELOCITY. > > > > (Note, some guis do currently use [TRAJ]MAX_ANGULAR_VELOCITY and > > [TRAJ]DEFAULT_ANGULAR_VELOCITY. For instance, the axis gui > > uses these items as candidates for setting jog slider start > > and limiting values.) > > > > ----------------------------------------------------------------- > > I verified some comments above using a simple ngc file: > > #<fcirclerate> = 10000 > > f10000 > > g0x10y0z0a0 > > f#<fcirclerate> > > g2i-10 a100 > > g0x10y0z0 > > m2 > > > > and experimented with settings for #<fcirclerate> and the ini > > settings for [TRAJ]MAX_LINEAR_VELOCITY and [AXIS_nn]MAX_VELOCITY. > > For the ini items, it is convenient to use sim_pin, for example: > > > > $ sim_pin ini.traj_max_velocity \ > > ini.x.max_velocity \ > > ini.y.max_velocity & > > > > (Changes to ini.N.max_velocity values must be made when a > > program is not running) > > > > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
