Back
[00:44:58] <jmkasunich> why do we have both
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingConfigurationsForDevelopmentVersions and
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UPDATING
[00:45:28] <jmkasunich> the latter is more-or-less a duplicate of part 2 of the former
[00:45:33] <SWPadnos> one is 2.0->2.1, the other is 2.1-> TRUNK
[00:45:44] <SWPadnos> at least, according to the titles ...
[00:46:04] <jmkasunich> the former is _both_ 2.1->trunk AND 2.0->2.1
[00:46:07] <SWPadnos> ah
[00:46:32] <jmkasunich> this is just one of many places where the wiki is getting very disorganized
[00:46:32] <SWPadnos> right hand, meet left hand
[00:46:51] <SWPadnos> yep. there should be an index and some de-cruftization
[00:47:28] <jmkasunich> some page names really show a lack of forethought... like "UPDATING"
[00:47:31] <jmkasunich> updating from what to what?
[00:48:10] <SWPadnos> heh
[00:48:26] <jmkasunich> there wre three updating pages (at least)
[00:48:43] <SWPadnos> I'm not sure what "administrative tools" are there (without writing them in perl), so changing page names may be easy or hard
[00:49:02] <SWPadnos> since all links would need to be updated. at least I don't think that's automatic
[00:49:07] <jmkasunich> UPDATING (configs, 2.0->2.1), UpdatingTo2.1 (tells how to update the actual software), and UpdatingConfigurationsForDevelopmentVersions
[00:49:53] <SWPadnos> actually, there's a problem with wikis in general for this kind of support
[00:50:15] <SWPadnos> a wiki pretty much has one version of each page available - the "latest"
[00:50:21] <SWPadnos> we need to have older info as well
[00:51:17] <SWPadnos> it's in there, because there is some versioning support in the wiki code, but it's not easy / possible to get older versions (and search won't turn them up either, I think)
[00:52:15] <jepler> some wikis have tools for finding "wanted pages" (pages linked to that don't exist) and "orphan pages" (pages that are never linked to) but I don't think our wiki does
[00:52:39] <SWPadnos> I'm not sure either
[02:22:55] <cradek> hi all
[02:23:04] <jepler> hi chris
[02:25:49] <cradek> I'm supposed to be testing jogwheel today aren't I
[02:26:03] <jepler> yeah -- get to work
[02:26:17] <cradek> isn't it kind of early in the day to start something like that?
[02:26:33] <jepler> I'm waiting for ingrid's guest to leave so I can go to bed ..
[02:26:37] <jepler> so my answer would be "no"
[02:27:54] <cradek> I slept in the nice breeze about 3-6 this afternoon
[02:28:16] <cradek> I wish I had your discipline to go to bed and get up at consistent times
[02:29:36] <jepler> it hasn't really been working well since the time change
[02:29:57] <cradek> you wouldn't think an hour would make so much difference, but it sure messes with us
[02:30:17] <jmkasunich> it didn't bother me
[02:30:31] <jmkasunich> of course, thats because I never go to bed at the same time two days in a row
[02:30:46] <cradek> jmkasunich: did you see swp's analysis of your jogwheel code? I think he's right
[02:30:58] <jmkasunich> have you tried it?
[02:31:03] <cradek> no, building (slowly) now
[02:32:00] <jmkasunich> maybe he is... if so, changing "stop_dist=max_vel^2 /( 2*maxaccel)" to "stop_dist = max_vel^2/maxaccel" would probably fix it
[02:32:41] <jmkasunich> I bet it works ok as it is though
[02:32:43] <cradek> yes but that's going to be more than you need if you're already moving
[02:32:58] <cradek> I bet the best answer would take into account current velocity
[02:33:35] <jmkasunich> remember - this thing is only supposed to kick in if the wheel is getting ahead of the machine
[02:33:51] <jmkasunich> that should only happen if the machine is at max vel already, and the wheel is going faster
[02:34:39] <jmkasunich> although I guess it could happen if the wheel accels a lot faster than the machine can...
[02:35:08] <jmkasunich> it can't be entirely based on current vel
[02:35:22] <cradek> well if your wheel is set to 1" per count, one count looks like a big accel
[02:35:24] <jmkasunich> if current vel = 0, stop_dist = zero, and you can never command a move
[02:36:27] <SWPadnos> I think you need (current vel -> max )+ (max -> zero) distances (or something like that)
[02:37:01] <SWPadnos> but I'm not sure that part of the code knows the current velocity (I didn't notice any references to it in the diff)
[02:38:58] <jmkasunich> I don't see why you need current->max distance
[02:39:17] <SWPadnos> consider one tick when the jog increment is set to 1"
[02:39:51] <SWPadnos> depending on accel, the actual distance will be clipped to some small value
[02:39:53] <jmkasunich> the idea behind that code is if the wheel stops turning on the very next sample (and never turns again), the machine should start decelling on the very next sample
[02:40:13] <SWPadnos> I suppose so, so this would effectively limit the maximum jog increment
[02:40:34] <jmkasunich> yeah
[02:40:39] <SWPadnos> the trouble is that a higher performance machine will have a lower max jog distance
[02:40:54] <SWPadnos> and it'll be difficult to get to max machine speed
[02:40:59] <jmkasunich> after all, if you want the machine to stop when you stop turning the wheel, a 1" increment that requires a second or more of motion after the click isn't good
[02:41:05] <SWPadnos> since you need half the distance to accel then the other half to decel
[02:41:29] <cradek> it's almost as if the problem isn't well defined :-/
[02:41:39] <SWPadnos> maybe just 2x the value you have in the code now
[02:41:52] <jmkasunich> thats what I said a few lines ago ;-)
[02:42:11] <SWPadnos> heh - so it is :)
[02:43:07] <jmkasunich> its almost enough to make me clear a spot on my desk and get out my stepper test assembly with joghweel
[02:43:15] <SWPadnos> heh
[02:43:19] <jmkasunich> (almost)
[02:43:34] <SWPadnos> I'd stop at step 1: clear a spot on my desk
[02:43:39] <SWPadnos> that's too daunting a task
[02:44:05] <jmkasunich> that would mean moving the nema34 motor that is clamped to the bench... and the gecko..... and the 5i20 breakout board.... and the gecko power supply.....
[02:45:00] <SWPadnos> right. and the last year's worth of receipts, plus some junk mail, plus some useful things
[02:45:05] <cradek> hmm, I'm losing position, wonder if it's a bug or I'm overrunning the parport
[02:45:11] <SWPadnos> but maybe I'd find my soldering tweezers
[02:45:38] <cradek> bug
[02:45:47] <SWPadnos> bummer
[02:45:57] <jmkasunich> losing position how?
[02:46:15] <jmkasunich> you mean display not matching machine? or losing jogwheel counts?
[02:46:20] <cradek> jogscale is .01, I turn a full turn and it moves less than an inch
[02:46:27] <jmkasunich> in velocity mode?
[02:46:33] <cradek> no, I didn't set that
[02:46:39] <jmkasunich> ouch
[02:46:52] <SWPadnos> but MDI G1X1 goes 1 inch?
[02:46:57] <jmkasunich> did it woek before?
[02:47:16] <cradek> SWPadnos: it's wrong on the screen
[02:47:16] <jmkasunich> (because with vel-mode = 0, the new code does not run!
[02:47:22] <SWPadnos> oh
[02:47:50] <cradek> wait, maybe I'm crazy
[02:47:57] <SWPadnos> jmkasunich, I think the current->max+max->0 is better than 2x max->0, but possibly not enough better to warrant doing it that way
[02:47:59] <jmkasunich> could be
[02:48:16] <jmkasunich> (could be cradek is crazy)
[02:48:26] <SWPadnos> that's what I figured ;)
[02:49:00] <cradek> no, I'm not, it's totally wrong
[02:49:08] <jmkasunich> fsck
[02:49:21] <SWPadnos> 10% or some multiple of 25.4? :)
[02:49:24] <cradek> when axis.0.jog-counts increases by 1, with axis.0.jog-scale = .01, the position increases about .008
[02:49:30] <SWPadnos> urk
[02:49:34] <jmkasunich> max?
[02:49:45] <cradek> yes
[02:49:55] <SWPadnos> what about scale=1.0?
[02:50:11] <SWPadnos> is it 0.8 or some more precisely wrong number? :)
[02:50:20] <cradek> SWPadnos: still moves about .008
[02:50:28] <cradek> invalid command name "-1211673700callit"
[02:50:35] <SWPadnos> big oopsie
[02:50:36] <cradek> and there's still a rare bug in AXIS
[02:50:36] <jmkasunich> you running head?
[02:50:43] <cradek> jmkasunich: yes
[02:51:05] <jmkasunich> cause this sounds like the wheel/kbd/home interaction thing again
[02:51:09] <cradek> I agree
[02:51:27] <cradek> I think I had not tested the rewrite until know
[02:51:30] <cradek> now
[02:51:47] <jmkasunich> there are hal pins for "wheel-jog-active" and "kb-jog-active", perhaps scoping them will be usefull
[02:52:01] <jmkasunich> * jmkasunich starts to make a clean spot on the bench
[02:52:07] <cradek> ok I'll get that going
[02:52:10] <jmkasunich> this has GOT to be right for 2.1.4
[02:52:15] <cradek> yes
[02:54:59] <cradek> wheel-jog-active goes high for about 50ms
[02:58:03] <jmkasunich>
[02:58:05] <jmkasunich> oops
[02:58:14] <jmkasunich> from a single tick of the wheel?
[02:58:22] <cradek> yes
[02:58:34] <cradek> count increases by 1
[02:58:59] <cradek> I reduced the accel, and now it moves about .0002
[02:59:25] <jmkasunich> and the active pins is high for a shorter time?
[02:59:37] <cradek> oh I lied
[02:59:41] <cradek> gah sorry about the bad reporting
[03:00:05] <cradek> it moves *farther* now - about .013
[03:01:15] <cradek> it's not a fixed distance, because a jog 10 counts out and back ends in a different place
[03:02:44] <jmkasunich> * jmkasunich tried to get parport to read the jogwheel
[03:03:43] <cradek> no luck?
[03:04:03] <jmkasunich> I don't remember which pins its wired to
[03:04:16] <jmkasunich> so far, halmeter says "none of them"
[03:04:18] <cradek> oh you've got that little box don't you
[03:04:23] <jmkasunich> yes
[03:04:25] <cradek> got power?
[03:04:44] <jmkasunich> yeah, meter says the encoder is powered and at least one of its outputs toggles
[03:04:49] <jmkasunich> (real meter)
[03:09:31] <jmkasunich> ok, that works now...
[03:19:55] <cradek> jmkasunich: thanks for those 18G disks last year - they're running two machines now
[03:20:02] <jmkasunich> free-pos-cmd is moving by exactly 0.008 per count....
[03:20:07] <jmkasunich> cool
[03:22:06] <SWPadnos> is there a * missing in the check for axis->jog_vel_mode ?
[03:22:12] <SWPadnos> it's a pin, isn't it?
[03:22:18] <jmkasunich> oops
[03:22:44] <jmkasunich> * jmkasunich is a moron
[03:22:49] <SWPadnos> heh
[03:22:55] <SWPadnos> you should rewrite motion in comp ;)
[03:23:03] <jmkasunich> that means vel mode is always active
[03:23:05] <cradek> woo
[03:23:25] <cradek> good eye, that kind of thing is a nightmare to spot
[03:23:35] <SWPadnos> well, now we know how far you can jog something in vel mode ;)
[03:23:38] <jmkasunich> I was starting to get suspicious though
[03:23:45] <jmkasunich> cause it was acting like it was active
[03:23:59] <jmkasunich> I had already tried setting the bit, guessing that maybe I had the if backwards
[03:24:11] <jmkasunich> and it made no difference
[03:24:56] <jmkasunich> "this change is safe" I sez....
[03:25:16] <jmkasunich> "the code is entirely contained in an if and won't run if you don't enable it" I sez
[03:25:19] <SWPadnos> heh
[03:25:22] <cradek> hahaha
[03:25:57] <SWPadnos> well, at least Stuart was having other troubles today ...
[03:27:04] <jmkasunich> I think I found an axis bug
[03:27:28] <jmkasunich> the hal pins coming out of axis, that tell HAL what axis is selected for jogging...
[03:27:44] <cradek> that's much better!
[03:27:52] <jmkasunich> start EMC, come out of estop, machine on, and none of those pins are true
[03:28:02] <jmkasunich> even though X is selected
[03:28:07] <cradek> I've noticed that too, I wonder if it's a feature
[03:28:17] <jmkasunich> I don't think so
[03:28:37] <jmkasunich> if you can jog X by clicking on the + and - buttons, then you should be able to jog it by the wheel
[03:29:03] <cradek> yeah I wasn't entirely serious
[03:29:06] <SWPadnos> not necessarily
[03:29:27] <jmkasunich> SWPadnos: I mean "if you have wired the HAL that way...."
[03:29:33] <cradek> ok now that sillymode is turned off, the jogwheel works again
[03:29:38] <SWPadnos> right - I was just getting to that realization
[03:29:52] <SWPadnos> what's the accel in that config?
[03:30:18] <cradek> emc/task/taskintf.cc 598: Error on axis 0, command number 111
[03:30:18] <cradek> emc/task/taskintf.cc 598: Error on axis 0, command number 129
[03:30:28] <cradek> I get these errors when I try to keyboard jog while turning the wheel
[03:30:59] <jmkasunich> remember the other night when I was wondering what "SET_AXIS_ERROR_FLAG" actually does?
[03:31:04] <jmkasunich> now we know
[03:31:19] <cradek> it causes spewage on stdout?
[03:31:30] <jmkasunich> it reports an error to the user space code
[03:31:41] <jmkasunich> I guess the user space code spews
[03:31:43] <cradek> but not the kind that gets printed to the gui
[03:31:47] <cradek> sent
[03:32:07] <jmkasunich> if it did "report_error(foo)", then foo would go to the gui
[03:32:22] <jmkasunich> remember that I actually had messages, and we decided they were stupid?
[03:32:28] <cradek> yes
[03:32:37] <jmkasunich> I took out the "report_error"
[03:32:48] <jmkasunich> but not the "SET_AXIS_ERROR_FLAG()"
[03:35:17] <jmkasunich> in regular mode, the vel display in axis tops out at 33ish
[03:35:57] <cradek> jog diagonally and it'll go higher
[03:36:17] <jmkasunich> in vel mode it also tops out at 33ish
[03:36:32] <cradek> oh jogwheel, duh
[03:37:09] <jmkasunich> what are the units of vel anyway?
[03:37:24] <jmkasunich> jog speed is set to 24.7 ipm, but keyboard jogs also go to 33ish
[03:37:39] <cradek> ipm
[03:37:53] <cradek> ouch, that's another bug then
[03:37:53] <jmkasunich> so splain to me how 24.7 = 33ish
[03:38:18] <cradek> Issuing EMC_AXIS_JOG -- (+124,+24, +69, +0,14.000000,)
[03:38:37] <cradek> machine/set debug level, turn on Task Issue
[03:38:45] <cradek> you can see that AXIS is sending the right thing
[03:39:08] <jmkasunich> might be the vel display
[03:39:11] <jmkasunich> how is that computed?
[03:39:20] <cradek> it's not, I can hear it
[03:39:31] <cradek> motion is busted
[03:39:41] <cradek> (it's computed by watching the actual position change)
[03:39:44] <jmkasunich> keyboard jogs are busted?
[03:40:13] <cradek> yes but how can that be??
[03:40:37] <jmkasunich> dunno
[03:40:48] <jmkasunich> got to get my motors running too I guess
[03:41:12] <cradek> wait maybe it's a *60 problem
[03:41:13] <cradek> * cradek grumbles
[03:41:18] <cradek> I think jepler touched this recently
[03:42:06] <jmkasunich> dang - xylotex pinouts
[03:44:12] <jmkasunich> by ear, keyboard and wheel jogs top out at the same speed
[03:44:33] <cradek> yeah, axis bug, sorry
[03:44:45] <jmkasunich> in the vel display?
[03:45:33] <cradek> no, keyboard jog
[03:45:51] <jmkasunich> ah, the slider is being interpreted as ips
[03:46:05] <jmkasunich> so anything over 0.5ish is limited by motion, instead of the slider
[03:46:15] <cradek> yes
[03:46:20] <jmkasunich> damn machinists
[03:46:38] <jmkasunich> everybody else in the civilized world uses seconds as a unit of time
[03:46:54] <jmkasunich> except the damn machinists
[03:47:29] <cradek> inch/sec makes the numbers too small for most machining
[03:47:37] <cradek> I bet mm/sec would be fine
[03:51:32] <jmkasunich> it looks like vel mode wheel jogs don't quite reach the same top speed as pos mode ones
[03:51:35] <jmkasunich> but the difference is smapp
[03:51:38] <jmkasunich> small
[03:51:58] <jmkasunich> "saturated" pos mode jogs do 0.566 ips
[03:52:16] <jmkasunich> saturated pos mode jogs do 0.547 ips
[03:52:49] <cradek> but they don't maintain position at any speed - isn't that contrary to the goal/pseudospec?
[03:52:58] <jmkasunich> yeah they do
[03:53:19] <cradek> I'm sure mine didn't - did you change it?
[03:53:19] <jmkasunich> it may be sensitive to jog-scale
[03:53:24] <cradek> yes it is
[03:53:38] <jmkasunich> I set my jog-scale to 0.00625, because that gives one rev of the motor per one rev of the wheel
[03:53:38] <cradek> set it to .1 for instance
[03:53:51] <jmkasunich> and it tracks nicely
[03:54:08] <cradek> I suppose it depends on jog-scale, accel, etc interacting
[03:54:12] <jmkasunich> oh, I was using 0.000625
[03:55:05] <jmkasunich> I set the scale to 10x bigger,and if I turn the wheel very slowly, it maintains position
[03:55:12] <jmkasunich> but if I speed up, it starts slipping
[03:55:29] <cradek> before the motors hit maxvel?
[03:55:48] <jmkasunich> the bad thing about the distance based approach is that _anything_ that makes it fall behind by more than stop_dist results in slip
[03:56:36] <jmkasunich> maxvel = 0.566, maxaccel = 20
[03:56:54] <jmkasunich> stop_dist = 0.008
[03:57:04] <jmkasunich> don't take much to fall behind by 0.008
[03:57:16] <cradek> so any jog increment over .008 is automatically busted?
[03:57:18] <jmkasunich> if scale is more than 0.008, its guaranteed
[03:57:20] <jmkasunich> yes
[03:57:25] <jmkasunich> suckage
[03:57:31] <cradek> yeah, that bites
[03:57:47] <jmkasunich> it behaves the way I bet they want it to behave
[03:58:00] <jmkasunich> "instantly" responds to the wheel
[03:58:16] <SWPadnos> hmmm
[03:58:21] <jmkasunich> remember, the guy who wants this has a wheel with no "clicks" and no markings
[03:58:29] <cradek> right
[03:58:35] <SWPadnos> two possibilities: (already thought of, I think)
[03:58:44] <jmkasunich> so he probably doesn't give a fart if it slips
[03:58:50] <cradek> but he also said earlier that on a wheel with marks, if the axis doesn't hit maxvel, it tracks
[03:59:05] <jmkasunich> well, this comes back to setting the scale right
[03:59:06] <SWPadnos> 1) change vel-mode to a stop distance. 2) change vel-mode to a stop time
[03:59:16] <SWPadnos> rather than a bit
[03:59:51] <jmkasunich> SWPadnos: any distance other than v^2/2a is probably less than ideal
[03:59:58] <jmkasunich> if its lower than that, it limits top speed
[04:00:08] <SWPadnos> depends on the definition of ideal
[04:00:17] <jmkasunich> if higher than that, it won't respond instantly to changes in wheel speed/direction
[04:00:40] <jmkasunich> I think the real answer is "don't set the scale so high"
[04:00:45] <cradek> ideal = we quit getting bug reports saying it doesn't "feel" right
[04:01:11] <SWPadnos> but when "so high" is 0.008 on a not-exceedingly-fast config, I'm not sure it's the best answer
[04:01:29] <jmkasunich> when I set scale to 0.0065, that means the motor turns 10 times as fast as the jogwheel
[04:01:40] <cradek> an inch per turn of my wheel sure might be a setting I would want to use
[04:01:44] <cradek> (.01)
[04:02:27] <jmkasunich> since the motor tops out at less than one rev per second, if you config for motor = 10x wheel, then the wheel will slip at 0.1 rev per second
[04:03:14] <jmkasunich> the xylotex is 1600 steps/rev IIRC
[04:03:26] <SWPadnos> I guess that as long as the max vel can be hit (or very very close to it) when "spinning" the wheel, it'it does what he wants
[04:03:32] <jmkasunich> right
[04:03:40] <jmkasunich> and that means a much smaller jog scale
[04:04:04] <SWPadnos> hmm
[04:04:20] <jmkasunich> if you hit max-vel at 0.1 revs/second of the wheel, and you are capable of spinning it 4 times per second, you are throwing away most of your dynamic range
[04:05:27] <SWPadnos> ok - I think it doesn't work "right" (for some value of right)
[04:05:52] <SWPadnos> if you move the wheel one count, the machine should move one jog increment
[04:06:28] <SWPadnos> if you've configured it for 20 second accel and 1" moves, then you have a problem
[04:06:28] <jmkasunich> one single isolated count, and stop afterwards?
[04:06:43] <SWPadnos> right, like I move the wheel one click, then pause, then do it again
[04:06:53] <SWPadnos> I should get 1, 2, 3x ... the jog increment
[04:06:58] <jmkasunich> I think stuart would disagree
[04:07:12] <jmkasunich> he wants it to stop when he stops turning
[04:07:15] <SWPadnos> I suspect he doesn't run into the pathologically slow accel issue
[04:07:24] <cradek> I agree with SWPadnos
[04:07:27] <jmkasunich> he doesn't care if it moves one increment or not
[04:07:38] <cradek> and I decline to guess what Stuart would want
[04:07:44] <jmkasunich> and I really can't imagine him setting the increment that large
[04:07:57] <SWPadnos> he (or someone) said that the wheel should track until you spin it too fast. moving one click isn't really "spinning it too fast"
[04:08:18] <SWPadnos> but a 1" jog would be limited to some few thou
[04:08:21] <cradek> he said it should track unless the axis hits maxvel.
[04:08:23] <jmkasunich> we should ask him
[04:08:51] <jmkasunich> his requested behavior is fundamentally incompatible with 1" increments
[04:09:02] <SWPadnos> you guys are using MAX for testing?
[04:09:17] <cradek> I am, but I turned down the accel somewhat
[04:09:18] <jmkasunich> because by definition, a 1" increment is going to keep moving for a long time after the wheel stops
[04:09:28] <SWPadnos> unless you have a fast machine
[04:09:29] <cradek> that's true.
[04:09:31] <jmkasunich> and that is what he complained about from the very beginning
[04:09:45] <SWPadnos> but a fast machine with high accel will be limited to an even lower jog increment
[04:09:47] <cradek> well he complained about the windup - I'm not sure that's the same
[04:10:32] <SWPadnos> ok - 1200 looks like fairly quick accel to me - is it?
[04:10:58] <SWPadnos> hmmm. maybe not - it should be in the realm of a BP with reasonable servos
[04:11:00] <jmkasunich> he wrote (in the very first message): "I believe it would be far better if the control would truncate the command and stop the machine as soon as the handwheel is stopped."
[04:11:03] <cradek> 1200ips2 is 3G
[04:11:20] <jmkasunich> SWPadnos: where are you getting 1200 from?
[04:11:23] <SWPadnos> MAX
[04:11:28] <cradek> uh no
[04:11:31] <jmkasunich> max has 20 as max accel
[04:11:32] <SWPadnos> oh - that's TRAJ - nevermind
[04:11:34] <cradek> that's for degrees maybe
[04:11:51] <SWPadnos> MAX_VELOCITY = 50
[04:11:52] <SWPadnos> DEFAULT_ACCELERATION = 1200
[04:11:54] <SWPadnos> MAX_ACCELERATION = 1200
[04:11:55] <SWPadnos> from TRAJ
[04:11:59] <cradek> yeah degrees
[04:12:02] <jmkasunich> if its traj, its crap
[04:12:21] <SWPadnos> right - I hadn't noticed the lower axis limits
[04:12:22] <jmkasunich> that needs to deal with two completely incompatible units systems
[04:13:24] <SWPadnos> ok - so 20 IPS^2 is quite reasonable, and actually low for "pro" equipment
[04:13:33] <jmkasunich> right
[04:13:52] <SWPadnos> which means the max jog increment on a HSM will be in nanometers
[04:14:15] <jmkasunich> hmm... the mazak has the same 20 in/sec^2 accel
[04:14:31] <jmkasunich> but its max vel is 5 ips, not 0.5 ;-)
[04:14:39] <SWPadnos> heh
[04:14:44] <jmkasunich> so its stop_dist is larger, not smaller
[04:14:50] <jmkasunich> 100 times larger actually
[04:15:06] <SWPadnos> true - it's being scaled by v^2/2A
[04:15:09] <jmkasunich> v^2 / 2a means V wins
[04:16:39] <jmkasunich> the reason I used "stop_dist" is because he said "stop when the wheel stops"
[04:17:02] <jmkasunich> a low speed machine with high accel can stop very fast
[04:17:09] <jmkasunich> so that is the most demanding case
[04:17:11] <SWPadnos> ok - so it may be perfectly reasonable to do the 2x mod - to account for accel and decel. it'll be very little extra time if the axis is at max vel
[04:17:16] <SWPadnos> right
[04:17:39] <cradek> it's possible he said conflicting things, so that we keep quoting his different messages is not very helpful
[04:17:40] <SWPadnos> but it allows the axis to *get* to max vel in the first click
[04:17:44] <SWPadnos> heh
[04:18:31] <jmkasunich> ? an axis can't get to max vel in the first click unless its zero-to-max accel time is 0.001 seconds
[04:22:06] <SWPadnos> when you move the wheel, the axis starts at 0, accels to some vel determined by the jog scale, then decels to 0
[04:22:24] <jmkasunich> you mean when you move it a single click?
[04:22:29] <SWPadnos> determined by jog scale in this mode, due to the stop_dist limit
[04:22:31] <SWPadnos> yes
[04:22:43] <jmkasunich> in either mode...
[04:22:56] <jmkasunich> it accels to whatever speed is needed to travel that distance
[04:23:01] <SWPadnos> sure - but the vel will be 1/2 max with this stop_distance
[04:23:12] <jmkasunich> nope
[04:23:21] <SWPadnos> since it needs to accel first
[04:23:36] <SWPadnos> unless you've already changed it to v^2/a
[04:23:56] <jmkasunich> I can spin the wheel and see the machine moving at about 99% of vmax
[04:24:11] <jmkasunich> the speed it reaches in a single click move isn't relevant
[04:24:15] <SWPadnos> sure, you'll asymptotically approach max
[04:24:49] <SWPadnos> if you move the wheel at exactly the right speed to create 100% velocity motion, you'll be well below 100% I think
[04:25:05] <SWPadnos> spinning very quickly will get you nearer to max
[04:26:44] <jmkasunich> actually, a single click move tops out a 0.707 * maxV
[04:27:01] <SWPadnos> ok, so the factor is ssqrt(2) :)
[04:29:04] <jmkasunich> I haven't tried with strange accel values yet (either very low or very high)
[04:29:24] <jmkasunich> with the default values, stop_dist is 0.008"
[04:29:37] <SWPadnos> or 0.8" for the Mazak ;)
[04:29:51] <jmkasunich> right - and either of those values is too high for a good wheel
[04:30:06] <cradek> .001 or .002 seems pretty natural for my machine
[04:30:21] <cradek> at .001 I can get to maxvel if I try really hard
[04:30:30] <jmkasunich> are you using x1 or x4 counting?
[04:30:56] <jmkasunich> I'm using x4, but I should probably change that, because 1 click of the wheel = four counts, and that just makes things strange
[04:30:57] <cradek> x1 so one count per click of the wheel
[04:32:02] <jmkasunich> at 0.002, can you get ahead of the machine easily?
[04:32:24] <cradek> yes
[04:32:43] <cradek> if I spin it, I can (barely) get ahead at .001
[04:33:41] <jmkasunich> so at 0.001 there is almost no difference between the modes
[04:33:50] <jmkasunich> (difference only appears if you spin it fast)
[04:34:45] <cradek> yes
[04:35:15] <jmkasunich> if you set the scale to 0.008, its much easier to get ahead
[04:35:27] <jmkasunich> and if you are careless, you can get far ahead
[04:36:08] <jmkasunich> if you set it to 0.08, you better be carefull how you handle that wheel
[04:36:20] <jmkasunich> or you might send the machine a long way by accident
[04:36:59] <cradek> here's an interesting twist: say I send the machine a long way with the wheel. can I hit escape on the keyboard to stop it?
[04:37:07] <jmkasunich> no
[04:37:12] <jmkasunich> well, I dunno
[04:37:16] <jmkasunich> try it ;-)
[04:37:18] <cradek> because it's blocked out?
[04:37:30] <jmkasunich> not really
[04:37:42] <jmkasunich> because as coded, axis_abort only aborts kb jogs
[04:37:49] <jmkasunich> lemme check the code before I insert foot in mouth
[04:38:10] <cradek> escape has always aborted homing - I hope you didn't change that accidentally
[04:38:34] <jmkasunich> what does escape send to motion?
[04:38:59] <cradek> I'm going to start trying it instead of talking out my ass
[04:39:13] <jmkasunich> I can tell you that esc doesn't abort a wheel jog
[04:39:54] <jmkasunich> but both ABORT and AXIS_ABORT will stop a wheel jog (unless I'm misreading the code)
[04:40:00] <jmkasunich> so esc must not be sending those commands
[04:40:09] <cradek> yes I think it does...?
[04:40:39] <cradek> TASK_ABORT
[04:41:00] <cradek> which I think aborts all the axes
[04:41:23] <jmkasunich> I was wrong
[04:41:29] <jmkasunich> esc _does_ abort a wheel jog
[04:41:36] <cradek> ok I think that's good
[04:41:53] <jmkasunich> as long as you are in the axis window, not the irc window, when you hit esc ;-)
[04:42:01] <cradek> haha
[04:43:04] <jmkasunich> I agree that esc should stop things
[04:43:38] <jmkasunich> hmm, thats bogus
[04:43:46] <jmkasunich> a kb jog stops a wheel jog
[04:44:17] <jmkasunich> probalby that damned AXIS_ERROR_FLAG thing
[04:44:40] <cradek> yeah probably
[04:45:50] <jmkasunich> I think if you try a kb jog during a wheel jog it should just be silently discarded...
[04:46:01] <jmkasunich> do you agree? if so, I'll remove that error flag thing
[04:47:19] <jmkasunich> hmm, the current code considers an attempt to jog onto limits as an error too
[04:47:54] <jmkasunich> "error" handling just plain sucks
[04:48:28] <jmkasunich> the coder has a choice:
[04:48:33] <jmkasunich> 1) discard command silently
[04:48:38] <jmkasunich> 2) print a message
[04:48:48] <jmkasunich> 3) set the error flag
[04:48:55] <jmkasunich> 4) print a message AND set the error flag
[04:49:03] <cradek> yes I agree with your initial statement
[04:49:05] <jmkasunich> how is anybody supposed to know what is the right thing to do
[04:49:14] <cradek> same for a jog that would exceed limits
[04:49:34] <jmkasunich> I think if you try a kb jog during a wheel jog it should just be silently discarded...
[04:49:38] <jmkasunich> that statement?
[04:49:40] <cradek> yes
[04:49:55] <jmkasunich> what about jog during homing?
[04:50:29] <cradek> I believe that would be a gui bug, so it should give an error
[04:50:45] <cradek> well no, it's not a gui bug is it
[04:50:52] <jmkasunich> no
[04:50:57] <cradek> gui doesn't know homing is still happening
[04:51:06] <cradek> guess I don't know the answer to that one
[04:51:11] <jmkasunich> currently there are the following tests:
[04:51:25] <jmkasunich> not in free mode (prints message)
[04:51:34] <jmkasunich> axis not enabled (prints message)
[04:51:47] <jmkasunich> homing or wheel jog (sets flag)
[04:52:00] <jmkasunich> jog farther onto limit (sets flag)
[04:52:25] <jmkasunich> oh, and "joint number is valid" (ignored completely)
[04:53:56] <jmkasunich> ok, new tests
[04:54:13] <jmkasunich> not in free mode or not enabled, same as before (print message and set flag)
[04:54:22] <jmkasunich> homing - print message and set flag
[04:54:33] <jmkasunich> wheel jog in progress - ignore silently
[04:54:40] <jmkasunich> farther onto limit - ignore silently
[04:54:49] <jmkasunich> invalid joint number - ignore silently
[04:54:59] <jmkasunich> (that last one should probably be an error)
[04:56:06] <jmkasunich> building now, I bet that will allow a wheel jog to continue when you press an arrow key
[04:56:14] <jmkasunich> but I also bet it will stop when you release the arrow key
[04:56:21] <jmkasunich> and that is non-trivial to fix
[04:56:28] <cradek> yeah
[04:56:43] <cradek> I don't think that's too big a deal
[04:56:44] <jmkasunich> because releasing an arrow key doesn't send "stop kbd jog", it sends "abort axis"
[04:56:52] <jmkasunich> which IMO is just plain wrong
[04:57:42] <jmkasunich> well, if we don't want hitting an arrow to abort a wheel jog, then we also don't want releasing it to abort the wheel jog
[04:57:54] <jmkasunich> otherwise, whats the point?
[04:58:55] <jmkasunich> oh, that axis hal pin thing (initial condition)...
[04:59:39] <jmkasunich> the pin is initially false, but you don't have to (re)select the axis to make it true, a keyboard jog will do it
[05:00:18] <jmkasunich> yep, as expected - hitting the arrow doesn't abort the wheel, but releasing it does
[05:00:50] <jmkasunich> I really should have gotten this contraption out and hooked it up while I was doing this code
[05:03:34] <jmkasunich> yuck - I bet this means that hitting (and releasing) an arrow will abort a home too
[05:06:11] <jmkasunich> * jmkasunich talks to himself
[05:06:24] <cradek> nah, I'm listening
[05:08:02] <cradek> part of me thinks if you don't want to interrupt something it's doing, you should keep your paws off the keyboard
[05:08:33] <cradek> so while these interactions aren't ideal, I'm having a hard time caring enough to bother fixing them, especially since nobody has noticed/complained in many years
[05:09:54] <SWPadnos> how many years has jogwheel support been there for a keyboard jog to interrupt?
[05:10:06] <cradek> homing
[05:10:10] <SWPadnos> oh, that too ;)
[05:10:11] <cradek> (forever)
[05:10:13] <jmkasunich> SWPadnos: we're now talking about kbd jog and homing interactions
[05:10:25] <SWPadnos> ok - I'll go back to near-sleep then :)
[05:10:34] <SWPadnos> oh wait - I never exited from near-sleep
[05:11:01] <jmkasunich> I do think that if releasing the key is gonna abort the home or wheel jog, then pressing it should generate the error and set the error flag
[05:11:12] <jmkasunich> might as well abort when they hit the key, not later
[05:11:23] <jmkasunich> and might as well explain what happened
[05:12:12] <SWPadnos> is it not possible for the keybaord jog code to check HOMING before sending the abort (or is it not that simple)?
[05:12:36] <jmkasunich> the sending code is in user space, and has no clue what is happening in the real world
[05:12:57] <SWPadnos> hmmm. is that not in emcstatus?
[05:13:13] <jmkasunich> yeah, but you're still talking about race conditions
[05:13:45] <jmkasunich> the last thing you want to do is fail to send an abort if there is a real keyboard jog going on - that leads to runaway axes
[05:13:50] <SWPadnos> sure, but the race is to hit a home key and then release a jog key so quickly that status hasn't been updated yet
[05:14:20] <SWPadnos> if homing is finished and status isn't updated yet, that's not a problem
[05:14:21] <cradek> like jmk said days ago, a new message for stop-the-continuous-jog is probably all that's needed
[05:14:31] <SWPadnos> yeah - that would be a better plan
[05:14:43] <jmkasunich> the proper solution (if we're gonna bother to do anything) is to have the arrow release send "JOG_END" instead of "AXIS_ABORT"
[05:14:49] <jmkasunich> and then let the RT code do the right thing
[05:15:01] <jmkasunich> what he said
[05:15:21] <cradek> that's a somewhat bigger pain to change though.
[05:15:24] <jmkasunich> right
[05:15:28] <SWPadnos> on that note, I think I'll send myself an IRC_END message now. night guys
[05:15:34] <cradek> g'night
[05:15:34] <jmkasunich> goodnight
[05:16:03] <jmkasunich> my plan for now is to have "jog during homing" send an error message and set the error flag
[05:16:17] <jmkasunich> jog during wheeling - dunno
[05:16:30] <jmkasunich> I think I will make it do the same
[05:17:21] <jmkasunich> if someday we add the JOG_END message, then we can get rid of the error messages, because pressing _and_ releasing the jog button during homing or wheeling would be completely ignored (the proper behavior)
[05:24:31] <cradek> I agree if it's going to abort homing, it should probably give an error
[05:24:44] <jmkasunich> and a message?
[05:25:06] <cradek> well in general I don't see any point to the errors that the user doesn't see
[05:25:12] <jmkasunich> ok
[05:25:55] <jmkasunich> someday (not tonight) we need to figure out what the hell JOINT_ERROR_FLAG actually does
[05:28:33] <jmkasunich> this was easy: if (emcmotStatus->homing_active) {
[05:28:33] <jmkasunich> reportError("Can't jog aby axis while homing.");
[05:28:53] <jmkasunich> this one, I dunno if there should be a message or not:
[05:28:54] <jmkasunich> if (joint->wheel_jog_active) {
[05:28:53] <jmkasunich> /* can't do two things at once */
[05:29:10] <cradek> typo in your message
[05:29:18] <jmkasunich> the ideal result would be the kb jog is ignored
[05:29:27] <jmkasunich> thank you
[05:29:47] <jmkasunich> the actual result is that the wheel jog is aborted (and the kb jog doesn't happen either)
[05:30:47] <jmkasunich> I have no clue what message, if any should be printed for that case
[05:31:00] <jmkasunich> maybe none
[05:31:09] <cradek> probably none
[05:31:37] <jmkasunich> simultaneous jogs on wheel and kb are unlikely, and any reasonable person would understand that they're gonna interact _somehow_
[05:31:38] <cradek> later, I guess we'll add that new message, and it'll be possible to fix it right
[05:31:43] <jmkasunich> agreed
[05:31:44] <cradek> yes
[05:31:56] <cradek> the old behavior was to run away, the new behavior is to stop
[05:32:00] <cradek> that's an improvement
[05:32:03] <jmkasunich> heh, yeah
[05:33:11] <jmkasunich> if a GUI is in incremental jog mode, it doesn't send AXIS_ABORT when you release the key does it?
[05:33:28] <cradek> no I think that would be bogus behavior
[05:33:37] <cradek> you'd interrupt the jogs sometimes
[05:33:53] <jmkasunich> so when handling an JOG_INCR command, I can completely ignore the jog, not even bother setting the error flag
[05:34:09] <jmkasunich> that is the long term desired behavior
[05:34:31] <jmkasunich> its only JOG_CONT that is followed by the AXIS_ABORT messages and messes things up
[05:34:44] <jmkasunich> hell, I shouldn't set the error flag for any of them
[05:34:46] <cradek> oh if the wheel is going, ignore JOG_INCR? yes
[05:35:13] <jmkasunich> actually for any kb jog, if the wheel is going, just ignore it
[05:35:23] <cradek> don't backport unnecessary error flag changes if you don't understand the big picture
[05:35:43] <jmkasunich> well, the tests themselves are new
[05:35:53] <cradek> ok
[05:37:16] <jmkasunich> ok, for all three jog commands - if homing, print message and set flag, if wheeling, ignore completely
[05:37:34] <jmkasunich> all the other tests are completely unchanged
[05:38:04] <jmkasunich> later, we just need to add JOG_END, we won't have to touch this code at all
[05:38:09] <cradek> I'll test after the backport too :-)
[05:38:22] <jmkasunich> good
[05:38:32] <cradek> darn, never heard back from ray about mini
[05:38:35] <jmkasunich> we can both test, since I now have my gadget set up
[05:38:49] <cradek> good we can share the blame then
[05:39:27] <jmkasunich> I'll take all the blame if people don't like how silly mode works
[05:40:14] <cradek> how about if some neither like it nor care (I'm an example of this)
[05:42:53] <cradek> actually I've been sometimes using a free-spinning encoder as a jogwheel (only because it's easier to mount to the mill using stickytape) and I might use silly mode for that
[05:43:07] <jmkasunich> if you never enable it, you won't blame anybody, now will you?
[05:43:13] <cradek> nope
[05:43:21] <jmkasunich> head is testable
[05:43:28] <jmkasunich> I'll start the backport
[05:43:55] <jmkasunich> you already made the same bugfix I did locally I think, that will probably conflict
[05:44:01] <cradek> I'm losing focus so I think I'll leave you for the evening
[05:44:03] <jmkasunich> ok
[05:44:05] <cradek> i fixed that already
[05:44:16] <jmkasunich> but you didn't commit it
[05:44:23] <cradek> no
[05:44:33] <cradek> I mean I fixed my own conflict
[05:44:41] <jmkasunich> oh...
[06:01:03] <jmkasunich> backport done
[06:01:07] <jmkasunich> testing tomorrow
[13:36:10] <jepler> George W's Palace
[13:36:11] <jepler> Construction of the largest embassy on Earth will shortly be completed in Iraq. Roughly the size of Vatican City, and previously estimated to cost nearly 1 billion, (later reduced to a mere 592 million ), this remarkable feat of engineering "...will have its own water wells, electricity plant and wastewater-treatment facility, 'systems to allow 100 percent independence from city utilities,' says the report..." .
[13:36:16] <jepler> by Avenger at March 25, 2007 01:42
[13:36:16] <jepler> http://cvs.linuxcnc.org/cvs/emc2/src/emc/motion/control.c.diff?r1=1.105;r2=1.106
[13:36:19] <jepler> oops
[13:36:35] <jepler> anyone want to test spindle speed override before I backport this?
[13:37:02] <jepler> it seems spindle speed override has no effect without it...
[14:30:15] <mschuhmacher> Hi-all
[14:32:20] <mschuhmacher> in mini.tcl there is popupJogSpeed
[14:33:19] <mschuhmacher> not defined is this a known issue?
[14:37:56] <jepler> looks like a genuine bug
[14:38:16] <mschuhmacher> I fixed it
[14:38:34] <jepler> you can send your patch to the emc-developers list and someone will incorporate it
[14:38:53] <mschuhmacher> but i´m not content with the fix
[14:39:23] <jepler> oh.
[14:40:06] <jepler> it's breakfast time here. bbl.
[14:41:40] <mschuhmacher> Enjoy your meal
[14:42:12] <mschuhmacher> I try to make the fix better
[17:10:26] <alex_joni> just tested halui analog jogging, and it still works OK on TRUNK
[17:17:37] <SWPadnos> suggestion: put a link to the wiki in the EMC2 menu ont he next LiveCD/package update ...
[17:17:48] <SWPadnos> s/he/the/
[17:18:05] <alex_joni> that could be in 2.1.4
[17:18:17] <alex_joni> LiveCD is a simple CD with 2.1.x installed
[17:18:18] <SWPadnos> yep
[17:18:54] <SWPadnos> the kinds of questions that are being posted on the user list make me think that there's no really obvious link to external help docs on an installed system
[17:21:45] <cradek> SWPadnos: you're very generous
[17:22:08] <SWPadnos> heh - yeah
[17:22:20] <SWPadnos> assuming that people even *look* at docs is a bit of a leap, isn't it?
[17:23:04] <cradek> this guy's strategy is obviously to look for someone to email, and fire away
[17:24:45] <SWPadnos> sigh. I really wish I could spend the time defending EMC and pointing out the advantages of actual PID servo control (on the CCED list)
[17:25:33] <cradek> I hear emc is harder to configure than an open-loop step servo system
[17:26:10] <cradek> (against that kind of thing?)
[17:26:26] <SWPadnos> no - more about people talking about using the "closed loop" add-on card for Mach
[17:26:38] <cradek> sorry, I'm in a trolly mood today, I should go do something else for a while
[17:26:47] <SWPadnos> it's a traveling following error thing, where the comparisons are done in non-RT
[17:26:50] <cradek> oh what does it do?
[17:27:22] <SWPadnos> the feedback is tracked in an on-screen DRO, and if the feedback vs command position is too far off, it stops Mach
[17:27:30] <SWPadnos> the feedback isn't used for control though
[17:27:46] <SWPadnos> but people still seem to think that's just fine, and some even call it closed loop
[17:28:08] <cradek> that would be halfway useful if it were realtime, at least it would stop when something goes wrong
[17:28:09] <SWPadnos> and they don't even consider that there are alternatives to Mach
[17:28:18] <SWPadnos> it still will, eventually
[17:28:22] <SWPadnos> probably
[17:28:58] <cradek> * cradek shivers
[17:29:29] <SWPadnos> yeah - that's why I wish I had the time ...
[17:29:37] <alex_joni> and nerve..
[17:29:46] <alex_joni> (some people don't deserve to get help..)
[17:29:55] <SWPadnos> that's true too
[17:30:54] <cradek> on one hand it would be nice if they knew all the options, but on the other hand I have no time to spend convincing people who dismiss anything that (1) doesn't cost money (2) doesn't use microsoft stuff
[17:31:21] <SWPadnos> yes - that's another annoyance
[17:31:54] <cradek> those people might come around when some microsoft release kills mach (and microsoft schemes to kill all the old OSs that will still run it)
[17:32:14] <SWPadnos> "but you can't use the computer for anything else" ... (yeah, but the same is true whenever Mach is running, in my experience)
[17:32:15] <cradek> either way, not my problem
[17:32:21] <SWPadnos> nope
[17:32:27] <alex_joni> nope?
[17:32:40] <SWPadnos> that was a nope of agreement :)
[17:32:46] <SWPadnos> not his (your, our) problem
[17:33:37] <cradek> need breakfast (?), bbl
[17:33:50] <SWPadnos> see you
[17:35:30] <alex_joni> hmm.. dinner here.. got the time change last night
[17:40:51] <jmkasunich> SWPadnos: I was thinking about vel mode jogwheels this morning
[17:41:04] <SWPadnos> uh-oh, I'm in trouble ;)
[17:41:10] <alex_joni> hi jmk
[17:41:15] <jmkasunich> suppose the distance was the greater of v^2/2a and jog-scale
[17:41:17] <jmkasunich> hi alex
[17:41:42] <jmkasunich> SWPadnos: that would ensure that you can always do a single click
[17:42:05] <SWPadnos> yep - that should work
[17:43:13] <SWPadnos> actually, the calculation for distance to accel to full speed then back to 0 is trivial - it doesn't even need a second divide since the denominators are the same
[17:43:32] <jmkasunich> its just twice the distance I already calculate
[17:43:38] <jmkasunich> but that is NOT the correct distance to use
[17:43:44] <SWPadnos> it's ((jogvel-currentvel)^2 + jogvel^2) / 2A
[17:44:20] <jmkasunich> oh, from current vel to full and then to zero....
[17:44:21] <SWPadnos> if currentvel is 0, that'll be 2x
[17:44:24] <SWPadnos> right
[17:44:58] <jmkasunich> I still don't think that is the right answer
[17:45:12] <SWPadnos> I'm not sure there's one right answer
[17:45:26] <jmkasunich> if scale is more than 2x it will still not give you a full single step
[17:45:30] <jmkasunich> lunchtime. bbl
[17:45:32] <SWPadnos> I'd almost rather have the max distance or max time to stop as a HAL parameter/pin
[17:45:35] <SWPadnos> see you
[17:45:37] <SWPadnos> right
[17:46:06] <SWPadnos> hmmm. if (already moving) use slip mode, else use erxact mode ...
[17:46:11] <SWPadnos> exact
[17:46:29] <SWPadnos> even if vel-mode is true
[18:12:22] <anonimasu> does anyone have a idea about homing?
[18:12:40] <anonimasu> I'm looking at the lathe config, and it homes then goes to zero..
[18:12:53] <anonimasu> why does it go to zero automatically/can you toggle it off?
[18:13:30] <anonimasu> err actually sorry, that was in the wrong place.
[19:20:46] <jmkasunich> cradek: jepler: I think I found an axis bug
[19:21:15] <jepler> jmkasunich: I'm listening
[19:21:21] <jmkasunich> well, maybe not a bug, but certainly something unexpected
[19:21:45] <jmkasunich> start axis, select axis Y, jog using the mouse on the +/- buttons, all is well
[19:21:53] <jmkasunich> jog using the wheel, all is well
[19:21:59] <jmkasunich> then use the arrow keys to jog X
[19:22:07] <jmkasunich> at the start of the jog, no prob
[19:22:19] <jmkasunich> when you release the arrow key, X becomes the selected axis
[19:22:34] <jmkasunich> and future jogs using the mouse on the +/- buttons, or the wheel, will jog X
[19:22:45] <jmkasunich> is that a feature? ;-)
[19:22:58] <jmkasunich> I would have expected the arrow key jogs to leave the selected axis alone
[19:23:12] <jepler> eek I just found something even worse
[19:23:38] <jepler> hold down the "+" button with the mouse. select a different axis from the keyboard. release the mouse button.
[19:23:41] <jmkasunich> btw, I'm running pre-2.1.4
[19:24:04] <jmkasunich> oh, nice....
[19:27:20] <jepler> the active axis has always changed when keyboard jogging .. there was some reason it was made to do it on key release rather than key press
[19:27:45] <jepler> I do see your mindset, where that was a surprise
[19:28:14] <jmkasunich> the arrows are permanently linked to an axis, therefore there seems to be no reason to change the selected axis when you use the buttons
[19:28:44] <jmkasunich> the selected axis is for input channels that you have only one of, like the +/- buttons, and the wheel
[19:29:19] <jmkasunich> ah, I should speak more clearly
[19:29:24] <jmkasunich> the arrows are permanently linked to an axis, therefore there seems to be no reason to change the selected axis when you use the ARROWS
[19:30:58] <alex_joni> jmkasunich: it works the same way in tkemc, mini and xemc
[19:31:34] <jmkasunich> ok
[19:31:48] <jmkasunich> I guess its obvious I spend more time working on HAL than I do with the GUIs
[19:31:51] <alex_joni> actually I'm not 100% for xemc, but I'm sure about the tcl ones
[19:32:02] <alex_joni> * alex_joni fears the day that'll change
[19:32:03] <alex_joni> :P
[19:32:27] <jepler> I'm not sure what the fall-out would be if I changed it (in axis)
[19:32:45] <jmkasunich> sounds like policy
[19:32:51] <jmkasunich> but the case you found isn't
[19:33:01] <jepler> imagine a person who uses pgdn to move Z to just above the work surface, then a fine jogwheel to move it the rest of the way... (that's me)
[19:33:08] <jepler> yeah there is a real bug here and I'll fix that part
[19:33:18] <jepler> it's the other I'm reluctant to change, even if it doesn't fit everyone's mental model
[19:33:25] <jmkasunich> understood
[19:34:02] <jmkasunich> ok, now what....
[19:34:12] <jmkasunich> Y home search vel is negative
[19:34:24] <jmkasunich> but homing it moves positive....
[19:34:29] <alex_joni> how about INPUT_SCALE?
[19:34:46] <jmkasunich> scales are all positive
[19:34:56] <jmkasunich> jogging positive moves positive
[19:35:02] <jmkasunich> only homing misbehaves
[19:35:32] <jmkasunich> oh, I know whats wrong
[19:35:40] <jmkasunich> I have the polarity of the simulated home switch wrong
[19:35:46] <jmkasunich> so its trying to back off the switch
[19:36:04] <jmkasunich> yep, yhome = TRUE
[19:38:54] <jmkasunich> works now
[19:44:23] <alex_joni> jepler: here's a question..
[19:44:37] <alex_joni> would it be possible to write a python script to save the current position?
[19:44:44] <alex_joni> I take it it should be fairly easy to do..
[19:46:15] <jepler> yes, probably
[19:47:41] <alex_joni> I'm thinking about hijacking emctop for that
[19:47:52] <alex_joni> but I never tried to write to a file from python
[19:48:14] <jmkasunich> what are you trying to do? pick-n-place toolchanger?
[19:48:24] <alex_joni> jmkasunich: no, teaching for robots
[19:48:33] <jmkasunich> ah
[19:48:38] <jepler> % python -c 'import emc; s = emc.stat(); s.poll(); print s.position[:3]'
[19:48:38] <jepler> (23.214448534202575, 8.5943433362007138, -0.0099999994039535502)
[19:48:52] <jepler> I'm not sure how s.position interacts with coordinate-system offsets
[19:49:07] <alex_joni> I'm not really interested in offsets right now
[19:49:13] <jepler> also in an installed system you probably have to set emc.nmlfile as mdi does
[19:49:16] <jmkasunich> we have so many different coordinate systems
[19:50:57] <jmkasunich> position mode jogging with large jog-scale values can get disconcerting
[19:51:30] <jmkasunich> you can easily command several inches of motion, then you stand there frozen wondering if its gonna stop anytime soon
[19:51:51] <jmkasunich> thats probably what started this whole mess
[19:51:57] <alex_joni> maybe an analog pin would be nice
[19:52:04] <alex_joni> one that would show DTG or similar
[19:52:31] <jmkasunich> the answer is to use more sensible jog-scale values
[19:52:36] <alex_joni> that too
[19:53:23] <jmkasunich> actually, a cool (but pita to do I bet) thing would be to have a "ghost" cone in the axis preview, that shows the destination of the jog
[19:53:41] <jmkasunich> it would move instantly as the wheel turns, and the main cone would catch up as the machine catches up
[19:54:05] <alex_joni> yeah, getting a second position to AXIS would be a pita
[19:54:33] <jmkasunich> silly anyway - if the move-per-click is so large that you can get yourself confused, you should either use a smaller scale, or use velocity mode
[20:08:36] <jmkasunich> well, I've played with jogwheel/keyboardjog/homing and with vel-mode vs position mode wheel jogs
[20:08:48] <jmkasunich> in pre-2.1.4
[20:09:09] <jmkasunich> and I don't see any issues - except one that jepler found and is working on
[20:12:39] <alex_joni> hmm.. I'm getting lots of weird messages on TRUNK using scara config
[20:12:43] <alex_joni> same for you guys?
[20:12:55] <alex_joni> INIFILE: ERR_CONVERSION, section=TRAJ, tag=LINEAR_UNITS, num=0, lineNo=139
[20:13:41] <jmkasunich> I haven't done anything with scara
[20:13:54] <alex_joni> I think it's because of the new IniFind
[20:13:59] <jmkasunich> seems that way
[20:14:43] <jmkasunich> where is petev when you need him?
[20:14:58] <alex_joni> grrr...
[20:15:05] <alex_joni> he didn't strip dos endings
[20:15:53] <jmkasunich> fsck
[20:16:32] <alex_joni> well.. the issue isn't that bad.. he's only checking for strings, not numbers
[20:16:36] <jmkasunich> I suppose I should be gratefull for any contributions.... but it irks me when people write code for a Linux based app on doze systems
[20:16:40] <alex_joni> scara has 1.0 for LINEAR..
[20:16:53] <alex_joni> yeah, makes you wonder how they test :P
[20:17:04] <jmkasunich> simple - they don't
[20:17:21] <alex_joni> I think he did.. but moved the files or soemthing like that
[20:46:44] <alex_joni> * alex_joni heads to bed
[20:46:47] <alex_joni> good night all
[21:04:44] <incase> Hi. Anyone only who is more or less responsible for the linuxcnc.org website?
[21:04:54] <jepler> incase: he just went to bed. :-P what's the problem?
[21:06:35] <incase> Well, when using the german language version, some links led into the joomla administration interface (or its login, to be more precise).
[21:06:59] <jepler> I see -- but I don't know enough about joomla to guess how to fix it
[21:07:25] <incase> But I can't find the relevant link at the moment. Odd, perhaps someone already noticed and fixed it. Oh well...
[21:08:16] <jepler> the person who knows the most about the website is alex.joni AT robcon.ro but he's gone for the day
[21:08:38] <jepler> feel free to e-mail him. he can read german as well as english.
[21:09:31] <incase> Anyway, I have another question: Can anyone give me a link to a nice introduction to writing G-code manually? The emc documentation alone is not verbose enough for me, especially since it lacks examples.
[21:09:59] <incase> Ok, I will mail him, perhaps he already knows or knows how to check.
[21:19:33] <incase> Oh well, seems noone can. Anyway, if someone reads this later, it would be nice if a matching link could be added to the Links section of the website or if it could be mailed to me at sven at incase.de, thanks :-)
[22:27:48] <cradek> ah, I figured out how to get the transient (and harmless) AXIS error
[22:28:05] <jmkasunich> you mean the one at startup?
[22:28:13] <cradek> invalid command name "-1211863252callit"
[22:28:33] <cradek> I bet it takes a slow machine
[22:28:52] <cradek> if you hit enter in the touch-off window before it's finished drawing everything, you get it
[22:29:17] <jmkasunich> I haven't seen anything from jepler - I hope he's not having troubles with the bug he ran across eariler....
[22:29:26] <cradek> what bug is that?
[22:29:54] <jmkasunich> select X, hit the + button with the mouse, X starts moving, while holding the mouse down, hit the Y key, then release the mouse
[22:30:04] <jmkasunich> it sends a jog-stop to Y, X keeps going
[22:30:37] <cradek> doctor, doctor!
[22:31:19] <jmkasunich> "it hurts when I do this" "then don't do it"
[22:31:29] <cradek> exactly
[22:31:43] <cradek> I'm running v2_1_branch now - jogwheel works
[22:32:04] <jmkasunich> runaway jogs are bad though - if there is even a chance of it happening by accident, thats not good
[22:32:38] <jmkasunich> good
[22:32:47] <jmkasunich> I ran it a while earlier
[22:33:01] <jmkasunich> the only thing I didn't really do is set wild accel to speed ratios
[22:33:18] <cradek> I haven't tested sillymode - did you?
[22:33:20] <jmkasunich> like vel = 5 ips, accel = 1 in/sec^2
[22:33:21] <jmkasunich> yes
[22:35:21] <jepler> sh tall
[22:35:22] <jepler> oops
[22:35:46] <jepler> jmkasunich: I think I squashed that bug already
[22:35:58] <jmkasunich> committed it?
[22:36:17] <jepler> I have that and one other thing (spindle speed override didn't work) that should be backported but haven't.
[22:37:03] <cradek> I don't get that. I used spindle speed override all the time
[22:37:26] <jepler> http://cvs.linuxcnc.org/cvs/emc2/src/emc/motion/control.c.diff?r1=1.105;r2=1.106
[22:37:35] <jepler> my fix must be wrong, then
[22:37:55] <jepler> the slider didn't work at all for me in sim/lathe from TRUNK
[22:38:17] <cradek> that's unpossible
[22:38:17] <jepler> I am not at a linux machine for the next 3 hours or so so I can't test any of this stuff
[22:38:22] <cradek> lemme try
[22:39:23] <cradek> it works fine for me
[22:39:47] <jepler> still works if you revert the change in 1.106?
[22:39:49] <cradek> machine on, F5, S1000 M3, (bargraph goes to 1000), slide SO to 73%, bargraph goes to 730
[22:40:04] <jepler> try issuing the spindle override disable g-code in MDI
[22:40:08] <jepler> g51p0 or something
[22:40:16] <jepler> then reenable it with g51p1
[22:40:21] <lerman_> lerman_ is now known as lerman
[22:40:35] <cradek> m51p0/m51p1 change it between 1000 and 730
[22:40:55] <cradek> but this is trunk where you fixed it, duhhh
[22:41:08] <jmkasunich> ;-)
[22:42:05] <cradek> in the branch, the slider works and m51 has no effect
[22:42:46] <cradek> I must have misunderstood the problem - you fixed m51
[22:44:17] <cradek> jepler: did you see I figured out how to trigger that after error?
[22:59:03] <jepler> cradek: yes, but remind me again later anyway
[22:59:10] <cradek> ok
[22:59:26] <cradek> looks too nontrivial for me to try to fix it myself
[23:01:23] <cradek> I went to the new harbor freight store for the first time today
[23:01:33] <cradek> it'll be a nice place to have around
[23:01:52] <jmkasunich> eww
[23:01:53] <cradek> my biggest surprise was they have dial calipers like mine that read in .001" and .02mm at the same time
[23:02:30] <jmkasunich> two different hands and two sets of numbers?
[23:02:34] <cradek> yes
[23:02:42] <cradek> I think it's extremely cool
[23:02:52] <jmkasunich> how much?
[23:02:55] <cradek> you can measure something and instantly see whether it's an inch or mm part
[23:03:03] <cradek> ~ $25
[23:03:10] <jmkasunich> hmm, maybe I should get one of those
[23:03:20] <cradek> it's really nice
[23:03:31] <jmkasunich> my Mitutoyo's have mm markings on the body, but not the dial
[23:03:38] <jmkasunich> need a calculator to translate
[23:03:43] <cradek> yeah, but those markings are useless
[23:03:54] <jmkasunich> well, they let you make rough measurements
[23:04:06] <jmkasunich> course a mm ruler does too ;-)
[23:04:23] <cradek> I suppose all the digital calipers do both - but I'd rather have a dial
[23:04:33] <jmkasunich> ditto - I hate things with batteries
[23:05:00] <cradek> anyone want to try the 2.1.4~b package?
[23:05:18] <jmkasunich> no
[23:05:21] <jmkasunich> just release it
[23:05:30] <jmkasunich> ;-)
[23:05:49] <cradek> nah, maybe jepler can fix this other thing later
[23:12:15] <cradek> I hadn't thought of this before but using index on the spindle like for lathe, we could do "peck tapping"
[23:13:08] <jmkasunich> peck tapping?
[23:13:16] <cradek> yeah, back out to clear chips
[23:13:20] <jmkasunich> oh
[23:13:55] <jmkasunich> need more sophisticated spindle control - position mode
[23:14:06] <jmkasunich> so you can say "go in 1/2 turn more than last time"
[23:14:14] <jmkasunich> scuse me, I have to go yell at the dog
[23:18:45] <jmkasunich> back
[23:34:33] <roltek> cradek i see your reading the book
[23:35:37] <roltek> anything else you found interesting
[23:37:56] <roltek> peck tapping in mill book not lathe