#emc-devel | Logs for 2007-03-19

[00:00:01] <alex_joni> nothing
[00:00:10] <jmkasunich> and thats what it should do now
[00:00:10] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/motion/control.c.diff?r1=;r2=
[00:00:34] <alex_joni> you need to clear the source if delta==0 and active==0
[00:00:46] <alex_joni> the tp_enable=0 was a mistake
[00:00:58] <jmkasunich> why not have the free tp itself clear out source, whenever it finishes a move
[00:01:23] <jmkasunich> the various things that might want to start a move check source, if zero they start their move and set source
[00:01:26] <jmkasunich> they never clear it
[00:02:28] <alex_joni> * alex_joni thinks about cases where the sticky bit is more usefull
[00:02:44] <alex_joni> http://pastebin.ca/400900 <- I think this would be the immediate fix for the problem you found
[00:03:08] <jmkasunich> immediate maybe
[00:03:21] <jmkasunich> but why should the source be cleared in more than one place?
[00:04:14] <alex_joni> you have a point there
[00:04:35] <alex_joni> might have been easier like this for me (implementation wise), then to look for the free TP
[00:05:10] <jmkasunich> JOG_CONT runs until somebody sends ABORT, right?
[00:06:23] <jmkasunich> ...AXIS_ABORT I mean ;-)
[00:06:24] <alex_joni> right
[00:06:57] <jmkasunich> and I see that it no longer aborts a wheel jog or a home, only a keyboard jog
[00:07:31] <alex_joni> right
[00:07:45] <alex_joni> which is the right thing to do..
[00:08:04] <jmkasunich> did I understand you when you said "might have been easier like this for me (implementation wise), then to look for the free TP"
[00:08:22] <jmkasunich> you added this free tp source stuff without actually changing the free tp at all?
[00:08:31] <alex_joni> jmkasunich: right
[00:08:41] <alex_joni> but I didn't see the need to change it
[00:09:05] <alex_joni> I meant that as opposed to move the source clearing in the free TP
[00:09:38] <jmkasunich> the way I see the source, it means "the free TP is busy doing something at the request of <source>, so until its done, no other source can use the free TP"
[00:09:49] <alex_joni> right, I agree so far
[00:10:05] <jmkasunich> the "until its done" part seems best done in the TP
[00:10:15] <alex_joni> right
[00:10:32] <alex_joni> it still checks for tp_active (as it did before)
[00:10:39] <alex_joni> so that's still done in the TP
[00:10:46] <jmkasunich> although that gets interesting in the homing case, because for homing, its not just "until the free TP is done with this move", it is "until the entire homing sequence is done"
[00:10:55] <alex_joni> yeah
[00:11:13] <jmkasunich> what makes me shudder is that there is code all over the place that tests, sets, and resets the source variable
[00:11:24] <jmkasunich> that kind of global stuff is what makes bugs
[00:11:40] <jmkasunich> and I try to centralize it as much as possible
[00:11:46] <alex_joni> I understand
[00:12:30] <jmkasunich> maybe thats not possible in this case though...
[00:12:44] <alex_joni> I think it is
[00:12:49] <jmkasunich> since homing has one condition for being "done", and jogs have another, and wheels have another
[00:13:14] <alex_joni> lets put homing aside for a minute
[00:13:31] <alex_joni> jogs and wheels end when the tp_active == 0
[00:13:32] <alex_joni> right?
[00:13:44] <jmkasunich> yes
[00:13:56] <jmkasunich> but homes don't
[00:14:12] <alex_joni> ok, and for homing it shouldn't matter I think
[00:14:24] <alex_joni> even if TP clears it, I will set it back on in the same cycle
[00:14:42] <alex_joni> when the check in do_homing() is run
[00:15:01] <jmkasunich> but....
[00:15:03] <jmkasunich> shudder
[00:15:11] <alex_joni> I know..
[00:15:37] <jmkasunich> the idea of one piece of code clearing something because "I know that some other code 1000 lines away will set it again before something goes wrong" is just wrong
[00:15:59] <jmkasunich> too fscking many globals
[00:16:09] <alex_joni> maybe the TP shouldn't clear the SOURCE_HOME
[00:16:10] <jmkasunich> struct members actually, but we're using them like globals
[00:16:24] <jmkasunich> it should either always clear, or never clear
[00:16:40] <jmkasunich> source specific behavior should not be embedded in the tp
[00:17:11] <jmkasunich> (I'm coming around to your original plan - the tp should leave it alone and let the "users" of the TP set and clear it)
[00:17:55] <alex_joni> I guess it can be done in both ways.. but you would still have lots of places to set it.. and a mess inside the TP to clear it
[00:18:24] <jmkasunich> I'm seeing references to free_tp_source in way too many places
[00:18:36] <jmkasunich> hit a limit, gotta clear it
[00:18:39] <jmkasunich> disable an axis, gotta clear it
[00:19:33] <alex_joni> maybe I overdid it..
[00:19:48] <alex_joni> most 'sources' only care if the TP is already active
[00:19:55] <alex_joni> or at least enabled
[00:20:21] <jmkasunich> originally, the interface to the free mode tp had: target pos, velocity, and enable
[00:20:23] <alex_joni> so if the TP is not enabled nor active, it should just overwrite the source with it's own
[00:20:23] <jmkasunich> and returned active
[00:21:24] <alex_joni> jmkasunich: get what I'm saying?
[00:21:57] <alex_joni> but I think that way (even if the code is clearer) is more error-prone
[00:22:09] <jmkasunich> yes
[00:22:48] <alex_joni> and of course HOME is the exception where even if it's not enabled nor active, one cannot overwrite
[00:24:41] <jmkasunich> I need to think on this some more
[00:24:57] <alex_joni> ok, me too
[00:25:01] <alex_joni> (during my sleep :P)
[00:37:12] <alex_joni> cradek: http://pastebin.ca/400937
[00:38:34] <alex_joni> anyways.. off to bed now
[00:38:47] <cradek> mine works!
[00:39:27] <jmkasunich> have you tried varying the jog-scale parameter?
[00:39:38] <cradek> nope
[00:39:57] <jmkasunich> I think if the jog-per-click is more than can be achieved in one (or maybe 2) servo cycles, it will get cut short
[00:40:00] <alex_joni> cradek: you can catch it only jogging very slowly
[00:40:15] <jmkasunich> set jog-scale to something big, like 0.050 per click, then turn the wheel one click
[00:40:21] <jmkasunich> I bet you don't get the full 0.050
[00:40:23] <cradek> argh
[00:41:09] <cradek> I always miss something - very frustrating
[00:41:19] <alex_joni> cradek: this is/was my bug
[00:41:30] <cradek> yeah but I "tested" it for you
[00:41:40] <alex_joni> clearing out free_tp_enable without checking that active is not 0
[00:42:00] <cradek> so it only bothers jogwheels?
[00:42:05] <alex_joni> cradek: yeah
[00:42:07] <alex_joni> and xemet
[00:42:31] <cradek> ok, maybe next weekend we'll fix it :-/
[00:42:32] <alex_joni> who uses some funky joystick -> sim-encoder -> encoder -> jogwheel jogging scheme
[00:44:23] <cradek> well if we had no bugs, we'd be out of our jobs
[00:44:31] <jepler> yeah we wouldn't get paid
[00:44:37] <alex_joni> haha
[00:48:00] <jepler> I need to figure out what to do in AXIS about incremental jogs with linear and rotary axes
[00:48:14] <jepler> it used to just be inconvenient, now it's downright deceptive
[00:48:23] <jmkasunich> Jymmm is such an idiot, why do I get pulled into conversations with him
[00:48:25] <jepler> (it says I'll get a 1mm jog on "A"?)
[00:49:30] <SWPadnos> it's somewhat deceptive to havea setting in the ini file that tells emc whether an axis is LINEAR or ANGULAR as well ...
[00:49:50] <jmkasunich> alex_joni: after thinking about it a bit - I'm still less than thrilled with the way the free tp source stuff works, but I can't really some up with anything better
[00:50:17] <jmkasunich> I do NOT think we should have the TP clear the source flag (even though I said we should earlier - I changed my mind)
[00:50:38] <alex_joni> jmkasunich: :(
[00:50:51] <alex_joni> maybe we'll come up with something better lateron
[00:51:15] <jepler> SWPadnos: that is really a piece of joint information .. consider scara, with rotary joints 0 and 1, and linear joint 2
[00:51:42] <jepler> SWPadnos: the gui should use that when jogging in joint mode
[00:51:46] <alex_joni> jepler: yeah, but afaik no-one uses that information right now
[00:51:49] <SWPadnos> ok - that makes sense
[00:52:09] <SWPadnos> right - for EMC, axes 0-2 are linear and 3-5 are rotary
[00:52:18] <SWPadnos> kins can do whatever it wants
[00:53:23] <jepler> it would be better if kinematics was able to communicate the rotary vs linear nature of joints back to the GUI, rather than forcing the integrator to write it in the inifile .. but that's for another day, after the GUIs actually use the information
[00:53:57] <SWPadnos> heh
[00:54:44] <jepler> I guess that on machines with 4+ axes, or with rotary joints, I should show two "incremental jog distance" comboboxes, but that turns the keystroke shortcuts (c, i, and I) into a mess
[00:55:11] <alex_joni> lets all use mm and degrees :D
[00:56:00] <alex_joni> then all UNITS are 1.0 :)
[00:56:30] <jepler> alex_joni: that's not compatible with all our users
[00:56:49] <alex_joni> jepler: I was joking.. hope you know that
[00:57:00] <jepler> alex_joni: my remark was supposed to read as a joke too
[00:57:15] <alex_joni> * alex_joni is tired
[00:57:15] <SWPadnos> well, mm/deg are the EMC way - inch users can take a hike ;)
[00:57:23] <alex_joni> 02:49 * alex_joni is tired
[00:58:01] <jepler> SWPadnos: it would fit with the emc2 philosophy as told by paul corner (hi paul)
[00:58:16] <jepler> bbl
[00:58:22] <SWPadnos> yes - I've had time to - uh - catch up on the lists ...
[01:08:40] <jmkasunich> ok, back to the jog wheel thing
[01:08:51] <jmkasunich> alex proposed a fix that I think I agree with
[01:09:03] <jmkasunich> I want to do a further review of the free tp source stuff
[01:09:09] <jmkasunich> then I'll commit
[01:11:45] <jmkasunich> eww... ALLCAPS for the name of the enum typdedf
[01:11:48] <jmkasunich> typedef
[01:12:33] <jmkasunich> even though it follows 3 other enum typedefs that don't use allcaps
[01:12:46] <jmkasunich> must.... resist.....
[01:13:29] <SWPadnos> resist
[01:13:41] <SWPadnos> you are stronger than the all-caps
[01:13:42] <jmkasunich> resisting
[01:18:52] <jmkasunich> this is broken
[01:19:02] <jmkasunich> /* if any joint is homing then we're not allowed to jog */
[01:19:00] <jmkasunich> if (joint->free_tp_source == FREE_TP_SOURCE_HOME) break;
[01:19:33] <jmkasunich> that line does NOT forbid a jog if any joint is homing, only if this joint is homing
[01:19:41] <jmkasunich> (it only checks this joint)
[01:19:49] <SWPadnos> hmmm
[01:20:04] <cradek> iirc, I noticed that too, and he pointed me to the rest of the code, which was elsewhere
[01:20:06] <jmkasunich> could be that the homing code sets all joint sources to FREE_TP_SOURCE_HOME, haven't gotten that far
[01:20:16] <jmkasunich> yeah, thats what bugs me about this whole thing
[01:20:18] <cradek> yeah that must be the trick
[01:20:22] <alex_joni> jmkasunich: that's correct
[01:20:23] <jmkasunich> its scattered all over the place
[01:20:33] <jmkasunich> I thought you were sleeping
[01:20:34] <alex_joni> * alex_joni goes back to sleeping
[01:20:36] <cradek> alex_joni: you're asleep
[01:20:37] <cradek> haha
[01:20:56] <alex_joni> I can still keep a watchfull eye in here.. even while sleeping
[01:21:06] <cradek> I do that sometimes too
[01:21:40] <alex_joni> luckyly I don't always sleep with my eye closed
[01:23:56] <jmkasunich> this is scary - I'm thinking about something that might be called a method function
[01:24:20] <jmkasunich> instead of "joint->free_tp_enable=1; joint->free_tp_source=FOO"
[01:24:37] <jmkasunich> start_free_move(joint, dest, vel, FOO)
[01:24:54] <jmkasunich> and "disable_free_tp(joint)"
[01:25:25] <jmkasunich> then all the code that decides whether you are allowed to start a move of type FOO would be in one place
[01:26:00] <SWPadnos> ooooooh - OO!
[01:26:16] <jmkasunich> I said it was scary
[01:26:47] <jmkasunich> there would need to be more functions than that
[01:27:03] <jmkasunich> its still a mess
[01:27:24] <jmkasunich> jog moves need to "cancel" the source of the move when it finishes, so that subsequent moves from other sources can run
[01:27:35] <SWPadnos> I'd add to the discussion, but I'm never what "fre" or "teleop" or those kinds of things mean
[01:27:39] <SWPadnos> free
[01:27:48] <SWPadnos> gah - I can't think or type, can I
[01:27:51] <jmkasunich> homing moves should NOT cancel the source, because there might be another homing move soon
[01:28:09] <jmkasunich> ignore teleop
[01:28:19] <SWPadnos> EMC1 supported HOME_OFFSET, right?
[01:28:21] <jmkasunich> free is the mode that you are in when you are not doing mdi or a program
[01:28:31] <jmkasunich> yes, as does emc2
[01:28:56] <jmkasunich> thats kind of changing the subject a bit ;-)
[01:28:58] <SWPadnos> ok - just wondering if that was an addition - there were several for EMC2, right?
[01:29:10] <SWPadnos> not intentionally ;)
[01:29:25] <jmkasunich> well
[01:29:33] <jmkasunich> free = the mode that you are in when jogging, or homing
[01:29:36] <SWPadnos> that means that for a long time (forever), homing could have resulted in multiple moves
[01:29:46] <jmkasunich> sure
[01:29:55] <jmkasunich> nothing new there
[01:30:08] <SWPadnos> right - that's what I was checking on :)
[01:30:16] <jmkasunich> and for a long time, I bet you could have done a jog right in the middle of a home and busted things nicely
[01:30:28] <jmkasunich> but what you could have done before is irrelevant
[01:30:55] <jmkasunich> we're trying to find a clean and bug-resistant way to enforce the following rules:
[01:31:28] <jmkasunich> 1) when any axis is homing (not just during a homing move, but during the entire process), prohibit keyboard jogs and wheel jogs on all axes
[01:32:07] <jmkasunich> 2) when a particular axis is doing a keyboard jog, prohibit wheel jogs on that axis (and I think homes on all axes - implied by 1)
[01:32:31] <jmkasunich> 3) when a particular axis is doing a wheel jog, prohibit keyboard jogs on that axis (and I think homes on all axes, implied by 1)
[01:32:55] <jmkasunich> so far its been coded twice by two people and both times we've found bugs
[01:33:05] <jmkasunich> part of the problem is that the code is in lots of places
[01:33:15] <jmkasunich> and the rules are not spelled out in any one place
[01:33:16] <SWPadnos> and of course, neither jogging nor homing is allowed when running a program, or when running an MDI line?
[01:33:39] <jmkasunich> yeah, but that is covered - when you are doing those things, you aren't in "free" mode
[01:33:38] <SWPadnos> ie, not free TP mode (?)
[01:33:41] <SWPadnos> ok
[01:34:20] <jmkasunich> the mode switch logic already selects between the output of the regular TP and the simpler single axis free mode tp based on mode
[01:34:27] <jmkasunich> (there is one free mode tp per axis)
[01:34:32] <SWPadnos> multiple joints can be homing at once, right?
[01:34:35] <jmkasunich> per joint to be precise about it
[01:34:37] <SWPadnos> ok
[01:34:40] <jmkasunich> yes
[01:34:53] <jmkasunich> multiple axes can be jogging at once too
[01:34:56] <SWPadnos> so this is a per-joint issue then
[01:35:08] <jmkasunich> and you can be doing a wheel jog on one with a keybord jog on another at the same time
[01:35:10] <SWPadnos> it can cause issues when things are shared
[01:35:23] <SWPadnos> but that's not necessarily a problem for the TP
[01:35:31] <jmkasunich> the wheel vs. keyboard jog lockout is a per-joint thing
[01:35:38] <jmkasunich> the jog vs homing lockout is global
[01:35:58] <SWPadnos> as written or as desired?
[01:36:00] <jmkasunich> the free mode tps for each joint are completely decoupled from each other
[01:36:10] <jmkasunich> as desired
[01:36:24] <jmkasunich> as written, I'm not at all sure all of those rules are enforced
[01:36:41] <SWPadnos> why no Z jogging when X is homing? (just curious about the reasons)
[01:36:42] <jmkasunich> especially the parenthesized parts of rules 2 and 3
[01:37:12] <jmkasunich> example is the best way to explain it
[01:37:14] <jmkasunich> lathe
[01:37:32] <jmkasunich> home sequencing is set up so that you have to home the cross-slide before you home the saddle
[01:37:40] <jmkasunich> so the tool will clear the chuck
[01:38:00] <SWPadnos> ok
[01:38:03] <jmkasunich> if you allow them to home the cross-slide, then jog it while the saddle is homing, they can jog the tool into hitting the chuck
[01:38:30] <cradek> that's not a jogging problem - it's a homing problem
[01:38:42] <jmkasunich> its a jog lockout problem
[01:38:44] <cradek> we need "only home axis A when axis B is (stays) at home"
[01:38:55] <SWPadnos> yes
[01:38:59] <cradek> yes which?
[01:39:14] <SWPadnos> yes to the need for "conditions" for homing a joint
[01:39:18] <SWPadnos> (your statement)
[01:39:19] <jmkasunich> we need to enforce one of two rules:
[01:39:22] <cradek> what you're saying is you can home A, then move it, then home B - I'm saying the problem is bigger than that
[01:39:26] <jmkasunich> 1) lock out jogs while homing
[01:39:36] <jmkasunich> 2) abort (not just lock out) homing if somebody jogs
[01:40:14] <cradek> I think you're missing the big picture (which is usually my job)
[01:40:27] <SWPadnos> actually, I think we may need "only home A if B is at home" and "if home A is requested, home B then A"
[01:40:28] <jmkasunich> we may want a rule that says "lockout homing X if Z isn't at home"
[01:40:42] <cradek> yes
[01:40:51] <jmkasunich> SWPadnos: the latter of your two rules exists already
[01:40:51] <SWPadnos> yes which? :)
[01:40:54] <cradek> that stuff works correctly if you use the home sequence (home all) today, but you can mess it up
[01:40:54] <jmkasunich> sort of
[01:41:17] <SWPadnos> you can "home all", or you can home #w in the sequence, AFAIK
[01:41:18] <jmkasunich> right - if you use home all, and don't jog during the sequence, you are good
[01:41:19] <SWPadnos> #2, that was
[01:41:21] <cradek> both (I think you said the same things)
[01:41:34] <jmkasunich> but if you home one axis manually, then another, I think the home-all sequencing rules are ignored
[01:41:46] <SWPadnos> if I have X,Y,Z set up as 1,2,3 in sequence, I can still home Z separately
[01:41:54] <SWPadnos> right
[01:41:54] <cradek> yes they are
[01:42:09] <jmkasunich> right, indivudual homes completely ignore the sequence rules
[01:42:23] <jmkasunich> whether that is a bug or not is only loosly related to this problem
[01:42:23] <cradek> and that might be a bug -- but I just realized that's another issue - you're working on jog lockouts now
[01:42:33] <cradek> agreed
[01:42:37] <cradek> sorry
[01:42:40] <cradek> * cradek goes back in his hole
[01:42:49] <jmkasunich> don't go (or be sorry)
[01:43:16] <SWPadnos> yeah - I had asked a homing question anyway (why can't I jog another axis while homing)
[01:43:27] <SWPadnos> so it's not your fault :)
[01:43:44] <jmkasunich> SWPadnos: last week, we debated that, and reached a concensus that any home should lock out all jogs
[01:43:46] <cradek> I think the consensus last time that came up was "you'd have to be crazy to do that"
[01:43:57] <SWPadnos> ok by me
[01:44:01] <cradek> brb
[01:44:10] <jmkasunich> the only proposed reason for jogging during a home was to try to "steer" the tool around obstacles
[01:44:32] <SWPadnos> sure, or "preposition" the next axis a bit
[01:44:37] <jmkasunich> and the decision was "if the operators sees that the tool is gonna hit something, its not time to play driving games, hit the damned estop"
[01:44:56] <SWPadnos> that's a good point
[01:45:16] <jmkasunich> hes as likely to drive it into trouble as out, especially if he's panicing
[01:45:31] <jmkasunich> so, thats how we came up with the ruiles
[01:45:32] <jmkasunich> rules
[01:45:46] <jmkasunich> the problem now isn't the rules themselves, its the implementation
[01:45:55] <SWPadnos> oh man. set_operating_mode is a big ugly function
[01:46:32] <jmkasunich> yep
[01:46:42] <jmkasunich> from the comments at the top of the file, about set_operating_mode:
[01:46:43] <jmkasunich> It is basically a state machine, with
[01:46:43] <jmkasunich> a current state, a desired state, and rules determining when the
[01:46:43] <jmkasunich> state can change. It should be rewritten as such, but for now
[01:46:43] <jmkasunich> it consists of code copied exactly from emc1.
[01:46:50] <rayh> As we create these rules, we ought to think of the long range idea of making them adjustable by the end user.
[01:47:04] <SWPadnos> yep
[01:47:16] <SWPadnos> though I suspect that will be a long ways off
[01:47:57] <SWPadnos> hmmm. actually, motion already reads some things from the ini file, but not the RT part (I thnk)
[01:47:59] <rayh> Right but if we make rules now with the thought of some way to enable or disable them it will help us then.
[01:48:03] <SWPadnos> yep
[01:48:12] <rayh> IMO
[01:48:22] <jmkasunich> rayh: the problem right now is that the rules aren't even written down in any one place
[01:48:55] <SWPadnos> well, given a particular state and a target state, there are three things you can do:
[01:48:59] <jmkasunich> some of them are not going to be subject to change anyway
[01:49:00] <rayh> Yep. And they are scattered all over the code.
[01:49:02] <SWPadnos> 1) immediately error
[01:49:06] <SWPadnos> 2) wait, then change state
[01:49:16] <SWPadnos> 3) abort the current state and immediately change state
[01:49:22] <rayh> oh I think we will need to make rules selectively enforcable.
[01:49:25] <SWPadnos> are there any other valid actions?
[01:49:27] <jmkasunich> for example, wheel jogs and keyboard jogs conflict with each other, as in "axis runs away if you do that"
[01:49:57] <SWPadnos> that shouldn't happen (but I'm not disputing that it does)
[01:50:25] <jmkasunich> SWPadnos: wheel jogs say "move the target position by 0.001 for every click, and go there as fast as you can"
[01:50:49] <SWPadnos> any jog command, from wheel or keyboard, should effectively abort the previous move and create a new one to the new target position at a target vel
[01:51:02] <jmkasunich> keyboard jog (continuous one) says "move the target position to the end of the axis (or beyond) and go there at rate X"
[01:51:28] <jmkasunich> SWPadnos: not that simple
[01:51:34] <SWPadnos> I'm sure it's not :)
[01:51:41] <SWPadnos> (but it seems like it should be :) )
[01:51:50] <jmkasunich> when a wheel jog click arrives, it doesn't set the new target to "where I am now + one click"
[01:52:00] <jmkasunich> it sets it to "current target + one click"
[01:52:17] <SWPadnos> at full speed ...
[01:52:23] <jmkasunich> well, if a keyboard jog just set the target to end of axis, you don't want a wheel jog
[01:52:56] <SWPadnos> setting the target to a light year away is the problem, not the wheel jog
[01:52:59] <jmkasunich> trust me when I say wheel jogs and keyboard jogs need to be interlocked
[01:53:12] <jmkasunich> how else do you expect to do a continuous keyboard jog?
[01:53:18] <SWPadnos> that's a hack to get continuous jogging from something that may be unreliable - the X/keyboard event stream
[01:53:40] <rayh> I tend to favor a jogwheel mode that locks out any other jog mode.
[01:53:43] <jmkasunich> granted
[01:53:50] <jmkasunich> but its a hack that won't be going away any time soon
[01:53:51] <SWPadnos> I'm not sure how else to do it, but I think that's the problem
[01:54:06] <SWPadnos> I'm not opposed to having the two types be mutually exclusive though
[01:54:11] <jmkasunich> rayh: you mean an explicitly selected by the user mode?
[01:56:13] <rayh> Right.
[01:56:29] <jmkasunich> that would entail changes to all the GUIs
[01:56:46] <jmkasunich> what is the reasoning behind wanting a special mode for wheel jogs?
[01:56:46] <rayh> If I were building a machine with a handwheel right now I'd do that in cl if I couldn't do it with a HAL pin.
[01:57:17] <rayh> So that a user does not accidently rub against the handwheel and cause unwanted motion.
[01:57:25] <SWPadnos> there are separate "jog-enable" pins for each axis (joint?)
[01:57:35] <jmkasunich> SWPadnos: yes
[01:57:54] <SWPadnos> so you can do that in CL, but I don't think CL can find out if a keyboard jog is in process
[01:57:57] <jmkasunich> rayh: so its not so much "lock out all other jogs" as it is "lock out the wheel to avoid accidental movement"
[01:58:29] <jmkasunich> right now, each jogwheel input has an enable
[01:58:33] <rayh> That is essential but I still favor locking out any other jog during handwheel.
[01:58:49] <rayh> I think of handwheel as an incremental jog.
[01:58:52] <SWPadnos> ok - that's what we're discussing - the free TP should do that already
[01:59:09] <SWPadnos> I was just wondering why you couldn't mix keyboard and wheel jogging
[01:59:10] <jmkasunich> the intent is both to allow you to select which axis the wheel will move _and_ to allow you to prevent any movement by disabling them all
[02:00:11] <jmkasunich> simplest implementation is a "wheel axis selector" switch that has settings for X, Y, Z, and NONE
[02:00:17] <jmkasunich> when in NONE, the wheel does nothing
[02:01:04] <jmkasunich> that can be done with a real 4 pos switch (hook the jog enable to three positions) or with CL, or with a pyvcp radiobutton
[02:01:06] <rayh> The x,y,z,none would go a long way toward safety.
[02:01:59] <rayh> and it none is modal when any other jog takes place it would satisfy me. But then I'm not easily satisfied concerning jogs.
[02:02:30] <jmkasunich> the first sentence doesn't parse for me ;-)
[02:02:36] <jmkasunich> the second one makes sense tho
[02:02:45] <SWPadnos> I think jmk was describing exactly what you want, and I questioned that necessity
[02:03:06] <SWPadnos> but hey - it's OK with me, so I don't think there's a problem
[02:03:14] <jmkasunich> ok, lemme try putting it into differnet words
[02:03:23] <SWPadnos> (not that there would be even if it weren't OK with me :) )
[02:03:52] <jmkasunich> the current rules would allow you to hit the up arrow to jog Y, then let go, and as soon as the axis stops, grab the wheel and turn it to jog Y (assuming Y is selected)
[02:04:28] <jmkasunich> I think ray is saying that after you release the up arrow you would have to make some other explicit command to enable the jogwheel, even if the wheel selector switch is already on Y
[02:05:06] <jmkasunich> and once you've made that command, then ONLY the wheel would work, the arrows would be disabled
[02:05:50] <jmkasunich> is that what you mean rayh
[02:05:54] <rayh> Yes
[02:06:06] <SWPadnos> ok - I didn't get that last part
[02:06:22] <jmkasunich> which last part?
[02:06:42] <SWPadnos> about not being able to use the keyboard again until you "exit" wheel jog mode
[02:06:56] <SWPadnos> by doing something more explicit than stopping turning the wheel
[02:07:04] <jmkasunich> sounds like you get it just fine
[02:07:15] <jmkasunich> or do you mean you don't understand why ray wants it?
[02:07:17] <SWPadnos> I do now :)
[02:07:31] <SWPadnos> no - I didn't get it until you summarized
[02:07:34] <SWPadnos> now I get it
[02:07:35] <jmkasunich> oh
[02:07:46] <jmkasunich> me, I don't understand why rayh wants it ;-)
[02:07:56] <SWPadnos> safey, of course
[02:07:59] <SWPadnos> +t
[02:08:25] <jmkasunich> today, the arrows work any time you are in free mode
[02:08:34] <SWPadnos> there's no guarantee that the jogwheel and the keyboard will be close to each other
[02:08:45] <rayh> * rayh does not understand free mode.
[02:08:54] <jmkasunich> the wheel inputs can be explicitly enabled or disabled by hal pins, thus by a selector switch or whatever
[02:08:54] <rayh> I do understand manual, auto, mdi
[02:09:05] <SWPadnos> free mode == manual, it seems
[02:09:10] <jmkasunich> yes, pretty much
[02:09:21] <rayh> ??
[02:09:35] <SWPadnos> when in manual lmode, the "free TP" is in control
[02:09:42] <jmkasunich> motion controller modes are free, teleop, and coord
[02:09:50] <jmkasunich> user modes are manual, mdi, and auto
[02:10:16] <jmkasunich> auto and mdi are both "coord" in the motion controller - complete coordinated motion under control of the interp
[02:10:41] <jmkasunich> manual mode on a trivkins machine = free mode in the motion controller - completely independent control of each joint
[02:11:02] <rayh> Does an x3 block use coordinated
[02:11:19] <SWPadnos> yes, that's MDI
[02:11:23] <SWPadnos> (or auto)
[02:11:41] <jmkasunich> yes, any g-code is coordinated
[02:11:59] <rayh> That is different than it used to be?
[02:12:02] <jmkasunich> nope
[02:12:05] <SWPadnos> ok, and "teleop" is "free" mode for non-trivkins? (ie, world jog mode)
[02:12:12] <jmkasunich> SWPadnos: exactly
[02:12:27] <SWPadnos> ok - thanks.
[02:12:44] <jmkasunich> teleop takes commands like "jog X", but to actually jog "X" on a non-trivlial machine might mean moving three motors
[02:12:50] <SWPadnos> theoretically, teleop is world jog and free = joint jog, but for trivkins they're the same
[02:12:53] <jmkasunich> so they're not decoupled like free mode is
[02:12:58] <rayh> There was a time when task chose whether a motion was coordinated or not.
[02:12:59] <jmkasunich> exactly
[02:13:34] <jmkasunich> rayh: ?
[02:14:21] <jmkasunich> all mode change commands come thru task
[02:14:56] <rayh> Not mode. It was simply a matter of a single axis move being different than a multi axis move.
[02:15:12] <jmkasunich> I don't think they are anymore
[02:15:36] <rayh> thanks for clarifying that for me.
[02:15:39] <SWPadnos> rayh, single/multi axis or single/multi-joint?
[02:15:45] <jmkasunich> assuming you start from X0 Y0 Z0, these moves "X2" and "X2 Y0.00000001" are treated exactly the same
[02:16:03] <jmkasunich> and of course "X2 Y2" is treated the same too
[02:16:05] <rayh> I'll look back and test some of the stuff I did with 2.14 and sherline's rotary.
[02:16:43] <rayh> Because we could treat a single axis move as different motion than a multi axis move.
[02:17:01] <SWPadnos> is there a reason to do that?
[02:17:06] <jmkasunich> I dunno, but we digress
[02:17:18] <SWPadnos> ie, why does the user care how it's treated as long as the correct axis moves?
[02:17:27] <SWPadnos> jmkasunich, indeed
[02:17:30] <SWPadnos> sorry about that
[02:17:31] <jmkasunich> any move that comes from G-code (program or MDI) is handled in auto mode, and that means its handled by the "main" TP
[02:17:50] <jmkasunich> in manual mode, there are individual single axis TPs for each joint
[02:17:52] <rayh> We were able to handle accel and max vel differently if only one axis was involved at a time, even from auto or mdi.
[02:18:01] <jmkasunich> all jogs and homes are done by those individual planners
[02:18:18] <SWPadnos> rayh, ok, the new TP does that correctly, do the single axis stuff shouldn't be necessary any more
[02:18:27] <jmkasunich> rayh: you mean if X had higher limits than Y, and the move was X only, it could go faster>
[02:18:30] <jmkasunich> ?
[02:18:49] <rayh> Yes
[02:19:00] <jmkasunich> I'm pretty sure the main TP does the correctly now
[02:19:10] <jmkasunich> even the X2 Y0.001 case works right
[02:19:26] <jmkasunich> if Y has slow limits, but doesn't have to move far, it won't limit the overall move
[02:19:33] <rayh> so an a axis only g0 move might travel at 3600 dpm
[02:19:45] <jmkasunich> I think so
[02:19:54] <rayh> Well sorry I caused the digression.
[02:19:59] <jmkasunich> in any case, that is the "main TP"
[02:19:59] <SWPadnos> yes - for a cartesian machine with equal accel/vels, you can set the TRAJ limits to sqrt(3)*axis_limits, and it'll correctly limit depending on the direction of the move
[02:20:01] <rayh> thanks for the info.
[02:20:13] <jmkasunich> lets go back to jogs
[02:20:46] <jmkasunich> it sounds like Ray would like to be able to explicitly disable keyboard jogs, wheel jogs, or both
[02:20:58] <jmkasunich> is that correct?
[02:21:20] <rayh> Yes
[02:21:23] <SWPadnos> addition of a single pin "key-jog-enable" would allow for that
[02:21:31] <jmkasunich> ok, wheel jogs already can do that
[02:21:48] <jmkasunich> currently you can't disable keyboard jogs
[02:21:55] <SWPadnos> motion would still need to prevent mixing of the different types (possibly based on settable policy later)
[02:22:00] <jepler> and a signal that would let you know that a keyboard jog had taken place, to reset the wheel jog pin
[02:22:17] <jepler> er, a pin
[02:22:21] <jmkasunich> actually, I don't think the motion controller is the right place to disable keyboard jogs
[02:22:33] <SWPadnos> no - you're right
[02:22:46] <jmkasunich> what if you have more than one keyboard (more than one GUI)? I can see you wanting to disable keyboard jogs from one GUI but not another
[02:22:55] <SWPadnos> motion should only do the work of moving the axes. something else should decide when to send "work packets" along
[02:23:24] <jmkasunich> the wheel(s) connect direct to motion. that is a neccessity to get smooth motion from a wheel
[02:23:39] <jmkasunich> so wheel jog enables are hal pins connect to motion, not much we can do about that
[02:23:58] <jmkasunich> keyboard jog disable should be a GUI function I think
[02:24:04] <jmkasunich> rayh, your thoughts>?
[02:24:47] <rayh> It's late for me to think.
[02:24:57] <jmkasunich> ;-)
[02:25:17] <SWPadnos> strangely, me too. must have been too much driving or lack of sleep or something
[02:25:23] <jmkasunich> thinking about multiple GUIs hurts my head....
[02:25:23] <rayh> I guess there ought to be some sort of protection at the command end of motion to filter conflicts.
[02:25:35] <jmkasunich> GUI A sends "jog start" (user presses key)
[02:25:47] <jmkasunich> GUI B sends "jog start" (user presses key)
[02:25:55] <rayh> I've run multiple guis a lot to test
[02:26:02] <jmkasunich> GUI B sends "jog stop" (user releases)
[02:26:16] <jmkasunich> user at GUI A says "why did it stop"?
[02:26:42] <SWPadnos> and many ways to screw with the system as well
[02:26:59] <jmkasunich> worse - user A hits up arrow, and user B hits down arrow
[02:27:00] <rayh> We can create some major risks using pyvcp and a "typical" gui.
[02:27:24] <SWPadnos> run 2 GUIs on one machine, press jog key, click to another program, release key, click on other GUI, jog the other way ...
[02:27:29] <jmkasunich> you mean halui?
[02:27:49] <rayh> The multiple gui ability was intended more so that "suits" in the shop office could watch production rather than run it.
[02:27:58] <SWPadnos> otherwise, it has to be separate machines with a remote GUI in there
[02:28:08] <SWPadnos> (since keyboard focus goes to one UI at a time)
[02:28:21] <rayh> NIST had some pretty big ideas about shop floor networks.
[02:28:37] <SWPadnos> so does fenn, but that's not important right now :)
[02:29:06] <jmkasunich> the NIST philosophy of "everything is a momentary switch" and "control from anywhere" has some nasty gotchas lurking in some of its darker corners
[02:29:28] <rayh> It does.
[02:29:44] <jmkasunich> the suit's GUI needs to be the playskool version
[02:29:52] <jmkasunich> plenty of pretty lites, buttons do nothing'
[02:29:54] <rayh> yep.
[02:30:13] <rayh> That is how I've enabled the few I've done that way.
[02:30:23] <jmkasunich> as usual, this has grown beyond the initial scope
[02:30:35] <rayh> Dan Falck used to feed them all into his Mac cube and run 5 machines from there.
[02:30:36] <jmkasunich> the multi-gui thing doesn't directly effect motion
[02:30:43] <jmkasunich> it knows not where the commands it gets are coming from
[02:30:51] <jmkasunich> that need to be resolved at the task level
[02:31:07] <rayh> exactly
[02:31:27] <jmkasunich> all motion knows is that it gets JOG_INCR, JOG_ABS, or JOG_CONT, the latter followed at some time in the future by AXIS_ABORT
[02:31:29] <rayh> Can a handwheel command a move past a soft limit?
[02:31:36] <jmkasunich> nope
[02:31:57] <rayh> Is that a hard stop or a decel
[02:31:56] <jmkasunich> * jmkasunich checks to be sure
[02:32:24] <jmkasunich> its just like regular jogs - you won't be permitted to command a target position beyond the limit
[02:32:56] <jmkasunich> think of wheel jogs as really pounding on a 0.001 incremental jog key and you have a pretty good idea of how its implemented
[02:33:22] <SWPadnos> wheel can't be set to "continuous"?
[02:33:27] <jmkasunich> (where 0.001 is actually axis.N.jog-scale, and can be changed)
[02:33:39] <jmkasunich> no, what is "continuous" for a wheel?
[02:33:44] <jmkasunich> scale sets the distance per count
[02:33:54] <SWPadnos> dunno ;) that's why I asked
[02:34:08] <jmkasunich> turn it continuously if you want continuous ;-)
[02:34:12] <SWPadnos> but you could set scale to 5 or 10, and get something like continuous
[02:34:12] <SWPadnos> heh
[02:34:34] <jmkasunich> if you set scale to 5, every click of the wheel would move the target position by 5 (inches, mm, whatever)
[02:34:45] <jmkasunich> so a quick spin would jog to the limit
[02:34:59] <jmkasunich> just like if you set incremental jog to 1" and then hit it 50 or 100 times
[02:35:26] <SWPadnos> yep
[02:35:37] <SWPadnos> ok, so what was the original question? :)
[02:35:45] <jmkasunich> jog interlocking
[02:36:11] <jmkasunich> we cannot allow the wheel jogs while a kb jog is in progress, or vice versa
[02:36:36] <SWPadnos> ok, any axis or per axis?
[02:36:47] <jmkasunich> but at the moment, I don't see any reason to prevent a wheel jog as soon as a kb jog ends, or vice versa
[02:36:50] <SWPadnos> (ie wheel in Z while key in X)
[02:36:57] <SWPadnos> ok
[02:37:06] <jmkasunich> per axis, wheel Z while keying X should be OK (IMO()
[02:37:31] <jmkasunich> if a machine builder wants to prohibit that, we should consider giving him the hooks
[02:37:39] <SWPadnos> ok, so if (in motion) don't allow anything
[02:37:40] <jmkasunich> but I don't see a reason to outlaw it from the start
[02:37:46] <SWPadnos> right
[02:37:50] <rayh> With tkemc and x at 9.3125 a 1 inch incremental jog will not move the axis.
[02:38:15] <rayh> It ignores an incremental jog that extends past the soft limit.
[02:38:18] <jmkasunich> right
[02:38:32] <jmkasunich> it also ignores a wheel jog that extends past the limit
[02:38:41] <SWPadnos> perhaps it should jog to the limit instead
[02:38:47] <jmkasunich> of course if your wheel increment is 0.001, you'll be able to get within 0.001 of the limit
[02:38:48] <SWPadnos> (soft limit)
[02:38:54] <jmkasunich> SWPadnos: nope
[02:38:57] <rayh> well that's another days issue.
[02:39:11] <SWPadnos> true - dropped for now
[02:39:15] <jmkasunich> if you are at 9.24, and you are doing 1" incrementals, you should always wind up at X.25
[02:39:32] <jmkasunich> if you aren't allowed to go to 10.25, then don't go at all
[02:39:33] <SWPadnos> ok, I can see that
[02:39:42] <jmkasunich> oops, typo, should have been 9.25
[02:39:48] <SWPadnos> figured ;)
[02:40:19] <rayh> Do you get any accel with jogwheel or is it human accel.
[02:40:27] <jmkasunich> rayh: when you said "thats another days issue", what issue were you talking about?
[02:40:47] <jmkasunich> you get the same accel that applies to all jogs
[02:41:05] <rayh> How that jog increment command beyond soft limit should be interpreter.
[02:41:13] <rayh> Okay. Good.
[02:41:17] <jmkasunich> let me repeat: wheel jogs are just like incremental jogs, except that you can hit the "key" really fast by spinning the wheel
[02:41:40] <rayh> okay.
[02:41:58] <jmkasunich> and usually the increments are smaller ;-)
[02:42:27] <rayh> Gotta run guys. I'll watch the conversation. Thanks
[02:42:32] <jmkasunich> ok
[02:42:44] <jmkasunich> so, back to implementation
[02:43:44] <jmkasunich> we don't need to worry about modes - if an integrator wants separate modes for wheel and keyboard jogging with explicit switching between them, that needs to be done in the GUI and/or task (at least the "block the keyboard jogs" part
[02:43:56] <jmkasunich> and the hal enable pins let them block the wheel jogs
[02:44:18] <jmkasunich> what we do need to worry about is blocking wheel jog from the start of a keyboard jog to the end
[02:44:28] <jmkasunich> blocking keyboard jogs from the start of a wheel jog to the end
[02:44:44] <jmkasunich> blocking homes (on any axis) from the start of any jog on any axis to the end
[02:44:58] <jmkasunich> and blocking any jog on any axis from the start of a home to the end
[02:45:19] <jmkasunich> I think the existing code does 80-95% of that
[02:47:18] <SWPadnos> it seems that any jog only needs to check whether its axis is in motion
[02:47:37] <SWPadnos> no, that's not right
[02:47:39] <jmkasunich> more complex than that
[02:47:56] <jmkasunich> any axis homing, or this axis in motion and I didn't command that motion
[02:47:58] <SWPadnos> yep, if in motion due to this kind of command, then more of this kind of command is OK ...
[02:48:08] <SWPadnos> homing implies motion, doesn't it?
[02:48:15] <jmkasunich> no
[02:48:17] <SWPadnos> ok
[02:48:23] <SWPadnos> right - any axis homing
[02:48:25] <jmkasunich> homing Z, somebody tries to jog X
[02:48:41] <jmkasunich> plus, a home sequence has several moves with pauses in between
[02:48:47] <jmkasunich> don't want to allow jogs during the pauses
[02:49:12] <jmkasunich> I think we need a separate "homing in progress" flag, and then the entire homing lockout can be handled easily
[02:49:33] <jmkasunich> well, locking out jogs during homing
[02:49:45] <jmkasunich> locking out homing during jogs is a wee bit trickier
[02:49:56] <jmkasunich> gotta test all axes to see if any are jogging
[02:50:26] <SWPadnos> unless homing is "higher priority",a nd can cancel a jog in progress
[02:50:33] <jmkasunich> right
[02:50:40] <jmkasunich> and in fact thats what it does
[02:50:52] <SWPadnos> which may be easier, even if it isn't desired
[02:51:03] <jmkasunich> except that it doesn't change the FREE_TP_SOURCE variable that was recently added
[02:51:09] <jmkasunich> another bug in this implementation
[02:51:35] <SWPadnos> the ...SOURCE is supposed to be "whatever caused the motion to occur"?
[02:51:40] <jmkasunich> yes
[02:52:17] <jmkasunich> so "if ( source != ME ) and ( source != NONE) then { I can't do nuttin }
[02:52:31] <SWPadnos> yep
[02:52:35] <jmkasunich> but that results in a proliferation of code
[02:52:48] <jtr> if you have two jogwheels, should you be able to move two axes, like manual X and Y?
[02:52:57] <jmkasunich> everywhere that free mode motion can get canceled, gotta remember to reset the source to none
[02:53:04] <jmkasunich> jtr: yes
[02:53:23] <jmkasunich> you can do that in hal - connect one wheel to x, one to y, and enable both at the same time
[02:53:27] <SWPadnos> wouldn't that be in "set_motion_mode" or whatever that routine was?
[02:53:39] <jmkasunich> (the usual approach is connect one wheel to x and y, but enable only one at a time)
[02:53:44] <SWPadnos> or is it "there, plus a bunch of other places"... ?
[02:53:57] <jmkasunich> there, plus a bunch of other places
[02:54:00] <SWPadnos> oh
[02:54:04] <SWPadnos> good night :)
[02:54:15] <jmkasunich> running away?
[02:54:46] <jmkasunich> fer instance, in command.c, when a HOME command is recieved, it cancels any jogs:
[02:54:55] <jmkasunich> /* abort any movememt (jog, etc) that is in progress */
[02:54:54] <jmkasunich> joint->free_tp_enable = 0;
[02:55:06] <SWPadnos> yeah - I am tired - haven't gotten a good night's sleep in several days
[02:55:37] <jmkasunich> this is in the ABORT command:
[02:55:37] <jmkasunich> /* tell joint planner to stop */
[02:55:37] <jmkasunich> joint->free_tp_enable = 0;
[02:55:37] <jmkasunich> /* discard any active source */
[02:55:37] <jmkasunich> joint->free_tp_source = FREE_TP_SOURCE_NONE;
[02:56:05] <jmkasunich> the additional line to clear free_tp_source is the recent addition, and didn't get added in the HOME command
[02:56:19] <jmkasunich> the fact that it needs to be added in all those places is a mis-feature
[02:57:28] <jmkasunich> goodnight
[02:57:37] <SWPadnos> you can't have some joints in free mode and others in teleop / coord
[02:57:52] <jmkasunich> no, the mode applies to the motion controller as a whole
[02:57:53] <SWPadnos> so there shouldn't need to be a separate mode flag for each joint
[02:58:08] <jmkasunich> all of this is free mode only
[02:58:19] <SWPadnos> there does need to be a separate source, of course (but only if you're allowed to jog one axis with keys and another with wheels)
[02:58:38] <SWPadnos> joint->free_tp_enable leads me to believe that some of that is duplicated per joint ...
[02:59:05] <jmkasunich> free_tp_enable is a per-joint thing
[02:59:42] <jmkasunich> although I guess you _could_ enable them all at the same time
[03:00:03] <jmkasunich> right now, when you go into free mode, the free planners remain disabled, until somebody requests an actual move
[03:00:10] <SWPadnos> it seems that way to me, but at this point, I wouldn't assume that I'm not missing anything
[03:00:15] <jmkasunich> somebody = homing, kb jog, wheel jog
[03:00:21] <SWPadnos> ok, that makes sense
[03:00:39] <SWPadnos> and if any free planner is enabled, you can't switch back (?)
[03:00:45] <jmkasunich> you can
[03:00:47] <jmkasunich> and you do
[03:00:52] <jmkasunich> for example - JOG_CONT
[03:01:05] <jmkasunich> sets the target position to "way out there" and enables the free planner
[03:01:13] <jmkasunich> (also sets a velocity limit)
[03:01:29] <jmkasunich> when you release the key, it sends AXIS_ABORT for that axius
[03:01:34] <jmkasunich> which disables the planner
[03:01:36] <SWPadnos> ok, but can you switch back to AUTO while that move is going?
[03:01:51] <jmkasunich> when you disable the planner, the target position is constantly forced to be the current position
[03:01:55] <SWPadnos> ok
[03:02:01] <jmkasunich> so it decels as fast as it can, then sits there
[03:02:09] <SWPadnos> (implementation-specific, not required operation)
[03:02:40] <LawrenceG> jmkasunich: I got my zero crossing hardware built and tested.... I can send a scope pix if you are interested
[03:02:46] <jmkasunich> if AXIS_ABORT left the joint enabled and just set the target pos to the current pos, the joint would decel to a stop, then back up to get to the position where it was when the abort arrived
[03:02:47] <SWPadnos> hmmm. I should hit the sack. I actually have a headache, which is pretty rare for me
[03:03:01] <jmkasunich> LawrenceG: unfortunately I got busy
[03:03:15] <jmkasunich> maybe in a couple of days
[03:03:25] <LawrenceG> no problem... I love the way little glitches get fixed here
[03:03:25] <jmkasunich> SWPadnos: goodnight
[03:03:43] <SWPadnos> night. good luck (you should make better progress without me pestering you anyway :) )
[03:04:03] <jmkasunich> well, I like to be able to throw my thoughts at somebody
[03:04:14] <jmkasunich> cradek should still be awake
[03:04:54] <LawrenceG> I also like to bounce ideas around... it works great until it degrades into design by committee
[03:05:23] <LawrenceG> jmkasunich: what is your email?
[03:05:55] <jmkasunich> jmkasunich at fastmail dot fm
[03:07:46] <LawrenceG> msg on the way.... where is .fm ?
[03:07:51] <jmkasunich> dunno
[03:07:55] <jmkasunich> they are a mail provider
[03:08:11] <jmkasunich> probalby picked fm cause it goes with FastMail
[03:08:36] <LawrenceG> ok... they seem to keep inventing new domains... never a dull moment on the internet
[03:21:35] <jmkasunich> got it
[03:22:06] <tfmacz> LawrenceG: hi there...
[03:22:34] <tfmacz> LawrenceG: can I lock you up for a minute???
[03:37:11] <LawrenceG> nope... out walking the dog
[03:54:08] <cradek> jmkasunich: hmm, did you see stuart's message?
[03:54:17] <jmkasunich> about wheels?
[03:54:22] <cradek> yes
[03:54:23] <jmkasunich> yes, I'm replying now
[03:54:34] <jmkasunich> he hasn't thought through the implications
[03:54:39] <jmkasunich> so I'm gonna dump them in his lap
[03:54:59] <cradek> surely he is mistaken about how the other machines work?
[03:55:06] <jmkasunich> damned if I know
[03:55:26] <cradek> if they work how he says, I'd say they are broken
[03:56:05] <jmkasunich> I'm calling it one of those "can't please all the people all the time" issues, and pointing out how my expectations differ (50 clicks should be 50 x increment in movement always)
[03:56:50] <jmkasunich> pointing out that I won't break my expectations to meet his, that making it selectable would be nice, but that his version is poorly defined and he needs to spec it better
[03:57:03] <cradek> yeah, I'd hate to call him wrong, as he may not be -- but it sounds like emc's jogwheel is working as designed
[03:57:38] <cradek> on the other hand, if you don't want to move the distance equivalent to 10 rotations, why would you spin the knob ten times?
[03:58:33] <a-l-p-h-a> ucs
[04:01:34] <jmkasunich> there...
[04:04:53] <jmkasunich> cradek: you de-lurked, therefore you are drafted
[04:05:14] <jmkasunich> this free_tp_source thing
[04:05:19] <cradek> argh
[04:05:37] <jmkasunich> the homing part is what really bugs me, so I've changed how that part is done
[04:06:12] <jmkasunich> there is now emcmotStatus->homing_in_progress, which goes non-zero at the beginning of an individual home or a home-all sequence, and goes zero again when the whole thing is done
[04:06:43] <jmkasunich> the homing code will not be looping to set free_tp_source for each axis to HOME
[04:07:12] <jmkasunich> instead, the jogs will do "if ( emcmotStatus->homing_in_progress) { don't jog }
[04:07:21] <jmkasunich> I think thats a lot clearer
[04:07:25] <cradek> that does seem less goofy
[04:07:48] <jmkasunich> a command to home already (and always has) aborts any jogs that are in progress
[04:08:07] <jmkasunich> so home vs. jog interlocking is done I think
[04:08:40] <jmkasunich> I'm trying to figure out if free_tp_source is the right way to do wheel vs keyboard lockouts, or if there is something better
[04:10:53] <cradek> I'd just like for us to get everything right at the same time for a decent 2.1 release
[04:10:58] <jmkasunich> lol
[04:11:09] <cradek> I'm actually serious
[04:11:13] <jmkasunich> I know
[04:11:21] <jmkasunich> that wasn't a happy laugh
[04:11:27] <jmkasunich> it was a cynical one
[04:11:56] <cradek> would alex's one line fix make it work? (then trunk can be cleaned up however)
[04:12:03] <jmkasunich> there are just too many places where free_tp_source gets touched
[04:12:26] <jmkasunich> that would solve the problem that was spotted today
[04:12:31] <jmkasunich> I spotted another one already
[04:13:03] <jmkasunich> (one of the places where free_tp_enable is set to zero, free_tp_source is not reset to NONE)
[04:13:14] <jmkasunich> just an oversight, but who knows how many more lurk
[04:14:02] <cradek> I better get to bed. I hope you figure it all out, sorry
[04:14:10] <jmkasunich> thanks a lot
[04:14:45] <jmkasunich> dog's whining to go out...
[04:14:47] <cradek> goodnight
[05:02:26] <jmkasunich> I think I have something much better
[05:02:44] <jmkasunich> instead of trying to use tp_source for all that stuff, I have three flags
[05:03:12] <jmkasunich> emcmotStatus->homing_active is one flag for all axes
[05:03:31] <jmkasunich> joint->kb_jog_active and joint->wheel_jog_active are per axis
[05:03:36] <jmkasunich> per joint, whatever
[05:04:30] <jmkasunich> kb_jog_active is set in three places (starting 3 kinds of jogs, CONT, INCR, ABS), cleared in 1 (when the free TP comes to a stop, it knows all jogs are done) and tested in 1 (before doing a wheel jog)
[05:05:20] <jmkasunich> wheel_jog_active is set in one place (start of wheel jog), reset in 1 place (free TP end of move), and tested in three (three kinds of kb jogs)
[05:06:34] <jmkasunich> homing active is set in two places (start of single axis home, start of home all), cleared in 4 places (various aborts and end of homing), and tested in 4 places (start of 3 kinds of kb jogs, and start of wheel jog)
[05:06:57] <jmkasunich> the rules are clearly defined by the tests, and the flags are pretty well decoupled
[05:07:34] <jmkasunich> the existing code forced all jogs to stop (aborted them) when a home command is received
[05:08:00] <jmkasunich> I don't know if that is right or not - we can easily change the rule by testing the jog-active flags in the home command
[05:08:16] <jmkasunich> (and refusing to home if a jog is in progress)
[05:14:29] <LawrenceG> jmkasunich: can you try the latest version of image-to-gcode.... its seems to be broken in 2.1.3 released today
[05:15:23] <jmkasunich> no....
[05:15:30] <jmkasunich> 1) I don't know anything about it
[05:15:40] <jmkasunich> 2) its 1:15am and I'm going to bed
[05:15:40] <LawrenceG> If I read the error message correctly it looks like the Gcode class is not expecting the spindle speed param
[05:15:49] <jmkasunich> jepler is your man for image-2-gcode
[05:15:59] <LawrenceG> no.. problem... I was headed there an hour ago myself!
[05:16:03] <jmkasunich> he's asleep, but he'll probaby read this tomorrow morning
[05:16:47] <LawrenceG> tfmacz: has the same problem with it faulting...... goonight
[05:17:32] <jmkasunich> goodnight
[13:44:42] <jmk2> this is annoying
[13:44:54] <SWPadnos> which?
[13:44:56] <jmk2> I could do the jogwheel timeout thing in about 15 minutes
[13:45:11] <cradek> timeout?
[13:45:20] <jmk2> except that getting the new item from the ini file into the motion controller would take an hour at least
[13:45:31] <alex_joni> jmk2: i can do that later
[13:45:36] <jmk2> the stuart stevenson thing
[13:45:37] <alex_joni> in about 30 minutes
[13:45:45] <cradek> I think that feature is bordering on crazy
[13:45:57] <jmk2> why's that?
[13:46:42] <alex_joni> jmk2: hitting the keyboard increment jog (set to 1") 5 times won't make the jog stop if I don't push any keys for 2 seconds
[13:46:55] <alex_joni> that would be really confusing
[13:47:28] <jmk2> ok, post a message to the list saying why you think its crazy
[13:47:42] <alex_joni> cradek thinks it's crazy
[13:47:47] <alex_joni> :-)
[13:48:47] <cradek> if you want to move a certain distance, you have to carefully never exceed a certain speed, otherwise you end up somewhere unknown
[13:48:56] <alex_joni> I didn't have the chance to play with an CNC control (would have said "real" but emc2 is also a real control), so I can't really argue about it
[13:48:57] <cradek> and the reason you want this? so you can go WHEEEEEEEE and spin the wheel??
[13:49:10] <cradek> that's a crazy tradeoff
[13:49:11] <jmk2> I know I woudldn't use the feature, but we have at lesst some people who want it
[13:50:15] <cradek> also, there's no feedback that you exceeded the magic speed for a little bit and lost your position
[13:50:43] <alex_joni> maybe someone uses the markings on the jogwheel for measuring
[13:51:03] <cradek> yes, presumably that's why the marks are there
[13:51:04] <alex_joni> if it loses position, it's not really usefull (I know he has to enable the stuff in the ini though)
[13:51:15] <jmk2> ray just spoke uo in favor of the way it works now
[13:51:26] <SWPadnos> you can always "re-zero" by setting the axis selector to "none" and turning the wheel to 0
[13:52:05] <jmk2> and ray discusses the fact that differnet folks want different things
[13:52:13] <SWPadnos> Stuart can probably get something close to what he wants if it's possible to limit the jog increments
[13:52:28] <SWPadnos> a 0.01" jog is unlikely to be exceeded by someone turning a wheel
[13:52:39] <SWPadnos> 0.001 even less likely
[13:52:53] <cradek> maybe he could use a limit block to get the behavior he wants
[13:53:07] <jmk2> yeah, I was going to talk about that too - if your scale is too big, you can get ahead of yourself
[13:53:17] <jmk2> I don't think he can do hal tricks to solve it tho
[13:53:34] <jmk2> hal doesn't know what the commanded jog position is, only where the axis is now
[13:53:42] <SWPadnos> no - the jogging code is all inside motion, or "above" it
[13:53:43] <cradek> jogwheel -> encoder -> limit -> sim_encoder -> motion
[13:53:50] <cradek> * cradek shivers
[13:53:51] <SWPadnos> ewww
[13:54:17] <jmk2> thats a speed limit anyway, not a "stop when I stop" thing
[13:54:29] <jmk2> besides being ugly and horrible
[13:54:31] <cradek> yes you'd set the speed limit to the axis limit
[13:54:56] <anonimasu> hm, wouldnt the wheel bottom out when you cant spin it any faster?
[13:54:56] <jmk2> theres accel in the picture too - you can accel the wheel faster than the machine
[13:55:02] <jmk2> at least for some machines and some wheels
[13:55:05] <SWPadnos> jogwheel -> encoder -> stepgen(type 2) -> motion
[13:55:14] <jmk2> sick sick sick
[13:55:16] <SWPadnos> heh
[13:55:19] <SWPadnos> I knew that ;)
[13:56:00] <jmk2> there are two ways to do it inside motion, both of which can default to "works just like today"
[13:57:44] <rayh> flexibility can be a bitch, 'eh.
[13:58:01] <cradek> flexibility can be a mistake
[13:58:18] <cradek> </unpopular viewpoint>
[13:58:22] <jepler> it makes the software harder to test thoroughly
[13:59:12] <rayh> and flexibility makes the documentation more difficult and the number of questions increase exponentially.
[13:59:31] <cradek> I think putting this in would be a mistake. If he wants this behavior there are ways he can get it. People think it's an ugly setup, but I think it's uglyish behavior he wants
[14:00:19] <jmk2> well, ray has gone on record as stating that he prefers (strongly) the existing behavior
[14:00:40] <SWPadnos> if you disable the jogwheel on an axis, does that cancel an in-progress jogwheel motion?
[14:01:05] <cradek> not sure
[14:01:11] <cradek> (it could)
[14:01:13] <rayh> This will appear at first reading as an aside.
[14:01:18] <jmk2> it doesn't now
[14:01:40] <rayh> Back in the old Tandy model 4 days I got a flight controller and some software for it.
[14:02:05] <rayh> I don't know how many times I crashed on landings.
[14:02:39] <rayh> Now if I tried to use one of those sorts of input devices to set part zero...
[14:02:49] <rayh> You get the idea.
[14:03:00] <cradek> heh
[14:03:02] <jmk2> yep
[14:03:25] <rayh> Damn! There goes another 1 inch endmill.
[14:03:34] <jmk2> we all agree that getting anything other than whe you dial in seems really dumb
[14:03:48] <cradek> someone running a manual machine would laugh if you said the wheel should be made to "slip" if you turn it too fast
[14:03:55] <jmk2> but we have a user who thinks that he's more like to bust an endmill our way than his way
[14:04:02] <rayh> Hey I like that.
[14:04:15] <jmk2> yeah, thats an excellent way to put it
[14:04:18] <cradek> because I like to spin it as fast as I can!
[14:04:38] <jepler> cradek: but with a manual wheel it also stops at the exact moment you do
[14:04:40] <jmk2> I nominate cradek to post that statement, and see what the reaction is from thise who want this "feature"
[14:04:41] <cradek> instead of turning it 10 turns to move an inch, I like to give it a good whirl, and when it looks like it has moved an inch, I stop it
[14:05:11] <cradek> I had to get a big heavy wheel to make it whirl better
[14:05:16] <cradek> ok I'm being an idiot, I'll stop
[14:05:26] <alex_joni> I think the main thing is that you can't whirl it faster then the machine can go on a manual one
[14:05:31] <alex_joni> but you can on a jogwheel
[14:05:35] <jmk2> yes
[14:05:36] <cradek> alex_joni: sure you can, if it slips
[14:05:57] <alex_joni> cradek: it usually doesn't slip
[14:06:02] <alex_joni> :-P
[14:06:07] <cradek> alex_joni: well that's the feature I want
[14:06:16] <rayh> Exactly. The big mills can move several hundred inches a minute so the lag is not so obvious.
[14:06:22] <jmk2> the fact is, you CAN turn a jogwheel faster than the machine can follow - so the manual analogy breaks down
[14:06:31] <SWPadnos> you also don't get a variable gear ratio on a manual mill
[14:06:44] <SWPadnos> s/mill/crank/
[14:06:49] <jmk2> you can have two chioces to deal with that - it slips, or theres a big old spring in there that winds up, and unwinds later when you stop turning
[14:07:10] <SWPadnos> force feedback wheels :)
[14:07:36] <jmk2> the spring unwinding part is what stuart doesn't like
[14:07:40] <alex_joni> bbl
[14:07:44] <SWPadnos> see you
[14:07:49] <rayh> see you later alex.
[14:07:55] <SWPadnos> yeah - I can see the argument for it
[14:08:08] <SWPadnos> "I stopped turning the wheel, why doesn't the machine stop?"
[14:08:30] <SWPadnos> in either case, you'll have a departure from a manual wheel
[14:08:43] <SWPadnos> it's either slip or continuing motion
[14:08:58] <jmk2> right
[14:09:05] <anonimasu> hm..
[14:09:11] <cradek> you can hear when the machine hits maxvel
[14:09:26] <cradek> in our scheme, you can stay below that to keep from overshooting
[14:09:33] <anonimasu> well, I wouldnt allow you to jog that fast..
[14:09:34] <SWPadnos> it may make sense to do some adaptive feedrates, rather than adaptive endpoints
[14:09:35] <cradek> in his scheme, you must stay below that to maintain position
[14:09:38] <anonimasu> ie, set the increment that big..
[14:09:43] <rayh> I think that these analogies should be published because they clarify the workings of EMC.
[14:10:14] <SWPadnos> the workings of EMC are changeable, it's what you (we, I , they) want that matters
[14:10:14] <jmk2> yeah, this discussion on the devel IRC channel does nothing for the discussion on the users email list
[14:10:17] <jmk2> but we can summarize
[14:10:21] <cradek> I suppose both can be a surprise to the user
[14:11:10] <rayh> Yes and we should not be completely closed minded as new devices and ways of doing things come along.
[14:11:21] <rayh> That was a note to self.
[14:11:20] <anonimasu> agreed
[14:11:36] <SWPadnos> heh
[14:11:36] <jmk2> crap - it looks like the logger isn't
[14:11:38] <anonimasu> being a copy of whatever control isnt a good goal..
[14:11:52] <SWPadnos> logger_dev, bookmark
[14:11:52] <SWPadnos> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-03-19.txt
[14:11:59] <SWPadnos> the logger isn't what?
[14:12:06] <jmk2> logging?
[14:12:15] <SWPadnos> seems to be
[14:12:25] <SWPadnos> if you /msg'd, I'm not sure that has ever worked
[14:12:27] <jmk2> maybe the web proxy here refuses to update the file, I just looked at it and none of this is in there
[14:12:38] <SWPadnos> it's there
[14:12:44] <jmk2> poxy proxys
[14:12:51] <SWPadnos> heh
[14:12:55] <SWPadnos> refresh?
[14:13:04] <jmk2> tried
[14:13:07] <SWPadnos> bummer
[14:13:29] <jmk2> anyway, should we post a link to this discussion to the users list?
[14:13:45] <jmk2> let them see the thought process
[14:14:13] <rayh> Good plan.
[14:14:22] <jmk2> (which I think is coming around to "neither approach really emulates a manual machine's wheels, maybe we should let them pick their poison"
[14:14:42] <SWPadnos> any thoughts on adaptive jog feedrate?
[14:14:57] <jmk2> I don't see how that helps
[14:14:59] <SWPadnos> ie, if the endpoint is "too far" ahead, increase feedarte in an effort to keep up
[14:15:08] <jmk2> it can only slow down the machine
[14:15:33] <SWPadnos> isn't jog rate the default vel (or separately set), not G0 rate?
[14:15:38] <jmk2> wheel jogs use max feed
[14:15:40] <cradek> I actually like SWPadnos's stepgen solution
[14:15:41] <SWPadnos> oh
[14:15:45] <SWPadnos> heh
[14:15:45] <SWPadnos> oh no
[14:15:58] <jmk2> the intent is that they keep up with the wheel, and that sets the rate
[14:16:39] <cradek> it would let the user do it today, and it would keep this (IMO) broken behavior out of the motion controller
[14:17:07] <jmk2> I wonder if stuard's wheel doesn't have detents and numbers around it? if so, that would explain why he doesn't care about slip
[14:17:17] <SWPadnos> if I rotate the wheel slowly, I should get a slow move, not a series of jerks to the next position
[14:17:30] <SWPadnos> of course the average will be a slow move
[14:17:46] <cradek> SWPadnos: since it's realtime you get excellent following with no jerks
[14:17:49] <rayh> Mazak is jerks as are most other dedicated cnc controllers.
[14:18:00] <jmk2> if you rotate at 5 clicks per second, you will get 5 distince 0.001" (or whatever) moves
[14:18:15] <cradek> ours beats the pants off them then...
[14:18:17] <jmk2> distinct
[14:18:24] <rayh> Roland's old Turner control did not have detents on the thumbwheel.
[14:18:37] <rayh> I never could understand why he liked it that way.
[14:18:40] <jmk2> I think cradek's "jerks" and ray's jerks aren't the same
[14:18:48] <rayh> It did change feedrate as you spun it faster.
[14:18:54] <jmk2> both move in distinct steps if you turn slowly
[14:19:02] <cradek> oh
[14:19:04] <rayh> but no fixed positioning.
[14:19:06] <mshaver> one man's jerk...
[14:19:09] <cradek> sure down to one count or step
[14:19:10] <SWPadnos> my jerks are little rapid motions when I'm turning the wheel slowly - it's a classic quantization problem
[14:19:25] <SWPadnos> one jerk-man's ...
[14:19:33] <mshaver> good one
[14:19:39] <cradek> mshaver: hi
[14:19:39] <rayh> I see where SWPadnos is coming from on this though.
[14:19:44] <rayh> Hi Matt.
[14:19:50] <mshaver> cradek: hi too!
[14:19:57] <mshaver> ray too!
[14:20:45] <mshaver> the jog wheels ive seen do move the avis somewhat bumpily
[14:21:21] <mshaver> bridgeport's didn't, but it would also buffer up clicks causing you to overtravel sometimes
[14:21:42] <jmk2> heh, thats what stuart doesn't like
[14:22:05] <cradek> stepgen! stepgen!
[14:22:18] <jmk2> stepgen is not what you want
[14:22:25] <jmk2> because it will buffer things up
[14:22:40] <SWPadnos> until you abruptly disable it :)
[14:22:44] <cradek> oh, duh
[14:22:44] <jmk2> I should say, not what stuart wants
[14:23:12] <jmk2> he _wants_ to drop wheel counts under certain conditions
[14:23:16] <mshaver> the problem is that you have to decel & you can't know when the guy is going to stop clicking
[14:24:33] <mshaver> so you can either bump along, or add each click to a trajectory plan
[14:24:41] <mshaver> or...?
[14:25:15] <jmk2> I don't think we have any complaints about the smoothness of our jogwheels
[14:25:49] <jmk2> swpadnos was speculating about jerky movement, right? you don't have a jogwheel and haven't tried it?
[14:25:55] <cradek> our jogwheel works very smoothly
[14:26:12] <cradek> as smooth as possible considering quantized position inputs (counts) and outputs (counts/steps)
[14:26:18] <mshaver> i haven't so i'm not talking from experience
[14:26:20] <SWPadnos> I have no machine to try it on, so it was all speculation :)
[14:27:50] <rayh> I don't see Mazak or Mitts worrying about smoothing out a customers handwheel palsey.
[14:28:33] <rayh> So I'd say if we have reasonably smooth motion we should be content.
[14:29:14] <rayh> The configurability issue is a biggie though.
[14:29:39] <jmk2> I think the only issue is what we do when the commanded move from the wheel is faster than the machine can follow... wind up and unwind later, or slip?
[14:30:10] <cradek> I think the slip will be hard to make smooth
[14:30:20] <cradek> jogwheel works well because it can update the target while it's already moving
[14:30:43] <rayh> Okay. I like that binary sort of option.
[14:31:01] <jmk2> the timeout version won't have any smoothness issues - it will just stop (break the wound up spring) shortly after you stop turning
[14:31:02] <jepler> there's a whole range of "slip" though -- I think the mailing list discussion already touched on this
[14:31:08] <cradek> so for slippage you're faced with not updating it unless you're already on target
[14:31:58] <cradek> ok I can see that
[14:32:06] <cradek> like you asked before, what's "stop turning" mean?
[14:32:17] <jmk2> did you read my email this morning?
[14:32:33] <jmk2> it listed two ways to do it
[14:32:38] <cradek> let me check
[14:32:46] <jmk2> one is "don't let the command get more than X ahead of actual"
[14:33:02] <jmk2> the other is "if no clicks in X seconds, and jog still going, abort it"
[14:33:12] <jmk2> X is an ini file number
[14:34:36] <jmk2> in either case, if X is zero (the default), there would be no slip - any windup would unwind when you stop, no matter how much
[14:34:40] <cradek> ok I see
[14:35:18] <anonimasu> jmk2: yeah but then you may never end up where you originally wanted..
[14:35:46] <jmk2> anonimasu yep, thats what happens if you configure your machine to slip if you turn to fast
[14:35:53] <SWPadnos> you can't have both exact positioning and timeouts
[14:35:56] <jmk2> (and I would never config my machine that way)
[14:36:03] <anonimasu> agreed..
[14:36:19] <mshaver> shouldn't x always be zero?
[14:36:27] <jepler> how hard would it be to change the motion controller so that remaining motion is dropped when axis.N.jog-enable goes FALSE? That way either of these new policies could be implemented in HAL, rather than setting a limited range of policy in the realtime motion controller
[14:37:02] <jmk2> jepler - not terribly hard to do that
[14:37:03] <rayh> flexibility bites again.
[14:37:03] <jepler> I guess HAL doesn't have easy access to "distance between requested and actual"
[14:37:20] <jmk2> but doing the timeout in HAL is more complex for the user
[14:40:52] <rayh> Fortunately I believe that we are seeing a very bright, if rapidly growing group of folk integrating these days.
[14:42:24] <mshaver> * mshaver is rerading jmk's email...much better synopsis of the issue than i've presented...
[14:53:25] <jmk2> just sent another email, summarizing a bit and pointing them to this discussion
[14:55:50] <rayh> Nice.
[15:03:43] <jmk2> I didn't know tkemc still had logging as a menu item
[15:03:57] <jmk2> logging has been gone (replaced by halscope) for a long time - that needs fixed
[15:05:42] <jmk2> * jmk2 goes away
[15:32:44] <a-l-p-h-a> anyone got an idea on how to do a quick and easy DIY coolant flow control?
[15:34:28] <a-l-p-h-a> I was thinking a bar, bored out, both ends tapped, and with the middle of the bar, tapped for brass hose couplers, with a 1/4-20 screw going in, to block off the flow.
[15:35:17] <cradek> a coworker recently hooked an aquarium pump into the top of a 2-liter bottle to use for watering plants
[15:35:28] <cradek> so the question is how quick and how easy :-)
[15:35:57] <cradek> the pump pumps out air, so he hooked that at the top, and took the water output from the bottom
[15:37:14] <cradek> I don't see logging in tkemc...? am I just missing it?
[15:45:26] <SWPadnos> why not use a ball valve?
[15:45:37] <SWPadnos> $10 or so at Home depot
[18:20:00] <jepler> is there any reason to have the policy "adaptive feed is capped at 1.0" in the realtime motion controller?
[18:36:36] <jepler> with a component like this, it would be easy to have whatever policy you wanted: http://emergent.unpy.net/files/sandbox/clamp.9.txt
[18:41:52] <SWPadnos> there's also the limit1 component
[18:47:39] <cradek> jepler: no reason that I can think of. when we wrote it, we were thinking EDM and being as conservative as possible I guess
[18:49:22] <jepler> SWPadnos: yeah that would be fine
[18:49:38] <jepler> as usual I can't remember what components exist already
[18:49:49] <SWPadnos> me either. I looked :)
[22:36:41] <jmkasunich> jepler: I think there was some valid reason for limiting adaptive feed to 1.0
[22:37:13] <jmkasunich> possibly because some things are precalced for the TP assuming that the product of FO and AF will not exceed the max FO in the ini file
[22:37:17] <SWPadnos> some planning / path creation thing, I think
[22:43:40] <cradek> I don't think that's true
[22:44:28] <cradek> the TP always limits to the machine constraints - you can request whatever feeds you want
[22:44:40] <jmkasunich> so the TP wouldn't care if adaptive feed went from 1.0 to 20.0?
[22:44:56] <cradek> nope
[22:45:08] <cradek> nor would it care if the FO slider goes from 100% to 2000%
[22:45:32] <jmkasunich> well, the FO slider can only go to 2000% if max_fo in the ini file lets it do that
[22:45:32] <cradek> (same thing)
[22:45:46] <jmkasunich> so the TP knows what the upper limit is
[22:45:48] <cradek> TP doesn't care about that setting
[22:45:52] <jmkasunich> ok
[22:46:21] <cradek> you're only scaling F words - the actual constraints never change
[22:47:23] <cradek> so if you request F0.001 and your scale is 10000, you get F10 if the machine can do it
[22:47:27] <SWPadnos> I guess there's no need for an explicit limit in the TP (other than nonnegative for now, I guess)
[22:47:52] <cradek> yes a clip at 0 is nice, although TP probably handles that too
[22:47:57] <jmkasunich> ok, I've just looked at the free mode planner, and the same is true there
[22:48:06] <SWPadnos> you can always limit with either a limit1 HAL component or with extra parameters for motion to do the same thing
[22:48:51] <jmkasunich> regarding my changes to homing/jogging interlocks....
[22:49:02] <jmkasunich> I did that in trunk - what about 2.1?
[22:49:20] <jmkasunich> it would be nice if they could be tested and/or reviewed before porting
[22:49:28] <cradek> it's gotta be fixed in 2.1 somehow...
[22:49:39] <cradek> I'll try to test it tonight
[22:49:47] <cradek> for what good that does (I tested the last try)
[22:49:48] <jmkasunich> dunno if anybody read my 1am comments in here after I got it done
[22:50:01] <jmkasunich> I think its pretty clean, but would like other eyes on it
[22:50:23] <jmkasunich> phew - what are we feeding that cat anyway!
[22:50:42] <jmkasunich> (problems with having the computer/desk in the basement)
[22:51:18] <cradek> TMI
[22:51:38] <jmkasunich> ;-)
[22:51:44] <jmkasunich> thought I share
[22:52:02] <jmkasunich> * jmkasunich goes upstairs to let the air clear
[22:52:53] <jepler> can one of you give me a 1-liner description of the bad behavior in 2.1.3, to write on the 'Release' page of the wiki as a Known Problem?
[22:53:23] <cradek> i2g is busted, jogwheel moves stop short
[22:53:49] <cradek> those are the only ones I know about
[22:53:49] <jepler> OK
[22:54:11] <cradek> bbl
[22:54:10] <jepler> information added
[23:01:47] <LawrenceG> hi guys... I am trying to write a new .comp .... the docs say to compile with "comp -install rtexample.comp" but where to I find comp?
[23:02:14] <jepler> LawrenceG: install the emc2-dev package if you are running from the prebuilt packages
[23:02:42] <LawrenceG> jepler: will do... thanks