Back
[00:07:01] <alex_joni> cradek: shouldn't arc_data_ijk catch that problem?
[00:07:17] <alex_joni> or is that checking the initial (uncomped) arc?
[00:09:16] <cradek> yes
[00:09:38] <alex_joni> ok, then I see 2 ways to 'fix' it
[00:09:38] <cradek> um yes, it looks like that's working on the uncomped arc
[00:10:09] <alex_joni> either in interp_convert.cc: another check to see if the comped arc is nil (endpos = initial pos)
[00:10:19] <alex_joni> or the same thing in CANON.. which might catch other stuff too
[00:10:30] <cradek> or both
[00:10:38] <alex_joni> or both..
[00:10:53] <alex_joni> guess beta is < small in this case.. right?
[00:11:00] <alex_joni> (one arc inserted, not two)
[00:11:00] <SWPadnos> I wonder how that would deal with the fact that the tangent vector has changed
[00:11:40] <SWPadnos> I guess you'd still have the new endpoint stored as the programmed point
[00:11:43] <cradek> if you don't issue the arc at all, the next move will still go around the corner
[00:11:47] <cradek> (I think)
[00:12:02] <SWPadnos> ie, you can't just cancel the move, you have to update the programmed point
[00:12:47] <alex_joni> it'll be the same point
[00:12:52] <alex_joni> so you can cancel the move
[00:13:02] <SWPadnos> no - the programmed point, not the actual tool position
[00:13:02] <cradek> actual is the same, programmed isn't
[00:13:15] <alex_joni> oh.. right
[00:14:07] <cradek> but I think that already happens correctly?
[00:14:16] <SWPadnos> that's probably true
[00:14:55] <cradek> I think you could just skip issuing the arc output if the arc is tiny enough, and leave everything else the same
[00:15:51] <SWPadnos> yep
[00:16:08] <SWPadnos> in fact, that can probably be done for any move that's <TINY long
[00:17:10] <cradek> that's troubling if there's a lot of them
[00:17:16] <cradek> 100*TINY >> TINY
[00:17:38] <cradek> how about if the arc is tiny, you could move in a straight line to the end of it
[00:17:56] <cradek> then if it's degenerate it's all happily handled later on
[00:18:14] <cradek> (it may even get culled before being sent to motion)
[00:18:30] <SWPadnos> yeah - I had thought of the pathological case of a relative coordinates loop of X+0.000000000000000000001
[00:18:47] <alex_joni> linear sounds like a good idea
[00:18:53] <SWPadnos> anything that's shorter than one servo period in length is a line anyway
[00:18:56] <alex_joni> cradek: does linear to the same spot work? I think so
[00:19:02] <cradek> ooh...
[00:19:30] <alex_joni> although I bet that the interp catches that usually
[00:19:31] <cradek> g0x0y0z0; g2x0y0.00001j0.00001z9
[00:19:47] <alex_joni> Z9 ?
[00:19:48] <cradek> you do NOT want to throw out that move
[00:19:50] <alex_joni> ouch
[00:20:01] <cradek> but replacing it with a line (because the arc is tiny) is fine
[00:20:19] <SWPadnos> anything less than MIN_FERROR isn't useful either :)
[00:21:05] <cradek> well erroring with "zero radius arc" is fine too
[00:21:10] <cradek> maybe an error is better!
[00:21:31] <alex_joni> in this case (comp) it might be confusing
[00:22:26] <cradek> there's already NCE_TOOL_RADIUS_NOT_LESS_THAN_ARC_RADIUS_WITH_COMP
[00:22:29] <SWPadnos> actually, a zero-radius arc is no motion. an infinite radius arc is a line
[00:23:10] <alex_joni> cradek: how about calling the check for arc_data_ijk again?
[00:23:15] <alex_joni> after the comp is applied..
[00:23:23] <alex_joni> I see that checks for zero radius..
[00:23:56] <cradek> any fix is fine with me :-)
[00:24:26] <cradek> I'm off to find some dinner...
[00:24:36] <alex_joni> I'm off to find some sleep :)
[00:24:38] <cradek> see you tomorrow alex, don't stay up too late!
[00:24:41] <cradek> good idea
[00:24:41] <alex_joni> right..
[00:24:42] <cradek> goodnight
[00:24:47] <alex_joni> good night
[00:24:49] <SWPadnos> I'm off to find some - err - time with my wife :)
[00:24:52] <SWPadnos> see you Alex
[01:20:26] <jmkasunich> regarding stepgen and 2.1.2..... don't wait for me
[01:20:51] <alex_joni> hi jmkasunich
[01:20:59] <jmkasunich> getting fractional count feedback means revamping how the steplen/dirhold/dirsetup stuff works
[01:21:04] <jmkasunich> so its a non-trivial change
[01:21:14] <alex_joni> 2.1.3 for that then
[01:21:16] <jmkasunich> Ed is a smart feller, I'
[01:21:24] <jmkasunich> I'll move him to CVS to work thru his problems
[01:21:30] <jmkasunich> than after some testing we can backport
[01:21:53] <alex_joni> ok.
[01:22:06] <alex_joni> for a minute I was afraid you were talking about the SMI guy
[01:22:18] <jmkasunich> no, thats jack
[01:22:26] <jmkasunich> he is not such a smart feller
[01:22:32] <alex_joni> :-)
[01:22:34] <jmkasunich> you gotta lead him by the hand
[01:22:40] <alex_joni> I see your filter is in place today
[01:23:23] <jmkasunich> well, I've been busy - I just finished repairing the garage door opener
[01:23:30] <alex_joni> oh, nice
[01:24:02] <alex_joni> * alex_joni had fun with 2 nice bugs today
[01:38:25] <jmkasunich> oh boy... just read the last from Jack
[01:38:33] <jmkasunich> he is a hazard to himself and everybody around him
[01:39:56] <alex_joni> * alex_joni decided not to respond to that
[01:40:03] <alex_joni> would probably be more trouble than help :(
[01:40:16] <jmkasunich> right
[01:40:44] <alex_joni> I wonder how he managed to fsck it up that nice
[01:43:24] <jmkasunich> probably used a gui file manager
[01:43:48] <alex_joni> not sure those use sudo
[01:51:49] <alex_joni> petev: hi, got your email
[01:51:54] <petev> ok
[01:52:01] <petev> let me know what you think
[01:52:07] <petev> I would like to get things cleaned up
[01:52:25] <alex_joni> * alex_joni wants the content of the ini file cleaned up aswell
[01:52:43] <petev> I can do that at the same time if we can get agreement
[01:53:10] <alex_joni> that's probably be a while
[01:53:30] <petev> yeah, hopefully we can just put the new code in place
[01:53:37] <petev> than make file changes later
[01:53:45] <petev> at least it will be easier then
[01:57:56] <alex_joni> petev: sometimes when I'm not sure about a change, I put a patch on pastebin.ca for others to comment on
[01:58:39] <petev> there was an attachment to the email
[01:58:55] <petev> it's an example of the calling code
[01:59:30] <petev> in the process of testing, I found other places in emc did not have the same behavior so default stuff didn't work anyhow
[02:03:16] <alex_joni> a patch/diff is always easier to read/evaluate.. because one can easily see what gets removed what gets replaced, etc
[02:03:35] <petev> ok
[02:04:15] <alex_joni> but I got the usrmotintf.cc
[02:04:17] <alex_joni> it looks good to me
[02:04:42] <petev> I just want to make sure that everyone is ok with changes like that and I'll clean it up everywhere
[03:02:11] <petev> I was just cleaning out some old stuff and had an idea for the hobby guys
[03:02:26] <petev> I was about to get rid of some old VCR remotes, when it hit me
[03:02:45] <petev> what do u guys think about an LIRC connector to allow an IR remote to be used?
[03:02:57] <petev> it has a jog wheel, number pad, etc.
[03:03:09] <petev> might make a cheap setup
[03:03:56] <SWPadnos> hi folks
[03:04:47] <SWPadnos> petev, just read your email
[03:05:36] <SWPadnos> I hadn't thoroughly reviewed the way the inifile class deals with exception enabling, so I'm sure that's fine
[03:06:25] <petev> ok, I'll check that module in and start on the others
[03:06:44] <petev> if we can decide how we want things to behave, I can fix that at the same time
[03:06:51] <SWPadnos> I guess I need to look over default values a bit - the way I've seen it done (in Windows, so maybe not a great example) is that you can pass in a default value, but you don't have to modify the variable beforehand
[03:07:05] <jmkasunich> * jmkasunich is trying to resist the temptation to change 'steplen' and friends from thread periods to nano-seconds
[03:07:29] <SWPadnos> I'd do that in TRUNK, but not in v2_1_brandh
[03:07:50] <petev> I guess we could have that, but most of the code seems to rely on static initializers for the defaults
[03:08:01] <jmkasunich> I'm working in trunk
[03:08:04] <SWPadnos> actually, defaults are taken from a number of places
[03:08:29] <jmkasunich> the thing is, I'd like to backport eventually, and I don't want to code and test twice
[03:08:38] <jmkasunich> the code for nS is actually simpler and cleaner than for periods
[03:08:43] <petev> well it's easy enough to add some more variants of the Find() method ;-)
[03:08:48] <SWPadnos> for the example of an axis MAX_VEL, it gets set to whichever of these is found last: a default value, the traj max, then the axis max
[03:08:53] <SWPadnos> heh - yep :)
[03:09:35] <SWPadnos> jmkasunich, the change for ns should be nearly nothing in the make_pulses func, and not too big in the calculate_period (or whatever that one is called)
[03:09:56] <jmkasunich> I think I'm gonna write it using nS
[03:10:18] <jmkasunich> then IF we decide to backport, I'll hack in the cruft needed to make it work in periods
[03:10:40] <SWPadnos> well, it may be a big enough change that it should go into 2.2 instead of 2.1.2
[03:10:49] <jmkasunich> the nS is definitely 2.2
[03:10:52] <SWPadnos> ns certainly is because of ini changes
[03:11:20] <petev> jmk, if you want any INI changes, now is the time
[03:11:18] <jmkasunich> if ed is the only one who has problems with stepgen as it is, I may just ask him to use cvs, and leave everything for 2.2
[03:11:20] <SWPadnos> right - I can stick the "quick hack" version of fractional step reporting in the 2.1 branch
[03:11:34] <petev> I have to edit about 20 files worth
[03:11:41] <jmkasunich> petev: I'm not talking about ini API stuff
[03:11:48] <SWPadnos> petev, this represents a change to configuration data, so it's not the same category as what you're doing :)
[03:11:53] <petev> I mean any naming or whatever
[03:12:04] <SWPadnos> interesting point
[03:12:15] <petev> alex wanted to name stuff like axis to joint, etc.
[03:12:19] <SWPadnos> but then again, HAL has no idea what the ini names are
[03:12:37] <SWPadnos> that's definitely 2.2 (or higher)
[03:12:59] <petev> yeah, I didn't want to touch that unless everyone agreed to what it should be
[03:13:15] <petev> joint sounds right, but someone will surely object
[03:13:26] <jmkasunich> hal is perfectly flexible about ini naming
[03:13:28] <SWPadnos> the one thing to change might (and this is a big might) be to make the section names into a #define
[03:13:53] <SWPadnos> but that's no more readable - it just makes another change easier
[03:14:02] <petev> true
[03:14:12] <petev> they are probably defined in multiple places now
[03:14:23] <SWPadnos> I think it's pretty easy to find all uses of "TRAJ" in the code and fix them
[03:14:30] <SWPadnos> or AXIS_
[03:14:38] <SWPadnos> (or all calls to inifind, for that matter)
[03:14:54] <SWPadnos> we'll have a good list of places to look from your diff ;)
[03:15:07] <petev> yep
[03:15:45] <cradek> if you guys change the any ini stuff, please keep a "how to convert" wiki page up to date - I think that worked great last time
[03:15:59] <jmkasunich> ok
[03:16:08] <jmkasunich> I just had a duh moment
[03:16:23] <SWPadnos> uh-oh :)
[03:16:35] <jmkasunich> I can code the actual algorithm to use ns, and just convert the HAL params from periods to nS in the slow code
[03:16:44] <cradek> ... duh
[03:16:49] <jmkasunich> then the change to accept nS can come later
[03:16:57] <SWPadnos> heh - duh!
[03:17:13] <petev> tough crowd
[03:17:22] <jmkasunich> (the old algorithm ran counters as "counter--;" and I was thinking if I wanted to use periods I'd have to use that
[03:17:49] <jmkasunich> the new one will be "if ( counter > periodns ) counter -= periodns else counter = 0;
[03:17:51] <SWPadnos> for maximal efficiency, that should be codede as --counter;
[03:17:57] <SWPadnos> * SWPadnos dons flame-proof suit ;)
[03:18:34] <SWPadnos> jmkasunich, you still need to subtract the rest from the next step period
[03:18:44] <jmkasunich> ?
[03:18:51] <jmkasunich> these are simple down counters
[03:18:53] <jmkasunich> think one shots
[03:18:59] <SWPadnos> ok
[03:19:07] <SWPadnos> right - not the DDS - duh!
[03:19:24] <jmkasunich> heh. now we're even
[03:19:28] <SWPadnos> heh
[03:20:37] <jmkasunich> for trunk/2.2, I intend to get rid of the duplicate code in freqgen and stepgen, and resolve the inconstencies between them
[03:20:43] <jmkasunich> see the bugs section in man stepgen
[03:22:17] <jmkasunich> the vast majority of the changes will be in freqgen, which few people use
[03:22:34] <jmkasunich> that will minize but not eliminate the impact on configs
[03:22:55] <jmkasunich> one thing at a time tho...
[03:23:00] <jmkasunich> * jmkasunich goes back to work
[03:38:14] <SWPLinux> gah - stupid kate
[03:38:39] <SWPLinux> never select "view difference" when a file has changed on disk
[03:38:58] <jmkasunich> its trying to be too smart
[03:39:12] <SWPLinux> it disappeared - with the 43 open files
[03:39:21] <cradek> ouch
[03:39:29] <SWPLinux> the files are still there, but all history is gone
[03:39:33] <SWPLinux> (undo history)
[03:39:36] <SWPLinux> sigh
[03:40:00] <SWPLinux> I guess I need to (re)learn how to use a real editor
[03:40:02] <jmkasunich> there should be 3 choices: load the changed file (discard any changes in the editor), save from the editor (discard the changes on disk), save to another filename
[03:40:15] <SWPLinux> there are 4, the other is "View Differences"
[03:40:19] <jmkasunich> right
[03:40:32] <SWPLinux> #4 is unsafe :)
[03:40:41] <jmkasunich> it used to be worse - the BDI era Kate would sometimes crash even if you did the "reload from disk" choice
[03:40:53] <SWPLinux> yep - I recall that kind of thing
[03:41:12] <SWPLinux> in fact, once Kate disappeared, I remembered that you're not supposed to hit "View Differences"
[03:41:27] <SWPLinux> about 3 seconds too late
[03:52:37] <cradek> how do you turn on the dmesg logging of teh EMCMOT_ messages?
[03:52:59] <jmkasunich> are they using rtapi_print_msg?
[03:53:06] <cradek> yes
[03:53:16] <SWPadnos> DEBUG_LEVEL?
[03:53:19] <cradek> rtapi_print_msg(RTAPI_MSG_DBG, "JOG_CONT");
[03:53:36] <jmkasunich> echo 4 >/proc/rtapi/debug
[03:53:37] <cradek> I thought I could do it without recompiling
[03:53:38] <cradek> yeah that's it, thanks
[03:54:40] <jmkasunich> writing "signed long" is just as redundant as writing "signed int" isn't it?
[03:54:54] <SWPadnos> exactly as redundant
[03:55:31] <SWPadnos> though if you want to guarantee a signed number, it may be safer - it's possible that a compiler flag can make the default int unsigned
[03:55:55] <jmkasunich> well, that flag will probably break several thousand declarations all over EMC
[03:55:56] <SWPadnos> (I'm not sure if that's implemented by any compiler, or if it's against the spec though)
[03:56:05] <SWPadnos> heh
[03:56:20] <jmkasunich> so I'm removing the signed decls that I put in way back when
[03:56:33] <petev> char is the only one I think ANSI allows to be either
[03:56:41] <jmkasunich> I also used char for things that could have used int, and are probably faster as int
[03:57:22] <SWPadnos> I know some compilers for microcontrollers can default to unsigned, but I'm not sure if any PC compilers do
[03:58:15] <petev> I was just thinking the other day though, that EMC should define some types
[03:58:28] <SWPadnos> it does - at least for HAL
[03:58:38] <petev> there should be defined typed for holding coords, etc
[03:58:45] <petev> not just double and stuff like that
[03:58:47] <SWPadnos> ah - more advanced types ;)
[03:58:55] <SWPadnos> absolutely
[03:59:01] <petev> then is would be easy to change to double double or whatever
[03:59:08] <SWPadnos> the first one should be a "length", which has a unit along with the number
[03:59:13] <jmkasunich> * jmkasunich says goodbye to some silly unions too
[03:59:14] <petev> yes
[03:59:27] <jmkasunich> gawd I did strange things in the name of saving a byte or a cycle
[03:59:32] <SWPadnos> heh
[04:00:02] <SWPadnos> try using the little tricks jepler and I were fiddling with - you may be surprised by what will save a byte
[04:00:09] <jmkasunich> thats OK
[04:00:11] <SWPadnos> but don't use them in real code
[04:00:15] <SWPadnos> "_
[04:00:18] <SWPadnos> :)
[04:00:50] <SWPadnos> I was surprised that the order in which results were stored made a difference in code size
[04:02:35] <petev> with optimizer on?
[04:02:56] <SWPadnos> using -O3 and a couple of other flags (-funroll-loops and such)
[04:03:10] <jmkasunich> I'm fixing another thing that has annoyed people....
[04:03:20] <jmkasunich> when at a standstill, DIR used to always go to zero
[04:03:28] <jmkasunich> now it will hold its last state
[04:03:40] <SWPadnos> cool
[04:13:53] <jmkasunich> I am keeping one tweak that was in there before... struct members are declared in the order in which the fast thread function accesses them
[04:14:07] <jmkasunich> so fetching the first will get the next few into cache
[04:14:19] <jmkasunich> and no cache lines are wasted storing stuff that only the slow function accesses
[04:45:55] <cradek> that jogwheel problem caused runaway
[04:46:15] <jmkasunich> nasty
[04:46:20] <jmkasunich> jog that would not stop?
[04:46:28] <cradek> start a continuous keyboard jog (hold down key), spin the wheel, and while it's still spinning, let go of the key
[04:46:38] <cradek> right, it would keep going
[04:46:50] <jmkasunich> even after the wheel stopped
[04:46:54] <cradek> yes
[04:47:05] <jmkasunich> it lost the "keyboard jog is done" message
[04:47:07] <cradek> right
[04:47:40] <jmkasunich> what does it do when you have both at the same time? add them?
[04:47:48] <cradek> the other one was not as bad, but still bad - a keyboard jog is going on at low speed, you touch the jogwheel, the speed suddenly gets set to max
[04:47:54] <jmkasunich> keyboard jog left, and wheel right, to hold the axis stationary ;-)
[04:48:02] <cradek> haha
[04:48:19] <cradek> currently (if I got it right) when one is moving the machine, the other is ignored
[04:48:37] <jmkasunich> seems reasonable
[04:49:26] <cradek> funny what shows up when you test on hardware
[04:49:42] <jmkasunich> and when you are trying to do odd things
[04:49:58] <jmkasunich> I could test all week and not think of doing simutaneous kb and wheel jogs
[04:50:06] <cradek> yeah, I've been trying to break it
[04:50:23] <cradek> that's why it takes more than one person testing I guess - they all think of different strange things to do
[04:51:51] <cradek> how's stepgen?
[04:52:00] <jmkasunich> slow
[04:52:12] <cradek> progress is slow, or stepgen is slow?
[04:52:14] <jmkasunich> the new makepulses is done, working on the low speed code now
[04:52:18] <jmkasunich> progress is slow
[04:52:26] <cradek> talking to me helps that, I'm sure
[04:52:27] <jmkasunich> methodical is a better word
[04:52:53] <jmkasunich> its just about impossible to test all the edge cases - you gotta design for them
[04:54:41] <jmkasunich> the advantage of the new design is that it is more straightforward in how it does the steplen/stepspace, etc stuff, thus fewer and less obscure edge cases
[04:55:12] <jmkasunich> I now apply the timing params to all step types
[04:55:15] <jmkasunich> http://www.pastebin.ca/390138
[04:57:33] <cradek> jeez, so many cases
[04:57:49] <jmkasunich> ?
[04:57:52] <jmkasunich> only 3
[04:58:00] <cradek> all the different timings
[04:58:18] <jmkasunich> they're not really different
[04:58:31] <jmkasunich> type 0 is defined exactly the way it used to be
[04:58:37] <cradek> if steplen is small enough, can you do the up and down on the same run of the thread?
[04:58:42] <jmkasunich> no
[04:59:09] <jmkasunich> remember, the hardware update happens later in the thread
[04:59:25] <cradek> oh
[04:59:30] <jmkasunich> if you set something hi and then low in one run of a function, the hw write function never sees it
[04:59:59] <jmkasunich> hal is a sampled/clocked system
[05:00:20] <jmkasunich> so is the 5i20 FPGA, and it will be doing almost _exactly_ what this code does
[05:00:36] <jmkasunich> but its clock will be 33MHz instead of 20, 50, 100KHz
[05:00:43] <cradek> that will be nice.
[05:01:31] <cradek> emc1 had low-going step pulses. do you know which (if either) is normal?
[05:01:48] <jmkasunich> stepgen makes high going, you invert if desired at the output driver
[05:02:11] <jmkasunich> the 5i20 version will also make high going, and have an invert bit
[05:02:39] <jmkasunich> I dunno if there is a "normal" as far as drives go
[05:02:49] <jmkasunich> TTL tends to like active low stuff
[05:03:06] <jmkasunich> other interfaces don't have much of a pattern
[05:04:04] <cradek> these will all be nanoseconds ceilinged to a multiple of periods?
[05:04:23] <jmkasunich> yes
[05:04:40] <cradek> that's good, you can copy the numbers from the spec sheet more directly
[05:05:01] <jmkasunich> the plan is that if you enter 5000 and the ceilinged value is 5630, the parameter value will be changed go 5630
[05:05:08] <jmkasunich> so you can see what you are actually running
[05:05:17] <jmkasunich> s/go/to
[05:15:55] <jmkasunich> if I use (1<<24) in a float or double expression, the compiler will treat '1' as an int, shift it, then convert to float, right?
[05:16:25] <cradek> I don't know
[05:16:30] <jmkasunich> (as opposed to making 1 into 1.0, and then shifting it)
[05:16:47] <SWPadnos> it may depend on where in the expression it is
[05:16:49] <cradek> why not write the number you want with a .0?
[05:17:16] <SWPadnos> is << even valid for floats?
[05:17:17] <jmkasunich> because the number I want is (1<<DEFINED_VALUE)
[05:17:27] <cradek> SWPadnos: I doubt it
[05:17:49] <SWPadnos> you can get parens happy with (float)((int)(1<<DEFINED_VALUE))
[05:17:53] <jmkasunich> aka 2.0^(DEFINED_VALUE-1)
[05:18:07] <SWPadnos> well, you could use that
[05:18:22] <jmkasunich> except it would be incredibly slower
[05:18:24] <SWPadnos> is it a compile time constant
[05:18:28] <jmkasunich> yes
[05:18:36] <jmkasunich> so I guess that doesn't matter, does it
[05:18:36] <SWPadnos> then it'll be a single load in the code
[05:18:38] <cradek> it will be the same
[05:18:39] <SWPadnos> nope
[05:19:09] <jmkasunich> actually, I want 2.0^DEFINED_VALUE
[05:19:16] <jmkasunich> there is no floating point ^ operator though
[05:19:26] <jmkasunich> its a function, isn't it?
[05:19:28] <SWPadnos> pow
[05:19:37] <jmkasunich> in the math library, which I can't use in kernel space
[05:19:39] <SWPadnos> I think pow2 is a function as well though
[05:19:53] <jmkasunich> can the compiler invoke pow at compile time to make the constant?
[05:20:06] <SWPadnos> maybe
[05:20:24] <jmkasunich> see - its things like that make me want to use the (1<<DEFINED) version
[05:20:26] <SWPadnos> (float)((int)(1<<DEFINED_VALUE))
[05:20:35] <jmkasunich> I know the compiler can do that at compile time
[05:22:21] <jmkasunich> stepgen->scale_recip *= 1.0 / (double)((int)(1<<PICKOFF))
[05:22:48] <jmkasunich> PICKOFF is the accumulator bit at which I "pick off" the signal I use to create steps
[05:25:05] <SWPLinux> ok - you can't << a float
[05:25:38] <jmkasunich> so 1.0/(1<<PICKOFF) will do the Right Thing
[05:25:52] <SWPLinux> lemme check
[05:26:18] <SWPLinux> no
[05:26:43] <jmkasunich> no?
[05:27:12] <jmkasunich> take int 1, shift it to the left, convert to double because 1.0 is double, then do the divide
[05:27:16] <SWPLinux> argh
[05:27:26] <SWPLinux> it helps if I recompile before running the test program again ;)
[05:29:07] <SWPLinux> much better
[05:29:54] <SWPLinux> if a is a float, then a=(1<<P) works as expected, and 1.0/(1<<P) is needed or you get 0 (since 1/(1<<P)) can be an int=0)
[05:30:10] <jmkasunich> right, I knew the first 1 had to be 1.0
[05:30:15] <SWPLinux> yep
[07:53:32] <jmkasunich> it builds.... little details like actually working will have to wait until tomorrow
[15:12:11] <jepler> jmkasunich: ldexp() is the standard function for what you're doing: ldexp(x, q) == x * 2.0^q
[15:13:12] <jepler> for x86, ldexp is implemented as a single 'fscale' instruction so it would be easy to add to rtapi_math.h.
[15:25:32] <alex_joni> jepler: around?
[15:33:13] <alex_joni> hi ray
[15:33:23] <cradek> hi alex
[15:33:32] <alex_joni> hey chris.. there is one slight thing I want to ask you
[15:33:38] <alex_joni> about your latest jogging change
[15:34:18] <alex_joni> it seems to have changed behaviour while jogging with the gamepad I have
[15:34:22] <cradek> I was hoping someone would review it
[15:34:26] <cradek> uh-oh, howso?
[15:35:00] <alex_joni> dunno.. it seems to be missing some jog commands
[15:35:42] <cradek> how does the gamepad hook up? does it use jogwheel or halui?
[15:35:47] <alex_joni> halui
[15:35:55] <alex_joni> but it can change directions very fast
[15:35:58] <rayh> Hi alex
[15:36:17] <cradek> which nml jog messages does it use?
[15:36:38] <alex_joni> Issuing EMC_AXIS_JOG -- (+124,+24, +156, +1,-1.437909,)
[15:36:38] <alex_joni> Issuing EMC_AXIS_JOG -- (+124,+24, +157, +1,-6.666667,)
[15:36:38] <alex_joni> Issuing EMC_AXIS_JOG -- (+124,+24, +158, +0,-1.071895,)
[15:37:59] <cradek> can you say exactly how it works differently?
[15:38:34] <alex_joni> yes, I can spin the joystick around (it should jog X+, X+Y+, Y+, Y+X-, X-, X-Y-, Y-,Y-X+)
[15:38:40] <alex_joni> and it used to do that
[15:39:09] <alex_joni> now after spinning very fast, it decides to stay on one direction (say Y+) and it keeps going in that direction, even if from halui there are new jog commands
[15:40:16] <cradek> hm, yuck
[15:40:29] <cradek> that's not what I expected
[15:41:12] <alex_joni> also, changing jogging speed while active doesn't work anymore
[15:41:21] <alex_joni> (with halui and a joystick you can do that nicely)
[15:41:37] <alex_joni> jog slowly by moving the stick only a tiny bit, faster by tilting it completely
[15:42:04] <cradek> I wonder if that's EMCMOT_JOG_CONT EMCMOT_JOG_INCR or EMCMOT_JOG_ABS
[15:42:17] <alex_joni> http://pastebin.ca/390586
[15:42:59] <alex_joni> sendJogCont it's called
[15:43:00] <cradek> I bet that's EMCMOT_JOG_CONT and the argument is the velocity?
[15:43:05] <cradek> ok
[15:43:42] <cradek> yep I sure did break that
[15:43:47] <alex_joni> but the NML message is called EMC_AXIS_JOG or EMC_TRAJ_SET_TELEOP_VECTOR (based on view)
[15:44:00] <cradek> with my change you can't set a new velocity until you stop
[15:44:20] <cradek> wonder what the right fix is
[15:44:23] <alex_joni> right.. so I can't change direction (that's a negative velocity)
[15:44:43] <alex_joni> I wonder why you shouldn't set a new velocity..
[15:44:58] <alex_joni> (one fix: ugly, send a jogstop, then the new jog with changed speed)
[15:45:26] <cradek> the interaction I fixed was this: you have a slow continuous jog going, using the keyboard (key held down)
[15:45:34] <cradek> you bump the jogwheel one click
[15:45:52] <cradek> the continuous jog turns into full speed jog
[15:46:13] <alex_joni> because the jogwheel has no vel. limit
[15:46:19] <cradek> right
[15:47:48] <cradek> hmm I bet jogwheel will also make a homing axis go full speed
[15:48:12] <cradek> my fix is no good, and there's a bigger problem
[15:48:57] <cradek> maybe we have to keep track of who is responsible for the free mode planner being active: homing, jogwheels, EMCMOT commands
[15:49:08] <cradek> then don't let one interfere with the others
[15:49:33] <cradek> each "source" can control the planner just fine, it's the combinations that are bad
[15:52:04] <alex_joni> right..
[15:52:23] <cradek> maybe we should ask jmk
[15:52:30] <alex_joni> maybe we need to enable jogwheels and disable EMCMOT jogging
[15:52:39] <alex_joni> and the other way around
[15:52:49] <cradek> yes
[15:53:07] <alex_joni> this sounds like a jogwheel-enable pin to motion
[15:53:26] <cradek> I hope that's not needed
[15:53:37] <cradek> jogwheel should work whenever something else isn't moving the machine
[15:54:07] <alex_joni> ok, so if there's a jog active then it won't work..
[15:54:28] <alex_joni> just like AUTO
[15:54:37] <cradek> if there's jog active that wasn't started by the jog wheel
[15:54:42] <alex_joni> right
[15:55:00] <cradek> it may have been started by EMCMOT message or homing
[15:55:10] <cradek> not sure if there are other things that use the free planner, but if so, those too
[15:55:24] <alex_joni> backlash comp
[15:55:38] <cradek> eek
[15:55:45] <alex_joni> eek indeed
[15:56:43] <cradek> so I'm thinking free_tp_active should be set to some defines like HOMING_IS_USING_FREE_PLANNER_RIGHT_NOW, not just 1
[15:58:00] <cradek> I'm not sure I understand the interaction between free_tp_active and free_tp_enable
[15:58:58] <cradek> _active is set only by the planner
[15:59:17] <alex_joni> I think that one tells that there is a commanded move
[15:59:27] <alex_joni> and that it's moving towards the target pos
[15:59:31] <cradek> yes
[15:59:46] <cradek> and _enable tells the planner to stop or go
[15:59:48] <alex_joni> the tp_enable is a command to tell the free tp that it needs to turn on and perform a move
[16:00:18] <cradek> ok so maybe we'd set the motion "source" on _enable, and it would copy it to _active
[16:01:27] <alex_joni> * alex_joni prefers to keep watching the puma jogging
[16:01:42] <cradek> then when another source wants to move, it would compare its "source" with _active, and if they don't match, it would not mess with the free planner's parameters
[16:01:48] <alex_joni> it's so much fun to jog with a gamepad 4 directions ar once in world view
[16:01:54] <alex_joni> s/ar/at/
[16:02:27] <cradek> cool
[16:04:06] <alex_joni> ok, I shut it down
[16:04:12] <alex_joni> it was too distracting :D
[16:04:24] <cradek> what do you think of my plan?
[16:04:45] <alex_joni> sounds good enough
[16:04:53] <alex_joni> although..
[16:05:03] <alex_joni> there might be a jog on joint 2 from the keyb
[16:05:12] <alex_joni> and a jogwheel on joint 3
[16:05:16] <cradek> true
[16:05:18] <alex_joni> those aren't necessarely related
[16:05:26] <alex_joni> but I guess it's easier to keep them separated
[16:05:41] <alex_joni> if the keyb user later decides to press another key for joint 3 jogging too..
[16:05:48] <cradek> free_tp_* are per joint
[16:05:49] <alex_joni> then there's trouble
[16:05:59] <cradek> no, it'll be fine
[16:06:02] <alex_joni> oh, then it's great
[16:06:17] <alex_joni> it's been a while since I looked at the stuff
[16:06:32] <alex_joni> * alex_joni is happy with that plan
[16:06:59] <alex_joni> ok, I'll start looking at the places where enable=1
[16:07:02] <alex_joni> and count the sources
[16:07:09] <cradek> ok
[16:07:23] <cradek> and make an enum in motion.h with the sources
[16:07:37] <alex_joni> right
[16:07:42] <cradek> change the type of _active and _enabled to that enum
[16:07:47] <cradek> then massage as necessary :-)
[16:07:57] <alex_joni> hold you're horses, I'm not that fast :P
[16:08:29] <cradek> meanwhile, I will go shower!
[16:08:45] <cradek> thanks :-)
[16:08:47] <alex_joni> ok :)
[16:27:11] <jmkasunich> hi guys
[16:27:15] <alex_joni> hi jmk
[16:27:28] <alex_joni> we need to mess with the free tp
[16:28:05] <jmkasunich> I saw
[16:28:19] <jmkasunich> one thing you don't need to mess with: backlash does not use the free mode planner
[16:28:24] <jmkasunich> backlash is added later
[16:29:34] <alex_joni> ok..
[16:29:41] <alex_joni> * alex_joni is making a list first
[16:29:47] <alex_joni> maybe you can look at it in a couple of minutes
[16:31:36] <jmkasunich> http://linuxcnc.org/docs/EMC2_Developer_Manual.pdf
[16:31:39] <jmkasunich> figure 3.1
[16:31:42] <jmkasunich> is a good reference
[16:40:21] <alex_joni> http://pastebin.ca/390667
[16:43:05] <jmkasunich> hmm... lots of sources trying to control that thing
[16:44:03] <jmkasunich> for homing I thought a bunch of states used it?
[16:44:13] <jmkasunich> or is #6 in the 2nd list just an example?
[16:44:27] <alex_joni> no, I think it's the only one I saw
[16:45:25] <alex_joni> I think that home_start_move sets it for every state?
[16:45:55] <alex_joni> right.. that's correct..
[16:46:46] <jmkasunich> I wonder why the last move doesn't use hom_start_move?
[16:46:51] <jmkasunich> guess it doesn't really matter
[16:47:31] <jmkasunich> oh, home_start_move starts a move that is intended to hit something
[16:47:42] <alex_joni> because it has a destination
[16:47:43] <jmkasunich> (end of axis, limit switch. home switch)
[16:47:46] <alex_joni> right..
[16:48:00] <jmkasunich> ok
[16:48:02] <alex_joni> the last one is move to a certain position, so it's different
[16:48:03] <alex_joni> anyways
[16:48:14] <alex_joni> 3 sources so far
[16:48:24] <alex_joni> jogging (cont, incr, abs), jogwheels and homing
[16:48:25] <jmkasunich> the problem is multiple sources of commands contending for the free mode planner
[16:48:43] <alex_joni> * alex_joni is talking about the ones that set enable = 1
[16:48:45] <jmkasunich> IMO, during homing, jogs of any kind should be locked out
[16:48:50] <alex_joni> cradek suggest this
[16:49:00] <alex_joni> change enable = 1 with enable = SOURCE
[16:49:14] <alex_joni> that way once a sounce commanded a move, no other sources are allowed to move it
[16:49:56] <jmkasunich> actually, change "enable = 1" with "if (enable=0 or enable=ME) { enable=ME; cmd=mycmd; vel=myvel}
[16:50:14] <alex_joni> yeah, something like that
[16:50:29] <alex_joni> so I'll add an enum to motion.h
[16:50:42] <jmkasunich> slow down a moment
[16:50:53] <jmkasunich> that does a good job of locking down any single move
[16:51:02] <alex_joni> FREE_TP_SOURCE_JOG, FREE_TP_SOURCE_JOGWHEEL, FREE_TP_SOURCE_HOME
[16:51:06] <alex_joni> how so?
[16:51:51] <jmkasunich> during a home, when one move ends, there is a pause before the next one (even if there wasn't, there is at least one servo period where the free tp has stopped)
[16:52:09] <jmkasunich> if somebody spins the jogwheel during that pause, we don't want the axis moving
[16:52:26] <jmkasunich> sorry, brain fart
[16:52:33] <jmkasunich> active goes false at the end of the move
[16:52:54] <jmkasunich> enable doesn't go false until something tells it to
[16:53:01] <alex_joni> right
[16:53:13] <alex_joni> and when it's false, then it will be active very soon
[16:53:28] <alex_joni> so there's no way something else will interfere
[16:53:34] <jmkasunich> but your list has a bunch of places in do_homing_sequence where it goes false
[16:55:52] <alex_joni> indeed
[16:56:04] <jmkasunich> and it will stay false for a while
[16:56:14] <alex_joni> 'a while' ?
[16:56:28] <alex_joni> guess it will wait for active to go false
[16:56:30] <jmkasunich> for example - HOME_INITIAL_BACKOFF_WAIT clears enable when you get off the switch
[16:57:00] <alex_joni> right, and it sets the next state
[16:57:10] <jmkasunich> then HOME_INITIAL_SEARCH_START waits first for active to go false (decel to zero speed) then for the pause timer to time out
[16:57:31] <jmkasunich> only after that does it start the next move
[16:58:13] <jmkasunich> another issue: do_homing only controls one axis at a time (there could be multiple homes in progress at once, but assume there are not)
[16:58:22] <jmkasunich> you could jog any other axis while one is homing
[16:58:38] <jmkasunich> which defeats the home sequencing
[16:58:49] <alex_joni> well.. not necessarely
[16:59:02] <jmkasunich> "don't home Z unless X is at home already because you might hit the lathe chuck"
[16:59:14] <alex_joni> unless the user joggs it to the limit switch or whatever
[16:59:27] <alex_joni> but I guess they can crash it even while not homing
[16:59:34] <jmkasunich> so, they home X, then start homing Z, and jog X out in front of the chuck
[16:59:42] <alex_joni> wonder if one can jog while emc does jogging
[16:59:48] <alex_joni> (from the upper level of control)
[17:00:03] <alex_joni> wonder if one can jog while emc does homing
[17:01:49] <jmkasunich> dunno
[17:02:33] <alex_joni> guess that's possible
[17:03:29] <alex_joni> ok, so the answer is to set all enable's to the HOME SOURCE while homing (even if only one joint is homing)
[17:04:01] <alex_joni> maybe we need another param (free_tp_source, free_tp_enable and free_tp_active)
[17:04:21] <alex_joni> the source is the one that gets set to prevent other sources from driving the free tp
[17:11:32] <jmkasunich> alex_joni: not that simple - if you aren't homing X, its enable should be off
[17:11:49] <alex_joni> jmkasunich: that's why I suggested another variable
[17:11:51] <jmkasunich> I think enable has to remain boolean, and something else should deal with the multiple sources
[17:11:53] <alex_joni> free_tp_source
[17:11:58] <jmkasunich> duh, ok
[17:12:00] <alex_joni> and the free_tp_enable as it is now
[17:12:19] <jmkasunich> lets finish the discussion in #emc about what it should do, then we can figure outthe implementation here
[17:12:37] <alex_joni> right
[17:56:07] <jmkasunich> alex_joni: some thoughts on implementation....
[17:56:17] <alex_joni> * alex_joni is listening
[17:56:28] <jmkasunich> its probably simpler (and thus maybe safer) to make jog buttons higher priority
[17:56:38] <jmkasunich> because the wheel has no "jog end" message to get lost
[17:56:56] <jmkasunich> you can disable the wheel at any time,even in mid-spin, and it won't bite you in the ass later
[17:57:41] <alex_joni> not sure that's so pretty
[17:57:44] <jmkasunich> command.c jog commands would disable the wheel, and the jog-end command (for jog cont) or planner-active going false (for incremental or abs) would re-enable it
[17:58:36] <alex_joni> hmm.. there's a bit of a problem with the homing & jogging thing
[17:58:37] <jmkasunich> whats not pretty?
[17:58:54] <alex_joni> how do we know when to reset the homing flags?
[17:59:00] <alex_joni> err.. that's not clear enough
[17:59:22] <alex_joni> when a homing gets issued, we set the free_tp_source to FREE_TP_SOURCE_HOME.. right?
[17:59:26] <alex_joni> for all joints
[17:59:50] <jmkasunich> I don't think free_tp_source is neccessarily the right way to go
[18:00:03] <alex_joni> after the home finished, we need to reset all joints (free_tp_source=FREE_TP_SOURCE_NONE)
[18:00:06] <alex_joni> why not?
[18:00:12] <jmkasunich> the rules are too complex
[18:00:20] <jmkasunich> homing on any axis disables jogs on all axes
[18:00:36] <jmkasunich> button jog on any axis disables wheel jog on that axis only
[18:01:08] <jmkasunich> I think we should have explicit "enable" flags for each thing (home, button jog, and wheel jog)
[18:01:16] <jmkasunich> and set/clear the flags as needed
[18:01:34] <jmkasunich> maybe - I haven't thought thru it completely yet
[18:01:52] <alex_joni> free_tp_home_enable, free_tp_jog_enable and free_tp_wheel_enable?
[18:01:57] <alex_joni> I don't see how that helps..
[18:02:15] <jmkasunich> certainly for homing, the fact that a homing sequence is in progress should be a single flag, not something split between multiple joints
[18:02:28] <jmkasunich> thats not what I meant at all
[18:02:52] <jmkasunich> first - a global (bad word) "homing is in progress, disable all jogs" flag
[18:03:12] <jmkasunich> that has nothing at all to do with the free tp itself, its a higher level thing
[18:03:51] <alex_joni> I was thinking of adding a test at the end of the homing (check for any other joints still homing)
[18:04:02] <alex_joni> if any other joints are still homing, do nothing
[18:04:11] <alex_joni> if all finished homing, clear whatever
[18:04:19] <jmkasunich> if any joint->home_state != HOME_IDLE, set flag and disable jogs
[18:04:43] <jmkasunich> that can be evaluated every time thru the code
[18:04:51] <alex_joni> any need to do so?
[18:04:56] <alex_joni> it adds some time..
[18:05:04] <alex_joni> why not only when EMCMOT_HOME is received
[18:05:14] <alex_joni> without any checks.. simply set them all
[18:05:26] <jmkasunich> its a mindset thing
[18:05:39] <jmkasunich> command.c is a bunch of code that runs when a command is received
[18:05:50] <alex_joni> right
[18:05:51] <jmkasunich> control.c is a bunch of code that runs at the servo rate (mostly)
[18:05:55] <jmkasunich> do_homing runs all the time
[18:06:02] <alex_joni> right
[18:06:09] <jmkasunich> but most of the time, the state machine state is IDLE, and nothing much happens
[18:06:25] <jmkasunich> do_homing can easily deal with this:
[18:06:48] <jmkasunich> at the start: set homing_flag = 0
[18:06:59] <jmkasunich> in the loop: if state!=IDLE set homing_flag=1
[18:07:11] <jmkasunich> at the end copy local homing_flag to global one
[18:07:19] <alex_joni> I understand how to do it..
[18:07:26] <alex_joni> I don't get why it should be there
[18:07:53] <alex_joni> it simply does the same as doing it in command.cbut with some more time expense
[18:08:01] <jmkasunich> the additional time is negligable, and the code is far more reliable than anything that is based on leaving the flag at its current state unless FOO happens
[18:08:18] <jmkasunich> command can NEVER clear the flag
[18:08:26] <alex_joni> yes, I know
[18:08:28] <jmkasunich> because it doesn't know when homing finishes
[18:08:30] <alex_joni> not talking about clearing it
[18:08:42] <alex_joni> guess if I already need to clear it there, might aswell set it there aswell
[18:09:00] <jmkasunich> if you take my approach, do_homing is totally responsible for the flag - everything is in one place, no possible race conditions ever
[18:09:40] <jmkasunich> clear and set are done by the same code even
[18:12:36] <alex_joni> hmm.. do_homing_sequence()
[18:13:49] <alex_joni> there is a variable called emcmotStatus->homingSequenceState
[18:14:20] <alex_joni> jmkasunich: can I bother you to look at the code?
[18:16:29] <jmkasunich> back (was doing laundry)
[18:17:42] <jmkasunich> do_homing_sequence is jepler's addition to support multi-axis and sequential axis homing
[18:17:48] <alex_joni> ah, ok..
[18:17:58] <alex_joni> the first 3-4 lines are confusing
[18:18:18] <jmkasunich> it would be nice if all homing was considered a sequence, even if there is only one axis
[18:18:28] <jmkasunich> but doesn't look that way
[18:18:58] <jmkasunich> command.c takes joint=-1 as a clue to run a sequence, otherewise it does "normal" homing
[18:20:24] <jmkasunich> I don't completely follow the code in do_homing_sequence, maybe jepler can shed some light on it
[18:20:44] <jmkasunich> I need food
[18:20:46] <jmkasunich> back later
[18:21:04] <alex_joni> ok
[18:21:16] <alex_joni> I'll finish it as good as I can, then put a patch somewhere
[18:35:17] <jepler> you start the homing sequence by setting the state to HOME_SEQUENCE_START, which falls through to HOME_SEQUENCE_START_JOINTS
[18:35:40] <jepler> for each homing order 0, 1, ... HOME_SEQUENCE_START_JOINTS starts them homing and drops into state HOME_SEQUENCE_WAIT_JOINTS
[18:36:00] <jepler> HOME_SEQUENCE_WAIT_JOINTS waits for them each to finish homing, then increments the sequence and goes back to START_JOINTS
[18:36:19] <alex_joni> ahh.. ok
[18:36:31] <alex_joni> so it's basicly a wrapper above the normal HOMING
[18:36:35] <jepler> yes exactly
[18:58:39] <alex_joni> jepler: what about home_sequence?
[18:58:50] <alex_joni> I see you set it to -1 first, then check for that again
[19:00:15] <jmkasunich> homing sequence is based on a home-all command,right? it has nothing to do with single axis homing?
[19:01:25] <alex_joni> right
[19:01:43] <alex_joni> except that when in the right sequence it starts a regular single axis homing
[19:01:48] <alex_joni> (or two ;)
[19:01:52] <jmkasunich> right
[19:01:56] <alex_joni> jmkasunich: as I implemented it now it works ok
[19:02:02] <alex_joni> no jogging while homing
[19:02:08] <jmkasunich> good
[19:02:21] <alex_joni> but if one jogs like a frentic during home sequence it's still possible to stop it :)
[19:02:32] <jmkasunich> not good
[19:02:46] <alex_joni> so I'm thinking about adding another check to HOME_SEQUENCE & co
[19:03:23] <jmkasunich> the jog sneaks in after one axis finishes homing but before the next one starts?
[19:03:29] <alex_joni> yeah
[19:03:38] <alex_joni> but you do need to hit jogging like crazy for that to work
[19:03:50] <alex_joni> (or keep turning the jogwheel)... guess that's easier
[19:04:27] <jmkasunich> homingSequenceState is part of emcmotStatus
[19:04:41] <jmkasunich> so you can test for it being ! IDLE
[19:04:51] <alex_joni> right
[19:04:56] <jmkasunich> at the same place you test for axes being ! IDLE
[19:05:00] <alex_joni> maybe in do_home
[19:05:03] <alex_joni> right
[19:19:23] <alex_joni> jepler: short question..
[19:19:40] <alex_joni> why do you set emcmotStatus->homingSequenceState to HOME_SEQUENCE_IDLE
[19:20:07] <alex_joni> at the beginning of do_homing_sequence() ?
[19:21:41] <jmkasunich> thats just initialization code
[19:21:51] <jmkasunich> first pass thru after startup
[19:22:15] <alex_joni> doesn't do_homing_sequence() get called periodically?
[19:22:20] <jmkasunich> yes
[19:22:34] <alex_joni> and the home_sequence=-1 from the top, happens only once?
[19:22:38] <jmkasunich> yes
[19:22:43] <alex_joni> ahh.. ok, I see
[19:40:12] <alex_joni> * alex_joni doesn't understand why emcmotStatus->homingSequenceState would change to HOME_SEQUENCE_IDLE during a multi-axis home
[19:41:13] <jmkasunich> that does seem strange
[19:41:29] <alex_joni> but it does.. cause I still can catch it with a jog
[19:41:34] <alex_joni> and it's at 0
[19:42:11] <jmkasunich> I'm trying to understnad exactly how sequence homing works
[19:43:14] <jmkasunich> ok, the set to IDLE in HOME_SEQUENCE_START cancels the entire sequence if you attempt to start it while a previous (maybe single axis) home is in progress
[19:43:26] <alex_joni> right.. I got that
[19:43:44] <jmkasunich> there is no break, so it drops into START_JOINTS
[19:44:02] <alex_joni> yup
[19:44:16] <jmkasunich> and starts homing any joints whose home_sequence value is zero
[19:44:24] <alex_joni> and it sets the individual joints to home
[19:44:55] <jmkasunich> if there are any, it moves to WAIT_JOINTS, otherwise, you are done, and it moves to IDLE
[19:44:57] <alex_joni> then it changes to HOME_SEQUENCE_WAIT_JOINTS till all those with 0 finish
[19:45:22] <alex_joni> yes, but it moves to HOME_IDLE (which probably has the same value as HOME_SEQUENCE_IDLE)
[19:45:47] <alex_joni> ok, and there's where the test I wrote fails
[19:45:54] <jmkasunich> the test of JOINT_AT_HOME_FLAG and move to idle says "joint is IDLE, but not homed, something failed, abort
[19:46:29] <jmkasunich> I think that test is improperly nested
[19:46:42] <jmkasunich> it should be an else of the previous test
[19:46:49] <jmkasunich> if !idle, set seen and continue
[19:47:08] <jmkasunich> if idle, test joint at home flag and abort the sequence if not at home
[19:47:15] <alex_joni> I did it like this:
[19:47:38] <alex_joni> initialize the homing_flag to 0 (or 1 if emcmotStatus->homingSequenceState)
[19:47:47] <alex_joni> then if any joint is homing set to 1
[19:47:59] <jmkasunich> right
[19:48:01] <alex_joni> if at the end it's 1, mark all joints with FREE_TP_SOURCE_HOME
[19:48:09] <jmkasunich> the bug isn't yours
[19:48:11] <alex_joni> else clear the flag (if it was HOME before)
[19:48:23] <jmkasunich> I think there is a bug in do_homing_sequence
[19:48:25] <alex_joni> jmkasunich: I just want to find it
[19:48:37] <jmkasunich> I just described what I think it is
[19:48:47] <jmkasunich> <jmkasunich> I think that test is improperly nested
[19:49:09] <alex_joni> I thought you referred to my test
[19:49:31] <jmkasunich> <jmkasunich> I'm trying to understnad exactly how sequence homing works
[19:49:35] <alex_joni> :-)
[19:49:41] <jmkasunich> everything I wrote after that was about sequence homing
[19:50:43] <alex_joni> ok, so you refer to if (!GET_JOINT_AT_HOME_FLAG(joint)) { ?
[19:50:51] <jmkasunich> yes
[19:51:00] <jmkasunich> line 1150 here
[19:51:10] <jmkasunich> maybe differnent if you've changed things
[19:51:11] <alex_joni> 1160 here, ;)
[19:51:44] <alex_joni> ok, so lets read it again :)
[19:52:16] <cradek> hi guys
[19:52:17] <jmkasunich> just the wait_joints state?
[19:52:20] <jmkasunich> hi
[19:52:30] <alex_joni> first it checks if the sequence is ok.. else it skips the joint
[19:52:55] <cradek> it's a bigger problem than I first thought, isn't it
[19:53:01] <jmkasunich> alex_joni: have you made any changes inside do_homing_sequence?
[19:53:08] <alex_joni> jmkasunich: not that I know
[19:53:10] <jmkasunich> ok
[19:53:11] <alex_joni> cradek: not that much bigger
[19:53:16] <jmkasunich> then we won't conflict
[19:53:24] <jmkasunich> as we figure this out, I'm gonna add comments
[19:53:30] <jmkasunich> and then commit
[19:53:28] <alex_joni> ok
[19:53:35] <jmkasunich> start at the top
[19:53:42] <alex_joni> ok
[19:55:29] <alex_joni> cradek: I got most of the stuff figured out I think
[19:55:34] <jmkasunich> the purpose of _START is to make sure an individual home isn't in progress, and bail if it is
[19:55:51] <alex_joni> cradek: just trying to catch the stuff I can test here, and leave the rest to you :P
[19:56:01] <cradek> I'm ready to test on my hardware...
[19:56:01] <alex_joni> jmkasunich: and to start the whole thing
[19:56:10] <alex_joni> jmkasunich: that's what gets set in command.c
[19:56:16] <jmkasunich> right
[19:57:32] <jmkasunich> dunno why he uses j in START_JOINTS
[19:57:41] <jmkasunich> I think he assigns it once and reads it once
[19:57:59] <jmkasunich> (to compare it to home_sequence)
[19:58:10] <jmkasunich> would be clearer to just do the compare directly
[19:58:26] <alex_joni> * alex_joni doesn't like definitions in for loops
[19:58:30] <jmkasunich> * jmkasunich changes it
[20:03:36] <jmkasunich> well, after commenting everything, I take back what I said about the bug
[20:03:51] <alex_joni> hmm :)
[20:03:52] <jmkasunich> there are continue; in there that have the same effect as the else
[20:03:55] <jmkasunich> but harder to read :-)
[20:04:18] <jmkasunich> I don't see how the state would go to idle during a successfull sequence
[20:04:24] <jmkasunich> lemme commit the commented code
[20:04:29] <alex_joni> ok
[20:04:49] <jmkasunich> lemme build it first, make sure I didn't bust anything
[20:05:54] <jmkasunich> I did ;-)
[20:05:56] <jmkasunich> just typos
[20:09:39] <jmkasunich> committed
[20:10:41] <alex_joni> thx
[20:10:58] <jmkasunich> I don't see how the state goes to idle
[20:11:11] <alex_joni> ok, merge went OK
[20:12:36] <alex_joni> hmm.. using halmeter I don't see it either
[20:12:51] <jmkasunich> try halscope, and trigger on the edge
[20:12:54] <jmkasunich> halmeter is slow
[20:15:30] <alex_joni> I don't understand what's wrong
[20:16:04] <jmkasunich> what is happening?
[20:16:17] <alex_joni> I can jog after a HOME finished, just before the next one starts
[20:16:34] <jmkasunich> pastebin your code that decides if its safe to jog
[20:16:43] <jmkasunich> maybe it needs fresh eyes looking at it
[20:17:18] <alex_joni> ahh.. I think I understand
[20:17:24] <alex_joni> the jog doesn't happen first..
[20:17:37] <alex_joni> but when I release the jog key a EMCMOT_ABORT gets sent
[20:17:45] <alex_joni> which aborts the homing
[20:17:53] <jmkasunich> what a crock of crap
[20:17:58] <jmkasunich> abort shouldn't be used to stop a jog
[20:18:11] <alex_joni> there is no other command to do that though ;)
[20:18:14] <cradek> EMCMOT_AXIS_ABORT stops a jog
[20:18:20] <alex_joni> cradek: that one
[20:18:23] <cradek> EMCMOT_ABORT only comes from escape key I think
[20:18:40] <jmkasunich> cradek: EMCMOT_AXIS_ABORT also stops a home
[20:18:49] <alex_joni> * alex_joni wonders if that's needed
[20:18:54] <jmkasunich> releaseing a jog key should not stop a home
[20:19:34] <jmkasunich> jog start and jog end should be their own commands, jog end shouldn't use abort
[20:19:46] <jmkasunich> IMHO
[20:19:47] <alex_joni> the problem is that EMCMOT_AXIS_ABORT sounds very nifty, not like JOG_END
[20:19:50] <jmkasunich> ;-)
[20:19:55] <cradek> EMCMOT_AXIS_ABORT == jog end
[20:20:07] <cradek> if you're ignoring jog commands during home, you have to ignore that
[20:20:08] <alex_joni> cradek: and nothing else iirc.. is that correct?
[20:20:12] <jmkasunich> cradek: understood - I'm saying it shouldn't
[20:20:17] <alex_joni> if that's right, I'll first fix the rest
[20:20:20] <alex_joni> then I will rename it
[20:20:23] <alex_joni> jmkasunich: better like that?
[20:20:23] <jmkasunich> AXIS_ABORT rightly aborts all motion on an axis
[20:20:35] <jmkasunich> and there are probably times when you want AXIS_ABORT
[20:20:46] <jmkasunich> but not if all you wnat to do is stop a jog
[20:21:27] <cradek> I don't think anything would need to abort one axis (except for stopping a jog)
[20:21:37] <jmkasunich> famous last words
[20:21:52] <cradek> so renaming it STOP_JOGGING seems fine (if anyone cares enough)
[20:21:59] <jmkasunich> I'm reluctant to rename and change the behavior of an existing command
[20:22:09] <jmkasunich> especially if we don't know where else it might be used
[20:22:11] <cradek> me too, so leave it
[20:22:42] <jmkasunich> well if we don't change the behavior (or better, introduce a command that has the desired behavior) then we have a bug
[20:22:47] <cradek> to me, it's equal to "stop jog", an examination of the guis would tell if it's ever used for anything else (I bet it's not)
[20:23:12] <cradek> I'll go do that and report
[20:23:12] <jmkasunich> ok, I see two "proper" choices
[20:23:33] <jmkasunich> 1) change the name to stop_jog, and change the behavior to stop jog - deprecate axis_abort
[20:23:45] <jmkasunich> 2) add stop_jog, and retain axis_abort as is
[20:23:52] <alex_joni> it's only used for jog stop
[20:23:58] <alex_joni> I just checked
[20:24:08] <cradek> alex_joni: you're faster than me
[20:24:17] <alex_joni> it is only generated by EMC_AXIS_ABORT (which causes emcAxisAbort, which sends EMCMOT_AXIS_ABORT)
[20:24:21] <jmkasunich> grepmeister
[20:24:52] <jmkasunich> but what causes EMC_AXIS_ABORT? only guis when you let go of jog?
[20:24:56] <cradek> so the minimal change needed is to make it not abort homing?
[20:24:56] <alex_joni> yes
[20:24:57] <cradek> jmkasunich: yes
[20:25:15] <jmkasunich> cradek: and change its name
[20:25:26] <jmkasunich> if it doesn't abort the axis, it shouldn't be called axis-abort
[20:25:27] <alex_joni> jmkasunich: I checked emcmodule, xemc, shcom, keystick and halui
[20:25:40] <jmkasunich> right now it does what it says it does, but its being used where it shouldn't be
[20:25:42] <alex_joni> it's only jog stop, but only if not in TELEOP mode
[20:26:05] <alex_joni> jmkasunich: bet you implemented it judging by name (which was improper chose in emc1)
[20:26:17] <jmkasunich> could be
[20:26:36] <jmkasunich> or maybe even in EMC1 it would have stopped a home
[20:26:47] <jmkasunich> it seems that you might want to be able to do that.....
[20:26:47] <alex_joni> except that there's no EMCMOT_AXIS_ABORT in emc1
[20:26:53] <jmkasunich> thats why I favor a new command
[20:26:59] <jmkasunich> huh?
[20:27:16] <jmkasunich> I can't believe I would have added it
[20:27:22] <alex_joni> oh.. it caused EMCMOT_ABORT in emc1
[20:27:25] <alex_joni> even weirder
[20:27:54] <jmkasunich> so letting go of a jog key would stop jogs on all axes? as well as stopping homing on any axis...
[20:28:04] <cradek> no, emc1 did not do that
[20:28:11] <cradek> very early emc2 DID (incorrectly) do that
[20:28:48] <cradek> multi-axis jogging worked right in emc1 (only when using AXIS)
[20:30:00] <alex_joni> it's probably not that important how emc1 did it
[20:30:19] <cradek> true
[20:31:04] <alex_joni> wonder if you probably sent something else to stop the jog
[20:31:10] <alex_joni> like jog_cont with 0 vel
[20:31:23] <cradek> don't know
[20:31:32] <alex_joni> because emcsh.cc does send EMCMOT_ABORT in emc1
[20:31:44] <alex_joni> which caused all jogs to stop
[20:35:18] <cradek> I'm interested in getting this fixed in 2.1, and I don't think renaming messages and touching all the GUIs is a good way to do it - but sure, renaming the message in trunk is fine
[20:35:27] <alex_joni> right
[20:35:37] <alex_joni> I plan to do it in 2 different commits anyways
[20:36:07] <cradek> if you rename the message second, the first patch will backport easily
[20:36:18] <alex_joni> yeah, that's my plan so far
[20:36:36] <alex_joni> better yet, I'll wait till you tested and fixed any additional bugs
[20:36:45] <cradek> :-)
[20:36:57] <cradek> I don't have a halui joystick...
[20:37:09] <cradek> or home switches, for that matter
[20:37:11] <cradek> not sure how to test it all
[20:37:25] <alex_joni> I'm testing the halui joystick
[20:37:28] <cradek> ok
[20:37:38] <alex_joni> and simulated home switches (sim->axis)
[20:40:21] <alex_joni> yay, seems to work as it should now
[20:40:58] <cradek> * cradek goes to fire up the beasty PII
[20:41:05] <jmkasunich> * jmkasunich is back from taking the dog outside
[20:41:13] <alex_joni> a bit more testing, and I'll commit
[20:44:21] <jmkasunich> stupid stupid dog....
[20:45:06] <jmkasunich> we have a park outside - its a nice sunny day, and there are kids in the park
[20:45:28] <jmkasunich> he thinks the park is his yard, and those kids are not supposed to be there
[20:46:01] <cradek> that's better than him thinking those kids look like good eatin'
[20:46:12] <jmkasunich> maybe he does think that
[20:46:18] <jmkasunich> (not likely)
[20:46:32] <jmkasunich> he's in the house, so it doesn't matter what he thinks - but he'
[20:46:43] <jmkasunich> he's barking his fool head off
[20:47:14] <cradek> for us, garden hose (outside) and squirt bottle (inside) worked for stopping barking
[20:47:27] <jmkasunich> that requires my presence within squirting range
[20:47:42] <jmkasunich> he already knows not to bark when I'm in range
[20:47:43] <cradek> * cradek <- cat person
[20:48:13] <alex_joni> haha
[20:48:35] <alex_joni> one minor discomfort I still see, which I wanna fix before committing
[20:48:45] <jmkasunich> we have this anti-bark collar that gives him a little zap if he barks - but we only put it on him when he's being stupid
[20:48:50] <alex_joni> don't seem to be able to change jog speeds during a jog
[20:49:04] <cradek> you took out my hackery, right?
[20:49:11] <alex_joni> cradek: parts of it
[20:49:18] <alex_joni> might have missed some..
[20:49:23] <cradek> because it broke that
[20:49:31] <jmkasunich> the parts that locked the jogspeed so the wheel couldn't mess it up?
[20:49:42] <cradek> yes
[20:50:00] <jmkasunich> I mean did alex take out those parts
[20:50:26] <alex_joni> * alex_joni tries to identify all of them
[20:50:41] <cradek> it was just two commits, both last night
[21:00:00] <alex_joni> oh silly me..
[21:00:02] <alex_joni> it was working :(
[21:00:10] <alex_joni> but I had the halui jogspeed set too high
[21:00:20] <alex_joni> so the scaling it did was all above the max jogspeed
[21:00:24] <alex_joni> so it got clamped
[21:00:30] <alex_joni> and I didn't see any difference :(
[21:00:41] <alex_joni> * alex_joni whines for wasting time
[21:02:21] <alex_joni> cradek: now it works right for me.. got no jogwheel to test though
[21:02:30] <cradek> I'm ready to try it
[21:02:49] <alex_joni> a couple more diff's to check for forgotten stuff
[21:04:46] <jmkasunich> VMs and RT do NOT get along
[21:05:17] <cradek> these old PII and PIII machines sure do work well for realtime
[21:05:26] <cradek> you don't have to mess with them, they just work
[21:05:33] <alex_joni> * alex_joni loves his athlon
[21:05:33] <jmkasunich> even though the VMs aren't doing much at the moment, when I start EMC and the interrupt rate goes from 1KHz to 50KHz, the VM processes have to handle things
[21:05:57] <jmkasunich> I want a fast server - put the VMs and my webserver and such on it and forget about them
[21:06:26] <jmkasunich> * jmkasunich suspends the compile farm
[21:06:43] <jmkasunich> I'll probably forget to resume it tonight
[21:07:01] <alex_joni> cron?
[21:07:06] <alex_joni> or at
[21:07:25] <jmkasunich> its not that simple - for some reason the ubuntu VMs don't correct their clocks when they resume
[21:07:39] <jmkasunich> the BDI-4.51 one does
[21:07:53] <cradek> the ntp setup in dapper is very screwy
[21:08:17] <cradek> don't know if that's related or not
[21:08:19] <jmkasunich> the VMs are breezy, but they probalby have the same screwyness
[21:09:02] <jmkasunich> the problem is that the VMs don't belong on my RT development machine
[21:09:04] <alex_joni> ok, here it goes
[21:11:10] <jmkasunich> gack....
[21:11:19] <jmkasunich> halcmd show displays u32 vars in hex
[21:11:34] <jmkasunich> I know that was my idea, and I know there was a time I thought it was a good idea
[21:11:38] <cradek> I thought it displayed both dec and hex
[21:11:46] <jmkasunich> at one time it did
[21:12:04] <jmkasunich> but that borked up things like halshow that were parsing the output
[21:12:27] <jmkasunich> halshow should be using script mode now, and maybe the regular output should have both, but it doesn't
[21:12:29] <jepler> they should be changed to use 'halcmd getX' instead of parsing 'halcmd show'
[21:12:50] <jmkasunich> yeah
[21:12:57] <jmkasunich> I just love how these side issues keep popping up
[21:13:06] <jmkasunich> I'm trying to test the stepgen
[21:13:12] <cradek> alex_joni: testing...
[21:13:27] <jmkasunich> dunno whether to whip out the hex calculator, or fix the u32 display problem
[21:13:51] <alex_joni> jmkasunich: bc
[21:14:18] <cradek> alex_joni: looks right
[21:14:23] <alex_joni> yay
[21:14:29] <cradek> I can jog one joint with the keyboard and one with the wheel
[21:14:43] <alex_joni> try homing the third one
[21:14:46] <cradek> but if I try to jog the same joint with both controls, they ignore one another
[21:15:14] <alex_joni> right.. there's place for arguing there
[21:15:19] <alex_joni> but I like the ignore way better
[21:15:36] <alex_joni> jmk suggested to have one with higher importance, which would just take over
[21:15:36] <jmkasunich> ignore one another = neither one does anything?
[21:15:49] <cradek> when one is working, the other is ignored
[21:15:50] <alex_joni> the one active keeps working, the other is shorted out
[21:16:14] <cradek> hmmm
[21:16:25] <jmkasunich> not "one", I was thinking of keyboard jog as higher, because wheel jog can be cleanly disabled and enabled - no worries about getting a start message and missing the end message or vice versa
[21:16:30] <cradek> when jogging with the keyboard, I think the wheel still is updating the target
[21:16:55] <alex_joni> cradek: I tried to get the rest right..
[21:17:00] <alex_joni> we can look closer at wheel if you want
[21:17:33] <jmkasunich> the wheel has an enable hal pin - seems you could just hook into that logic
[21:17:55] <jmkasunich> somewhere there is "if (joint->jog_enable_pin)
[21:18:13] <jmkasunich> change to "if (joint->jog_enable_pin && wheel_enabled)
[21:18:58] <cradek> alex_joni: in handle_jogwheels, maybe "set target position" should be inside the if
[21:18:58] <alex_joni> cradek: oh, the target pos is set outside my test
[21:19:04] <alex_joni> right
[21:19:17] <alex_joni> I started from your version though :P
[21:19:24] <alex_joni> just move that in there, and it should be ok
[21:19:28] <cradek> bad mistake :-)
[21:20:04] <alex_joni> I started from a "backported version" :P
[21:20:37] <cradek> ok, I'm trying it now
[21:21:47] <cradek> that fixes it
[21:22:03] <alex_joni> great
[21:22:54] <alex_joni> hmm.. we need another test
[21:23:29] <alex_joni> cradek: I think we need to check for joint->free_tp_source == FREE_TP_SOURCE_HOME
[21:23:42] <alex_joni> if that's set, then the jogwheel needs to be disabled as well
[21:24:13] <cradek> wouldn't it be _active while homing?
[21:24:19] <alex_joni> not always
[21:24:30] <alex_joni> there are pauses between states I think
[21:24:49] <alex_joni> also another issue: _all_ joints need to be disabled from jogging while homing
[21:25:03] <alex_joni> because of HOME_SEQUENCE (imagine homing joint 1, and jogging joint 3)
[21:25:08] <cradek> so (active && JOGWHEEL) || (!active && IDLE) ?
[21:25:35] <alex_joni> (active && JOGWHEEL) || (!active && NONE)
[21:26:01] <cradek> make tags
[21:26:03] <cradek> err
[21:26:05] <alex_joni> but I'd rather put:
[21:26:18] <alex_joni> if (joint->free_tp_source == FREE_TP_SOURCE_HOME) continue;
[21:26:29] <alex_joni> as a separate rule before that..
[21:26:41] <cradek> !=
[21:26:57] <alex_joni> ==
[21:27:21] <alex_joni> continue breaks out of the current loop.. right?
[21:27:27] <cradek> oh sorry, I read it as NONE
[21:27:29] <cradek> font too small
[21:27:32] <alex_joni> heh
[21:28:05] <alex_joni> I'm using 10-point
[21:28:55] <cradek> but it's not just home that makes us want to continue is it?
[21:29:16] <cradek> also I'm worried about JOINT_ERROR_FLAG etc
[21:30:11] <alex_joni> that only clears any possible joint errors
[21:30:36] <cradek> if (joint->free_tp_active && joint->free_tp_source != FREE_TP_SOURCE_JOGWHEEL) { continue; }
[21:30:48] <cradek> isn't this the required logic?
[21:31:34] <cradek> I think that handles all the cases?
[21:31:38] <alex_joni> FREE_TP_SOURCE_HOME can be there even if not active
[21:32:00] <alex_joni> FREE_TP_SOURCE_HOME gets set on all joints, when at least one is homing
[21:32:03] <cradek> oh, right, I keep forgetting that
[21:32:12] <cradek> ok that can be a separate test above
[21:32:21] <alex_joni> that's what I suggested
[21:32:48] <alex_joni> if (joint->free_tp_source == FREE_TP_SOURCE_HOME) continue;
[21:32:50] <alex_joni> then your test
[21:33:07] <alex_joni> then the existing without a test
[21:34:08] <cradek> http://pastebin.ca/391054
[21:35:22] <alex_joni> perfect
[21:41:30] <alex_joni> cradek: feeling confident enough to backport it?
[21:41:52] <cradek> it's definitely better than what was there
[21:48:48] <alex_joni> should I or will you?
[21:49:17] <cradek> I will if you need to get to bed...
[21:49:52] <jmkasunich> cradek: alex mailed you the code?
[21:50:32] <alex_joni> jmkasunich: no, I commited it a while ago
[21:50:56] <cradek> it's in trunk
[21:51:00] <jmkasunich> duh
[21:51:00] <alex_joni> about 40 minutes ago
[21:51:00] <cradek> I committed those tweaks
[21:52:02] <alex_joni> cradek: will you?.. I think I'll head to bed soon
[21:52:06] <cradek> sure
[21:52:19] <alex_joni> if you make a new release, don't worry about SF & linuxcnc.org
[21:52:24] <alex_joni> I'll do that in the morning
[21:57:18] <cradek> argh
[21:57:43] <jmkasunich> ?
[21:58:19] <alex_joni> cradek: ?
[21:58:43] <cradek> jmkasunich: are your 1.95 and 1.96 commits no real change?
[21:59:00] <jmkasunich> the last one is no real change at all
[21:59:00] <cradek> you rearranged where some variables were declared or something
[21:59:17] <jmkasunich> the former one pulls out some inline declarations, no functional change
[22:00:23] <jmkasunich> sorry....
[22:00:38] <cradek> emcmot_hal_data->debug_s32_0 = emcmotStatus->id;
[22:00:38] <cradek> emcmot_hal_data->debug_s32_1 = emcmotStatus->homingSequenceState;
[22:00:44] <cradek> are these new?
[22:00:50] <alex_joni> cradek: that's mine..
[22:01:03] <alex_joni> I put the s32_1 = emcmotStatus in there
[22:01:05] <cradek> they shouldn't be backported?
[22:01:08] <alex_joni> it has no real value
[22:01:09] <cradek> ok
[22:01:10] <jmkasunich> any change to where those debug signals come from is pretty much irrelevant
[22:01:42] <jmkasunich> its "the last developer who needed these debug signals was looking at this internal variable"
[22:02:02] <alex_joni> yeah, but probably a bit more usefull than leaving them = 0
[22:02:15] <alex_joni> although I bet that the needed value won't ever be there ;)
[22:02:21] <alex_joni> so you still need to recompile
[22:02:24] <jmkasunich> nobody other than a developer should be expecting any specific thing on those params
[22:02:32] <alex_joni> right..
[22:02:51] <alex_joni> * alex_joni was thinking about real-time debugging a user
[22:03:09] <jmkasunich> some of our users need debugged
[22:06:14] <alex_joni> indeed
[22:07:54] <alex_joni> good night all
[22:07:59] <cradek> goodnight
[22:08:02] <cradek> thanks for working this out
[22:08:10] <cradek> I'll do my best to get the backport right
[22:08:23] <alex_joni> plan to release too?
[22:08:27] <cradek> not sure
[22:08:36] <alex_joni> ok..
[22:08:39] <cradek> do you think I should?
[22:11:05] <alex_joni> there are quite a few bugfixes in the changelog..
[22:11:45] <cradek> yes definitely
[22:11:49] <alex_joni> 14 entries in the changelog
[22:12:05] <alex_joni> 2.1.1 had 12 over 2.1.0
[22:12:51] <cradek> sure hope I got that right...
[22:13:00] <cradek> I will build a package and test
[22:13:02] <alex_joni> * alex_joni reviews
[22:13:14] <anonimasu> cradek: are you awake?
[22:13:34] <cradek> how asleep could I be if I'm typing?
[22:13:55] <anonimasu> cradek: just joined here :)
[22:13:59] <cradek> right
[22:14:20] <anonimasu> cradek: What do you mean by "free mode planner" ?
[22:14:38] <cradek> the thing that plans the motion in free (not coordinated) mode
[22:14:57] <anonimasu> ah ok
[22:15:01] <anonimasu> I see :)
[22:17:22] <alex_joni> it takes care of jogging for example
[22:17:39] <cradek> jogging, homing, jogwheel
[22:17:57] <anonimasu> alex_joni: yeah I know the diff :)
[22:18:36] <alex_joni> anonimasu: ok, just wanted to make sure that you know what it means in emc
[22:25:54] <cradek> hmm, I got a runaway jog ... once
[22:27:21] <alex_joni> cradek: yuck.. doing what?
[22:27:40] <cradek> playing with the wheel and arrows
[22:27:43] <cradek> can't get it again
[22:29:01] <cradek> nope just once
[22:29:20] <cradek> wish I had imagined it
[22:29:31] <alex_joni> I think I know why..
[22:29:41] <alex_joni> if (joint->free_tp_active && joint->free_tp_source != FREE_TP_SOURCE_JOGWHEEL) {
[22:30:06] <alex_joni> when the jog command is received it sets free_tp_enable to 1
[22:30:19] <alex_joni> it also sets the free_tp_source to FREE_TP_SOURCE_JOG
[22:30:41] <alex_joni> if in the same servo cycle you move the jogwheel, it will not catch that
[22:30:54] <alex_joni> the free_tp_active only comes lateron
[22:31:00] <cradek> oh....
[22:31:23] <cradek> that's a very small window - I'm surprised I did it
[22:31:39] <alex_joni> yeah, but that's the only case I can see that would do it
[22:32:00] <alex_joni> try pushing the jogkey at the same time you start turning the wheel
[22:33:48] <cradek> I can't do it again
[22:34:50] <cradek> aha, did it again
[22:34:51] <jepler> can you run with a longer servo period to try to make it happen? 100ms? 1s?
[22:35:03] <cradek> it makes a full speed jog to the limit
[22:35:17] <cradek> when it's going, pushing and releasing the keyboard arrow several times does not stop it
[22:35:21] <cradek> hitting escape stops it
[22:35:29] <cradek> jepler: good idea
[22:35:47] <anonimasu> cradek: that's a scary bug :)
[22:35:59] <cradek> yes
[22:36:02] <alex_joni> - if (joint->free_tp_active && joint->free_tp_source != FREE_TP_SOURCE_JOGWHEEL) {
[22:36:07] <alex_joni> + if ((joint->free_tp_active || joint->free_tp_enable) && joint->free_tp_source != FREE_TP_SOURCE_JOGWHEEL) {
[22:37:28] <cradek> with .1s servo cycle I can do it every time
[22:37:37] <alex_joni> cradek: can you try that fix?
[22:37:41] <cradek> although abort takes a long time!
[22:38:03] <cradek> yes, one minute
[22:41:07] <cradek> now the jogwheel stops working sometimes
[22:42:06] <alex_joni> stops for good?
[22:42:18] <cradek> it works once, after each keyboard jog
[22:43:07] <cradek> _enable doesn't get set to 0 after the target is reached?
[22:43:34] <cradek> ^^ a guess
[22:43:43] <alex_joni> * alex_joni looks
[22:44:11] <alex_joni> enable gets set to 0 after the jog ended
[22:44:20] <alex_joni> not sure about jogwheel though
[22:44:24] <cradek> but what if it reaches the target by jogwheel
[22:44:37] <cradek> (that would explain it)
[22:45:59] <alex_joni> yup.. that's the case
[22:46:22] <alex_joni> add the _enable = 0 to the if (delta == 0) above
[22:46:35] <alex_joni> where I cleared the free_tp_source
[22:46:42] <cradek> file:line#?
[22:46:48] <alex_joni> control.c
[22:46:58] <alex_joni> line 990 in my version
[22:47:48] <cradek> testing
[22:48:59] <cradek> now keyboard jogging doesn't work at all
[22:49:10] <alex_joni> oh ..
[22:49:15] <alex_joni> forgot to say :)
[22:49:41] <alex_joni> put that in the other if together with the joint->free_tp_source = FREE_TP_SOURCE_NONE
[22:49:47] <cradek> I did
[22:50:04] <alex_joni> so only disable it if FREE_TP_SOURCE_JOGWHEEL is set
[22:50:09] <cradek> oh
[22:50:13] <cradek> duh
[22:50:28] <alex_joni> sorry.. wasn't clear enough :(
[22:50:31] <jmkasunich> this is sounding ugly
[22:50:33] <cradek> sorry I'm not paying attention
[22:50:44] <jmkasunich> but since you guys are doing the work, I should shut up
[22:50:53] <alex_joni> jmkasunich: half that serious really
[22:51:06] <alex_joni> but it's late here.. and I don't have a jogwheel
[22:51:21] <alex_joni> I bet cradek would fix it in 5 minutes if I weren't around :)
[22:51:49] <anonimasu> heh it's like jepler and the visualization stuff.
[22:51:56] <jmkasunich> well, you figured out the race condition between free_tp_source and free_tp_active without a wheel
[22:52:24] <cradek> now I think it's right
[22:52:32] <alex_joni> yay, finally :)
[22:53:09] <alex_joni> jmkasunich: yeah, but there are lots of strange things that appear in practise
[22:53:59] <alex_joni> * alex_joni still wonders how cradek managed to get it to fire :)
[22:54:08] <cradek> pure luck
[22:54:19] <alex_joni> the second time I mean :P
[22:54:32] <cradek> a ms is a long enough time I guess
[22:55:04] <jmkasunich> its scary that we depend on testing stuff like that
[22:55:05] <alex_joni> anyways, glad it's right now
[22:55:21] <cradek> alex_joni: yay, me too
[22:55:44] <alex_joni> jmkasunich: I mostly think testing is nicer than assuming code works as it's designed for :)
[22:56:04] <jmkasunich> testing is usefull, but it can never prove the absence of bugs
[22:57:14] <anonimasu> that's actually very scary
[22:57:25] <jmkasunich> but true
[22:57:31] <anonimasu> yeah
[22:57:45] <jmkasunich> the only want to be sure there aren't bugs in something is to keep it simple enough that you can analyze all cases
[22:57:51] <anonimasu> yeah
[22:58:01] <alex_joni> and even that doesn't guarantee you anything
[22:58:02] <cradek> and then be a perfect analyzer
[22:58:06] <jmkasunich> as things get more complex, and especially as they interact with each other, it becomes impossible
[22:58:10] <alex_joni> (think about bugs in the compiler, etc)
[22:58:23] <cradek> there will never be bug-free software - everyone accept that now
[22:59:08] <anonimasu> well, yeah, but for something like emc, it has the potential to kill someone.. :/
[22:59:27] <alex_joni> anonimasu: not unless you are willing to take the chance
[22:59:26] <cradek> anonimasu: not on a properly configured machine.
[22:59:51] <cradek> if you bet your life on emc's not having any bugs ...
[22:59:59] <jmkasunich> IT IS _EXTREMELY_ UNWISE
[22:59:59] <jmkasunich> TO RELY ON SOFTWARE ALONE FOR SAFETY. Any machinery capable of
[22:59:59] <jmkasunich> harming persons must have provisions for completely removing power
[22:59:59] <jmkasunich> from all motors, etc, before persons enter any danger area.
[23:00:03] <cradek> that's just crazy
[23:00:12] <jmkasunich> that is in the headers of many EMC2 files
[23:00:31] <anonimasu> well, do you power your drives down for a manual toolchange?
[23:00:44] <alex_joni> anonimasu: it's fast & easy
[23:00:45] <alex_joni> F2 twice
[23:01:05] <alex_joni> once for machine off, once for machine on
[23:01:08] <cradek> anonimasu: that's not exactly betting my life
[23:01:17] <jmkasunich> betting your fingers though
[23:01:20] <alex_joni> cradek: maybe not on your machine :P
[23:01:42] <alex_joni> anonimasu: I am betting my life on the robots I work with sometimes
[23:01:44] <jmkasunich> not on cradek's machine maybe, but if you are holding a 3" long x 1" dia endmill and the spindle starts... messy
[23:01:46] <cradek> betting 3 stitches maybe
[23:02:23] <alex_joni> I had one runaway at full speed once
[23:02:24] <jmkasunich> want to talk about betting your life on software - see the robot ride video thats floating around the interweb
[23:02:36] <cradek> yep, that's pretty nutso
[23:02:36] <alex_joni> jmkasunich: yup.. that's insane ;)
[23:02:41] <anonimasu> alex_agreed
[23:02:45] <anonimasu> err agreed..
[23:04:17] <cradek> I'm hungry!
[23:04:41] <alex_joni> hmm.. I was going to bed
[23:04:41] <alex_joni> at some point
[23:04:47] <cradek> goodnight alex_joni
[23:04:52] <cradek> thanks again
[23:04:57] <jmkasunich> I thought we had a hal component that picked the larger of two inputs....
[23:05:03] <anonimasu> good work! :)
[23:05:03] <jmkasunich> goodnight alex
[23:05:08] <alex_joni> comp & mux ?
[23:05:42] <jmkasunich> yeah, but that gets messy when you have several inputs
[23:05:54] <jmkasunich> perhaps I should write it
[23:05:55] <alex_joni> max ?
[23:07:01] <jmkasunich> "loadrt highest num_inputs=2,5,2,3" maybe
[23:08:10] <jmkasunich> drat - comp won't do things with variable numbers of hal pins
[23:08:43] <jmkasunich> guess I can write "max2" and cascade them
[23:10:58] <jmkasunich> or I can forget it and test one axis at a time ;-)
[23:11:06] <cradek> what are you working on?
[23:11:14] <jmkasunich> stepgen testing
[23:11:21] <cradek> ah
[23:11:35] <jmkasunich> want to trigger the scope if any of 3 or 4 vars goes over a level
[23:12:02] <jmkasunich> with a max comp, I'd have a value that was the max of all 4, then I can adjust the trigger level in the scope
[23:12:05] <cradek> I did that for tp testing, using a bunch of comparators and a match8
[23:12:29] <cradek> match =~ nor8
[23:12:32] <jmkasunich> yeah, but changing the level is more of a pain
[23:12:36] <cradek> yes
[23:13:04] <jmkasunich> I was getting the disturbance on X last time, I'll just use X again
[23:13:28] <jmkasunich> flowsnake is pretty symmetrical in XY anyway
[23:13:35] <jmkasunich> it doesn't move Z, so I don't need to watch that