Back
[12:47:05] <jepler> op
[12:47:38] <jepler> er, hi
[13:08:00] <CIA-1> EMC: 03bigjohnt 07master * r0cfb0164b1fa 10/docs/src/drivers/hostmot2.lyx: expand encoder scale description
[13:43:09] <jepler> cradek: so you think the G76 bug is serious enough to warrant a new release real soon
[13:43:58] <cradek> am I right that it breaks cutting external threads (negative I)?
[13:45:00] <jepler> yes, I think that's right -- it breaks the g76 sample, which is an external thread
[13:45:01] <cradek> I was still using 2.3.1 when I did my chuck mount, so I haven't officially been affected by the bug
[13:45:31] <jepler> I incorrectly rejected I <= 0 instead of just I == 0
[13:46:24] <cradek> well it's up to you - that's pretty serious breakage for lathes. but I don't know how many active lathe users we have.
[13:49:35] <SWPadnos> BJT-Work, typo in your latest: 100 PPR, not 100 PPM encoder :)
[13:50:47] <BJT-Work> :) SWPadnos thanks guess you should not type when your in a hurry
[13:50:56] <SWPadnos> nope
[13:52:38] <jepler> that's a pretty accurate encoder
[13:52:58] <SWPadnos> 2500 PPR = 100 PPM in quadrature
[13:54:13] <jepler> hm, isn't "P" for pulses and "C" for cycles? It'd be a 2500CPR encoder = 10000PPR.
[13:54:24] <SWPadnos> well, there's the rub
[13:54:40] <SWPadnos> some encoders are listed with a PPR rating, which is actually cycles
[13:54:47] <SWPadnos> not counts or edges
[13:55:44] <SWPadnos> I don't like the term "pulse" though, because it seems to be used for both cycles and edges sometimes
[13:56:06] <jepler> we need to make up a new term, then. TPR = transitions per revolution.
[13:56:20] <SWPadnos> QCPR: quadrature counts per revolution
[13:56:38] <SWPadnos> SCPR: state changes per revolution
[13:56:41] <jepler> WQCPR: wide quadrature counts per revolution
[13:56:59] <jepler> (whoops, flashback from laptop shopping..)
[13:57:14] <SWPadnos> WQUCPR: wide quadrature unambiguous counts per revolution
[13:57:36] <SWPadnos> yeah - LCD resolution acronyms are pretty inscrutable, aren't they
[13:57:38] <jepler> DDRQCPR: double data rate quadrature counts pre revolution
[13:57:48] <jepler> CPR2-667
[13:57:57] <SWPadnos> heh
[13:58:07] <SWPadnos> woth 5-2-2-2 timing
[13:58:09] <SWPadnos> with
[13:59:01] <BJT-Work_> I think that WQCPR broke my connection :)
[14:00:45] <SWPadnos> hmmm. so I have this AVR assembly code which uses a construct like "fred EQU fred+1" all over the place (keeping track of the current index number in an array, for example). Other than just using a #define fred fred+1 (which I'm not sure will work correctly), can anyone think of a good way to do this in C?
[14:01:22] <jepler> static int fred; ....; fred++ ?
[14:01:24] <cradek> isn't that just incrementing a counter?
[14:01:29] <cradek> yeah what he says
[14:01:47] <SWPadnos> no, I need compile-tiime constants that can be included in the array / code
[14:02:02] <cradek> why?
[14:02:09] <cradek> I mean can you give an example of how it's used?
[14:02:53] <SWPadnos> I have the equivalent of an array of structs, and each struct has the index of one or more other array elements
[14:03:11] <SWPadnos> it's like a linked list, but it's static
[14:03:24] <cradek> ok
[14:03:33] <SWPadnos> (if user does this, use element N next, if they do something else, use element M next)
[14:03:49] <SWPadnos> N and M should be compile-time constants
[14:04:17] <SWPadnos> now I suppose I have the option of making separate lists of these structs and using pointers, which might make more sense anyway
[14:04:18] <BJT-Work_> BJT-Work_ is now known as BJT-Work
[14:04:41] <cradek> I still don't see why they need to be constants
[14:04:58] <SWPadnos> hmmm
[14:05:25] <cradek> no matter what their type, they work as pointers
[14:05:53] <SWPadnos> yes, they're either array indices or addresses
[14:06:36] <SWPadnos> I should think about it more I guess
[14:07:01] <SWPadnos> this is a UI where there are lists of screens (what's shown on the LCD), each of which has one or more "fields" that the user can edit
[14:07:34] <SWPadnos> there's a field select key and an enter key, and the next field and next screen depend on which key is pressed
[14:08:02] <SWPadnos> so it's almost like a doubly-linked list, with the key (enter or field select) choosing which list to traverse
[14:09:28] <SWPadnos> hmmm. how hard would it be to make a repo and emc2-dev packages for 9.04 (or other unsupported releases)?
[14:09:45] <SWPadnos> or more accurately, emc2 build-deps
[14:11:07] <jepler> http://emergent.unpy.net/files/sandbox/swpmenu.c
[14:11:56] <SWPadnos> heh. thanks :)
[14:12:03] <SWPadnos> (that much I knew ;) )
[14:12:17] <SWPadnos> I guess the real issue here is that I'm still thinking in assembly instead of C
[14:12:25] <SWPadnos> trying to transliterate instead of translate
[14:12:58] <cradek> maybe you should use lisp
[14:13:08] <SWPadnos> I don't think tho
[14:13:13] <jepler> only problem with this is that you might have been able to get away with an index (not pointer) for menus before, saving 2 bytes per menu
[14:13:20] <SWPadnos> yes
[14:13:30] <SWPadnos> the menus are pretty compact, but don't really need to be
[14:13:48] <SWPadnos> the original code was written for an 8k part, then 32k, and now we have 128k, about 35k used
[14:15:11] <jepler> http://emergent.unpy.net/files/sandbox/swpmenu2.c
[14:15:25] <SWPadnos> the really fun part will be deciphering all that work I had to do to get everything to fit into the same number of bytes
[14:15:41] <SWPadnos> it would be a very interesting set of unions
[14:16:14] <SWPadnos> oh. that's interesting. thanks
[14:16:38] <SWPadnos> I think I'll make an "edit set" struct
[14:16:38] <jepler> I think that's a gcc extension that's also in c99, not sure though
[14:16:50] <SWPadnos> winavr / avr-gcc should have it I think
[14:17:43] <jepler> yes
[14:18:36] <SWPadnos> dbScreenMode, Flags, EnterMode, FieldSelectMode, CursorPos, Var2Offset
[14:18:38] <SWPadnos> dwVar1Addr, MaxAdder, MaxValue, MinValue, IncProc, DecProc, StoreProc, BeginProc
[14:18:59] <SWPadnos> that's what the data looks like now, times about 150
[14:19:41] <SWPadnos> (function pointers for increment / decrement / begin editing / end editing, limits on the value, addresses, edit order ...
[14:19:44] <SWPadnos> )
[14:27:56] <skunkworks> That is why I use lines. (like I have a 2500 line encoder that is 10000 edges) ;) I like lines and edges I guess. I can visualize it. (lines on the disk will have 4 edges with 2 sensors)
[14:28:12] <skunkworks> (I am weird
[14:28:13] <skunkworks> )
[14:29:45] <SWPadnos> BJT had originally used lines, but I thought it looked weird :)
[14:30:23] <skunkworks> heh - also not something I have ever run across. ;)
[14:35:47] <jepler> does it make sense to have an option "keep spindle on during toolchange" for lathes?
[14:36:35] <cradek> there already is
[14:36:55] <skunkworks> jepler: did you get a chance to hook up the rest of your axis?
[14:36:56] <cradek> also, yes it does :-)
[14:37:19] <jepler> cradek: oh really? sim/lathe doesn't use it, then?
[14:37:24] <jepler> skunkworks: all three are hooked up
[14:37:25] <jepler> not tuned
[14:37:28] <cradek> guess not
[14:37:30] <skunkworks> Cool!
[14:37:53] <jepler> it's the home switches that need to be rewired next, so I can do tuning with less fear of hitting limits
[14:38:02] <cradek> http://www.linuxcnc.org/docs/devel/html/config_ini_config.html#sub:%5BEMCIO%5D-Section
[14:38:03] <skunkworks> heh
[15:16:16] <alex_joni> Ubuntu 6.06 LTS Desktop will reach end of life on Tuesday, July 14, 2009. At that time, Ubuntu Security Notices will no longer include information or updated packages for the Ubuntu 6.06 LTS Desktop. Server Edition will continue to receive maintenance updates through June 2011.
[15:20:00] <skunkworks> hey - that is tomorrow
[15:20:22] <alex_joni> yup, it is
[15:21:11] <skunkworks> Hi alex - how is the baby?
[15:23:10] <jepler> oh, I thought that day had come and gone
[15:23:40] <jepler> (end of 6.06 support from ubuntu)
[15:26:23] <jepler> cradek: I think these files both show "spindle at speed" bugs:
http://emergent.unpy.net/files/sandbox/tcss.ngc http://emergent.unpy.net/files/sandbox/tcss2.ngc
[15:26:52] <jepler> I'm running master, sim/lathe, with a change to BASE_PERIOD and to add the don't-stop-spindle-at-tool-change
[15:47:29] <cradek> bleh
[15:59:15] <cradek> hm, I can't even remember how it works. I hope it's documented in C somewhere.
[16:05:06] <jepler> in the lowest levels it's based off tc->atspeed (or some conditions related to spindle sync motion that aren't relevant here), that's all I've determined so far
[16:08:00] <cradek> ah, motion/command.c, search for atspeed
[16:08:32] <jepler> hm, in the degenerate move, is tc->target == tc->progress immediately?
[16:08:42] <jepler> (tcss2)
[16:09:03] <cradek> it may not even get issued
[16:09:10] <cradek> thrown out in the interpreter
[16:09:24] <cradek> ... or some other layer
[16:09:31] <jepler> lots of layers :(
[16:09:37] <cradek> exactly
[16:11:18] <cradek> if(emcmotStatus->atspeed_next_feed && emcmotCommand->motion_type != EMC_MOTION_TYPE_TRAVERSE) {
[16:11:36] <cradek> this is the tcss.ngc bug
[16:12:04] <cradek> iirc, tool change motions have a different motion_type
[16:13:40] <jepler> linearMoveMsg.type = EMC_MOTION_TYPE_TOOLCHANGE;
[16:14:08] <cradek> and I bet you are on the right track for tcss2
[16:14:48] <jepler> for tcss.ngc it looks like there should be a function to return TRUE for ARC, FEED, and PROBE. then it should be called twice in command.c instead of the existing != comparison
[16:14:52] <jepler> you want me to work on that?
[16:15:31] <cradek> if(emcmotCommand->motion_type == EMC_MOTION_TYPE_TRAVERSE && emcmotStatus->spindle.css_factor) {
[16:15:44] <cradek> ^ I'm still struggling to reunderstand this one
[16:15:58] <jepler> you wait for spindle-at-speed before each move in css mode
[16:16:10] <jepler> it's just like the first one except you don't look at at atspeed_next_feed
[16:16:45] <cradek> oh right, at every traverse you might be followed by a feed
[16:17:34] <cradek> sure, if you feel like fixing it, please do
[16:17:58] <cradek> I started, but mine is incomplete and yours sounds better anyway
[16:22:35] <jepler> er, I read the code again and what I said about that second if was totally wrong
[16:24:41] <cradek> well at every rapid in css, you say: if it's followed by a feed, wait for atspeed
[16:25:04] <jepler> also if it's after an EMC_MOTION_TYPE_TOOLCHANGE
[16:25:05] <cradek> but that's the wrong test too - you should still say the same thing for a tool change move
[16:25:12] <cradek> right
[16:25:15] <jepler> so it's still in terms of this new function I proposed
[16:25:22] <cradek> yes I think so
[16:25:56] <jepler> http://emergent.unpy.net/files/sandbox/0001-fix-tcss.ngc-bug.patch
[16:27:45] <cradek> your switch is correct but IMO too clever by half
[16:28:52] <cradek> yep I think your patch is right
[16:31:32] <jepler> I like the idea that we'll get an error when somebody adds EMC_MOTION_TYPE_CURLYCUE
[17:04:08] <jepler> hmm not sure if this is another bug. During the "pull out fresh stock" step, I have M5 / M103 / G1. It doesn't seem to wait for spindle stopped before the G1.
[17:05:20] <jepler> If I write "M5 S1" it does wait
[17:44:00] <SWPadnos> doesn't the spindle speed change trigger the wait for at-speed?
[17:44:24] <SWPadnos> (if there's no commanded change, there's no reason to think that at-speed will go false)
[18:53:52] <micges> alex_joni: yesterday I've made joints_axes3 working better
[18:54:39] <micges> It loads ini file like described on wiki
[18:55:26] <micges> different joints/axes vel/acc alimits are acceptable
[18:55:30] <micges> works co0ol
[18:58:33] <skunkworks> micges: that is awesome!
[18:59:30] <skunkworks> is it separate from the kins problem where commanded axis acc/vel could exceed joint vel/acc?
[18:59:37] <micges> jepler: have you ran cppcheck 1.34? It detects lot more things
[19:00:58] <micges> skunkworks: I don't think so, I've redone only defining limits not checking them
[19:01:58] <micges> skunkworks: can you give a exmple ?
[19:06:16] <micges> skunkworks: I remember now what you talking about - no, my work is totally separate from problem you mentioned
[19:07:01] <skunkworks> Ok - still - nice work!
[19:08:00] <micges> thanks
[19:09:47] <cradek> micges: I'm glad you're working on this, thank you
[19:13:32] <micges> np
[19:20:24] <jepler> micges: I ran the version from git
[19:21:21] <jepler> SWPadnos: M5 is "spindle stop". It's not exactly the same as a speed change, but in fact I know I do want the spindle to be stopped when I do the next move
[19:22:35] <jepler> in fact I want it to be stopped before issing M103, collet open..
[19:22:51] <micges> jepler: new cppcheck version was released yesterday
[19:25:49] <jepler> micges: I checked and there are no substantial differences between 1.34 and the git version I ran on emc
[19:27:10] <micges> ok
[19:29:18] <jepler> (ugh, the cppcheck developer likes to run an automated code-indenting program all the ****ing time)
[19:29:41] <jepler> (or at least twice in the last 10 commits)
[19:30:03] <cradek_> cradek_ is now known as cradek
[19:30:39] <micges> thats a lot
[19:37:29] <jepler> as long as the automated indenter is idempotent, it would be OK to run it before every checkin
[19:38:16] <jepler> that'd be way better than running it periodically
[19:59:57] <cradek> sure, all we need is this mythical program
[20:00:36] <jepler> if there were an indenter that really worked, I'd use it
[20:00:55] <jepler> I'd have it reformat the code to look like it should on checkout, then into ugly dreck on commit
[20:01:11] <jepler> if everybody does the same, everyone wins (except for how you can never trust line numbers in bug reports, I suppose)
[20:01:38] <jepler> you'd just have to change error reports to say "at token 112358"
[20:02:24] <cradek> for some definition of win
[20:03:25] <SWPadnos> the IOCIC (international obfuscated check-in contest)
[20:04:15] <cradek> may as well remove whitespace to save room in your VC
[20:05:17] <jepler> (incidentally, git mostly supports this with "smudge filters")
[20:05:34] <jepler> nah, you'd want a fairly standard, readable indentation style for checkins, so that gitweb is still fairly useful
[20:08:48] <jepler> with git filter-branch we could even rewrite the project's history so that all the checkins since the dawn of time were properly indented
[20:09:20] <cradek> are you trying on purpose to hurt me?
[20:10:16] <jepler> I'm trying to see this issue from the opposite side, and taking all of you along for the ride
[21:14:40] <CIA-1> EMC: 03bigjohnt 07master * rede995197ca8 10/docs/src/drivers/hostmot2.lyx: Fix typo, M is not even near R on the keyboard
[21:15:18] <SWPadnos> heh
[22:33:07] <BigJohnT> :/ I just changed one letter and I get a buildbot failure?
[22:37:28] <BigJohnT> * BigJohnT wanders off to complete another 60" tall door for a miget...
[22:38:22] <jepler> BigJohnT: it's not your fault
[22:38:40] <jepler> it's building on a machine I also use, and if I'm running emc at the time, the tests fail
[22:39:06] <BigJohnT> ah, ok
[22:39:09] <jepler> since that keeps causing trouble, I just shut down that buildbot
[22:49:07] <BigJohnT> If I'm lucky in a couple of weeks I'll have a wireless 256k connection :) that's over 5 times faster than my string
[22:53:07] <BigJohnT> * BigJohnT wanders back to the miget door
[23:15:07] <jepler> BigJohnT: cool, I hope it works out