Back
[01:38:35] <jmkasunich> cradek: you around?
[01:39:54] <jmkasunich> I've found that the blend between segments 1 and 2 (with the bobble) is half as long as subsequent blends
[01:40:05] <jmkasunich> even tho all segments are the same lengt and speed
[01:40:11] <SWPadnos> hmmm
[01:40:29] <SWPadnos> maybe only blending during one "side" of the blend time
[01:40:34] <jmkasunich> also, the start of segment 2 (and maybe segment 1) seem screwy
[01:40:36] <CIA-22> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/vars_names.c: Fix for blank symbol name crash when clicking for status and fix compiler warnings
[01:41:09] <jmkasunich> well, the pin "program-line" changes state right in the middle of the blend in both cases, so I don't think I'm missing half of the blend
[01:41:23] <SWPadnos> hmmm. ok then
[01:41:53] <CIA-22> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/emc_mods.c: more error checking/small message changes
[01:41:57] <jmkasunich> I'm plotting tc->progress and nexttc->progress, and for later segments they seem to be what I'd expect
[01:42:13] <jmkasunich> during the blend, tc->progress is decelling, and nexttc->progress is acceling
[01:42:23] <jmkasunich> then it transitions, and what was nexttc becomes tc
[01:42:52] <CIA-22> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/edit.c: small message changes
[01:43:07] <jmkasunich> at the start of the 2nd segment tho, it seems like nexttc->progress doesn't accel as much as it should (which is consistent with too short a blend time
[01:43:27] <SWPadnos> that
[01:43:40] <SWPadnos> that's the start of the second synchronized segment?
[01:43:48] <jmkasunich> and after the transition, it continues to accel and overshoots the target velocity until it catches up
[01:43:49] <jmkasunich> yes
[01:44:20] <SWPadnos> so you have one segment where sync begins, and that one seems to be fine, then the next one has the bobble?
[01:44:34] <jmkasunich> the bobble is at the transition between segs 1 and 2
[01:44:35] <SWPadnos> next transition that is
[01:44:44] <jmkasunich> subsequent transitions are fine
[01:45:21] <jmkasunich> there is an overshoot at the start of segment 1 as well, which I originally thought was just a result of trying to catch a moving spindle at start-of-sync, but now I'm beginning to wonder
[01:56:06] <jmkasunich> man, a comment or two in the blending code would be nice
[01:56:25] <jmkasunich> I'm sure somebody knows what "secondary_before" means
[01:57:45] <SWPadnos> heh
[01:57:59] <SWPadnos> that's just before primary_after, right? :)
[01:58:04] <jmkasunich> oh, I think I'm starting to get it
[01:58:07] <jmkasunich> yes, actually
[01:58:15] <SWPadnos> heh
[01:58:20] <SWPadnos> lucky guess
[01:58:33] <jmkasunich> primary_before = the positoon of the first segment, before running the planner on that segment
[01:58:52] <jmkasunich> primary_after = position of first segment after running planner
[01:58:56] <jmkasunich> ditto for secondary
[01:59:05] <SWPadnos> ok, sounds easy enough
[01:59:11] <SWPadnos> the naming anyway
[01:59:44] <jmkasunich> then they calculate the difference between before and after for each
[01:59:55] <jmkasunich> into "primary_displacement" and "secondary_displacement"
[02:00:21] <jmkasunich> and funally add both displacements to the current position
[02:00:53] <jmkasunich> finally even
[02:01:17] <jmkasunich> I guess it would be informative to look at the primary and secondary displacements
[02:01:30] <CIA-22> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/spy_vars_gtk.c: Adjust name and size of var windows
[02:18:55] <jmkasunich> well, dog is whining again... but I think I'm slowly making progress
[02:19:04] <jmkasunich> goodnight
[02:19:42] <SWPadnos> see you later
[02:20:49] <fenn_> fenn_ is now known as fenn
[02:29:19] <cradek> jmkasunich: I bet you found it. the accels don't match (some are /2.0 and others aren't)
[02:29:30] <cradek> ^ (unverified)
[02:29:51] <cradek> the accels must match for the blend to be smooth
[02:30:59] <cradek> those excellent names after/before/displacement/primary/secondary ARE the documentation... :-)
[02:35:48] <skunkworks> yeck - cold coffee.
[02:36:02] <skunkworks> cradek: what does it all mean? Fixable?
[02:37:01] <cradek> oh everything is fixable
[02:37:09] <skunkworks> Heh - I suppose.
[02:37:48] <cradek> there is a trivial fix - always cut all the accels in half, even in exact stop mode
[02:37:55] <cradek> that's the first thing jmk should try
[02:38:09] <cradek> of course that's not ideal if you ever use exact stop mode.
[02:38:20] <cradek> but if it fixes it, it's the smoking gun
[02:39:07] <skunkworks> Huh - I will leave that to you guys.. :) (a bit outside my knowledge base)
[02:39:17] <cradek> too bad he left already
[02:39:35] <cradek> I've had less time for emc lately and it's hard to catch him for long
[02:39:59] <cradek> especially since he lives in the future so it's later for him
[02:40:17] <skunkworks> Heh - I think all you guys live in the future.
[02:40:44] <cradek> nah, I live partly in the past and partly in the present
[02:40:51] <cradek> it's my birthday
[02:41:01] <skunkworks> Happy birthday. 33?
[02:41:02] <cradek> I've decided I feel 23
[02:41:20] <cradek> that's when I quit getting older :-)
[02:41:20] <skunkworks> Heh - I think I remember you being about my age.
[02:41:24] <cradek> 34
[02:41:42] <skunkworks> oh - exactly my age.
[02:41:43] <jmkasunich> I
[02:41:49] <jmkasunich> I'm baaaaaack
[02:41:52] <cradek> welcome
[02:42:03] <jmkasunich> happy birthday!
[02:42:16] <cradek> thank you
[02:42:46] <SWPadnos> "Harpie boot-day to ooooo"
[02:42:54] <jmkasunich> I actually wasn't planning on doing any more on that bug tonight - I was gonna take a quick stab at the "halscope used to be able to sample ever N runs of the thread, and now it won't" bug
[02:43:04] <jmkasunich> but since you're here....
[02:43:10] <cradek> can you try that one simple change?
[02:43:13] <skunkworks> oh well - back to grouting.. wish me luck.
[02:43:23] <jmkasunich> good luck
[02:43:25] <cradek> sounds fun
[02:43:30] <cradek> grunting?
[02:43:33] <SWPadnos> oh, lovely. have fun, especially if you have some of the colored stuff :)
[02:43:36] <cradek> grousing?
[02:43:38] <jmkasunich> cradek: it will be simple if you tell me what accels I should change
[02:43:42] <SWPadnos> all of the above, I'm sure
[02:43:48] <jmkasunich> grunting is only if its a floor, and you have old knees like me
[02:43:58] <cradek> take away the ifs on lines 727 and 745
[02:44:05] <cradek> make the /= always happen
[02:44:25] <jmkasunich> my line nums are a big borked, lemme look around in that area
[02:44:43] <cradek> search for /= 2.0
[02:44:44] <jmkasunich> this if: // honor accel constraint in case we happen to make an acute angle
[02:44:56] <cradek> yes - there are two of them
[02:46:13] <jmkasunich> still bobbles
[02:46:42] <cradek> same?
[02:46:49] <jmkasunich> looks like it
[02:46:54] <jmkasunich> which seems suspicious
[02:47:00] <cradek> I agree
[02:47:35] <jmkasunich> I did this:
[02:47:37] <jmkasunich> // honor accel constraint if we happen to make an acute angle with the
[02:47:37] <jmkasunich> // above segment or the following one
[02:47:37] <jmkasunich> / debug jmk if(tc->blend_with_next || nexttc->blend_with_next)
[02:47:37] <jmkasunich> nexttc->maxaccel /= 2.0;
[02:47:43] <jmkasunich> in two places
[02:47:53] <jmkasunich> the / debug jmk is really a //, IRC stole one
[02:48:15] <cradek> that should do it
[02:48:15] <SWPadnos> with two slashes, hopefully
[02:48:15] <SWPadnos> ah
[02:48:15] <cradek> did you compile
[02:48:16] <cradek> did you compile the right thing
[02:48:16] <jmkasunich> yes ;-)
[02:48:18] <cradek> are you running what you compiled
[02:48:32] <cradek> surprisingly I can sometimes get all of those wrong in a row
[02:48:44] <jmkasunich> I'd be astonished if not, because prior changes (mostly moving debug params) have all taken effect
[02:48:49] <jmkasunich> lemme move something
[02:48:55] <cradek> well maybe that's not it.
[02:49:12] <cradek> sure seems likely though if you see different blend times
[02:50:48] <jmkasunich> ok, ruled out pebkac - I did compile and run the changed code
[02:50:58] <cradek> darn.
[02:52:51] <jmkasunich> removed the hack and ran again - absolutely no effect (at least on synced moves, both good and bad)
[02:53:07] <jmkasunich> probably had an effect on the g0, but I didn't capture that on scope
[02:53:42] <cradek> well that's mixed comfort because I didn't really spot anything wrong with it
[02:53:55] <cradek> can you show me the plot that somehow showed differing blend times?
[02:54:18] <jmkasunich> sure, just a sec
[02:55:28] <jmkasunich> http://jmkasunich.com/pics/threading-bobble-2.png
[02:56:17] <cradek> those labels don't help much when they splatter over one another
[02:56:26] <jmkasunich> nope
[02:56:29] <cradek> might be nice to try to fix that somehow
[02:56:38] <jmkasunich> yeah
[02:56:49] <cradek> I like them by the traces, but they could go on the top or something instead.
[02:56:51] <SWPadnos> a list at the top left/right, in position order and the correct color
[02:56:51] <jmkasunich> anyway - green is the bit that says "we're blending"
[02:57:48] <jmkasunich> the upward ramp (magenta) is an int that is incremented each time RunCycle runs - just a timestamp (and also a test to confirm that the TP runs every 10mS, not every 1mS
[02:58:11] <SWPadnos> jmkasunich, when you get to fiddling with halscope, can you change how the trigger level is displayed / changed? (when you change scale/offset on the trigger channel trace, the trigger level shouldn't change, the line should move to reflect the new scale)
[02:58:30] <jmkasunich> SWPadnos: I disagree
[02:58:43] <jmkasunich> trigger level is screen relative - otherwise the slider doesn't make sense
[02:58:54] <SWPadnos> ok, nevermind. we can discuss it at a later time
[02:58:57] <cradek> really? I'm surprised
[02:59:00] <jmkasunich> anyway, I want to stay focused on this
[02:59:01] <cradek> but yeah, later
[02:59:18] <jmkasunich> the brown trace is tc->vel_at_blend_point
[02:59:27] <jmkasunich> (the brown one above zero)
[03:00:23] <jmkasunich> the puke green one that starts out zero, then ramps down to -0.0016 at the first blend, and down to -0.0030 at the 2nd blend, is secondary_displacement.tran.z
[03:00:30] <cradek> the green "we are blending" is ~ 5 wide the first time and ~ 10 the second time
[03:00:48] <jmkasunich> yep - thats the "blend times don't match" observation I made earlier
[03:00:51] <cradek> that must be the problem, and it seems like it must be accel mismatch
[03:01:07] <jmkasunich> the secondary_displacement one is interesting too
[03:01:20] <cradek> which is that?
[03:01:21] <jmkasunich> it should be going down to -0.0030 for both segments
[03:01:26] <jmkasunich> puke green
[03:01:45] <jmkasunich> oh, I bet it was highlighted when I made the screenshot
[03:01:47] <cradek> debug_float_1?
[03:01:51] <jmkasunich> yes
[03:01:53] <cradek> ok
[03:02:35] <jmkasunich> that Z velocity shortfall is the result of the call to tcRunCycle for the nexttc
[03:02:47] <jmkasunich> approx line 920
[03:03:16] <jmkasunich> I noticed that the value of nexttc->reqvel is being tucked away, replaced with something else, and restored after the call
[03:03:39] <cradek> yes that's to help them match in spite of their quantization (better blend)
[03:03:43] <jmkasunich> the something else is based on tc->vel_at_blend_start - primary_vel, and I was trying to understand that
[03:04:50] <cradek> oh! oh!
[03:05:10] <jmkasunich> ;-0
[03:05:12] <SWPadnos> hmmm
[03:05:14] <cradek> I bet segments 2 and later can get both of the /= 2.0
[03:05:35] <cradek> err no. if(tc->active == 0)
[03:05:46] <jmkasunich> actually, that is something I wanted to ask about
[03:05:55] <jmkasunich> if(tc->active == 0) {
[03:05:56] <jmkasunich> and
[03:05:57] <cradek> can you just print or plot the accels?
[03:06:03] <jmkasunich> if(nexttc && nexttc->active == 0) {
[03:06:22] <jmkasunich> those two ifs (and the blocks of code they activate)
[03:06:49] <jmkasunich> are they supposed to be mutually exclusive, or should both be invoked for each tc?
[03:07:18] <cradek> I don't know
[03:08:13] <jmkasunich> I'm instrumenting something... stand by'
[03:08:45] <cradek> brb
[03:10:08] <jmkasunich> tc->active == 0 (id = 11), count = 120
[03:10:08] <jmkasunich> tc->active == 0 (id = 12), count = 180
[03:10:08] <jmkasunich> nexttc->active == 0 (id = 13), count = 189
[03:10:08] <jmkasunich> nexttc->active == 0 (id = 14), count = 277
[03:10:08] <jmkasunich> n
[03:10:13] <SWPadnos> where in the hell is this code?
[03:10:17] <jmkasunich> tp.c
[03:10:21] <SWPadnos> which dir?
[03:10:28] <jmkasunich> emc/kinematics
[03:10:34] <SWPadnos> ah, kinematics, of course
[03:10:42] <jmkasunich> id=11 is the G1 that preceeds the G33s
[03:10:57] <jmkasunich> id=12 is the first G33, id=13 is the second, etc
[03:11:09] <jmkasunich> count is that incrementing timestamp value
[03:11:43] <jmkasunich> so, we know that the if (tp->active) block is running for the G1 and first G33, and the nexttc->active block is running for the rest of the G33s
[03:16:46] <jmkasunich> I find it odd that id=12 trips the tc->active test at timestamp 180, but id=13 doesn't trip the nexttc->active test until 189
[03:19:27] <cradek> there's no blend between 11,12 because 12 is the first sync move
[03:19:42] <jmkasunich> right
[03:20:26] <jmkasunich> but once 12 becomes "tc", shouldn't 13 immediately become "nexttc" ?
[03:20:44] <SWPadnos> vel_at_blend_start is set to a value "tc->currentvel" in tcRunCycle
[03:20:44] <cradek> yes unless it hasn't come in yet
[03:21:00] <jmkasunich> hasn't come in as in hasn't been queued?
[03:21:17] <cradek> yes maybe?
[03:21:21] <SWPadnos> that may be a low value the first move after sync, since the first sync move has to sync up with the spindle
[03:21:33] <jmkasunich> there is a G4P1 in the program, to let the "spindle" come up to speed - I expect that the whole program is queued
[03:21:53] <cradek> no, G4 is a queue buster
[03:22:05] <jmkasunich> hmm
[03:22:18] <jmkasunich> the program has G4, G0, G1, G33, G33.....
[03:22:36] <cradek> you'd think it would queue everything during the G0
[03:22:43] <jmkasunich> the G0 doesn't normally get executed, because it happens to be where the tool parked at the end of the last run
[03:22:58] <jmkasunich> I believe the G0 is id=10
[03:23:10] <jmkasunich> (if ID = line number in the axis code view window anyway)
[03:23:16] <cradek> I think it is
[03:23:46] <jmkasunich> lemme insert a blank line between the G1 and the first G33 - that way the IDs are unambiguous
[03:24:35] <jmkasunich> yep, numbers match
[03:24:57] <jmkasunich> 10 is the (skipped) G0, 11 is the G1, and now 13 and up are the G33s
[03:25:50] <jmkasunich> grumble
[03:25:56] <jmkasunich> I hate ifs without {}
[03:25:58] <cradek> after those two blocks that might change accel, print the accels of tc and nexttc
[03:26:16] <cradek> they ought to match. I still think they don't
[03:27:50] <jmkasunich> ok
[03:29:14] <cradek> huh the next ones (like above the 15) look surprisingly good
[03:29:20] <jmkasunich> dang, I wish we could print floats in kernel space
[03:29:40] <jmkasunich> wait, this isn't kernel space...
[03:30:30] <cradek> whee
[03:30:49] <cradek> we should send jepler a dollar every time we're glad we're not in kernel space
[03:30:51] <jmkasunich> dang - data spew
[03:34:28] <jmkasunich> arg - I corked the wrong spew
[03:35:55] <jmkasunich> they don't match - one is 8 and the other is 4
[03:36:04] <jmkasunich> for subsequent blends, both are 4
[03:36:21] <cradek> good
[03:36:26] <cradek> we knew this, now we're sure
[03:36:44] <SWPadnos> can you do a G4 while synched?
[03:36:50] <SWPadnos> or exact stop mode, for that matter?
[03:36:52] <cradek> SWPadnos: if you're smart, you won't
[03:37:14] <SWPadnos> of course it's stupid. I'm wondering if it's allowed or even sometimes useful
[03:37:28] <jmkasunich> don't distract us
[03:37:33] <SWPadnos> this is relevant
[03:37:57] <jmkasunich> not really - I'm doing the G4 before I get synced
[03:38:02] <SWPadnos> I was getting to the question of whether you can assume at the start of sync mode that all subsewuent segments will be blended
[03:38:05] <cradek> jmkasunich: so one isn't getting the /2 and it should
[03:38:38] <SWPadnos> my assumption here is that at the start of sync, it's missing the fact that the next segment will be blended
[03:38:40] <jmkasunich> I've gotta stick a few prints in that code - id numbers help immensly to see what is going on
[03:38:50] <cradek> yes the ids are great
[03:39:07] <cradek> there's an assumption somewhere that isn't true for your program
[03:40:05] <cradek> argh I see it
[03:40:24] <cradek> // don't move: wait
[03:40:26] <cradek> return 0;
[03:40:53] <jmkasunich> ah, breaking out of the iff
[03:41:03] <cradek> yep
[03:41:09] <cradek> reorder that and it'll fix it
[03:42:04] <SWPadnos> does that block get executed exactly once while waiting for spindle sync?
[03:42:22] <cradek> yes tc->active protects it
[03:42:38] <SWPadnos> ok
[03:43:16] <jmkasunich> woo hoo
[03:43:18] <cradek> jmkasunich: thanks for doing the hard work on this one
[03:43:21] <jmkasunich> fixed it
[03:43:29] <cradek> yeah I know :-)
[03:43:33] <jmkasunich> thanks for finding the bug
[03:43:35] <SWPadnos> heh
[03:43:37] <cradek> it all made sense when I figured that out
[03:43:54] <cradek> yayyy
[03:44:14] <jmkasunich> I moved the entire "it (tc->synchronized) block down to the end of the if (tc->active) block
[03:44:23] <cradek> that looks good to me
[03:44:33] <SWPadnos> makes sense to me too, fwiw :)
[03:44:37] <jmkasunich> my tree is full of debug crap - do you want to make the change and commit, or do you have crap too?
[03:44:57] <jmkasunich> I can de-crap - need to do that anyway
[03:45:07] <cradek> cvs up -C
[03:45:23] <cradek> C is for Crap
[03:46:15] <SWPadnos> -Clean up Crap
[03:46:28] <SWPadnos> -Clear Crap from Code
[03:52:55] <jmkasunich> should I put anything in debian/changelog?
[03:53:09] <jmkasunich> it seems like the plan is to copy that stuff from the 2.2 branch
[03:53:31] <cradek> it does seem like this is a safe one to backport
[03:53:34] <jmkasunich> (I guess we should be applying this patch to the branch as well, I guess it can go in that changelog and then be copied with all the rest)
[03:55:05] <CIA-22> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/kinematics/tp.c: fix velocity disturbance that affects the 2nd of a series of consecutive synchronized moves
[03:56:28] <cradek> goodnight! thanks again jmkasunich
[03:56:40] <SWPadnos> night cradek. happy birthday
[03:56:44] <cradek> thank you
[03:56:44] <jmkasunich> thank you
[03:56:48] <SWPadnos> (you're catching up :) )
[03:56:57] <cradek> I'm older than I've ever been
[03:57:05] <cradek> (and now I'm even older)
[03:57:06] <SWPadnos> I'll throw in a note of thanks to jmkasunich as well :)
[03:57:13] <SWPadnos> damn, you're gaining at an astounding rate
[03:57:19] <SWPadnos> like 1 second per second
[03:57:31] <SWPadnos> RTAging
[04:00:07] <CIA-22> EMC: 03jmkasunich 07v2_2_branch * 10emc2/debian/changelog: fix velocity disturbance that affects the 2nd of a series of consecutive synchronized moves
[04:00:07] <CIA-22> EMC: 03jmkasunich 07v2_2_branch * 10emc2/src/emc/kinematics/tp.c: fix velocity disturbance that affects the 2nd of a series of consecutive synchronized moves
[04:00:14] <jmkasunich> there - done in time for 2.2.4
[04:00:29] <SWPadnos> heh
[04:00:51] <jmkasunich> bedtime for me - goodnight
[04:00:59] <SWPadnos> night
[04:07:18] <CIA-22> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/vars_names.c: quiet message
[13:52:30] <skunkworks_> Nice work last night figuring out the threading bobbble. !
[13:55:16] <cradek> one thing is still bothering me about that
[13:55:33] <cradek> is bobble really a word?
[13:59:41] <jepler> http://www.answers.com/bobble
[13:59:42] <jepler> apparently so
[13:59:48] <jepler> but bobbble isn't a word
[14:01:04] <skunkworks_> oh
[14:01:07] <skunkworks_> oops :)
[14:06:59] <alex_joni> haha
[14:07:25] <alex_joni> In knitting, a bobble is a localized set of stitches forming a raised bump.
[14:08:37] <alex_joni> well.. TP ain't that far from stitching
[16:37:00] <CIA-22> EMC: 03jepler 07TRUNK * 10emc2/docs/man/man9/pwmgen.9: document the 'offset' parameter
[16:37:32] <CIA-22> EMC: 03jepler 07v2_2_branch * 10emc2/docs/man/man9/pwmgen.9: merge from TRUNK: document the 'offset' parameter
[16:51:39] <SWPadnos> jepler, one thing I was thinking about for stepconf: change the order of the druid pages so the pin selection comes after everything else
[16:52:01] <SWPadnos> that way, you can restrict the pin options to whatever is actually configured (spindle, limits ...)
[16:52:33] <jepler> it's written the other way around -- for instance, if you don't have a home switch available for X, the fields on the X axis configuration are restricted.
[16:52:42] <jepler> if you don't have a PWM spindle output, that page isn't presented
[16:53:07] <SWPadnos> oh, interesting.
[16:53:24] <SWPadnos> that makes sense then
[16:54:03] <SWPadnos> incidentally, stepconf.glade loaded fine once I replaced glade-2 with glade-gnome-2
[16:54:07] <jepler> oh good
[16:54:16] <jepler> too bad about the error handling inside glade-2 for that case
[16:54:35] <SWPadnos> actually, that was glade-gnome-3 that would coredump
[16:54:43] <SWPadnos> so it's even worse about the error handling
[16:56:59] <SWPadnos> stepconf really highlights one of my pet peeves about gnome - that you have to exit then re-enter the active area of a control before it will accept mouse-clicks
[16:57:31] <SWPadnos> so when the "next" button appears on the Y axis page (after I've clicked it on the X-axis page), I have to move the mouse away then back before I can click again
[16:57:46] <jepler> that's not a problem I can correct
[16:57:51] <jepler> file a bug against gtk
[16:58:15] <SWPadnos> yeah, I know it's a gniome/gtk problem - I just find it annoying
[16:58:22] <jepler> * jepler tries repeating himself
[16:58:25] <SWPadnos> I think it's a "feature" though - Ithink I looked it up once
[16:58:31] <SWPadnos> heh
[16:58:51] <jepler> they have probably got a very long bug report in which the gtk developers keep justifying it and the people who actually support applications keep reporting it as a bug
[16:59:18] <SWPadnos> heh - could be
[16:59:26] <cradek> I'm pretty sure I noticed that's now fixed in ubuntu version mumble.mumble
[16:59:35] <alex_joni> 9.14
[16:59:42] <alex_joni> or was it 3.14 ?
[16:59:57] <SWPadnos> 13.13
[17:00:41] <jepler> the behavior persists in 7.10
[17:02:19] <SWPadnos> yes, that's where I was running stepconf
[17:04:32] <alex_joni> hmm.. there was no other release since 7.10
[17:05:04] <SWPadnos> 8.04 is next
[17:05:20] <SWPadnos> there will be an 8.04.1 probably (it's in the release schedule)
[17:13:18] <SWPadnos> I think this is it:
http://bugzilla.gnome.org/show_bug.cgi?id=56070
[17:13:36] <SWPadnos> plus a bazillion duplicates
[17:21:20] <alex_joni> heh, I just noticed that
[17:59:31] <skunkworks_> someone asked for the patent
http://www.cnczone.com/forums/showpost.php?p=424631&postcount=40
[18:00:22] <fenn> if you have Free cam software and a PC based control, does it really matter?
[18:01:17] <skunkworks_> if emc implimented something similar.. Would it be a problem? being free and all?
[18:01:37] <fenn> depends what country you live in :)
[18:01:45] <skunkworks_> * skunkworks_ isn't up on patent law
[18:02:02] <fenn> united states recognizes software patents, but the EU does not
[18:02:15] <skunkworks_> interesting
[18:02:38] <skunkworks_> something microsoft pushed thru? ;)
[18:04:30] <fenn> "Once a patent is granted in a given country, no person may make, use, sell or import/export the claimed invention in that country"
[18:04:42] <SWPadnos> interesting:
http://www.bitlaw.com/software-patent/history.html
[18:04:50] <fenn> so, i guess you could "make" it in europe, and give it away in the US?
[18:07:06] <SWPadnos> that would still constitute importing
[18:07:11] <SWPadnos> the sale price is zero
[18:10:02] <cradek> make?
[18:10:03] <cradek> huh.
[18:11:46] <fenn> i think if you want to patent software then the source should be made open 14 years later (or whatever its up to now)
[18:12:19] <SWPadnos> I think patents are still in the 17-20 year range
[18:12:29] <SWPadnos> it's copyright that's "the indefinite future"
[18:13:10] <fenn> in the United States, a patent covers research, except "purely philosophical" inquiry. A U.S. patent is infringed by any "making" of the invention, even a making that goes toward development of a new invention — which may itself become subject of a patent.
[18:14:00] <SWPadnos> yes, the concept is like a stool. if I patent a 4-legged stool, and you see it but want to make a chair with a back, you have to license my stool patent so you can add the back to it
[18:14:14] <SWPadnos> since your invention incorporates my invention in it
[18:14:44] <fenn> a four legged stool? ridiculous!
[18:14:52] <fenn> everyone knows that stools have three legs
[18:14:54] <SWPadnos> hey, it's mine!
[18:35:58] <cradek> jepler: when I open this lathe program
http://timeguy.com/cradek-files/emc/nmtb30.ngc in sim/axis, I get a traceback I don't understand: SystemError: new style getargs format but argument is not a tuple
[18:36:05] <cradek> result, seq = gcode.parse(f, canon, unitcode, initcode)
[18:36:08] <cradek> ^ at this line
[18:36:34] <cradek> sim/axis on trunk
[18:38:05] <cradek> I also have another file that does it
[18:39:44] <jepler> huh
[18:39:47] <jepler> I dunno what that means either
[18:43:23] <jepler> it might be in #3 0xb620e196 in GET_EXTERNAL_TLO_IS_ALONG_W () at emc/rs274ngc/gcodemodule.cc:467
[18:43:31] <jepler> not sure
[18:46:19] <jepler> yep
[18:46:59] <CIA-22> EMC: 03cradek 07TRUNK * 10emc2/tests/interp/cam-nisley/ (cam.ngc expected test.sh test.tbl test.var):
[18:46:59] <CIA-22> EMC: This is a nice program that Ed Nisley sent to help us
[18:46:59] <CIA-22> EMC: find a problem some time ago. It exercises a lot of the
[18:46:59] <CIA-22> EMC: interpreter's math, o-word, cutter comp, and arc functions.
[18:47:32] <CIA-22> EMC: 03jepler 07TRUNK * 10emc2/src/emc/rs274ngc/gcodemodule.cc: Fix the error 'SystemError: new style getargs format but argument is not a tuple' when loading certain gcode files
[18:47:50] <cradek> that was fast, thanks
[18:48:39] <jepler> I don't think TRUNK gets used much; if I understand what's going on, that would have come up with any file that uses tool length offsets
[18:49:18] <cradek> interesting
[18:51:34] <fenn> i noticed a tlo error before but i thought i had borked something since nobody else mentioned it
[18:52:06] <cradek> it's true I currently run my machines on the 2.2 branch
[18:52:17] <cradek> I'm more interested in finding bugs there than on trunk
[18:52:26] <cradek> I'm not sure if that's good strategy or not
[18:53:28] <jepler> it's fine right up to the point where we want to turn TRUNK into 2.3..
[18:53:49] <cradek> sure
[18:55:49] <fenn> if finding bugs is your goal then you should run TRUNK
[18:59:41] <CIA-22> EMC: 03jepler 07TRUNK * 10emc2/scripts/halrun.in: this message should go on stderr
[19:10:30] <CIA-22> EMC: 03lerman 07TRUNK * 10emc2/src/emc/rs274ngc/ (6 files): Add named owords. Make owords local/global. Add LAZY_CLOSE as option to .ini so as to permit calling subroutines from MDI.
[19:45:45] <jepler> * jepler reconsiders backporting the "show config name in axis title bar" change to 2.2
[19:45:46] <fenn> jepler: (sorry if i asked this before and forgot) why is loadrt probe_parport not always run when the parport driver is loaded?
[19:45:55] <jepler> fenn: because some users have reported that it breaks things.
[19:46:11] <cradek> I think stepconf-generated configs do always run it
[19:46:11] <jepler> fenn: for instance, on cradek's machine that runs max, the eventual unload of probe_parport killed the parport until reboot
[19:46:21] <jepler> what cradek says is true
[19:49:33] <SWPadnos> I don't know if it's better to show the config name or the loaded file name in the title bar, and it may be confusing with both
[19:49:43] <SWPadnos> I'd ceratainly add it to the help/about dialog though
[19:49:54] <jepler> yeah that's an idea too
[19:50:05] <jepler> the original user suggestion was to change the whole GUI color depending on the configuration
[19:50:08] <fenn> edit -> preferences :)
[19:50:11] <SWPadnos> heh
[19:50:34] <SWPadnos> or were you saying that the title would be something like "My-Mill - demo.ngc" ?
[19:50:39] <SWPadnos> ie, remove AXIS altogether
[19:52:27] <fenn> machine name (MACHINE =) is usually not modified by users and can be misleading
[19:52:38] <jepler> that's sure true
[19:52:39] <fenn> whereas a file name would be unambiguous
[19:53:10] <cradek> nope
[19:53:27] <fenn> ~/emc/foo.ini
[19:53:55] <jepler> you can give files stupid names
[19:54:01] <fenn> sure
[19:54:04] <SWPadnos> and really long ones
[19:54:43] <SWPadnos> "configuration for the 3-axis mode of my 5-axis Bridgeport close with rotary table in zero position"
[19:54:48] <SWPadnos> err - clone
[19:55:03] <fenn> yeah so what
[19:55:38] <SWPadnos> well, one of the ideas about having information in the title bar is that it's actually useful
[19:55:49] <SWPadnos> which lots of words probably aren't
[19:55:58] <SWPadnos> and lots of directory info probably isn't
[19:56:29] <SWPadnos> the machine name probably is, especially with stepconf since you can add it yourself
[19:57:19] <fenn> axis only shrinks down to about 800 pixels wide, so if the title bar is less than that it's wasted space
[19:58:06] <SWPadnos> heh - that's one way to look at it
