ries_ is now known as ries
EMC: 03cmorley 07v2.4_branch * r57ac6f7acdf0 10/src/emc/usr_intf/pncconf/pncconf.py: clean up generated HAL file text for jogging signals
EMC: 03cmorley 07v2.4_branch * r7098f4f04396 10/src/emc/usr_intf/pncconf/pncconf.py: change touchy's quillup signalname
EMC: 03cmorley 07v2.4_branch * r65371b9d28e3 10/src/emc/usr_intf/pncconf/pncconf.py: use constants for descibing GUIs. fix Touchy signal names
EMC: 03cmorley 07v2.4_branch * rb8fecffb8c1c 10/src/emc/usr_intf/pncconf/pncconf-help/ (help-extcontrols.txt help-gui.txt): Add info about TOUCHY
EMC: 03cmorley 07v2.4_branch * r16a80ca82e19 10/src/emc/usr_intf/pncconf/pncconf.py: fix error in hal file with default selected-jog-incr
EMC: 03cmorley 07v2.4_branch * r00d512d30841 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): Add Touchy GUI choice. Fix spindle-at-speed code
ries_ is now known as ries
hm, the documentation apparently says that ABC axis motion is accepted during canned cycles but it looks like they're pretty emphatically not
well, accepted but ignored :/
From the sample file, it seems like they are ignored until you exit canned cycle mode?
seems to me that if they're not going to be used by the canned cycle, the line should be rejected altogether
not just make a spooky motion to a different C coordinate after changing to some other motion type
Sorry, I was unclear. I have noidea if they are then acioned after the canned cycle.
What I meant was, you migh (just) be able to accept that G98 G81 X0 Y0 C10 R2 F20 (say) might ignore the C10, but the sample code had the C move on a separate line.
I would expect that if C moves are not valid in a Canned Cycle, then they should at least have a sticky G0 or G1.
wonder what he expects that C word to do!
I have a dim memory of an ngc doc that said ABC are accepted on canned cycles, but they can only respecify the existing position (cause no motion)
ok - now that I have your attention ;)
I have come across an oddity
you mean JT?
(he's not that odd)
he must mean me
if I set the counter mode of the mesa encoder counter to X4 mode - it seems to loose counts.
yeah, couldn't be me
sorry - not that fast ;)
but x4 is the default
so - if I turn my mpg one turn - it might be off by 2
sorry - not X4.
but if I have it in X4 (;)) it counts perfectly each turn
weirdly I'm not seeing an option for x4
to 1 seems to do it.
(bit r/w) counter-mode: Set to False (the default) for Quadrature. Set to True for Step/Dir (in which
case Step is on the A pin and Dir is on the B pin).
that might be why then...
yeah, that parameter is not what you think it is
I just assumed.... funny
I was surprised that mesa could do non-x4
well that explains that.
cradek: how do you handle that?
divide by 4?
yeah, just set the scale accordingly. it's kind of sucky because you get motion between clicks.
too bad every jog wheel in the world is non-x4
non-x4 sounds easy until you start wondering about stuff like how index should work
I don't know if it can be reasonably faked in the driver, or if firmware support is needed to make it work right
it is funny that setting the counter mode made it count almost perfectly 100 counts per rev (vs 400)
cradek: how do you have your encoder hooked in? are you scaling the increments? like for .001 you have .00025?
cradek: are you sure you read encoder counter-mode?
(Bit, RW) Set to False (the default) for Quadrature. Set to True for Up/Down or for single input on Phase A. Can be used for a frequency to velocity converter with a single input on Phase A when set to true.
setp scale.2.gain 0.00025
setp scale.3.gain -0.000125
yep I'm scaling it (for X, the increments are in diameter)
and clockwise moves in, instead of +x (out)
I'd go nuts if it worked opposite a manual lathe
on the mill too:
setp scale.0.gain .00025
net JogIncr touchy.jog.wheel.increment => scale.0.in
but..... if you use ilowpass anyway, can't you just as easily scale it there?
I would think
if you have high accel, ilowpass sure makes the wheel work nicer
otherwise - yes it really CAN move 0.010 and then stop again for each click of the wheel... bangity bangity bangity
(jr can, anyway)
it is pretty smooth right now but we do have pretty low accels at the moment
I have not looked yet - but are there enough pins in axis to use the gui for setting the jog wheel scales and stuff? (instead of having extra buttons and such - or a pyvcp pannel?
(if that made sense)