Back
[00:28:22] <pier> good night all
[01:11:04] <CIA-8> 03cradek 07HEAD * 10emc2/src/emc/motion/control.c: basic overrun detection
[01:23:21] <cradek> * cradek hides from jmkasunich
[01:40:46] <LawrenceG> cradek: question re emc2... Has anyone suggested adding functionality that would support include files in gcode files?
[01:41:19] <cradek> yes I think that's come up quite a few times
[01:41:40] <LawrenceG> maybe (INCLUDE,"/home/emc/ncfiles/xxx.ngc")
[01:41:44] <cradek> especially with subroutines I think it seems useful.
[01:42:10] <cradek> yes another magic comment might be a good way to do it
[01:42:18] <LawrenceG> yes... I have been writing a bunch of oword subroutines and I would like to include them in different programs
[01:43:11] <cradek> I've done some of that too - I put them in useful-subroutines.ngc to share
[01:43:22] <LawrenceG> so far I only managed to write 2 infinite loops!
[01:43:36] <cradek> it's pretty easy to screw up
[01:44:28] <LawrenceG> yes... the debugging is a little tough.... some kind of printf or a modified msg cmd would help
[01:44:44] <cradek> yes that has also come up
[01:45:29] <cradek> you can use M101 Px Qx to show two values but I think that's the only way currently
[01:45:37] <LawrenceG> I didnt think I would be the first.... but the oword stuff is very useful..... most of the cp1 stuff can be redone as gcode now
[01:46:19] <cradek> I think we all agree includes and prints would be nice - all we need is someone to do it now
[01:46:52] <LawrenceG> hint hint... say no more...
[01:47:03] <cradek> heh
[01:47:51] <LawrenceG> I see Jeff has been doing a bunch of work on image to gcode.... I havent tried it out yet, but it looks very promising
[01:48:00] <cradek> yes it sure does
[01:48:58] <LawrenceG> I have been working on some hardware servo drivers.... the proto is alive and has spent a week or trying to let the smoke out...
[01:49:20] <cradek> cool
[01:49:23] <LawrenceG> http://members.shaw.ca/swstuff/dspic-servo.html
[01:50:34] <cradek> you're smart to use quadrature instead of step/dir
[01:50:42] <cradek> but why not use the pid in emc?
[01:50:49] <LawrenceG> I am working on building a dedicated pcb mill and I want to use small servos
[01:51:56] <LawrenceG> this was easier... less communication and hardware issues putting the servo loop in a pic.... used a simplified version of the servo loop code from emc2
[01:52:03] <cradek> my little lathe is like that, servo with a very simple driver and loop closed in emc
[01:52:49] <cradek> do you plan to allow it to report ferror to emc somehow? just enough to estop?
[01:53:18] <cradek> (I like that it stops when I crash into something...)
[01:53:41] <LawrenceG> yea... that is my next project... getting the shoptask lathe running.... I should just have to get an encoder on the chuck
[01:54:07] <LawrenceG> yes... there is an error output that can be tied to emc
[01:54:15] <cradek> perfect
[01:54:37] <cradek> so you will have the biggest benefit of closing the loop in emc
[01:55:35] <cradek> how fast can you count the quadrature?
[01:56:07] <LawrenceG> at least 250khz.... its done in hardware
[01:56:20] <cradek> nice
[01:56:24] <LawrenceG> the pic has a 16 bit encoder interface
[01:57:07] <LawrenceG> cmds from pc are done using interrupt on change....
[01:57:43] <LawrenceG> pid loop takes about 200us to execute,... I am currently running a 1ms servo loop, but that could be stepped up quite a bit
[01:59:09] <LawrenceG> I had the servo doing a yoyo type affair running back and forth for several days to see if it lost any counts on either the encoder of the pc interface and as far as I could tell it was flawless
[01:59:15] <cradek> how do you mean interrupt on change?
[02:00:50] <LawrenceG> the 2 bits of quadrature drive from the pc (step type 2) feed into pins on the pic that cause an interrupt anytime they change... this isr then runs a state machine that either incr, decr or flags an error on the internal commanded position
[02:01:09] <cradek> ah gotcha
[02:04:32] <LawrenceG> I am impressed with those dspic chips.... I am not even using the dsp part of the chip... writing in C and using floating point is no problem (as in the PID loop)
[02:38:44] <jmkasunich> * jmkasunich looks at cradek's overrun code
[02:39:05] <cradek> it sucks but it might be good enough
[02:39:27] <cradek> davidf's problems encouraged me to do it
[02:39:37] <jmkasunich> you could probably set CYCLE_HISTORY to 1 and have it work reasonably well
[02:39:54] <cradek> true
[02:40:09] <cradek> I like seeing a bit of the history though, it lets you see what's normal and what's anomolous better
[02:40:27] <cradek> [1723626.972425] In recent history there were
[02:40:27] <cradek> [1723626.972428] 1977456, 1982217, 1977790, 1980970, and 1979305
[02:40:27] <cradek> [1723626.972430] elapsed clocks between calls to the motion controller.
[02:40:27] <cradek> [1723626.972432] This time, there were 3752640 which is so anomolously
[02:40:29] <jmkasunich> yeah, that is nice
[02:40:47] <cradek> this is one of my runs where I started glxgears on my nvidia machine
[02:40:48] <jmkasunich> hmm
[02:41:07] <jmkasunich> you should export this_run as a hal pin
[02:41:10] <jmkasunich> then you can scope it
[02:41:30] <cradek> that's a clever idea
[02:41:31] <jmkasunich> hal param actually, no need to connect anything to it
[02:41:45] <cradek> make sure it gets updated even after the messages are suppressed
[02:42:10] <jmkasunich> I'll do that now
[02:42:42] <jmkasunich> heh, and another one that counts overruns
[02:43:37] <cradek> ideally each thread could do this, especially the base thread (if there is one)
[02:44:00] <cradek> but I figured something is better than nothing, and this code runs on all configs
[02:44:08] <jmkasunich> yeah
[02:44:15] <jepler> "which is so anomolously"?
[02:44:36] <jmkasunich> my problem (perfection enemy good enough) is that I wanted to do it on a per thread bases
[02:44:38] <jmkasunich> basis\
[02:44:41] <cradek> * cradek kicks jepler
[02:44:46] <cradek> err, hi jepler
[02:44:57] <jmkasunich> but the hal params need to be owned by some component, and generic threads don't qualify
[02:45:56] <cradek> jmkasunich: I knew you wanted to figure out the best way to do it, so I did something stupid instead for now
[02:46:32] <jmkasunich> lol
[02:46:39] <jmkasunich> not stupid anyway
[02:46:41] <cradek> jepler: oh there's more message
[02:47:11] <cradek> I don't have a feel for whether if(this_run > 1.2 * cycles[i]) is sane or not
[02:47:29] <jmkasunich> for the servo thread that's probably not bad
[02:47:43] <jmkasunich> for the base thread might want to go more like 1.5 or so
[02:47:56] <cradek> yeah
[02:48:03] <jmkasunich> if we get too many false alarms we can change it
[02:48:08] <cradek> sure
[02:48:19] <cradek> (if we can tell what's a false alarm and what isn't)
[02:49:05] <jmkasunich> if the 5 "normal" values range from 100000 to 119000, and the bad one is 121000, its a false alarm ;-)
[02:49:42] <jepler> I was just having trouble understanding what the message meant
[02:49:44] <jepler> I think I get it now
[02:49:51] <cradek> ...
[02:49:52] <cradek> [1723626.972435] large that it probably signifies a problem with your
[02:49:52] <cradek> [1723626.972440] realtime configuration. For the rest of this run of
[02:49:52] <cradek> [1723626.972442] EMC, this message will be suppressed.
[02:50:00] <jmkasunich> it is a bit wordy
[02:50:21] <cradek> it sure is
[02:50:33] <jepler> cradek: maybe you can get w--- d-- to write a longer message
[02:50:44] <jmkasunich> w--- d-- ?
[02:50:50] <jmkasunich> somebody from work?
[02:50:52] <jepler> yeah
[02:50:53] <cradek> but explanation when faced with a complex problem is good
[02:51:26] <cradek> the error emc presents is simpler
[02:51:34] <cradek> 'Unexpected realtime delay; check dmesg for details.'
[02:51:43] <cradek> better wording welcome
[02:54:58] <jmkasunich> hmm
[02:55:20] <jmkasunich> someone changed _some_ of the pin exports in motion.c to use jepler's newer syntax
[02:55:43] <jmkasunich> oh, pins were changed, params not
[02:55:43] <jepler> I hope 'someone' wasn't me
[02:55:49] <jepler> but it probably was
[02:56:20] <jmkasunich> did you implement the new hal_pin_foo_newf() stuff for params too, or just pins?
[02:56:57] <jmkasunich> * jmkasunich could just go look, but I'm lazy
[02:58:52] <jepler> jmkasunich: I don't remember
[02:58:59] <A-L-P-H-A> are there "Sam's club" down in the states?
[02:58:59] <jmkasunich> ok
[02:59:06] <jmkasunich> A-L-P-H-A: yeah
[02:59:08] <A-L-P-H-A> Is there Costco as well?
[02:59:15] <jepler> jmkasunich: yes, for pins and params
[02:59:26] <A-L-P-H-A> I just tried out their photo club thing... [sam's]... pretty painless...
[02:59:45] <A-L-P-H-A> for prints... lets see how my prints come out... at $0.18CDN/each it isn't expensive. :)
[02:59:49] <jepler> 'night guys
[02:59:56] <jmkasunich> goodnight
[02:59:58] <A-L-P-H-A> lates jeplerp.
[03:00:05] <jmkasunich> lerp?
[03:00:24] <A-L-P-H-A> lerp? lurch? lunge? leap? jump? jumped? raped?
[03:00:41] <A-L-P-H-A> jepler. :)
[03:01:11] <cradek> jeplerp => nil
[03:01:28] <A-L-P-H-A> jepler > nil > cradek > null ?
[03:01:48] <cradek> it was a lisp joke
[03:01:49] <A-L-P-H-A> nil = 0. null = nothing. so I guess cradek is btween 0 and infinity.
[03:01:53] <cradek> maybe not very funny
[03:02:04] <A-L-P-H-A> neg infinity.
[03:02:44] <A-L-P-H-A> damn. abs. kills.
[03:02:57] <A-L-P-H-A> worked them out. stupid friend made me laugh... and now I'm hurting
[03:04:23] <A-L-P-H-A> brb. windows wants a REBOOT again.
[03:05:54] <jmkasunich> cradek: you lie!
[03:06:11] <cradek> eh??
[03:06:14] <jmkasunich> report_delay = 0 doesn't just turn off reporting, it turns off checking
[03:06:16] <jmkasunich> ;-)
[03:07:01] <cradek> well until you got all fancypants about it, that was the right thing for it to do
[03:07:07] <jmkasunich> lol
[03:08:26] <jmkasunich> s/report_delay/check_delay/
[03:09:31] <cradek> a much better check would be to calculate the mean and standard deviation of the saved samples, and check to see if the current one is more than a couple deviations from the mean
[03:09:56] <jmkasunich> * jmkasunich shoots cradek for mentioning standard deviation
[03:10:06] <jmkasunich> (you are right of course, but I ain't going there)
[03:10:47] <cradek> I probably won't either, but I think that's exactly the right test to use
[03:11:16] <jmkasunich> I wonder how complex it is to calc the std deviation of a continuing stream of numbers?
[03:12:24] <jmkasunich> oh, its just RMS of variation from the mean
[03:12:59] <jmkasunich> mean on a window can be done in constant time
[03:13:13] <jmkasunich> but std deviation of a window takes time proportional to the window length
[03:15:23] <jmkasunich> screw it, I'm just gonna use the last 5
[03:15:28] <jmkasunich> because those are the ones we print
[03:15:53] <cradek> so you need sqrt to do stddev
[03:16:25] <jmkasunich> technically (for this you could just square the most recent value, then compare square of recent to square of std dev
[03:17:01] <jmkasunich> but I'm more concerned about the summation taking time
[03:17:22] <jmkasunich> if I was gonna do mean and std dev, I'd be upping the sample size to a hundred or so
[03:17:34] <A-L-P-H-A> don't y'all love windows...
[03:17:40] <A-L-P-H-A> where a reboot solves most problems.
[03:17:43] <A-L-P-H-A> :(
[03:17:44] <cradek> A-L-P-H-A: don't use it...
[03:18:13] <A-L-P-H-A> cradek... well... if I can get ubuntu to run ALL three of my monitors... I'd be in there with white on rice.
[03:18:18] <A-L-P-H-A> with=like
[03:19:04] <cradek> choose your poison, huh
[03:19:09] <jmkasunich> cradek: I just managed to convince myself that std dev is _not_ the proper criteria ;-)
[03:19:15] <cradek> haha
[03:19:19] <cradek> ok what is?
[03:19:43] <jmkasunich> suppose mean is 100000 and std dev is 80000 - that doesn't mean that the threshold should be 260000
[03:19:47] <jmkasunich> it means you have a crappy system
[03:20:09] <cradek> well that's true I guess
[03:20:16] <A-L-P-H-A> anyone got an idea for an engraving? I'm looking to make something on a 4"x4"x1/4" plexiglass... it's a demo piece, for a plastics company that wants to do engraved plexi signs.
[03:20:17] <jmkasunich> small std dev is good, large is bad
[03:20:35] <cradek> it depends what question you're asking
[03:20:43] <A-L-P-H-A> probably looking for image that's 3x3", so I have a 1/2" border.
[03:20:45] <jmkasunich> 2 times mean is definitely an overrun
[03:21:05] <cradek> if you want to know "is this value quantifiably extreme compared to historical values" that's stddev
[03:21:19] <A-L-P-H-A> going to light it up from a edge, so that stuff that's engraved lights up.
[03:21:49] <jmkasunich> but if the system has a lot of variation, that is bad... it shouldn't raise the level that is considered "very bad"
[03:21:49] <cradek> A-L-P-H-A: use a V shaped tool
[03:22:02] <A-L-P-H-A> cradek, drill bit?
[03:22:04] <cradek> true
[03:22:13] <jmkasunich> use jepler's dot-cat
[03:22:20] <jmkasunich> (with permission of course)
[03:22:28] <cradek> yeah the dot-cat is cool
[03:22:29] <A-L-P-H-A> got a photo fo the dot-cat?
[03:22:42] <A-L-P-H-A> I'll ask him, of course.
[03:22:51] <jmkasunich> its on his website
[03:23:02] <jmkasunich> unpythonic.net I think?
[03:23:16] <cradek> http://emergent.unpy.net/files/default/marielogo.jpg
[03:23:33] <jmkasunich> cradek: C++ has corrupted you
[03:23:39] <A-L-P-H-A> now that IS cool.
[03:23:44] <jmkasunich> mixing declarattions and code.... for shame
[03:23:52] <cradek> A-L-P-H-A: that's sidelit with red LEDs
[03:23:53] <jmkasunich> Kernigan and Ritchie would be so sad
[03:24:03] <cradek> jmkasunich: it's C99, not C++
[03:24:10] <jmkasunich> whatever
[03:24:11] <A-L-P-H-A> yeah, I was thinking of doing that... sidelit. red LEDs are cheap... but that is freak'n COOL.
[03:24:18] <cradek> 99 was 7 years ago!
[03:24:41] <cradek> (I won't be offended if you change it)
[03:24:42] <A-L-P-H-A> cradek, that's sooo last millineum
[03:24:47] <jmkasunich> I learned C 27 years ago!
[03:24:56] <A-L-P-H-A> jmkasunich, when exactly?
[03:24:58] <jmkasunich> (well, 25 actually)
[03:25:00] <A-L-P-H-A> jmkasunich, month wise.
[03:25:03] <cradek> I was in kindergarten 27 years ago
[03:25:23] <A-L-P-H-A> I would have been 2.5months old, 27 years ago. hahaha
[03:25:36] <jmkasunich> I
[03:25:43] <jmkasunich> I'm surrounded by youts
[03:25:49] <cradek> A-L-P-H-A: the algorithm to decide where to put the dots is what makes the dot-cat interesting
[03:26:02] <cradek> '''''
[03:26:02] <A-L-P-H-A> cradek, yea, it is... that's really freak'n cool.
[03:26:08] <cradek> * cradek gives the old guy some more '
[03:26:25] <jmkasunich> ?
[03:26:38] <A-L-P-H-A> jmkasunich, don't feel bad... you probably have more money than us... [you definitely have more money than me]
[03:27:07] <cradek> I wonder where the software for dot-cat is
[03:27:08] <jmkasunich> less hair I bet
[03:27:26] <cradek> jmkasunich: I'm sure I'm catching right up with you
[03:27:45] <jmkasunich> we both have the same problem - the hair is reacting to gravity
[03:27:53] <jmkasunich> moving from top of head to bottom of head
[03:28:00] <A-L-P-H-A> I'm asian... I don't have hairloss in my family... so I probably do have more hair on my head... but I'm pretty hairless on my arms... and I only grow whiskers, I couldn't grow a beard if my life depended on it...
[03:28:21] <cradek> you could have half my beard and I'd still have plenty
[03:28:33] <jmkasunich> http://home.att.net/~jmkasunich/Pics/cncworkshopemc.JPG
[03:28:47] <cradek> A-L-P-H-A:
http://emergent.unpy.net/stippler
[03:28:47] <jmkasunich> the emc bunch at fest
[03:28:56] <A-L-P-H-A> hey! the hippy is SWPadnos right?
[03:29:00] <jmkasunich> definitly an abundance of facial hair
[03:29:02] <jmkasunich> yes
[03:29:05] <cradek> which hippy?
[03:29:10] <A-L-P-H-A> damn... I'd be like 1/2 the age of most there.
[03:29:14] <jmkasunich> the beardess one
[03:29:31] <A-L-P-H-A> heh... SWPadnos looks stoned in that photo.
[03:29:35] <cradek> there was a huge range of ages
[03:29:49] <A-L-P-H-A> well, I'd be 26 at the time of that photo.
[03:29:56] <A-L-P-H-A> and GROSSS!!!! Someone had McD.
[03:30:30] <A-L-P-H-A> who's the big guy with the overlarge shirt that has no stretch anymore? [3rd from the left]
[03:30:54] <cradek> 3rd from left is jmk
[03:30:55] <A-L-P-H-A> that photo needs a name tag...
[03:31:02] <jmkasunich> 3rd from left is me (in the dark green jacket)
[03:31:04] <cradek> but his shirt looks fine to me...?
[03:31:08] <A-L-P-H-A> nono... jmk, is the thick beard guy right?
[03:31:17] <A-L-P-H-A> the guy with the newbalance shoes.
[03:31:22] <jmkasunich> which thick beard guy? ;-)
[03:31:24] <A-L-P-H-A> white hair.
[03:31:30] <cradek> oh I see how you're counting
[03:31:30] <A-L-P-H-A> there's a guy I'm counting, that has his back turned.
[03:31:36] <jmkasunich> matt shaver
[03:31:39] <cradek> the white hair guy is matt shaver
[03:31:51] <cradek> I missed the leftmost backwards guy
[03:31:52] <A-L-P-H-A> who's the uncool guy, with his back turned?
[03:31:57] <jmkasunich> from the left (not counting seated backwards guy)
[03:31:59] <cradek> no idea
[03:32:09] <A-L-P-H-A> we'll call him "Mysteriouso"
[03:32:37] <A-L-P-H-A> do not forget to give Tux shoutout. :)
[03:32:53] <cradek> not counting the matt shaver and mystery-guy (2nd from right) we're all the same height
[03:32:55] <jmkasunich> Steve Stallings, Matt Shaver, JMK, Jepler, TUX, Ray Henry, Jon Elson, SWPadnos, Dave Engvalls (daveE), unknown, Cradek
[03:33:51] <jmkasunich> 80% facial hair, 80% glasses
[03:34:02] <jmkasunich> not a random sample of the population for sure
[03:34:15] <cradek> I bet 80% glasses isn't too odd
[03:34:27] <cradek> (thanks, intelligent design)
[03:34:37] <cradek> oops did I say that?
[03:34:52] <A-L-P-H-A> but 3/11 people being obese is a standard sample of North America (English speaking America)
[03:35:07] <jmkasunich> thanks evolution (that no longer selects for good vision thanks to glasses)
[03:35:17] <A-L-P-H-A> I think the others are just vain and were contacts, or has laser surgery.
[03:35:18] <A-L-P-H-A> hehehe
[03:35:25] <A-L-P-H-A> wear
[03:35:36] <cradek> I used to wear contacts, but stopped because they're a pain
[03:35:47] <jmkasunich> I never started
[03:35:49] <cradek> they work much better than glasses
[03:35:59] <A-L-P-H-A> OH! jepler... why are you so silly... SANDLES while working with machinary?? what about your toes!!!
[03:36:06] <jmkasunich> not at stopping metal chips and flying solder blobs
[03:36:21] <jmkasunich> he doesn't run the machine, he codes!
[03:36:58] <A-L-P-H-A> fair enough.
[03:37:16] <cradek> A-L-P-H-A: did you see the link
http://emergent.unpy.net/stippler
[03:37:21] <A-L-P-H-A> jmk is trendy... wearing 'broken in' jeans. :)
[03:37:36] <A-L-P-H-A> oh STIPPLER... :) thanks.
[03:38:04] <A-L-P-H-A> I'd just be the 'hawt azn guy' with nice hair, if I were in the photo. hah
[03:38:05] <A-L-P-H-A> j/k
[03:38:23] <jmkasunich> those are my accomplishment pants
[03:38:26] <cradek> "the one with hair"
[03:38:36] <jmkasunich> thats SWPadnos
[03:38:41] <A-L-P-H-A> spelling mistake. "inptut" on that stippler page. :)
[03:38:53] <cradek> tell jepler...
[03:39:19] <cradek> hey we didn't note 100% male ... certainly not representative of the general population
[03:39:21] <jmkasunich> jepler has hair too, he's just hiding it
[03:39:32] <cradek> yeah he has lots of hair
[03:39:40] <jmkasunich> well, when you go to CNC workshop, 100% make pretty much goes without saying
[03:39:46] <jmkasunich> s/make/male
[03:39:48] <A-L-P-H-A> SWPadnos, has hair... and lots of it.
[03:40:05] <cradek> I used to have more than both of them combined
[03:40:13] <jmkasunich> you?
[03:40:23] <cradek> yep
[03:40:24] <A-L-P-H-A> 'unknown' guy kind looks like a mole man...
[03:40:35] <A-L-P-H-A> heh.
[03:40:42] <A-L-P-H-A> photos are fun. :)
[03:40:51] <A-L-P-H-A> look at how much time we killed talking about it? :)
[03:40:55] <jmkasunich> yeah
[03:40:55] <cradek> I still have it on my drivers license even
[03:41:14] <A-L-P-H-A> OMG... you should have seen my photo for my university ID.
[03:41:15] <cradek> is it may again yet? that was fun.
[03:41:25] <A-L-P-H-A> it was from grade 11... I looked like I was 14.
[03:42:01] <A-L-P-H-A> it was sad, when I'm using that ID, that didn't look a thing like me. when I was like 21.
[03:42:11] <cradek> A-L-P-H-A:
http://emergent.unpy.net/files/stippler/img_9023.jpg
[03:42:49] <A-L-P-H-A> now that is super cool.
[03:43:19] <cradek> he made a few of these with different images - at least one was a gift for someone iirc
[03:43:38] <A-L-P-H-A> airc?
[03:43:47] <A-L-P-H-A> as I recall?
[03:43:54] <cradek> if I remember correctly
[03:44:35] <A-L-P-H-A> oh
[03:44:52] <cradek> http://www.oberlin.edu/math/faculty/bosch/tspart-page.html
[03:44:56] <A-L-P-H-A> this is messed.
[03:45:01] <cradek> another thing that would be very cool to engrave and light
[03:45:12] <A-L-P-H-A> if I order DSL and sign up for 3 years... I get a DELL 19" monitor.
[03:45:33] <jmkasunich> cradek: did you post that link recently?
[03:45:42] <cradek> I think jepler did
[03:46:02] <cradek> I mean I know he found it, but I don't remember what channel I saw him paste it
[03:46:10] <A-L-P-H-A> cradek. DAMN.
[03:46:12] <A-L-P-H-A> nice.
[03:46:42] <cradek> that's another one where both the algorithm is interesting and the result is artistic
[03:46:44] <jmkasunich> I know I saw that pic recently, either the link was here, or I randomly browsed to the same page
[03:47:33] <A-L-P-H-A> any other cool links?
[03:47:45] <A-L-P-H-A> we should have like an EMC del.icio.us page. :)
[03:47:47] <cradek> those are the only two things I can think of that would be nice for envgraving
[03:48:05] <cradek> both are a lot of programming to do well
[03:48:31] <cradek> looks like the tsp guy doesn't have code, but tsp algorithms are pretty easy to find
[03:48:37] <A-L-P-H-A> that isn't gcode exports the TSP art?
[03:48:49] <cradek> ?
[03:48:50] <A-L-P-H-A> dots it is.
[03:49:24] <cradek> yeah if you want to engrave the tsp stuff you'll have some programming to do, jepler and I haven't done it yet :-)
[03:49:51] <cradek> but it would be very easy to convert the dot-cat into the tsp style art
[03:50:10] <cradek> it was already tsp optimized (or it would have taken a year to engrave the dots)
[03:50:47] <cradek> goodnight guys, I better go
[03:51:04] <cradek> jmkasunich: are you going to check something in still tonight?
[03:51:41] <A-L-P-H-A> night
[03:51:43] <jmkasunich> yeah
[03:51:55] <jmkasunich> too much talking, not enough coding
[03:51:58] <cradek> ok, I'm anxious to have a look at it tomorrow then
[03:52:00] <jmkasunich> think its done, gotta test
[03:52:16] <cradek> we haven't had a gabfest for a while
[03:54:33] <A-L-P-H-A> I think I'm gonna nap now. ciao guys. thanks for the info.
[03:54:42] <cradek> goodnight
[03:54:55] <jmkasunich> goodnight A-L-P-H-A
[03:56:22] <jmkasunich> cradek: you can induce overruns on your machine?
[03:56:28] <cradek> yep
[03:56:41] <jmkasunich> this seems to work, if I commit right now can you test before sleep?
[03:56:45] <cradek> sure
[03:58:54] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/emc/motion/ (control.c mot_priv.h motion.c): make servo thread period and overrun count hal paramaters so they can be scoped
[03:59:11] <jmkasunich> you can just halmeter them
[03:59:27] <jmkasunich> oops, there's a bug
[03:59:29] <jmkasunich> stand by
[03:59:50] <jmkasunich> (it will blow up dmesg on the first overrun)
[04:03:10] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/emc/motion/control.c: fix a bug that would flood the system log
[04:03:17] <jmkasunich> ok, now try it
[04:03:22] <cradek> ok
[04:03:42] <jmkasunich> you can halmeter "overruns" and "last-period" to see if it works
[04:03:46] <jmkasunich> (or scope em, if you want)
[04:04:13] <jmkasunich> I know last-period works, dunno about overruns and the printing logic (which I tweaked)
[04:04:35] <jmkasunich> overruns is a read/write param, you can reset it to zero to re-enable the printing of the error message
[04:04:49] <cradek> cool
[04:05:04] <jmkasunich> well, the first attempt wasn't so cool
[04:05:14] <jmkasunich> it would print whenver overruns == 1
[04:05:40] <jmkasunich> iow, 1000 times a second from the time of the first error until another one happens
[04:05:45] <jmkasunich> :-(
[04:06:46] <cradek> ooh
[04:09:30] <cradek> http://timeguy.com/cradek-files/emc/overruns.png
[04:10:05] <jmkasunich> wow, you really wacked it
[04:10:12] <jmkasunich> did it print only once?
[04:10:21] <cradek> yes
[04:10:31] <cradek> one error from tkemc and one message in the log
[04:11:03] <cradek> there's a little problem with nvidia, wouldn't you say
[04:11:10] <jmkasunich> just a little
[04:11:37] <jmkasunich> 66 overruns in one second
[04:12:10] <cradek> I sure won't be running a machine on this box
[04:12:24] <jmkasunich> just don't run glxgears
[04:12:24] <cradek> I'm anxious to try this on my good machine
[04:12:35] <cradek> I bet even axis will mess it up sometimes
[04:12:45] <jmkasunich> whats the scaling on the red trace?
[04:12:56] <cradek> 500k/div
[04:12:58] <jmkasunich> are the overruns just a little over, or lots over
[04:13:04] <cradek> the baseline is at the bottom
[04:13:18] <cradek> so the overruns are about twice the normal number
[04:13:19] <jmkasunich> so 2.5 million most of the time
[04:14:00] <cradek> normal is 2e6, most of the spikes are 4e6+
[04:14:22] <cradek> some are only 3e6
[04:14:33] <jmkasunich> so 20% over is fine for detecting them
[04:14:50] <jmkasunich> I notice some "grass" on the basline level on the left side... how tall is that?
[04:15:17] <jmkasunich> seems like about 5% or so
[04:15:30] <cradek> nominal 1.98 grass 2.17
[04:15:33] <jmkasunich> one major division should be 20% if I'd reading it right
[04:15:51] <jmkasunich> hmm, 9%
[04:16:01] <cradek> that's with one glxgears running
[04:16:02] <jmkasunich> I wonder if 20% is cutting it too close?
[04:16:05] <cradek> don't trust it as normal
[04:16:15] <cradek> we should try on our reliable machines
[04:16:31] <jmkasunich> I thought glxgears started in the middle of the screen?
[04:16:46] <cradek> no that's when I started a second one
[04:16:54] <cradek> that made it REALLY bad
[04:17:04] <cradek> but even just one running will cause kern/latency test overruns
[04:17:34] <cradek> let's collect more data before worrying about what magic number to choose
[04:17:34] <jmkasunich> well, 9% of the servo thread is probably 100% or more of the base thread
[04:17:38] <jmkasunich> yeah
[04:17:41] <cradek> true
[04:17:50] <jmkasunich> I'm firing up scope now, to see what this machine gives as normal
[04:18:03] <cradek> I better get to bed
[04:18:13] <jmkasunich> goodnight
[04:18:18] <cradek> I'll try it on max (very trusted machine) tomorrow and report back
[04:18:45] <jmkasunich> ok
[04:20:08] <jmkasunich> hmm, pretty tight distribution here
[04:20:12] <jmkasunich> nominal 1.64 million
[04:20:48] <jmkasunich> 99% of the fuzz is +/- 3000, worst peaks I've seen so far about +/- 15000
[04:22:11] <cradek> 1%?
[04:22:25] <jmkasunich> yeah
[04:22:30] <jmkasunich> just found a scope bug
[04:22:42] <cradek> cursor off by one?
[04:22:43] <jmkasunich> when you use a vertical offset, the trigger level slider ignores it
[04:22:57] <jmkasunich> I offset the trace by 1.64 million, then upped the gain to 10K/div
[04:23:16] <cradek> yeah I never thought I understood how that was supposed to work
[04:23:35] <jmkasunich> trigger level should be screen relative
[04:23:37] <cradek> (so I avoided using it)
[04:23:46] <jmkasunich> so it should take into account offset and scaling
[04:23:57] <jmkasunich> offset is simply subtracted from the sample before any other processing is done
[04:25:11] <jmkasunich> to late to mess with it tonight
[04:25:17] <jmkasunich> too late too
[04:25:25] <jmkasunich> goodnight
[04:25:30] <cradek> heh
[04:25:31] <cradek> goodnight
[06:29:37] <ValarQ_> ValarQ_ is now known as ValarQ
[07:28:22] <A-L-P-H-A> awake again. so sad.
[12:30:08] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: button3 and ctrl+button1 should zoom in the same way
[13:30:50] <A-L-P-H-A> wth... jymmm made his nick private.
[13:38:50] <jepler> huh
[15:31:33] <alex_joni> hi all
[15:32:01] <jepler> hi alex_joni
[15:32:33] <alex_joni> hi jeff, got some internet access at the hotel ;)
[15:32:49] <jepler> nice of you to join us
[15:32:59] <alex_joni> but no-one knew of that
[15:33:04] <alex_joni> not even the guys from the hotel
[15:33:06] <alex_joni> (lol)
[15:33:40] <alex_joni> anyways, I saw you announced the move of the debs
[15:33:55] <alex_joni> I kinda left abrupt the other day.. ran out of power
[15:39:15] <jepler> yes -- haven'theard one way or the other if it has helped people
[15:41:04] <alex_joni> ok, I was thinking a bit about update
[15:41:33] <alex_joni> and was wondering if we couldn't release one of the future emc2 packets which does a bit of sed in the postinst script
[15:42:10] <alex_joni> so basicly when we'll have 2.0.4 or even 2.1.0, we'll have a small postinst hack to search /etc/apt/sources.list and replace the old repo with the new one
[15:42:23] <SWPadnos> hi guys
[15:42:32] <jepler> hi SWPadnos
[15:42:50] <SWPadnos> alex_joni, I think there's a way of updating repositories anyway - the breezy->dapper update did that
[15:43:14] <alex_joni> SWPadnos: yeah, but that's for distupgrades
[15:43:18] <jepler> I'll let one of you guys dig into that
[15:43:23] <alex_joni> jepler: ty ;)
[15:43:27] <SWPadnos> heh
[15:43:30] <alex_joni> * alex_joni will sign up to do it
[15:43:33] <SWPadnos> yeah - go for it ;)
[15:43:45] <alex_joni> on saturday, when I'm back home ;)
[15:44:05] <alex_joni> anyways.. here are some nice goodies:
http://www.screenkeys.com/screenkeys/s1.html
[15:44:34] <SWPadnos> I saw those at NAB this year - they're pretty cool
[15:44:46] <SWPadnos> expensive as hell though
[15:56:12] <alex_joni> jepler: forgot to say thanks for the announcement:
http://ziza.ru/other/082006/17/thks/thks.swf
[15:59:38] <jepler> alex_joni: that's very silly
[15:59:58] <alex_joni> I know .. but I couldn't resist
[16:01:51] <SWPadnos> two days later, they're finally done ;)
[16:02:07] <alex_joni> who will ever know ?
[16:02:12] <SWPadnos> not me, I assure you
[16:02:44] <SWPadnos> but even that would be preferable to getting a Windows 98SE system to properly utilize a USB keyboard
[16:03:13] <SWPadnos> correction: trying to get a Win98SE system to properly utilize a USB keyboard
[16:03:51] <alex_joni> heh
[16:05:13] <alex_joni> hmm.. saw a nice bending machine today (CNC)
[16:05:19] <alex_joni> to tubes.. guess what OS?
[16:06:04] <jepler> oh, windows CD?
[16:06:06] <jepler> CE?
[16:06:20] <alex_joni> XP Pro :(
[16:06:52] <alex_joni> on startup it complained about a missing RT deadline (100usec overrun over the normal 630usec)
[16:07:08] <alex_joni> so it's probably patched, but I couldn't figure out with what
[16:08:18] <alex_joni> but it had fiber optics talking SERCOS to the servo drives (big AC drives & motors), so that part was nice
[16:10:26] <alex_joni> ok guys.. I'm off.. talk to you some other time
[16:10:45] <SWPadnos> see you
[16:10:45] <alex_joni> bye all
[16:42:59] <Lerneaen_Hydra> 'lo
[17:27:51] <Lerneaen_Hydra> none here?
[17:27:55] <Lerneaen_Hydra> jepler: you there?
[17:28:06] <ValarQ> * ValarQ is almost here
[17:28:33] <Lerneaen_Hydra> 'lo
[17:29:32] <SWPadnos> We're sorry, the person you're trying to reach is dealing with Windows 98SE. Please leave a message, and he'll get back to you if he doesn't commit suicide first. Thank you.
[17:32:13] <Lerneaen_Hydra> oh noes....
[17:32:33] <Lerneaen_Hydra> why would one have to do anything with a 9x system?
[17:33:00] <Lerneaen_Hydra> (except for the COMMERCIAL CNC lathe at my old school, that ran 98se...)
[17:36:20] <SWPadnos> my wife's computer is still 98se, and it died. I would like to keep all of her old email and graduate coursework
[17:36:47] <SWPadnos> so I'm fighting with a nearly identical motherboard, which sadly has no PS/2 style keyboard / mouse ports - it's USB only
[17:36:54] <SWPadnos> which of course works so well in 98SE
[17:37:21] <SWPadnos> I may just install Ubuntu, but then she'd lose access to things like Corel Draw
[17:37:22] <Lerneaen_Hydra> argh!
[17:37:34] <Lerneaen_Hydra> corel doesn't like wine?
[17:37:54] <SWPadnos> yeah, and even better, since it's the USB drivers that are a problem, I can't transfer drivers that are larger than a floppy
[17:38:15] <SWPadnos> the CD-ROM doesn't work in safe mode (though the keyboard and mouse do, since the BIOS is left in control)
[17:38:55] <SWPadnos> I'm not sure about Corel/wine - I've never gotten wine to work satisfactorily on any Linux machine
[17:38:57] <Lerneaen_Hydra> nothing like old, legacy systems...
[17:39:11] <SWPadnos> yeah - tell me about it
[17:39:36] <SWPadnos> if I could be sure that I can migrate the Mozilla/Windows mail to Thunderbird/Linux, I'd jump that way faster
[17:39:47] <SWPadnos> luckily, most of her coursework was done in OpenOffice
[17:40:27] <SWPadnos> oh joy - reboot #73
[17:41:07] <Lerneaen_Hydra> happy joy
[17:45:13] <SWPadnos> and of course, once it gets past the USB driver detection, the keyboard stops working. aaaaaaaarrrrggggghhhhhhh
[17:46:23] <cradek> SWPadnos: no ps2 port for a normal keyboard?
[17:46:28] <SWPadnos> nope
[17:46:39] <SWPadnos> it's the "legacy free" Abit AT7Max
[17:46:40] <cradek> yuck
[17:46:42] <SWPadnos> yep
[17:46:50] <cradek> that's a terrible match for windows 98
[17:46:51] <SWPadnos> works fine with Linux or Win2k
[17:46:58] <jepler> Lerneaen_Hydra: I'm back from lunch now
[17:46:58] <SWPadnos> probably on a new install of 98se as well
[17:47:15] <Lerneaen_Hydra> hi jepler
[17:47:24] <Lerneaen_Hydra> how goes the image-to-gcode app?
[17:47:28] <Lerneaen_Hydra> hi cradek
[17:47:35] <cradek> hi
[17:48:01] <SWPadnos> ubuntu it is then
[17:49:38] <jepler> Lerneaen_Hydra: it needs desparately to be tested on a real machine
[17:49:57] <jepler> desperately even
[17:50:06] <Lerneaen_Hydra> I see... I don't have a mill at the moment so I won't be able to test it I'm afriad
[17:51:03] <jepler> Lerneaen_Hydra: there's an organizational problem that makes it hard to specify different feed rates for different segments, and when doing up/down milling the place to split needs to be chosen better
[17:51:36] <Lerneaen_Hydra> oh, ok
[17:51:59] <Lerneaen_Hydra> how hard is it to apply differing feedrates to different lines?
[17:52:32] <jepler> set_feed() and cut() are two different methods on the object which actually writes the gcode
[17:52:51] <jepler> cut() actually puts the line into a structure and later performs the simplification algorithm on it
[17:53:06] <jepler> set_feed() just writes an F-word to the output
[17:53:56] <jepler> so if you try to just write set_feed(); cut(); set_feed(); cut() you either get all the F-s bunched before any of the G1s, or you lose the benefit of the simplification algorithm because it can't work across F-s
[17:54:54] <jepler> so I have to reorganize it so that when the G1s are actually being output (after simplification) some function can be called to choose the F for each segment actually being output
[17:56:05] <jepler> I'm not sure if that explanation makes sense when you're not familiar with the code
[17:58:40] <SWPadnos> what's the reasoning behind using different F words? (other than separating plunge cuts from mill cuts)
[18:00:12] <jepler> I'll let Lerneaen_Hydra answer that .. I'm (considering) implementing it at his suggestion
[18:03:14] <SWPadnos> I can see the separation in the case of plunge only vs. any other move, but varying the feed based on the direction of cut doesn't make a lot of sense to me
[18:05:44] <Lerneaen_Hydra> I'm back now
[18:05:47] <Lerneaen_Hydra> * Lerneaen_Hydra reads
[18:09:30] <Lerneaen_Hydra> SWPadnos: the reason for limiting plunge feed is becuase endmills aren't very good at cutting material when plunging, so if you have a 45 degree cut then should you have plunge feed or plane feed? it would seem to me that an average of them would be best
[18:34:38] <cradek> ignoring arcs for a moment, you could definitely adjust the feed for every segment depending on its angle from Z
[18:37:48] <jepler> yeah and that's what I intend(ed) to implement, before I realized that the "obvious" way to implement it wouldn't work
[18:48:30] <Lerneaen_Hydra> arcs should (IMO) use the speed with the lowest speed, in or out
[18:48:34] <Lerneaen_Hydra> if that makes any sense
[19:02:12] <Lerneaen_Hydra> that is to say, it shoudl use the feed of the g1 attached to its' end, and have the feed of the slowest g1 attached to it
[19:02:20] <Lerneaen_Hydra> again IMO
[19:13:39] <SWPadnos> Lerneaen_Hydra, I figured that plunge and mill should be different, but averaging for off-angle cuts probably isn't the answer
[19:13:51] <SWPadnos> you end up with varying finish in that case
[19:14:52] <Lerneaen_Hydra> you'll get that even if you have a hard-cut transition between plunge and plane
[19:15:01] <SWPadnos> ideally, I think the feed and depth of cut would be chosen by the program for roughing, and would remain constant for finish passes
[19:25:45] <Lerneaen_Hydra> what about during the roughing pass?
[19:25:57] <Lerneaen_Hydra> how is feed defined for plunge/plane feed then?
[19:26:18] <SWPadnos> roughing is an unimplemented feature, as far as I can tell
[19:26:56] <SWPadnos> one way it could work is to have the user enter a material removal rate (cubic inches/minute or similar)
[19:26:58] <Lerneaen_Hydra> well, if one were to assume its existance
[19:27:02] <SWPadnos> heh
[19:27:07] <Lerneaen_Hydra> just hypothetically
[19:27:50] <SWPadnos> that rate will be dependent on the spindle power, material, cutter composition, coatings, coolant ... (it could be calculated by the program, given enough data, but it's a PITA)
[19:28:37] <SWPadnos> once you have that, and the expected cutting speed (SFM), cutter diameter, and desired chipload, you can calculate spindle speed, feedrate, and depth of cut automatically
[19:29:16] <SWPadnos> so a set of "waterline" roughing passes would be done first, at the "ideal" material removal rate
[19:29:42] <SWPadnos> at that point, there's not much need to change the feedrate based on plunge/plane moves
[19:30:26] <SWPadnos> you could still have something that does separate plunge vs "finishing" moves, but I'd say that at that point, you don't need to vary the feedrate based on angle
[19:30:49] <Lerneaen_Hydra> that's still a lot more calculation than just defining a plunge and plane rate ;)
[19:31:17] <SWPadnos> sure, but I'm not sure of the usefulness of the plunge/plane thing :)
[19:31:22] <Lerneaen_Hydra> probably a PITA to get the calc to work correctly WRT material, sharpness, and so on
[19:31:42] <SWPadnos> that's why I'd just have the user enter a number for that
[19:32:18] <SWPadnos> there are some tables on the net that tell you the optimum removal rate for various materials (per HP ot spindle power, usually)
[19:32:20] <Lerneaen_Hydra> in the machining handbook I have here the recomended plunge feedrate is 1/3 - 1/4 of the planing feedrate
[19:32:22] <SWPadnos> s/ot/of/
[19:32:43] <Lerneaen_Hydra> so there is (IMO) reason to feed differently depending on plunge/plane
[19:32:45] <SWPadnos> right - the chips don't clear as fast with a plunge move
[19:32:48] <Lerneaen_Hydra> yeah
[19:33:00] <Lerneaen_Hydra> so in the end you will need different feedrates for plunge/plane
[19:33:19] <SWPadnos> but a diagonal move doesn't have that problem, and may leave undesirable finish variations
[19:33:56] <SWPadnos> (if the speed is varied)
[19:35:40] <Lerneaen_Hydra> I see what you mean
[19:35:51] <Lerneaen_Hydra> so a hard limit at some certain angle may be best?
[19:35:59] <Lerneaen_Hydra> say around 70-80 degrees?
[19:36:13] <SWPadnos> could be (also probably settable)
[19:36:20] <Lerneaen_Hydra> AFAICT my cam app has some hard limit angle that it uses for that
[19:37:04] <Lerneaen_Hydra> how ingrained is the raster image base?
[19:37:12] <SWPadnos> ?
[19:37:18] <Lerneaen_Hydra> is it some form of raster -> 3d model conversion
[19:37:29] <Lerneaen_Hydra> or are all things done based on pixel brightness
[19:37:43] <SWPadnos> the idea for this type of thing is engraving images, not making parts from CAD
[19:40:15] <jepler> the program right now assumes it's milling within a rectangular area, that it can do a good job by looking at the height specified at discrete regularly-spaced locations, and that it can find the height of any location. You could change it to use a 3D model instead of an image as input.
[19:41:02] <SWPadnos> it would be funny to render an STL, then use image-to-gcode to mill it ;)
[19:41:53] <Lerneaen_Hydra> yeah, that's what I was thinking. with the high level of CAM in the app now it would be nice to be able to import real 3d models, or at least high-res height-maps without too much CPU penalty
[19:42:08] <Lerneaen_Hydra> jepler: ooh, nice
[19:42:13] <jepler> well, cradek's unreleased 'toolpath' does basically that: take a polygonal model, render it to a z-buffer, and use that to compute the milling path. image-to-gcode adopts some of its methods (primarily, the tool shape compensation/gouging).
http://unpy.net/jepler/toolpath.png
[19:42:33] <Lerneaen_Hydra> oh, I see
[19:42:36] <Lerneaen_Hydra> nice
[19:43:15] <jepler> with this method, the effort increases approximately according to the cube of the image width (I think)
[19:44:08] <SWPadnos> hmmm - why the cube?
[19:44:20] <SWPadnos> (I suppose I should read the code before asking that)
[19:44:33] <Lerneaen_Hydra> the cube of the image width?
[19:44:47] <Lerneaen_Hydra> shouldn't the area determine the calculations done?
[19:46:51] <jepler> at each point it computes max(tool_shape + part_of_model_shape). tool_shape becomes a larger matrix when more pixels fit "under" a circle the diameter of the tool
[19:47:08] <jepler> so that's an n-squared operation
[19:47:11] <Lerneaen_Hydra> oh
[19:47:13] <Lerneaen_Hydra> right
[19:47:15] <jepler> and you repeat it at each pixel location across a row or column
[19:47:36] <Lerneaen_Hydra> so you don't want to do stuff bigger than 1k by 1k pixels?
[19:48:50] <jepler> depends how patient you are
[19:49:10] <jepler> I usually use a 400x400 image while testing, though I turn up the spacing between rows
[19:49:30] <jepler> I think the tool_shape is typically a 45x45 matrix, but I'm not sure
[19:49:39] <Lerneaen_Hydra> ok
[19:50:28] <SWPadnos> what do you mean by "max(tool_shape + part_of_model_shape)"
[19:51:32] <jepler> SWPadnos: it does the by-element addition of matrices and then finds the maximum element
[19:54:14] <SWPadnos> hmmm - ok
[19:56:01] <SWPadnos> most tools will be either falt bottomed, round, or have an angle (possibly mostly flat and angled at the edges)
[19:56:31] <SWPadnos> it seems that the max calculation could be similified considering those restrictions
[19:56:39] <SWPadnos> simplified, even
[19:57:15] <Lerneaen_Hydra> yeah
[19:57:24] <Lerneaen_Hydra> it would be good to have max calc open though
[19:57:34] <Lerneaen_Hydra> with a bitmap for custom tools
[19:57:43] <Lerneaen_Hydra> if you know that shape and so on
[19:57:54] <SWPadnos> sure - that's the most generic form
[19:58:03] <Lerneaen_Hydra> not very needed though, might be nice
[19:58:53] <cradek> now in toolpath the tool shape is programmed as a math expression so no matter what pass resolution you want, the tool matrix can be easily filled
[19:59:05] <cradek> a bitmap is going to not have that property
[19:59:59] <SWPadnos> right, but the underlying comparison is still done on a "point-by-point" basis, though the tool points can be calculated to be the same resolution
[20:00:07] <SWPadnos> as the bitmap
[20:05:32] <jepler> I agree there are only a few tool shapes (you can currently choose 45 degree and 60 degree vee, flat, and ball-end tools) but I don't see how you can find the correct depth to cut to without doing the full max(tool+model) calculation at each location
[20:06:03] <SWPadnos> me either. I was thinking that ther emay be a more efficient way of getting the max though
[20:07:11] <SWPadnos> but I don't know what it is
[20:08:00] <cradek> even if you can save some results from the previous max calculation and use that (since it covered all but one row of the current scan) you don't reduce the actual complexity
[20:08:58] <SWPadnos> sure - you'd have to offset each grid item, instead of just racalculating it (which is the same amount of work, memory caching issues notwithstanding)
[20:09:15] <cradek> seems like you ought to be able to reduce it to n2 but I don't see how
[20:09:41] <SWPadnos> it just "seems like there should be a better way", but as I said, I don't know what the better way is
[20:09:52] <cradek> yep I agree
[20:17:19] <jepler> the big payoff would be to use modern opengl hardware (except for the way you can't run any of that and emc at the same time)
[20:18:13] <jepler> render the model to the framebuffer then render the tool texture tiled over the whole model
[20:18:14] <SWPadnos> heh - that is a problem :)
[20:18:28] <jepler> then repeat moving the tool origin to each of N*N locations
[20:18:46] <jepler> now you have the data for all the points on the model
[20:19:02] <SWPadnos> same complexity, only several thousand times faster, so we don't care
[20:19:05] <jepler> right
[20:19:58] <cradek> I don't understand "render the tool texture tiled over the whole model"
[20:20:41] <SWPadnos> use the tool depth map as a texture, and tile it over the entire source image
[20:21:10] <SWPadnos> do that for N*N offsets, where N is the number of pixels wide the tooltip height map is
[20:56:04] <Lerneaen_Hydra> 'night
[21:13:11] <danex> hello all
[21:27:20] <Michel1> Hello everyone
[21:27:59] <Michel1> I have now a working emcprobe
[21:56:03] <MichelG> Hello again; network dropout;.
[21:58:38] <danex> hello
[22:49:15] <NickServ> This nickname is owned by someone else
[22:49:15] <NickServ> If this is your nickname, type /msg NickServ IDENTIFY <password>
[23:10:05] <danex> Hello All
