Back
[01:24:40] <LawrenceG> there sure seem to be a lot of new people starting to use emc.... low level support questions are hot and heavy
[01:28:19] <cradek> yes
[01:29:06] <LawrenceG> once they see the motors spin, they are hooked :}
[01:30:20] <LawrenceG> how is chris doing? ... I like those knobs you made
[01:30:28] <cradek> thanks
[01:30:49] <cradek> he's doing fine but he is somewhat uncomfortable talking about himself in the third person
[01:31:04] <cradek> my latest lathe project was an air cleaner assembly for my new compressor
[01:31:25] <cradek> display model, they lost some parts and knocked it over once (leaving a hole in the floor...), I win on price
[01:31:40] <cradek> it's extremely top-heavy
[01:31:50] <cradek> so I anchored it to the floor
[01:31:56] <LawrenceG> I have been looking for some 3" rounds stock to make some mpg knobs.... big and meaty
[01:32:05] <cradek> neat
[01:32:18] <cradek> how thick? might be easier to start with plate. 3" is big.
[01:33:32] <LawrenceG> knob would probably be 2.75 dia by .75" thick... knob + integral graduated flange... plate would work as well
[01:35:06] <cradek> sounds neat
[01:38:03] <LawrenceG> for your lathe programs, have you been g coding mostly by hand?
[01:38:31] <cradek> completely by hand
[01:39:53] <LawrenceG> seems like a lot of the lathe ops are repetitive ... owords and subroutines for a lot of operations could be quite useful
[01:40:15] <cradek> I often use the drill/bore cycles
[01:40:59] <cradek> like to bore a hole, g91 g85 z-.5 x.02 r0 l10 to make ten passes .020 radius each, .5 deep
[01:41:34] <cradek> I could write a loop (I'd use O-repeat and g91 mode), but this is pretty easy
[01:42:34] <cradek> I try to keep the gcode extremely simple, so I can read it later and maybe reuse parts of it
[01:44:07] <LawrenceG> that sure like a nice lathe you picked up
[01:44:20] <cradek> yep it's a nice machine
[01:44:22] <LawrenceG> looks like
[01:44:25] <cradek> it was quite useless before EMC
[01:58:53] <cradek> still I don't feel like the retrofit is done - maybe I never will
[01:58:58] <jmkasunich> LawrenceG: you ain't kidding about low level questions
[01:59:23] <jmkasunich> you handed the text-to-g-code guy a link, and he seems to have not read anything there'
[02:00:11] <cradek> http://www.catb.org/~esr/faqs/smart-questions.html#lesser
[02:02:01] <jmkasunich> that is a long page
[02:02:20] <cradek> yeah, very
[02:02:29] <jmkasunich> I was considering adding a link to it at the bottom of each message (where the sourceforge spam is)
[02:02:36] <cradek> ha
[02:02:39] <jmkasunich> I don't know if we can do that, I bet we can
[02:02:59] <cradek> I wouldn't be surprised
[02:03:44] <cradek> so if my hard disk hasn't given any of those errors for a while, is it reasonable to pretend it must have healed?
[02:04:00] <jmkasunich> if you have good backups, sure
[02:04:09] <cradek> aha, you're right
[02:04:12] <jmkasunich> maybe it found all the bad sectors and mapped around them
[02:04:20] <jmkasunich> and maybe there is a tooth fairy
[02:04:50] <cradek> I like to put off repair work until it's as incovenient a time as possible
[02:10:35] <LawrenceG> jmkasunich, a little concerning that people without basic skills are playing with power tools!
[02:10:48] <jepler> hi jmkasunich
[02:11:13] <jmkasunich> hi jeff
[02:11:20] <jepler> want to talk about double-precision in hal?
[02:12:18] <jmkasunich> sure
[02:12:57] <jmkasunich> btw, you should put your reply to Dave Merriman on the wiki somewhere
[02:13:17] <jepler> well, all I know is in the top 3 entries on my blog,
http://axis.unpy.net/ -- summary: I think it works; my little nagging doubt is that we can't trust all gcc in the past and future to work the same as my gcc does today.
[02:14:12] <jepler> but in the future there's less reason than in the past to ever do the one thing that breaks it (two movls)
[02:18:24] <jmkasunich> reading...
[02:21:30] <jmkasunich> I have to agree with the last sentence in the 2nd post - this case is a perfect example of "testing cannot reliably prove correctness, only wrongness"
[02:22:16] <jepler> yeah
[02:22:30] <jepler> I wish I could say I was 100% sure of what today's gcc does, but I can't even say that -- it's very complex software.
[02:22:32] <jmkasunich> I think this change would need two parts
[02:22:55] <jmkasunich> part 1) change the syntax for accessing hal pins/params, such that we can hide the actual code that does it
[02:23:06] <jepler> ugh, no
[02:23:09] <jmkasunich> 2) code up something that we trust (which might change over time)
[02:23:30] <jmkasunich> why? just the massive diff that would result?
[02:24:00] <jepler> because set(x, y*a*b) is ten times less readable than x = y*a*b
[02:24:02] <jmkasunich> comp already hides the access
[02:24:19] <jepler> macros can't change "=", though
[02:25:07] <jmkasunich> true about the ugly
[02:25:17] <jmkasunich> and reading would be even worse
[02:25:38] <jmkasunich> because a pin or param is more likely to be read than written
[02:26:11] <jmkasunich> however, keep in mind that good practice is to copy all pins/params to locals at the start of a function, and write all results to pins/params at the end
[02:26:36] <jmkasunich> if you only use a value once, there is no real need, but if you use it twice, there is no guarantee that it will have the same value both time
[02:26:38] <jmkasunich> s
[02:27:05] <jepler> here's the question I have for you: why do you trust that gcc will never generate 4 byte-moves or 2 word-moves for "a = b" when a and b are ints?
[02:27:55] <jmkasunich> because gcc would have to be stupid to do that
[02:28:12] <jepler> because it would be bad for performance and a greater number of instructions
[02:28:19] <jmkasunich> yes
[02:28:20] <jepler> .. the same as for fld/fst vs two-movl on all modern CPUs
[02:28:37] <jmkasunich> then we need to get rid of "non-FP" threads
[02:28:43] <jmkasunich> (which is probably not a bad thing)
[02:29:26] <jepler> I think that's a separate debate, but I'd sure like to see the numbers on that question
[02:29:32] <jmkasunich> yeah
[02:29:38] <jepler> I think you had suggested a good way to measure it, even though it's hard to measure directly?
[02:29:39] <jmkasunich> not sure it is separate tho
[02:30:45] <jepler> what's the connection you see
[02:30:45] <jepler> ?
[02:30:46] <jmkasunich> I have too many mental threads going on - lets defer the "eliminate non-fp" one for now
[02:31:20] <jmkasunich> how does the compiler know that we are doing a non-rt thread, and thus it is not allowed to use the FPU
[02:31:53] <jmkasunich> I think I've heard of optimizations where the FPU is used to move around integers
[02:32:01] <jepler> it doesn't, it's up to the programmer not to refer to any variables of 'double' or 'float', or create any intermediates of that type..
[02:32:20] <jmkasunich> what if I have a long long int?
[02:32:39] <jmkasunich> (I realize that this problem could occur today - it is only loosely related to doubles)
[02:34:40] <jmkasunich> I'm not being negative - keep in mind that my way of doing stuff is to try to find every possible problem before I "build" it
[02:35:08] <jepler> I think you're right that the x87 fpu could be used for that, and mmx would work even better.
[02:35:09] <jmkasunich> I design hardware, the iteration time is long, so I try to poke holes in the design first
[02:35:49] <jepler> if we ever find that the compiler is generating mmx instructions to move integer data around, gcc provides the flag -mno-mmx
[02:35:51] <jmkasunich> if the fpu context save penalty is small (and shrinking over time), non-FP threads might be a "premature optimization"
[02:36:07] <jmkasunich> we won't find that unless we look for it
[02:36:22] <jmkasunich> any errors it causes will be far too intermittent to track down
[02:36:43] <jmkasunich> this stuff has to be known to be rock solid by design
[02:37:36] <jmkasunich> * jmkasunich hates timing dependent bugs
[02:37:55] <jmkasunich> I was helping track one down today at work
[02:38:07] <jmkasunich> two threads writing to the same non-volatile memory
[02:38:19] <jmkasunich> once in a blue moon they collide
[02:38:39] <jmkasunich> the result (for at least one customer) was a 4WD vehicle nearly jumping off of a test stand
[02:39:05] <jepler> oops!
[02:39:06] <jmkasunich> the collision has happened 4 times in a few months of operation
[02:39:35] <jmkasunich> we can't reproduce the collision, but we were able to confirm that it can happen
[02:40:19] <jmkasunich> anyway, down off my soapbox
[02:40:33] <jmkasunich> lets look at the change
[02:41:57] <jepler> OK, first chunk is the critical one: use -Os as the optimization flag; this is one of the two ways to turn off the "two movl" double load/stores. -mtune=i686 or higher could be chosen instead, they have exactly the same effect as far as this is concerned
[02:42:14] <jepler> -Os is probably a small payoff since it makes fewer I-cache misses without pessimising code much
[02:42:49] <jepler> second chunk: I found that it was useful to have (A) a non-volatile type that is "the same as" hal_float, and (A) a non-volatile type that is integral and as wide as hal_float
[02:43:17] <jepler> third file, first chunk: this is error checking that probably should be there independent of this patch
[02:43:39] <jmkasunich> wait
[02:43:45] <jmkasunich> are you actually referring to a patch somewhere?
[02:43:51] <jepler> er, yes
[02:44:15] <jepler> http://axis.unpy.net/files/01225549319/doubles-rev2.patch
[02:44:26] <jmkasunich> oh, 1st post
[02:44:50] <jmkasunich> how does Os compare to O2
[02:44:55] <jepler> there's a slightly different -rev2 patch; I think the only difference is that I use the "double read" trick to get consistent reads of doubles in halscope
[02:45:10] <jmkasunich> when I first was doing RTAPI, there was a "requirement" that RT code be compiled with o2
[02:45:18] <jepler> `-Os'
[02:45:19] <jepler> Optimize for size. `-Os' enables all `-O2' optimizations that do
[02:45:19] <jepler> not typically increase code size. It also performs further
[02:45:19] <jepler> optimizations designed to reduce code size.
[02:45:19] <jepler> `-Os' disables the following optimization flags:
[02:45:21] <jepler> -falign-functions -falign-jumps -falign-loops
[02:45:22] <jmkasunich> don't know the details of why, but it was in writing somewhere
[02:45:24] <SWPadnos> I thought kernel code required it
[02:45:24] <jepler> -falign-labels -freorder-blocks -freorder-blocks-and-partition
[02:45:26] <jepler> -fprefetch-loop-arrays -ftree-vect-loop-version
[02:45:29] <jepler> If you use multiple `-O' options, with or without level numbers,
[02:45:31] <jepler> the last such option is the one that is effective.
[02:45:57] <jepler> It might be inline functions that are required by the kernel; -Os doesn't turn those off
[02:46:08] <SWPadnos> but that requirement may have been due to some assembly-related thing
[02:46:13] <SWPadnos> oh, could have been inlines
[02:46:44] <jmkasunich> key phrase "Os enables all O2 optimisations that do not increase code size"
[02:46:47] <jepler> anyway, rest of the stuff in hal_lib is dealing with the new alignment requirement and the different type of dummysig
[02:46:54] <jmkasunich> which means it _disables_ some O2 opts
[02:48:11] <SWPadnos> which could be things like loop unrolling (which negatively impact code size)
[02:48:19] <jepler> in hal_priv.h I introduce a new union type and use it for dummysig
[02:48:30] <jmkasunich> jepler: slow down
[02:48:32] <jepler> ok ok
[02:48:34] <jmkasunich> I'm still reading hal_lib
[02:49:02] <jmkasunich> the test for a valid type is new, and unrelated (just fixes a problem that already existed), right?
[02:49:17] <jepler> (if you are concerned about -Os, I can use -O2 -mtune=i686 (same optimization level and compatible with all the same CPUs, but best code for i686 (aka pentium2 and above))
[02:49:40] <jepler> right, at one point I had an unrelated error that caused pin types to become corrupted. I added those while I was on my way to finding out the real problem.
[02:50:08] <jmkasunich> re O2, I only know what I read a long time ago - it may be out-of-date, or may have even been superstition then, but if it ain't broke I don't want to take a chance fixing it
[02:50:19] <jmkasunich> seems like a good test anyway
[02:51:08] <jmkasunich> ok, a new struct hal_data_u, can hold any size HAL object
[02:51:19] <jepler> right -- before it relied on them all being sizeof(long) (I think)
[02:51:28] <jmkasunich> so that winds up being 64 bits, even for a HAL bit (I don't care, just an observation)
[02:51:37] <jepler> yes
[02:52:05] <jepler> it occurred to me that if we do care we could move it to the end of the structure and do some terrible memory allocation trick
[02:52:17] <jmkasunich> I didn't remember that I was packing adjacent hal_bits
[02:52:41] <jmkasunich> wait, I see something suspicious
[02:52:53] <jmkasunich> hal_data_u is always 64 bits
[02:53:12] <jmkasunich> but you are still allocating sizeof(specific_type), not 64 bits
[02:53:13] <jepler> (by the way, I think these changes are also good even if this change to doubles isn't adopted:
[02:53:17] <jepler> -data_addr = shmalloc_up(1);
[02:53:19] <jepler> +data_addr = shmalloc_up(sizeof(hal_bit_t));
[02:53:22] <jepler> )
[02:53:38] <jmkasunich> I agree, sizeof is better
[02:53:55] <jmkasunich> so you are doing the same size optimization that I was
[02:54:21] <jmkasunich> but, that means that hal_data_u needs to be used with caution, doesn't it?
[02:54:39] <jmkasunich> since it is as big as the biggest hal type, but we're allocating variable sizes
[02:55:25] <jepler> for instance, you can't just memcpy from a signal to a hal_data_u using sizeof(hal_data_u)
[02:55:33] <jmkasunich> right
[02:55:46] <jmkasunich> is the size optimization worth it?
[02:56:06] <jepler> I think all my uses of hal_data_u are associated with dummysig, which is actually that union..
[02:56:14] <jmkasunich> what about the halscope buffer?
[02:56:39] <jmkasunich> that needs to be twice as big, regardless of whether we are doing the size optimization or not
[02:57:57] <jmkasunich> anyway, I digres
[02:57:58] <jepler> skipping down, you'll see in streamer.h that I doubled the shm size (which is allocated in bytes, not samples) and changed the type of the 'f' field in its data union to real_t
[02:58:18] <jmkasunich> seems like that could be a hal_data_t
[02:58:19] <jepler> in scope_rt.c you'll see that there were different cases for different data sizes; I added a "size 8" case
[02:58:48] <jmkasunich> I have a talent for bouncing around - I'm still in hal_lib, but I keep bringing up other issues
[02:58:52] <jepler> .. and I also changed scope_rt's union type
[02:59:18] <jmkasunich> I'm still at shmalloc_up()
[02:59:34] <jepler> ok, I was just trying to get every point you were raising
[02:59:36] <jmkasunich> everything looks fine for single objects of any hal type
[02:59:42] <jmkasunich> sorry, I bounce around
[03:00:00] <jmkasunich> the next shmalloc issue is when a comp defines a struct of hal objects
[03:00:27] <jmkasunich> struct foo { hal_float bar, hal_s32 baz, hal_bit zork, hal_float blat }
[03:00:46] <jmkasunich> the start of the struct will be on an 8-byte boundary
[03:00:53] <jmkasunich> will zork also be aligned?
[03:01:01] <jmkasunich> oops, I mean blat
[03:01:09] <jepler> aha good catch
[03:01:27] <jmkasunich> the compiler will probably do that, but it doesn't have to
[03:01:30] <jmkasunich> (I think)
[03:01:35] <jepler> I neglected to specify the alignment requirement of the hal_float_t; if I did, then your case would be OK
[03:02:36] <jmkasunich> I suppose the safe way is to specify the alignment requirements of every type
[03:02:47] <jmkasunich> even if we know the compiler would do the right thing anyway
[03:03:30] <jepler> the alignment for 'double' on ix86 is 4 bytes, so actually without that there would be a problem for parameters
[03:04:05] <jmkasunich> somewhere in a coder's guide we should say "don't define a struct that contains bit, float, bit, float, bit, float"
[03:04:05] <jepler> (and the alignment of a struct with only align-4 items will be 4)
[03:04:22] <jmkasunich> in shmem it will be 8
[03:05:11] <jmkasunich> because the shmalloc_up call will have sizeof(struct), which will be >=8 if there are two or more items
[03:05:14] <jmkasunich> that is fine though
[03:05:41] <jmkasunich> aligning the struct that contains all of a comp's HAL data to a larger then strictly needed boundary is OK
[03:05:47] <jepler> let me try again to say what I was trying to say: take struct foo { int32_t a; double b; } -- sizeof(foo) is 12
[03:06:06] <jepler> so if I allocate an array of 2 of them (your scenario), the second 'b' is not 8-aligned
[03:06:34] <jmkasunich> oh - arrays of structs
[03:06:54] <jepler> if b is a type that has an alignment requirement of 8, then the struct will have to have an alignment requirement and a size multiple of 8
[03:07:23] <jmkasunich> so the struct will be 16 bytes { a, 4bytes padding, b}
[03:07:24] <jepler> er maybe my example is struct {double b; int32_t a} ..
[03:08:00] <jepler> something like that, and you get a bad case where a double parameter will straddle a byte boundary it must not
[03:08:37] <jepler> by specifying __attribute__((aligned(8))) on the typedef, gcc will obey the alignment in structs and so forth
[03:08:49] <jepler> (it's possible for similar reasons that dummy_struct wasn't correctly aligned..)
[03:09:11] <jepler> typedef volatile double hal_float_t __attribute__((aligned(8)));
[03:09:21] <jmkasunich> in the case of structs, it specifies the alignment with respect to the start of the struct, _and_ it propogates to specify the alignment of the struct itself, right?
[03:11:00] <jmkasunich> cases: compiler allocated structs - the start needs to be aligned, the struct doesn't need to be a multiple of 8 long
[03:11:28] <jmkasunich> arrays of structs - the start needs to be aligned, and the struct _does_ need to be a multiple of 8 long, so array[1] will be aligned
[03:11:49] <jmkasunich> malloc'ed structs - we need to make sure the memory is 8 aligned
[03:12:30] <jmkasunich> the align directive covers cases 1 and 2 (I hope), and shmalloc takes care of the last case
[03:12:57] <jepler> yes, that is my analysis too
[03:15:31] <jmkasunich> made it down to streamer ;-)
[03:16:01] <jmkasunich> would it make sense to use hal_data_t as the union in streamer?
[03:16:53] <jepler> as for alignment, here's a program to help think about it:
http://pastebin.ca/1244560 (it prints 8 16 for me)
[03:17:41] <jepler> jmkasunich: yes, it might make sense to add ireal_t and real_t to that union as well, and then use it in halscope as well as in streamer
[03:18:23] <jmkasunich> also, streamer needs atomic access - real_t isn't atomic, hal_float is
[03:18:39] <jmkasunich> uh, maybe it doesn't need to be atomic
[03:18:52] <jepler> it's as atomic as float was -- if it's a bug it's not a new one
[03:19:37] <jmkasunich> real_t is 64 bits, right?
[03:19:42] <jepler> so in pid there was a bad cast to the wrong type, and in ddt there was usage of floats as temporaries that I had to fix in order to actually profit from the improved precision
[03:20:05] <jepler> yes, real_t (better name welcome!) is the same thing as hal_float_t but without the volatile qualifier. ireal_t is the integer type that is just as wide, but also without the volatile qualifier.
[03:20:51] <jmkasunich> what is the purpose for real_t, why not just say double?
[03:21:13] <jmkasunich> the purpose of the hal types is mostly to get the volatile in there
[03:21:25] <jmkasunich> (and now the align directive)
[03:22:22] <jepler> if we discover next year that people want to port to arm but there's no atomic double-precision value available, one avenue they would have is to change hal_float_t, real_t, and ireal_t declarations -- all in one place
[03:22:55] <jmkasunich> real_t isn't atomic
[03:23:02] <jepler> otherwise, they'll have to find all the places we changed "double" to "float" and change them back
[03:23:44] <jepler> there probably aren't that many but they do exist -- sampler and scope are two examples. I can't decide whether ddt is an example or not; it would never hurt correctness to have a double there even on only-floats-are-atomic systems
[03:24:22] <jepler> the same with ireal_t -- now that hal_s32_t and float are different widths, it's nice to have a way to refer to the integral type that is guaranteed to be exactly as wide as hal_float_t
[03:24:42] <jepler> strictly speaking those typedefs aren't necessary, but I found that I wanted to refer to those types in multiple locations
[03:25:01] <jmkasunich> I'm just wondering if ireal should have volatile
[03:25:20] <jmkasunich> and if we shouldn't just use hal_float where real is used?
[03:25:55] <jepler> the places where I used real_t and ireal_t did not have volatile qualifiers on the types I was replacing
[03:26:02] <jepler> - float d_float;/* variable for float */
[03:26:02] <jepler> + real_t d_real;/* variable for float */
[03:26:07] <jmkasunich> right
[03:26:26] <jepler> - unsigned long tmp1, tmp2;
[03:26:26] <jepler> +ireal_t tmp1, tmp2;
[03:26:57] <jmkasunich> yeah - it's starting to sink in
[03:27:23] <jmkasunich> I'm having to open files to see the diffs in context, my stack is getting full
[03:29:04] <jepler> I hope we can pop everything off the stack soon, I need to vacuum yet tonight :-P
[03:29:34] <jmkasunich> I can review at my own pace
[03:29:52] <jmkasunich> I'll probably be able to answer some of my own questions, and whatever is left I'll type here
[03:30:05] <jepler> I'll drop by again before heading off to bed
[03:30:09] <jmkasunich> ok
[03:30:17] <jepler> thanks for taking the time
[03:31:26] <jmkasunich> you didn't change the comments around the trigger level compare hack in scope_rt.c
[03:31:40] <jmkasunich> /* get the value as 32 raw bits (unsigned long) */
[03:31:40] <jmkasunich> -tmp1 = value->d_u32;
[03:31:40] <jmkasunich> +tmp1 = value->d_ireal;
[03:31:40] <jmkasunich> /* get the trigger level as 32 raw bits */
[03:31:40] <jmkasunich> -tmp2 = level->d_u32;
[03:31:41] <jmkasunich> +tmp2 = level->d_ireal;
[03:41:50] <jmkasunich> jepler: I suddenly reached the bottom of the patch! not really that big
[03:42:04] <jmkasunich> you wrote that you were surprised... by how small it was?
[03:48:29] <jepler> It felt like I had to touch all sorts of source files
[03:48:55] <jmkasunich> well, you didn't have to touch most of the components and drivers
[03:48:59] <jmkasunich> which kind of surprises me
[03:49:05] <jepler> there will probably be more stuff like ddt where locals are declared as floats
[03:49:11] <jmkasunich> perhaps
[03:49:17] <jepler> but yes, they all compile
[03:49:30] <jmkasunich> I haven't found any other issues with the patch, except that couple of comments I mentioned
[03:49:35] <jepler> I haven't run my actual machine with it yet...
[03:49:40] <jmkasunich> I'm all in favor of putting this into 2.3
[03:49:59] <jepler> any name suggestions for ireal_t and real_t?
[03:50:19] <jmkasunich> nothing comes to mind
[03:50:39] <jepler> ok
[03:50:46] <jmkasunich> seems like they ought to be "something_float"
[03:50:53] <jepler> I'll sleep on it, and then run my silly little machine on it before I check it in
[03:50:53] <jmkasunich> since they correspond to hal_float
[03:51:13] <jmkasunich> I'm curious about the net effect on shared memory usage
[03:51:16] <jepler> thanks again for the patch review and thoughts
[03:51:36] <jmkasunich> HAL memory status
[03:51:36] <jmkasunich> used/total shared memory: 57544/131000
[03:51:36] <jmkasunich> active/recycled components: 10/0
[03:51:36] <jmkasunich> active/recycled pins: 438/0
[03:51:36] <jmkasunich> active/recycled parameters: 278/0
[03:51:37] <jmkasunich> active/recycled signals: 30/0
[03:51:39] <jmkasunich> active/recycled functions: 17/0
[03:51:41] <jmkasunich> active/recycled threads: 2/0
[03:51:53] <jmkasunich> that is what I get when I do halcmd status on the HBM vismach config
[03:52:17] <jepler> I can do that before I leave for the night
[03:52:28] <jepler> how do I get that info?
[03:52:41] <jmkasunich> start emc, run halcmd in another shell
[03:52:44] <jmkasunich> "status mem"
[03:53:17] <jepler> used/total shared memory: 62048/131000
[03:53:17] <jepler> active/recycled components: 10/0
[03:53:17] <jepler> active/recycled pins: 439/0
[03:53:17] <jepler> active/recycled parameters: 279/0
[03:53:17] <jepler> active/recycled signals: 30/0
[03:53:19] <jepler> active/recycled functions: 17/0
[03:53:22] <jepler> active/recycled threads: 2/0
[03:53:36] <jepler> so an 8 % growth in shared memory usage
[03:53:39] <jmkasunich> odd that you got one more pin and param
[03:53:42] <jepler> yeah it is
[03:53:49] <jmkasunich> I think 8% is quite acceptable
[03:54:14] <jepler> maybe I updated since chris added the spindle ready thing, and you haven't?
[03:54:20] <jepler> that would explain one pin, anyway
[03:54:23] <jmkasunich> yeah
[03:54:29] <jmkasunich> I haven't updated in a day or two
[03:54:34] <jepler> anyway, goodnight
[03:54:39] <jmkasunich> spend yesterday getting four new VMs installed in the farm
[03:54:51] <jmkasunich> need to load all the build deps now, and actually get them working
[03:54:52] <jepler> yeah I saw some of that go by -- sounded like no fun
[03:55:36] <jmkasunich> goodnight
[04:42:35] <CIA-37> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/utils/ (halcmd.c halcmd_commands.c): fix 'status' command without arg (caused error message, now does 'status all'), fix 'lock' and 'unlock' commands without arg (segfaulted, now does 'lock/unlock all')
[04:57:19] <jmkasunich> jepler: I found some RTAI docs that say "the –O2 flag must be specified, as many functions are declared as
[04:57:19] <jmkasunich> inline in the header files, and gcc doesn't expand inlines, unless optimization is enabled."
[04:59:08] <jmkasunich> source:
http://www.cs.ru.nl/lab/rtai/DIAPM_RTAI_prog_guide.pdf
[04:59:31] <jmkasunich> I wonder if -Os will avoid inlining, to save space
[05:00:21] <jmkasunich> goodnight
[11:01:19] <Roguish_> Roguish_ is now known as Roguish
[12:44:23] <jepler> jmkasunich: interestingly, my compiler manpage says inlining is only turned on by -O3
[12:44:29] <jepler> `-O3'
[12:44:30] <jepler> Optimize yet more. `-O3' turns on all optimizations specified by
[12:44:30] <jepler> `-O2' and also turns on the `-finline-functions',
[12:44:30] <jepler> `-funswitch-loops' and `-fgcse-after-reload' options.
[12:46:45] <jepler> if a problematic module turns up, I could use -Os -finline-functions or -mtune=i686 instead of the -Os I'm proposing
[15:18:49] <SWPadnos> heh, too funny
[15:19:09] <SWPadnos> I get a Barnes&Noble email today, and strangely enough Bjarne Stroustrup is one of the authors
[15:19:20] <SWPadnos> (being advertised, not of the email)
[15:19:45] <SWPadnos> his book is on sale: "Programming: Principles and Practice Using Candand"
[15:20:01] <SWPadnos> though the photo of the cover clearly shows C++ :)
[16:42:53] <jtr> but wait! there's more! and! and!
[17:37:08] <CIA-37> EMC: 03jepler 07TRUNK * 10emc2/src/hal/components/limit2.comp: from Michael Buesch: fix compilation error on 2.6.26.7
[17:55:14] <alex_joni> SWPadnos: Candand?
[17:57:15] <alex_joni> btw, C++0x looks really freaky :D (at least parts of the additions)
[17:57:43] <jepler> "auto" will be very cool. I think I was very "meh" on the rest.
[17:58:18] <jepler> for(auto it=somecontainer.begin(); ...) ...
[17:58:29] <jepler> beats figuring out the type of somecontainer.begin() by hand and then writing it
[17:58:32] <alex_joni> "polymorphic function object wrappers" <- yuck
[17:58:44] <alex_joni> jepler: yeah, that looks nice
[18:00:50] <jepler> and it will be nice if they can solve the forwarding problem without introducing too much suck.
http://std.dkuug.dk/JTC1/SC22/WG21/docs/papers/2002/n1385.htm
[18:01:13] <jepler> but unfortunately it looks like they'll introduce a whole new concept, the "rvalue reference", to do it
[18:02:02] <jepler> the function object thing looks useful too
[18:02:17] <alex_joni> yeah, I think it could apply to the forwarding problem
[18:02:41] <jepler> in python you can always pass a function, or a class with __call__ defined, or a bound method -- "polymorphic function object wrappers" looks like it'll bring C++ closer to that
[18:05:52] <alex_joni> this is probably a bit over my OOP grasp atm
[18:06:04] <alex_joni> * alex_joni ponders keeping it that way for now
[19:53:13] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: this would also activate a widget if you had previously tabbed to it.
[20:16:20] <cradek> what am I forgetting if halui doesn't seem to respond to anything?
[20:17:05] <SWPadnos> signals?
[20:17:33] <cradek> even its outputs aren't doing anything
[20:18:14] <jepler> I dunno
[20:18:18] <jepler> you could try attaching to it with gdb
[20:20:00] <cradek> oh, um, it's not running
[20:20:07] <cradek> maybe it's crashing right away or something.
[20:20:26] <jepler> if a program crashes it leaves its pins and parameters in hal
[20:20:32] <SWPadnos> no / wrong ini (or NML file) specified?
[20:21:04] <cradek> -rw------- 1 cradek develop 536576 2008-11-04 14:20 core
[20:21:08] <cradek> whee
[20:22:01] <cradek> duh
[20:22:02] <cradek> my fault
[20:22:12] <cradek> * cradek <- can't write C
[20:23:02] <cradek> thanks, everyone who told me to shut up and troubleshoot
[20:23:05] <SWPadnos> bash only?
[20:23:23] <jepler> that's alright, I just spent two minutes staring at "NV OH VA" on my screen and saying "how could they be in that order? I know I sort them before printing"
[20:23:53] <cradek> ha
[20:23:57] <jepler> cradek: adding something interesting to halui?
[20:24:36] <cradek> I think max velocity/feed limit is done, except for the gui part
[20:24:46] <cradek> I added hooks in emcmodule and did halui
[20:24:47] <jepler> oh
[20:26:23] <cradek> strange: when a pin is 1e99, halcmd shows "inf"
[20:27:22] <jepler> interesting
[20:27:36] <jepler> I think it uses either %12.7g or %.7g as the format
[20:28:23] <jepler> but printf(1) doesn't display inf for either of those formats..
[20:28:44] <SWPadnos> is it a double or a float?
[20:28:53] <cradek> yes it is using %.7g
[20:29:09] <jepler> SWPadnos: aha!
[20:29:11] <jepler> ding ding ding
[20:29:17] <jepler> 1e99 is bigger than the biggest representable float
[20:29:24] <SWPadnos> yep
[20:29:39] <SWPadnos> another great reason to switch to doubles ;)
[20:29:55] <cradek> emctop happily shows 1e+99 though
[20:30:06] <SWPadnos> interesting
[20:30:24] <cradek> oh, maybe it's actually a double but halcmd doesn't know this.
[20:30:30] <cradek> snprintf(buf, 14, "%.7g", (double)*((hal_float_t *) valptr));
[20:30:35] <jepler> yeah, motion and task communicate doubles through non-hal shared memory
[20:30:36] <cradek> uhh whatever
[20:32:19] <cradek> AXIS (or maybe everything) is muddy about "feed" "speed" and "rapid"/"traverse"
[20:32:28] <cradek> consequently I don't know what to call this new thing
[20:33:02] <SWPadnos> traverse speed limit
[20:33:07] <cradek> feed can mean any rate of tool motion, or it can mean something that's not a traverse
[20:33:28] <cradek> SWPadnos: that's inaccurate though. it's not for traverses only, and it's also not a speed (in the machining sense)
[20:33:41] <jepler> cradek: all of these limits apply equally to G0 and G1/G2/G3 moves, right
[20:33:42] <jepler> ?
[20:33:49] <jepler> "speed limit" and "speed override"?
[20:33:53] <jepler> drop "feed" altogether
[20:33:57] <SWPadnos> ok, so it's an absolute velocity limit override (as opposed to proportional override)?
[20:34:01] <cradek> SWPadnos: yes
[20:34:12] <SWPadnos> how about velocity limit?
[20:34:13] <cradek> jepler: but 'speed' is loaded - it means something else
[20:34:19] <SWPadnos> is it per axis, TRAJ, or both?
[20:34:24] <jepler> cradek: yeah
[20:34:44] <cradek> SWPadnos: it limits the rate of the tooltip motion
[20:35:23] <SWPadnos> so it's just a variable [TRAJ]max_vel
[20:35:26] <cradek> 'jog velocity' 'velocity scale' 'velocity limit' 'spindle scale'
[20:35:41] <cradek> or override in both places instead of scale
[20:36:02] <cradek> OR make feed override actually do just feeds
[20:36:27] <SWPadnos> maybe the thing to do is add "max_max_vel" as a constant, and allow run-time changes to max_vel :)
[20:36:51] <cradek> SWPadnos: I made maxvel modifiable at runtime (by guis)
[20:37:07] <SWPadnos> ok, that's the second half
[20:37:13] <cradek> I think this is what people want when they think they want "rapid override %"
[20:37:29] <cradek> or it's what I want, or both
[20:37:32] <SWPadnos> I guess you could set the limit to the ini file value, and allow the user to scale that down
[20:37:39] <SWPadnos> err, reduce it, not scale
[20:37:39] <cradek> yes that's the idea
[20:38:27] <cradek> well they can also increase it
[20:38:42] <SWPadnos> there needs to be a hard limit though
[20:38:46] <SWPadnos> I think so anyway
[20:38:50] <cradek> there are axis limits
[20:39:15] <SWPadnos> yeah, OK
[20:39:18] <cradek> we could add limits enforced by the gui, like FO has
[20:39:18] <cradek> guis
[20:39:52] <cradek> but you will want to start at a sane number - it will take a lot of turns of my encoder to get down to "0.5" from "inf"
[20:40:46] <jepler> it may call for an exponential slider, as for jog speed
[20:40:54] <cradek> yes
[20:41:06] <cradek> it has everything in common with jog speed afaic
[20:41:22] <jepler> (that reminds me, I should give 1/2/5 jog speed increments a try, instead of the current "random exponential increments" it is now)
[20:43:08] <cradek> I think that would be nice
[20:44:08] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: add velocity cap, useful for dry-runs etc. so far, only halui can set it.
[20:44:11] <SWPadnos> me too, FWIW
[20:44:13] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/ (halui.cc shcom.hh): add velocity cap, useful for dry-runs etc. so far, only halui can set it.
[20:44:18] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: add velocity cap, useful for dry-runs etc. so far, only halui can set it.
[20:44:23] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/kinematics/tp.c: add velocity cap, useful for dry-runs etc. so far, only halui can set it.
[20:44:43] <SWPadnos> it may still make sense to set a GUI adjustment limit in percent a multiple of the TRAJ limit
[20:45:28] <SWPadnos> even though the GUI would set an absolute number, a unitless factor would be preferable for getting a sane default (like 2x or 3x the TRAJ max)
[20:45:29] <cradek> why do you think that's better than setting ipm/mmpm directly, like for jog rates?
[20:46:04] <SWPadnos> it allows sane defaults like "2x the configured maximum"
[20:46:06] <cradek> FO is rightfully a % because it applies to various numbers accordingly
[20:46:08] <SWPadnos> and the units don't matter
[20:46:24] <cradek> sorry, a sane default for what?
[20:46:25] <SWPadnos> I'm just talking about how the adjustment limit would be set in the ini
[20:46:41] <cradek> oh, I thought you were talking about how a gui should present this
[20:46:42] <SWPadnos> the adjustments would be in absolute terms though
[20:46:44] <SWPadnos> no
[20:47:15] <cradek> can you start again from the beginning please?
[20:47:19] <SWPadnos> heh, sure
[20:47:24] <cradek> I'll not type anymore for a bit.
[20:47:51] <SWPadnos> you mentioned that using a jogwheel to come down from 1e99 would take a while, and that you would want to start at a sane number
[20:48:03] <SWPadnos> for the override limit, I'm assuming
[20:48:38] <SWPadnos> so in the ini file there would be a number that says how far you can adjust the tooltip velocity limit
[20:49:00] <SWPadnos> that number can be an absolute number (like 1000), or it can be a multiplier that gets applied to the TRAJ max
[20:49:38] <SWPadnos> the advantage to a multiplier is that we can put something like "2" in all the sample configs, and it will make sense
[20:50:16] <SWPadnos> the advantage to using a number is that you can see what the number is without having to do any math
[20:50:44] <SWPadnos> (in either case, the UI would set an absolute number)
[20:51:07] <SWPadnos> I guess when I say it like that it doesn't really matter one way or the other how it's set in the ini file
[20:51:11] <SWPadnos> * SWPadnos is done now
[20:51:27] <cradek> for an xyz machine, we could calculate the max possible tooltip velocity by considering the axis max velocities. there is no reason for the 'vel cap' slider/knob to go above this value because it will have no effect
[20:51:42] <cradek> likewise, a reasonable minimum to use is zero
[20:52:19] <cradek> so I guess I don't see in what other ways it needs to be configurable
[20:53:20] <SWPadnos> the machine limit can be calculated only for trivial XYZ machines, so for anything else the user would have to be in control
[20:53:41] <cradek> that could be
[20:54:05] <SWPadnos> also, even on an XYZ machine, I may want to limit the max to some value that's less than the vector sum of the 3 axis max vels
[20:54:25] <cradek> why?
[20:55:20] <SWPadnos> I'm not sure really, but it seems silly to assume that nobody can thing of a good reason just because I can't
[20:55:24] <SWPadnos> think
[20:55:38] <cradek> heh
[20:55:53] <cradek> that's the least convincing argument ever :-)
[20:55:56] <SWPadnos> heh
[20:56:10] <SWPadnos> I can think of some situatiuons where it would be useful though
[20:56:25] <SWPadnos> since it applies to feed and traverse, this may end up replacing FO % for some people
[20:56:45] <SWPadnos> err, no, wait
[20:56:45] <cradek> yeah, it's sort of like FO
[20:57:10] <cradek> I'm really tempted to make FO apply only to feed moves once 'vel cap' is available.
[20:57:30] <SWPadnos> mmm
[20:58:37] <SWPadnos> ok, consider a high speed router tha tcan do 1000IPM on X+Y. Going 1400IPM on a 45 degree angle might either break tools or overload the spindle
[20:59:04] <SWPadnos> so I may want to set the limit to 1200 (faster than either axis, but < vector_sum(axes) )
[21:00:36] <SWPadnos> hmmm. I think it's food time
[21:00:39] <SWPadnos> bbiab