#emc | Logs for 2005-05-07

Back
[00:00:16] <jmkasunich> well we know it's wrong... being able to describe more clearly _what_ is wrong would be helpfull
[00:00:45] <jmkasunich> can you use stripchart to see what it is doing?
[00:00:51] <les> well g64 in general...but TP/TC is incapable of blending arcs without an exact stop...that is a problem.
[00:01:08] <jmkasunich> uh.... yeah, I guess that's a problem
[00:01:16] <les> big.
[00:01:17] <jmkasunich> I had no idea it was that screwed up
[00:01:19] <SWPadnos> * SWPadnos wonders what TC is :)
[00:01:38] <les> JMK it's gonna get fixed
[00:01:45] <SWPadnos> (got my head in Rodeo-land)
[00:01:46] <jmkasunich> see tp.c, and tc.c
[00:01:53] <les> swp: tc.c
[00:01:57] <jmkasunich> who's gonna fix it?
[00:02:30] <les> Fred , Paul, a little bit me, perhaps you too
[00:02:40] <jmkasunich> sounds like a plan
[00:02:50] <les> yeah!
[00:02:59] <jmkasunich> beats the heck out of trying to grok autoconf scripts
[00:03:10] <les> heh
[00:03:39] <SWPadnos> more like - what does TC stand for (like Trajectory Planning or Segment Queue :) )
[00:03:49] <les> well we have a ferrari witha rubber band engine here
[00:04:00] <les> have to put thingd in perspective
[00:04:02] <jmkasunich> I used to know... it's something to do with the algorithm
[00:04:08] <jmkasunich> described in tc.c I think
[00:04:11] <jmkasunich> * jmkasunich looks
[00:04:34] <SWPadnos> TC = Discriminate-Based, I guess ;)
[00:04:49] <les> TC calculates blended trapeziodal plans
[00:04:59] <SWPadnos> OK
[00:05:03] <les> tc queues them up
[00:05:07] <les> I think
[00:05:20] <les> tp I mean
[00:05:34] <SWPadnos> I'll be on a plane tomorrow (and tuesday), and I can think about this a bit during those times
[00:05:35] <jmkasunich> but I think it can only blend over pairs of adjacent moves
[00:05:53] <jmkasunich> which is fundamentally flawed
[00:06:08] <les> It is textbook from an unpublished delta tau paper
[00:06:14] <les> but we have a copy
[00:06:29] <SWPadnos> there is a simple equation (which I haven't derived yet) to tell if a segment is impossibly small for the planner
[00:06:34] <les> we need at least cubic
[00:06:42] <SWPadnos> (meaning that more than one velocity command is needed in a single update cycle)
[00:06:48] <les> which is 4 pt 3 segment lookahead
[00:07:01] <jmkasunich> les - even that isn't gonna do it imho
[00:07:20] <jmkasunich> go back to my example, of 10ips and 50ips^2
[00:07:25] <SWPadnos> you need time / length - based lookahead, not a specific number of segments (at the lowest level)
[00:07:37] <jmkasunich> accel/decel from stop to 10ips takes 0.2 seconds
[00:07:49] <jmkasunich> and travels 0.1 inches during that time
[00:07:51] <les> SWP: yeah kinda
[00:08:31] <jmkasunich> so assume a long move, followed by a 0.050 move in the exact same direction, followed by either a pause or a sharp turn
[00:08:45] <les> We are trying to establish a benchmark on what adequate performance would really be
[00:09:01] <jmkasunich> you need to begin the decel _before_ the beginning of the 0.050 move
[00:09:08] <les> yes
[00:09:30] <SWPadnos> Just so I'm not flailing along (on battery power on a plane), - the hierarchy of motion control is interpreter -> motion commands -> planner -> interpolator -> PID ???
[00:09:32] <jmkasunich> the pathological case is if the 0.050 move is actually 10 moves of 0.005
[00:09:51] <jmkasunich> yep, that's pretty much it
[00:09:56] <SWPadnos> not so pathological for CAM-generated codefrom a STL file
[00:10:17] <SWPadnos> (ie, common, but still pathological)
[00:10:33] <les> right now....02" segment distance and 30 ipm completely chokes emc
[00:10:35] <jmkasunich> when I say pathalogical, I don't mean won't happen, I mean will bust things
[00:10:49] <jmkasunich> 30 ipm is 0.5 ips
[00:10:51] <les> but we have a serious tp stck depletion problem
[00:11:04] <les> stack
[00:11:08] <jmkasunich> your only talking about 25 segments per second at 0.02"
[00:11:09] <jmkasunich> wow
[00:11:37] <jmkasunich> I expected it to choke at somewhere around 500 segments/sec
[00:11:38] <les> that is not even good enough for bridgeport type feedrates
[00:12:10] <les> We need to give you guys thew spiral test program
[00:12:17] <jmkasunich> when you say it chokes it, do you mean that motion stops completely and it crashes, or just that it gets jerky
[00:12:54] <les> It violently pauses due to TP stack depletion, waits, the resumes
[00:13:02] <jmkasunich> on that note... I was thinking about adding a subdir under "emc2/ncfiles" called "test_progs"
[00:13:05] <les> there is no velocity adaptation
[00:13:16] <jmkasunich> your spiral and my torture tests could both be in there
[00:13:26] <les> sounds good
[00:13:36] <les> the spiral is very telling
[00:13:50] <jmkasunich> how big is the program (lines, and kbytes)
[00:13:51] <les> cause the points get closer and closer together
[00:14:05] <jmkasunich> right
[00:14:13] <les> it is a few 10k or so
[00:14:17] <les> not big
[00:14:43] <jmkasunich> but I'd want one that fails right away (just go right to the combination that busts it) so I could trigger a scope on the badness
[00:14:52] <les> we will publish it
[00:15:12] <jmkasunich> I can just remove the parts that don't cause failure
[00:15:20] <les> the c program can be configure to fail at any desired tme
[00:15:32] <les> we will post it
[00:15:36] <jmkasunich> cool
[00:16:37] <SWPadnos> what cycle times are the various levels of the motion command chain typically run at?
[00:16:39] <les> We have determined that the first failure mode is NOT aliasing...I.E. motion plans that are faster than the trajectory rate
[00:17:14] <jmkasunich> right - it will fail for other reasons first
[00:17:26] <les> We need to do moe testing though
[00:17:33] <les> more
[00:17:36] <jmkasunich> SWP, traditionally traj is at 10mS and servo at 1mS
[00:17:54] <jmkasunich> but they are ini file params, I bet les is running faster
[00:18:06] <SWPadnos> OK - isn't there another level (smoothing or sub-interpolation) in there?
[00:18:17] <les> Paul says that kernel space/ user space communication is the limiting factor
[00:18:23] <jmkasunich> servo does the "sub interpolation"
[00:18:42] <jmkasunich> les: yes, the _abosolute_ maximum rate is one command per servo cycle
[00:18:49] <les> We talked with fred about sub interpolation
[00:18:57] <jmkasunich> and in practice it's much less than that
[00:18:58] <les> it is at the servo rate
[00:19:17] <les> it needs to be at the trajectorry rate
[00:19:48] <les> it is in the wrong place
[00:19:54] <les> fred says this
[00:20:22] <SWPadnos> the trajectory code deals with canonical primitives, right? (line, arc...)
[00:20:59] <les> we are gathering data...then paul will go back to gaithersburg and work with fres
[00:21:07] <jmkasunich> don't follow... the reason for sub-interp is to transform from the traj rate to the faster servo rate... doing subinterp at the traj rate would mean using the same position for 10 servo cycles in a row
[00:21:14] <SWPadnos> (sorry about bonehead questions - answers from those who know are way faster than looking through code on a laptop)
[00:21:17] <les> SWP: the interpreter deals with cannonicals
[00:21:32] <SWPadnos> the interpreter issues canonicals to the TP, no?
[00:21:43] <les> yes
[00:21:53] <les> with a big buffer
[00:22:00] <jmkasunich> SWP, you have a emc2 code tree handy?
[00:22:04] <SWPadnos> yes
[00:22:09] <jmkasunich> src/emc/motion/motion.h
[00:22:23] <les> BTW...we are working with emc2 tree
[00:22:56] <jmkasunich> line 100-157, the cmd_code_t enum, are the commands from user space to the motion code
[00:23:16] <jmkasunich> the only ones interesting for this problem are SET_LINE and SET_CIRCLE
[00:23:29] <jmkasunich> the rest are mostly config and higher level control
[00:24:04] <jmkasunich> src/emc/motion/command.c line 695 is what handles a SET_LINE
[00:24:17] <les> Paul says that there is about a 100 -200 microsecond brick wall due to kernel/user communication regardless of proccessor speed
[00:24:29] <jmkasunich> basically just sticks it in a queue
[00:24:45] <SWPadnos> right - that's not the interesting part :)
[00:24:47] <A-L-P-H-A> what CAM program do you guys like to use?
[00:24:48] <jmkasunich> you talking about the user-kernel bottleneck
[00:24:58] <les> yeah
[00:25:04] <les> paul is really
[00:25:17] <jmkasunich> that bottleneck is because the buffer between user and kernel only holds one message
[00:25:31] <les> really
[00:25:31] <SWPadnos> along with the fact that I/O is basically constant-time, regardless of CPU
[00:26:16] <jmkasunich> the user side is capable of processing many messages while it is running, but then it gets scheduled out by Linux and can do nothing for a long time... so its inherently bursty
[00:26:29] <SWPadnos> A-L-P-H-A: the cheapest one out there: STLWorks ($75 US)
[00:26:33] <les> well you are the programming experts...I can only say faster would be better
[00:26:52] <les> I just do math.
[00:26:56] <jmkasunich> the RT code on the other hand never processes more than one per cycle, to keep the processing time bounded, but it can _always_ process one per servo cycles, it never gets scheduled out
[00:27:00] <jmkasunich> so it is not bursty
[00:27:30] <jmkasunich> the user-kernel buffer would be better if it was a deep fifo to match the bursty input with continuous output
[00:27:54] <Jymmm> jmkasunich couldn't sumer buffer take care of that?
[00:27:59] <Jymmm> some
[00:28:14] <jmkasunich> the trick is that the buffer has to be at the user-kernel boundary
[00:28:23] <SWPadnos> I'd make a small motion FIFO, and leave the config stuff out of it (should make each message smaller)
[00:28:25] <jmkasunich> there is a buffer today, but it is _inside_ the kernel side
[00:28:33] <les> We checked the state of the art. A Galil legacy card with TI 320xx could do 64 microsecond servo updates.
[00:28:40] <les> an old ISA card.
[00:28:41] <A-L-P-H-A> SWPadnos, url?
[00:28:53] <jmkasunich> SWPadnos: it's worse than that... right now the user-kernel transport handshakes every message
[00:29:07] <jmkasunich> if you start FIFOing them, the entire handshake scheme needs to be revisited
[00:29:21] <SWPadnos> A-L-P-H-A: http://www.stlwork.com/
[00:29:33] <SWPadnos> jmkasunich: hmmm
[00:29:35] <jmkasunich> les: servo period has little to do with it
[00:29:54] <jmkasunich> unless you are running disk drive voice coils or something
[00:30:16] <les> It can be anissue john
[00:30:26] <les> basic nyquist stuff
[00:30:33] <Jymmm> jmkasunich; Heh, all this hassle that a $0.65 16KB buffer would resolve.
[00:30:41] <SWPadnos> shorter servo periods require less aggregation or higher contouring speed
[00:30:47] <les> and...heh...I have done servo voice coils
[00:30:50] <SWPadnos> or allow higher speed, that is
[00:31:04] <jmkasunich> right, IF the iron/motors etc have the inherent bandwidth to require a higher servo rate
[00:31:12] <jmkasunich> I bet even your machine doesn't
[00:31:44] <les> But our ony goal is good surface finish at bridgeport speeda and adequate results at router speeds
[00:32:09] <jmkasunich> les: thought experiment: build an analog PID loop on perfboard, connect it to your machine (add analog tachs for velocity feedback)
[00:32:12] <les> too bad I can't type huh
[00:32:27] <les> yeah?
[00:32:36] <jmkasunich> hook up a sinewave signal generator and start turning it up
[00:32:42] <les> k
[00:32:54] <jmkasunich> what did you say your first resonance was at?
[00:33:47] <jmkasunich> my point is that higher servo rates simply increase system bandwidth... if you are iron/motor limited, that doesn't help
[00:33:51] <les> mine? about 35 hz for the first complex conjugate pole pair in gantry rocking...but controllable
[00:34:20] <jmkasunich> with a 1mS servo period, Nyquist says you could aproach 500Hz control bandwidth
[00:34:36] <les> JMK: I can put zeros over the poles... and have.No problem.
[00:34:37] <jmkasunich> realistically 100Hz would be more like it
[00:35:02] <jmkasunich> but even a 100Hz input to your machine would have things hopping pretty badly
[00:35:12] <les> Bandwidth is servo freq /2 of course
[00:35:39] <jmkasunich> the problem isn't that the servo has too low bandwidth, the problem is that the path coming out of the TP has too _much_ high frequency content
[00:36:46] <les> well that is another issue...most all cnc feedback systems have notchand lowpass filters. EMC does not.
[00:37:18] <les> not hard to do though.
[00:37:22] <jmkasunich> HAL can address that... build a digital filter HAL module, and put it in
[00:37:31] <les> cool
[00:37:51] <jmkasunich> that's still pretty much a servo issue
[00:38:03] <les> yeah.
[00:38:11] <jmkasunich> another thought experiment: remove the PID loops and motors completely
[00:38:32] <jmkasunich> connect the position commands coming out of the TP right back as feedback, to prevent following errors
[00:38:33] <les> in fact emc can do enough bandwidth to do anti-vibration
[00:38:47] <les> but it beats up ballscrews etc
[00:39:18] <jmkasunich> now run the part program... the TP is running open loop, spitting out position commands... look at that as a signal... FFT it, or what have you
[00:39:31] <les> yeah...
[00:39:54] <jmkasunich> if that signal has spikes or other high frequency content, the machine isn't gonna be happy
[00:40:45] <les> Well that is what feedforward is for...you can run a servo loop right through a pole pair and maintain stability
[00:40:46] <jmkasunich> actually the thing to look at is the derivatives of that signal
[00:40:57] <jmkasunich> velocity, accel, jerk
[00:41:05] <les> yes
[00:41:20] <les> we are talking a lot about cubic vs quintic
[00:41:39] <jmkasunich> ignore the servos for this thought experiment... just think about the commanded path
[00:41:49] <les> ok
[00:42:03] <jmkasunich> if that path is nice, then moderate servo bandwidth can track it
[00:42:11] <jmkasunich> if it's nasty, then the servos get a workout
[00:42:28] <jmkasunich> our goal is to improve the path, regardless of the servo part of the picture
[00:42:32] <les> right...the spatial bandwidth of most shapes is very low
[00:43:08] <jmkasunich> exactly... if the spatial bandwidth of the part is X hz, but the generated path has components at 10X, then we have a TP problem
[00:43:42] <jmkasunich> your spiral - I bet the spatial bandwidth of that is only a few Hz even near the center
[00:44:17] <jmkasunich> btw, is the spiral just a bunch of straight lines, or are you using arcs or something?
[00:44:30] <les> Well TP is injecting unwanted High bandwidth things that are not needed to follow thwe path
[00:44:36] <jmkasunich> exactly
[00:45:03] <les> spiral is 3-d, xyz, straight g1 moves
[00:45:48] <jmkasunich> ok, so the theoretical path is a bunch of straight lines, and there is high frequency content in it (but at low amplitude, each line only makes a small change in angle)
[00:46:04] <les> yeah
[00:46:46] <les> increasing as it goes in
[00:47:02] <jmkasunich> you keeping line segment length fixed?
[00:47:11] <les> no
[00:47:16] <jmkasunich> if length is fixed, then frequency is constant and amplitude increases
[00:47:27] <les> delta theta is fixed
[00:47:36] <les> but it is an inward spiral
[00:47:42] <jmkasunich> if angle per segment is fixed, segments get shorter and frequency goes up, but amplitude remains fixed
[00:47:53] <les> so segment length decreases linearly
[00:48:10] <jmkasunich> right, so the second case is true, F goes up, A remains constant
[00:48:15] <les> segment tine does too
[00:48:23] <les> yeah
[00:48:26] <jmkasunich> right, F = 1/T
[00:48:32] <les> yeah
[00:49:00] <les> but...as fred says...TP does nor velocity adapt properly.
[00:49:11] <jmkasunich> since the PID and motors are a lowpass, the machine should actually get smoother (if the TP worked right)
[00:49:14] <les> so it breaks down into violent motions
[00:49:37] <jmkasunich> I'd give a lot to be able to scope those signals
[00:49:51] <les> That would be very good
[00:50:00] <les> We have not done that
[00:50:19] <les> I have a big box of sample AD accelerometers though
[00:50:35] <jmkasunich> you said you were using emc2... do you mean the HAL version, or the BDI-4 version?
[00:50:53] <les> BDI-4
[00:51:02] <les> Pauls's choice
[00:51:07] <jmkasunich> ok, that's basically emc1 in a different package
[00:51:15] <les> I'm sure you would prefer hal
[00:51:17] <les> heh
[00:51:18] <jmkasunich> duh, the HAL version doesn't have STG drivers yet
[00:51:28] <les> oh
[00:51:33] <jmkasunich> well for your testing, the HAL version has a build int 16 channel storage scope
[00:52:01] <les> well paul had to write an stg driver even for BDI-4 branch
[00:52:11] <jmkasunich> although I'd configure it as 4 channels, 4K points each
[00:52:18] <les> storage scope would be cool
[00:53:27] <jmkasunich> sampling at the servo rate, you'd get 4 seconds of motion (assuming 1KHz, what rate are you actually using?)
[00:53:50] <les> we aree down to 400 microseconds
[00:54:02] <les> period
[00:54:13] <jmkasunich> so 4K samples is 1.6 seconds of motion
[00:54:30] <les> that is plenty to see what's going on
[00:54:40] <Imperator_> les: have you tried the programm i send you
[00:54:56] <jmkasunich> hi Martin... didn't notice you were online
[00:55:03] <jmkasunich> how was the rest of your trip?
[00:55:04] <Imperator_> hi John
[00:55:13] <les> martin: no we have been thrashing about with bad decisions
[00:55:19] <Imperator_> maybe les can use the siemens card for testing
[00:55:42] <les> We VERY regretfully decided to abandon segmentqueue
[00:55:57] <Imperator_> jep i have read back
[00:56:07] <jmkasunich> I can send the seimens card to les
[00:57:00] <les> We had to step back and consider...in 5 years NO ONE (not even the author) could get it to work
[00:57:12] <les> many tried their hardest
[00:57:23] <jmkasunich> not a good sign
[00:57:24] <les> but there is a time to move on
[00:57:32] <Jymmm> les you didnt try hard enough... I dont see any buckets of blood!
[00:57:39] <les> haha
[00:59:03] <Imperator_> i think the profesionel controlers make a internal curve out of the g-code program, and then this is sub interpolated with lines and not with a spline like emc does. I think the reason is speed
[01:00:03] <les> Normal technology these days is cubic. High performance machines use quintic.
[01:00:56] <jmkasunich> I was just thinking and there is another issue...
[01:01:01] <Imperator_> emc uses splines in the subinterpolater, right ?
[01:01:46] <jmkasunich> think about the spiral... you know it's a spiral, I know it's a spiral, and we'd both be satisified if the interp blended over the full length of each segment, to make a smooth spiral
[01:01:53] <jmkasunich> but how does the TP know that
[01:02:24] <les> We think the subinterpolator does not do a lot.
[01:02:24] <jmkasunich> for all it knows, we want straight segments with just enough blend at each joint/corner to avoid the need to slow down
[01:02:44] <jmkasunich> agreed about the subinterp... it probably only confuses the issue
[01:03:00] <les> but... we are more getting towards programming ...
[01:03:42] <jmkasunich> anyway, the interp _has_ to assume that if the program contains straight segments, we want straight segments, and it should round them as little as possible
[01:03:46] <les> this is a good discussion...but I think I will hand it over to paul...he was watchin gthe simpsons on tv and gaging and stuff haha
[01:04:40] <jmkasunich> "as little as possible" means using the full power of the motors to very quickly change the direction of travel right around the corner, _not_ to use less force and make the turn over the entire length of the segment
[01:04:42] <Imperator_> i think the opposit is true, john
[01:05:34] <Imperator_> the interpolater has to calculate the curve that we want
[01:05:57] <Imperator_> we feed it with short straight lines, but we mean a curve
[01:05:58] <SWPadnos> there are G-codes for curve collowing vs. point following modes - the interpolator can switch modes based on that
[01:06:10] <les> les is now known as paul_c
[01:06:12] <Imperator_> maybe forgett the lines, take only the points
[01:06:16] <Jymmm> les : Tell paul_c DOH!
[01:06:46] <paul_c> tell _me_ What ??
[01:06:49] <jmkasunich> the only information it has to work with is the commands it gets.... set_line parallel to X, followed by set_line at a 2 degree angle from X, means make a straight line, then turn 2 degrees as sharply as possible and continue
[01:07:03] <Jymmm> paul_c It's a Simpson's thing =)
[01:08:10] <SWPadnos> right - but either at constant velocity, or stop at point and change direction
[01:08:19] <paul_c> even arcs get broken down in to straight lines..
[01:08:29] <jmkasunich> there are actually three modes according to the canonicals
[01:08:37] <jmkasunich> exact stop stops at each point
[01:08:54] <Imperator_> if you have many smal lines, then that means you want to have a spline trough this points, like the subinterpolater doeas
[01:08:58] <jmkasunich> exact_path isn't supposed to deviate from the path (which implies a stop unless the two segments are parallel)
[01:09:25] <jmkasunich> and finally continuous contouring which keeps moving thru the turn
[01:09:58] <SWPadnos> right - my point is that there are hints for the interpolator
[01:10:27] <SWPadnos> if you have a bunch of line segments that are supposed to make an N-gon, then set it to exact_path mode
[01:10:57] <SWPadnos> if you want curves, use continuous contour
[01:11:08] <jmkasunich> Imperator_: the problem with that is how does the TP decide "these are long lines, they should be straight with minimum radius (maximum effort) bends" and "those are short lines, they should be blended over their entire length"?
[01:11:50] <Imperator_> maybe we have only to take the points, and calculate a spline trough them, then we take the same points, and draw lines from point to point, then we look that the spline has not to be to far a way from that lines
[01:12:39] <Imperator_> there must be a easy algorithem for that
[01:13:05] <Imperator_> i would like to know how Siemens and Haidenhain does this
[01:13:55] <jmkasunich> when you guys were doing the spiral test, were you using tool offset?
[01:14:13] <Imperator_> i know that siemens has a complicatet algorithm, and that fails sometimes, Heidenhain does it very simple, and in real life that algorithm is at the moment the best, because it makes the best surfaces at the moment
[01:14:46] <Imperator_> the easy one i mean from Heidenhain
[01:15:47] <paul_c> jmkasunich: No tool offsets for the spiral test
[01:16:06] <jmkasunich> just making sure... offsets would introduce arcs between each segment
[01:16:15] <jmkasunich> s/could/would/
[01:16:49] <Imperator_> i think tool offsets are not used in such programs
[01:17:01] <Imperator_> we never do that
[01:17:11] <Imperator_> maybe it is impossible
[01:17:49] <jmkasunich> do you use the CAD/CAM program to compensate for the tool then?
[01:18:03] <Imperator_> jep
[01:18:24] <Imperator_> not to compensate it, you say with which tool you want to machine
[01:18:44] <Imperator_> then the CAM does the rest
[01:18:53] <jmkasunich> but if the tool is 6mm diameter, the toolpath must be 3mm away from the desired line
[01:18:57] <jmkasunich> that is compensation
[01:19:28] <jmkasunich> if your endmill wears down and is resharpened to 5.95mm, you must go back to the CAM to correct the path?
[01:19:54] <Imperator_> our steriolothographie machine must use offsets for the laser pathes, and if you zoom in it looks terrible, because it has to delete some parts and so on
[01:20:45] <Imperator_> you dont have to be away 3mm from the line, you have to be 3mm away from the surface of the model
[01:21:22] <jmkasunich> right--- I was thinking of the simplified case, straight end mill and 2D profiling
[01:21:39] <jmkasunich> ball-end mill and 3D profiling is the same thing only in 3 dimensions
[01:22:24] <Imperator_> the CAM program knows what part it has to produce and you say what tools it has to use, and some other things, then it does the rest
[01:22:28] <Imperator_> jep
[01:23:15] <Imperator_> even end mills are ball milles, exept the special case that you want to machine a surface parallel to xy-plane
[01:23:34] <Imperator_> :-)
[01:24:42] <Imperator_> i write a terrible english
[01:24:55] <Imperator_> after 30h of traveling
[01:25:19] <jmkasunich> your english is still much better than my german, so don't apologise for it
[01:25:41] <Imperator_> and 2h of searching my credit card in my luggage
[01:25:42] <jmkasunich> speaking of traveling, how did you like New York
[01:25:43] <Imperator_> :-)
[01:26:06] <Imperator_> it is not as big as i thought
[01:26:11] <Imperator_> very compact
[01:26:40] <Imperator_> it is cool to walk trough, because you don't realy take care about the cars
[01:27:03] <Imperator_> everybody walks there over red trafic lights
[01:27:24] <jmkasunich> driving there is not something I would want to do
[01:27:33] <Imperator_> jep
[01:27:55] <Imperator_> but moving arround by food and sub way makes fun
[01:28:33] <Imperator_> the view from the empire state building by night was great
[01:28:33] <SWPadnos> it's really fun to take a cab ride
[01:28:41] <SWPadnos> (while the driver reads the newspaper)
[01:28:48] <Imperator_> :-)
[01:29:21] <Imperator_> i wanted to ride with a bike there
[01:29:42] <Imperator_> but they would like to have 60$ per day for a old mountain biek
[01:29:44] <Imperator_> bike
[01:30:02] <SWPadnos> dangerous, plus it's likely to get stolen )or at least parts of it)
[01:30:23] <Imperator_> not if you sea the chains they use :-)
[01:30:30] <SWPadnos> yeah - that's what I mean
[01:30:33] <Imperator_> 15kg bike 20kg chain
[01:31:01] <SWPadnos> yeah - a real workout
[01:31:58] <Imperator_> new york is ok for the five days
[01:31:59] <jmkasunich> taxi vs. bike is not something I would want to be on the wrong side of
[01:32:30] <Jymmm> bike taxi
[01:32:34] <Imperator_> it is not like in gaithersburg for example there you are the looser on a bike
[01:32:53] <Imperator_> in NYC the cars cant realy drive
[01:33:05] <Imperator_> only one ways
[01:33:11] <jmkasunich> they can still go fast enough to squash a biker
[01:33:19] <jmkasunich> if not the cars, then the busses will do it
[01:33:19] <Imperator_> year
[01:33:36] <Imperator_> jep
[01:33:46] <Imperator_> that makes it funny
[01:36:21] <jmkasunich> Paul... I'm trying to figure out how to detect the kernel module extension (.o or .ko)
[01:36:46] <paul_c> rtai-config --module-ext
[01:37:00] <jmkasunich> ok, that sounds easy
[01:37:34] <jmkasunich> I was looking at section 3.3 of configure.in which looks for rtai_shm.o or mbuff.o
[01:37:45] <jmkasunich> thinking I'd have to locate one of those files and split the name
[01:37:55] <jmkasunich> those tests will need to be changed anyway
[01:38:07] <paul_c> replace .o with .*
[01:46:51] <Imperator_> ok it's 3:45 here time to leave
[01:47:01] <Imperator_> cu
[01:48:55] <jmkasunich> it's not safe to assume any RTAI-24.X system will use .o, or is it? What about kernel 2.4.27 and higher?
[01:49:19] <jmkasunich> (the rtai 24.x config script "realtime-config" doesn't have a module extension option
[01:49:55] <paul_c> all 2.4.xx and earlier kernels will be using .o
[01:50:56] <jmkasunich> even tho 2.4.27 can use kbuild? or is .ko determined by the kernel version, not by whether kbuild was used to build it?
[01:51:42] <paul_c> .ko is ${minor} related.
[01:52:12] <paul_c> major=2 ; minor=6
[01:52:27] <jmkasunich> well that makes things a wee bit simpler than I was expecting
[01:53:23] <paul_c> if rtai-config returns an error or .o, then assume 2.4 or earlier
[01:56:24] <paul_c> rtai-config --module-ext also returns an error with RTAI-3.0
[01:57:15] <jmkasunich> which RTAI is on BDI-4.20? I thought that was 3.0, and it returns .ko as expected
[01:57:32] <paul_c> 3.1 or 3.2
[01:57:57] <jmkasunich> I see
[01:59:16] <jmkasunich> does rtai-config --module-dir work on 3.0?
[01:59:47] <paul_c> yes
[02:00:25] <jmkasunich> so in the case of rtai 3.0, I could get the module dir, then look in it for *.o or *.ko, and set the extension based on which one I find
[02:06:09] <paul_c> checking....
[02:08:04] <paul_c> RTAI-3.0 will always be .o module extension
[02:08:18] <jmkasunich> it was never used with 2.6?
[02:08:29] <paul_c> no 2.6 patch
[02:08:32] <jmkasunich> cool
[02:11:04] <paul_c> RTAI-3.1 uses --module-ext
[02:12:59] <jmkasunich> so I can either check rtai-config --version, or just do rtai-config --module-ext and detect error return
[02:13:37] <CIA-4> 03paul_c * 10emc2/directory.map: Update the directory map to reflect moving of the configure & makefiles out of the top level directory.
[02:13:38] <paul_c> cut the multiple stages and just use --module-ext
[02:13:49] <paul_c> if you get an error, .o is used.
[02:14:18] <jmkasunich> any tricks for detecting error? I was thinking about something like this which seems to work but is convoluted:
[02:14:50] <jmkasunich> MODULEEXT=`$RTS --module-ext 2>/dev/null || echo .o`
[02:16:20] <paul_c> what are you expecting the || to do ?
[02:16:39] <jmkasunich> the echo runs only if the rtai-config fails
[02:16:52] <paul_c> you hope.
[02:16:56] <jmkasunich> tried it on the command line, seems to work
[02:17:11] <jmkasunich> but that's why I asked... it seems kind of iffy
[02:17:16] <paul_c> tried it on the server at home.... It doesn't.
[02:17:31] <jmkasunich> what happens there?
[02:17:44] <paul_c> zip.
[02:18:11] <jmkasunich> that system is running RTAI-3.0?
[02:18:54] <jmkasunich> on 3.1, the rtai-config (aka $RTS) should work and give .ko (or maybe .o)
[02:19:17] <jmkasunich> on 3.0 it should fail with an error return and || should run the next command, the echo
[02:21:20] <jmkasunich> or should I be using $? to check the return status?
[02:30:21] <jmkasunich> is || (and &&) unique to bash? I don't understand why it didn't work on your server
[02:30:43] <jmkasunich> foo && bar means run foo, then run bar if foo succeeded
[02:30:49] <jmkasunich> foo || bar means run foo, then run bar if foo failed
[02:37:15] <SWPadnos> Gotta run - see you guys later
[02:37:21] <jmkasunich> goodnight
[02:39:21] <CIA-4> 03paul_c * 10emc2/src/ (Makefile.inc.in configure configure.in): Extend the config tests to include the kernel module extension - This will be used with kbuild for 2.6 installs
[02:40:14] <jmkasunich> I was doing the same thing here (or did you decide it was simpler to do it yourself than to help me?)
[02:41:32] <paul_c> Figured while I was logged into the box at home, I might as well do a commit.
[02:42:12] <jmkasunich> I see a bug (maybe)
[02:42:23] <jmkasunich> on fail, you set MODEXT to "o"
[02:42:41] <jmkasunich> but on success, rtai-config gives ".ko", not "ko"
[02:43:04] <jmkasunich> either need to strip the . from .ko, or add it to o
[02:43:04] <paul_c> OK, change it to .o
[02:44:59] <CIA-4> 03paul_c * 10emc2/src/ (configure configure.in): Missed a dot - Darned typos..
[02:45:38] <paul_c> howzat ?
[02:46:37] <jmkasunich> bootiful
[02:46:48] <jmkasunich> I'm seeing something else here that is strange tho
[02:46:51] <jmkasunich> (not the code)
[02:46:53] <paul_c> not that the module extension really makes a difference...
[02:47:09] <paul_c> The test will be for ko anyway...
[02:47:10] <Phydbleep> jmkasunich: Is it in a mirror?
[02:47:29] <Phydbleep> * Phydbleep couldn't resist.. Sorry. :)
[02:47:30] <jmkasunich> I just did a cvs up -dP to get your changes, which appeared to work find
[02:47:42] <paul_c> s/d/e/
[02:47:57] <jmkasunich> then I did a cvs diff just to make sure I didn't have anything strange, and got tons of difference on configure
[02:48:19] <paul_c> rm -f configure
[02:49:26] <jmkasunich> that fixed it (no surprize) but doesn't even begin to explain it
[02:49:52] <paul_c> had you run autoconf your end ?
[02:49:59] <jmkasunich> yes
[02:50:08] <paul_c> there you go...
[02:50:11] <jmkasunich> (I added the ".", then ran autoconf
[02:50:28] <paul_c> bet you also had some conflicts in the update.
[02:50:40] <jmkasunich> nope - i was expecting to, but didn't
[02:51:09] <paul_c> probably different versions of autoconf then.
[02:51:18] <jmkasunich> I also expected that running autoconf here with only one line in configure.in changed would give me a configure with only one or two lines changed,
[02:51:20] <jmkasunich> could be
[02:51:49] <jmkasunich> which brings up an interesting point... minor changes to configure.in could cause large differences in configure depending on who does them
[02:52:42] <paul_c> As far as I'm concerned, configure shouldn't be part of a diff - It is an autogenerated file...
[02:53:11] <jmkasunich> does that mean configure shouldn't be in CVS?
[02:53:38] <paul_c> 'pends who you talk to...
[02:54:23] <jmkasunich> I think it should be in CVS, so folks can do a cvs checkout (or eventually get a tarball) and start with ./configure, then shouldn't have to run (or even have) autoconf
[02:54:39] <jmkasunich> s/then/they
[02:55:16] <paul_c> others would contend that CVS is a developer's tool and usrs shouldn't be checking out from there..
[02:56:12] <jmkasunich> correct in principle, but in practice, unless we start doing frequent tarballs... it's gonna happen
[02:56:49] <paul_c> The release manager needs to take a more active role.
[03:00:11] <jmkasunich> who is the release manager anyway
[03:01:21] <paul_c> dunno - Lost track.
[03:03:35] <paul_c> well... I'm gonna have to leave you.
[03:04:04] <paul_c> I'm sure you can manage the rest of the 2.6 makefile stuff.
[03:04:12] <jmkasunich> I'm gonna move your changes over to the kbuild branch and call it a night
[03:04:23] <jmkasunich> yeah, right! :-(
[03:04:42] <paul_c> I thought we were doing it in HEAD.
[03:05:23] <jmkasunich> todays change was very safe, but I suspect as time goes on there will be changes that at least temporarily break things for one or more systems
[03:05:58] <jmkasunich> folks should test before they commit, but if they test on a 2.6 box they don't know if they broke something on 2.4, and vice-versa
[03:06:03] <paul_c> It shouldn't break any pre-2.6 build.
[03:06:17] <jmkasunich> shouldn't, no, but nobody's perfect
[03:06:31] <jmkasunich> I certainly will make some mistakes during this process
[03:06:41] <jmkasunich> the compile farm will tell me about them and I can fix them
[03:07:31] <jmkasunich> I'm hoping the branch is only active for a couple weeks, then we merge it and go on with life
[03:09:02] <paul_c> well... g'night.
[03:09:08] <jmkasunich> goodnight
[03:09:12] <paul_c> paul_c is now known as les_away
[03:22:57] <CIA-4> 03jmkasunich 07kbuild-0-1 * 10emc2/directory.map: Merged Pauls MODEXT changes into the kbuild-0-1 branch. Work on the build system should be done in this branch to avoid accidentlly breaking HEAD. The compile farm is set up to run test compiles on this branch
[03:23:04] <CIA-4> 03jmkasunich 07kbuild-0-1 * 10emc2/src/ (Makefile.inc.in configure configure.in): Merged Pauls MODEXT changes into the kbuild-0-1 branch. Work on the build system should be done in this branch to avoid accidentlly breaking HEAD. The compile farm is set up to run test compiles on this branch
[04:00:21] <CIA-4> 03jmkasunich 07kbuild-0-1 * 10emc2/src/ (configure configure.in):
[04:00:21] <CIA-4> Revised MODEXT to work with RTLinux: rtl-config writes a usage message to stdout
[04:00:21] <CIA-4> when called with --module-ext, which was mistaken for valid output. Configure
[04:00:21] <CIA-4> now checks the return status of rtl-config, instead of simply looking for some
[04:00:21] <CIA-4> non-blank output.
[04:25:54] <CIA-4> 03jmkasunich 07kbuild-0-1 * 10emc2/src/ (configure configure.in): My previous fix was stupid, it simply appended the correct value to the undesired text. The new fix replaces the text with the correct value.
[04:34:28] <CIA-4> 03jmkasunich * 10emc2/ (4 files in 3 dirs): merged a fix from kbuild-0-1 branch
[05:34:22] <A-L-P-H-A> anyone around?
[05:34:34] <A-L-P-H-A> I got an STL model... and I can't seem to get any CAM program to make the gcode for me.
[06:33:01] <Jymmm> STL == Seattle ?
[06:33:33] <Phydbleep> Slower Than Light?
[06:34:03] <Phydbleep> * Phydbleep has yet to get a FTL model to work..
[06:34:26] <Jymmm> Funky Tail Light
[06:34:52] <Phydbleep> Yeah, Severe red-shift. :)
[06:36:27] <Phydbleep> You have to start with a white tail-light so it's red at velocity. :)
[06:38:36] <Jymmm> lol
[06:39:55] <Phydbleep> Frack, Frack! FRACK!
[06:40:05] <Phydbleep> The CIA is looking at re-locating to Denver????
[06:40:21] <Phydbleep> Are they expecting to lose DC to a "convenient" "terror incident"?
[06:40:37] <Jymmm> not DC, VA
[06:40:44] <Jymmm> or is that FBI
[06:41:06] <Phydbleep> Both..
[06:41:19] <Phydbleep> Langley is about 10 mins from DC.
[06:41:26] <Jymmm> ah
[06:41:28] <Phydbleep> Or so I've heard.
[08:18:46] <Jymmm> anyone awake?
[08:28:45] <Phydbleep> Nope... You're just hallucinating...
[08:29:07] <Jymmm> whats a more common name for a "cam bolt" ?
[08:29:18] <Phydbleep> * Phydbleep is just a figment of your warped imagination..
[08:29:53] <Phydbleep> "cam Bolt" Like to tighten a Phase-II toolpost?
[08:30:22] <Phydbleep> Bolt with a cammed out surface in the middle?
[08:30:44] <Phydbleep> Scratch that..
[08:30:52] <Phydbleep> Bolt with a cam cut in the middle?
[08:31:05] <Jymmm> I suppose... it's sorta offset and usually has a doohicky (or two) that when twisted goes offset to bind
[08:32:08] <Jymmm> the centerpoint is 'offset' a bit
[08:32:32] <Phydbleep> logger_aj: bookmark
[08:32:32] <Phydbleep> See http://193.226.12.129/irc/irc.freenode.net:6667/emc/2005-05-07#T08-32-32
[08:32:59] <Phydbleep> Quickest way to find a browser window... :)
[08:33:43] <Phydbleep> http://homepage.ntlworld.com/v.ford/qctp4.jpg
[08:33:54] <Phydbleep> Like the one in the pic?
[08:33:59] <Jymmm> yeah
[08:34:28] <Phydbleep> What are you trying to do? make one?
[08:34:36] <Jymmm> No, buy some
[08:34:46] <Phydbleep> Good Luck?
[08:34:58] <Jymmm> ah, so they're custom stuff.
[08:35:17] <Phydbleep> Yeah, Hardcore custom usually..
[08:35:49] <Jymmm> oh, didn't realize it was THAT special.
[08:36:00] <Phydbleep> And thats just odd.. ^^^^^^ :)
[08:36:47] <Jymmm> what is?
[08:37:15] <Phydbleep> Yeah, Quickest way to get a set is a lathe and a custom fixture to gring them.
[08:37:43] <Phydbleep> The way 'custom' lined up so nicely in both lines.. That was odd. :)
[08:37:52] <Jymmm> well, I have neither, so next bright idea....
[08:37:56] <Phydbleep> s/gring/grind
[08:38:12] <Phydbleep> Mill?
[08:38:27] <Jymmm> nope
[08:38:32] <Jymmm> drillpress
[08:38:41] <Phydbleep> That's a start..
[08:38:44] <Phydbleep> Brain?
[08:38:51] <Jymmm> in freezer
[08:39:03] <Phydbleep> Hehehe. ROFLMAO!
[08:39:05] <Jymmm> prevent Drain Bamage
[08:40:01] <Phydbleep> Hehehe.... I'm a firm believer that refrigeration prevents spoilage in fruits/veg/cats/kids.. :)
[08:40:25] <Jymmm> it's a lie, just gives you freezer burn
[08:40:59] <Phydbleep> No.. You kepp them @ 36F and they don't freeze. :)
[08:41:39] <Jymmm> I'm trying to design a bearing block, but I want to make one bearing semi adjustable, but having problems figuring that part out
[08:41:48] <Phydbleep> Although whem you open a bottle of Coke, it tends to grow ice crystals..
[08:41:56] <Jymmm> the cam bolt would have worked.
[08:42:13] <Phydbleep> Saw/file?
[08:42:33] <Jymmm> was thinking I could use set screws, but will run out of thread to put it into.
[08:42:59] <Jymmm> setscrew pushing againest bearing shaft
[08:43:04] <Phydbleep> cut the cam from 13mm plate and use a couple of pins, NOT set scews, to hold it.
[08:44:15] <Phydbleep> Hmm drillpress.. Got an angle grinder?
[08:44:43] <Jymmm> been thinking about getting a cheapy 4/5" hand grinder
[08:44:48] <Jymmm> 4.5"
[08:45:12] <Phydbleep> Cut the cam from 1/4 plywood and run a roller fixed to the grinder on it.
[08:45:29] <Phydbleep> Free running roller.
[08:46:02] <Jymmm> http://www.harborfreight.com/cpi/ctaf/Displayitem.taf?itemnumber=31309
[08:46:25] <Phydbleep> Cut the cam oversize and hinge the grinder at the bottom.
[08:46:53] <Phydbleep> Yeah, I get those for ~10 here. :)
[08:46:58] <Phydbleep> $10
[08:47:09] <Phydbleep> ~$10
[08:48:01] <Phydbleep> Get the idea about the grinder mount?
[08:48:14] <Jymmm> actually no (sorry)
[08:49:07] <Phydbleep> Seel the holes in the grinder body for the handle mount?
[08:49:17] <Jymmm> yep
[08:49:17] <Phydbleep> s/Seel/See
[08:50:39] <Phydbleep> (1) Make an arm to mount the grinder on.. You want a hinge at the bottom to bolt to the table..
[08:51:17] <Phydbleep> (1a) At the top is a rob with a bearing to run against the plywood cam..
[08:51:24] <Phydbleep> s/rob/rod
[08:53:19] <Phydbleep> If you make the whole thing to the proper proportions it should be a straight X:Y (16:4 18:6 etc) to scale the cam
[08:54:19] <Phydbleep> Stic the cam on the bolt, stick the bolt in the drillpress, Bolt the arm to the table..
[08:54:34] <Jymmm> http://www.harborfreightusa.com/usa/itemdisplay/displayItem.do?itemid=40613&CategoryName=null&SubCategoryName=null
[08:55:16] <Phydbleep> That would work too.. :)
[08:55:49] <Phydbleep> Add the tracking roller and make the roller wider than you want the cam.
[08:56:39] <Phydbleep> Run at the lowest speed on the press and take the return spring off of the cut-off kit.
[08:56:41] <Jymmm> so the plywood cam is being used as a guide?
[08:57:24] <Phydbleep> Yeah.. That's the shape you want your cam.. You want offset mounted round. :)
[08:58:14] <Phydbleep> Use a feather touch on the grinder and run the Z up and down. :)
[08:59:12] <Jymmm> I'm close, but the picture in my head is still a bit fuzzy
[08:59:22] <Phydbleep> Your're better off with the grinder at a ~60 degree angle dure to blade cut/dia
[08:59:29] <Phydbleep> s/dure/due
[09:00:20] <Phydbleep> That's what this frikken channel needs.. A java whiteboard. :)
[09:00:31] <Jymmm> there we go
[09:00:41] <Phydbleep> Phydbleep has changed the topic to: That's what this channel needs.. A java whiteboard. :)
[09:00:41] <ChanServ> ChanServ has changed the topic to: Welcome to the Enhanced Machine Control forum - Support and development of a linux based CNC control. | Home page www.linuxcnc.org | Regular Developer's meetings every Sunday between 14:00 & 18:00 GMT | General linux discussions and support the rest of the week.
[09:01:18] <Jymmm> topic is locked
[09:01:19] <Phydbleep> Hehehe... Now it'll show up in the chanserv logs too. :P
[09:02:25] <Phydbleep> Yeah, but the logging is automatic.. :)
[09:03:58] <Phydbleep> Sorry, Was distracted by a cannibal/maniac, french kissing a severed head..
[09:04:17] <Jymmm> O_o
[09:04:42] <Phydbleep> "Jeepers Creepers" On tv..
[09:05:06] <Jymmm> ah
[09:05:57] <Phydbleep> "Random button puncher escapes info-mercial.. No film @ 11"
[09:06:04] <Phydbleep> Hehehe... :)
[09:06:41] <Phydbleep> Hang on and I'll see if I can sketch the jig.
[09:06:51] <Jymmm> k
[09:20:06] <Phydbleep> OK... I think i got it.
[09:23:03] <Phydbleep> Jymmm: Wake up and grab that.
[09:23:16] <Jymmm> no dcc
[09:23:28] <Phydbleep> Ah. :\
[09:23:32] <Phydbleep> http?
[09:23:33] <Jymmm> beep beep my ass
[09:24:08] <Jymmm> ya, I have a browser
[09:24:10] <Phydbleep> There are SO many ways I could respond to that....
[09:24:42] <Phydbleep> None of them suitable for a family oriented channel
[09:26:58] <Phydbleep> http://www.nccabq.com/Network%20Trash%20Folder/cammer.bmp
[09:28:05] <Jymmm> ah, ok.
[09:28:37] <Phydbleep> Z1/Z2 are a function of the length and the angle and the dia of the wheel
[09:28:57] <Phydbleep> grinding wheel that is..
[09:29:42] <Phydbleep> you could use the cut-off for roughing it out and file the last bits.
[09:31:31] <Jymmm> I'm not sure what you call it, but I have this circle cutter for my drilldress that's adjustable. I'm wondering if I could attach a roller to it (instead of a cutter) and have that engage the grinder
[09:31:48] <Phydbleep> Either way.. The lighter the touch of the grinder, the longer the bearings in the press will last. :)
[09:32:37] <Phydbleep> Fly cutter? plug with a crossbar and a tooth?
[09:32:51] <Jymmm> yeah
[09:34:17] <Phydbleep> Not any way that I can figure..
[09:35:23] <Jymmm> Sears item #00925293000
[09:35:46] <Phydbleep> Mkae sure to index mark the bolt and the ply-cam otherwise it's a bitch to resync.
[09:36:09] <Jymmm> heh, will do
[09:36:25] <Jymmm> thanks for the idea!
[09:37:13] <Jymmm> in the interum, I think I found an alternative way of making this bearing block, and now it'll adjut from 1/2" to 3/4" diameter rail
[09:37:35] <Jymmm> maybe even 1"
[09:37:35] <Phydbleep> That would be ok to cam a rod with, you could attach the ply-cam to the arm.
[09:37:56] <Jymmm> I mean w/o the use of a cam.
[09:38:14] <Jymmm> I had to think outside the box...
[09:38:18] <Phydbleep> I was talking about the fly cutter.
[09:38:52] <Jymmm> ah, ok. an dthe fly cutter has a drill bit that is held by set screws
[09:38:59] <Jymmm> could just toss the bolt in there.
[09:39:10] <Phydbleep> use a bolt>nut>bearing>nut ?
[09:39:59] <Jymmm> hmmm, ok.
[09:40:15] <Phydbleep> That would screw the threads if you weren't careful.
[09:41:04] <Jymmm> sawed off bolt>coupling nut> bolt to be cammed
[09:41:17] <Phydbleep> Actually bolt threaeded hole>space>nut>nut>bearing>nut>nut.
[09:42:31] <Phydbleep> Threaded hole in the main part, bearing in the adjustable bit.
[09:44:49] <Phydbleep> That gives you a lock for push/pull.. Used that in a C64 disk drive to set track0 for the head stepper.. 2-56 screw/nuts and brass tube for a bushing.
[09:45:54] <Jymmm> you modified a C64 5.25" dish drive?
[09:45:58] <Jymmm> disk
[09:46:35] <Phydbleep> Yeah.. The old copy protection would throw them out of alignment all the time..
[09:47:08] <Jymmm> the lil stickers you mean?
[09:47:21] <Jymmm> write protext
[09:47:25] <Jymmm> protect
[09:48:28] <Phydbleep> 1985.. New drive was $150.. Just the drive, not the interface board/case.. No, Like hte laser burned holes or bad sectors that were deliberate.
[09:48:46] <Jymmm> ah
[09:49:19] <Phydbleep> Caused the drive to hammer the head against the stop and would move the stepper.
[09:50:24] <Phydbleep> Hehehe... I could throw in a test disk, tweak the knob and set the heads in ~15 secs. :)
[09:52:02] <Jymmm> that works =)
[09:53:54] <Phydbleep> Yeah.. Pissed the guys at the repair shop off.. I was giving away copies of my test disk and drawings for the mod.. Screwed them out of $75 ( ~ once a week, No guaranty) realign jobs. :)
[09:54:47] <Jymmm> $30 and a 90 day guarntee i could see as reasonable. but $75, fuck them
[09:55:09] <Phydbleep> $75/3 days max. :\
[09:55:28] <Jymmm> that's just wrong.
[09:56:20] <Phydbleep> And after about the 3'd/4'th time it was "So sorry, Cant realign this one anymore.. New drive chassis is $150, Rebuilt is $130.
[09:56:52] <Jymmm> *sigh*
[09:58:19] <Phydbleep> exchange even.. They would realign/locktite/dust the exchanges and screw somebody else every other day.
[09:58:43] <Phydbleep> Then all of a sudden they lost all the hardcore gamer biz.. ROFL!
[09:59:12] <Jymmm> C64 had hard core gamers?!
[10:00:12] <Phydbleep> Took them forever to figure out why all the gamers were suddenly at the hobby shop buying screws/nuts instead of getting screwed. :)
[10:02:46] <Phydbleep> gamers were also hackers/phreakers/trouble back then.. Hehehe... Ah, Blue-boxes..
[10:03:14] <Jymmm> you rebel you!
[10:05:41] <Phydbleep> Hehehe.. Took them forever to get decent passwords on the dot matrix sign @ the local bank.
[10:06:29] <Phydbleep> The time is: Half past lunch.. The temp is: FRIKKEN COLD!
[10:06:57] <Phydbleep> WOW! Check out the rack on the blonde.
[10:07:03] <Jymmm> lol.... next stop, the current flight sttus at the local airport
[10:08:05] <Jymmm> DELAYED, DELAYED, DELAYED, DELAYED, DELAYED, CANCELED, CANCELED, CANCELED, CANCELED, CANCELED, CANCELED, HIJACKED, CRASHING, CRASHING, CRASHING, CRASHING,
[10:08:21] <Phydbleep> Nope.. Never messed with that one.. Only played with the sign because it was a separate system from the main.. ROFLMAO!
[10:08:23] <Jymmm> OUT OF FUEL
[10:10:24] <Phydbleep> You forgot "Out of booze in cockpit"
[10:10:36] <Jymmm> PILOT SHITFACED
[10:10:50] <Phydbleep> LMAO!
[10:11:30] <Phydbleep> PILOT BAILED
[10:11:43] <Phydbleep> GOOD LUCK
[10:11:50] <Jymmm> HAVE A NICE DAY
[10:12:01] <Jymmm> YOUR FUCKED
[10:12:08] <Phydbleep> K Y A G
[10:12:32] <Jymmm> Place your head between your legs and KYAG
[10:12:39] <Phydbleep> DID YOU REMEMBER INSURANCE?
[10:12:43] <Phydbleep> ROFL!
[10:12:51] <Jymmm> GOT WILL?
[10:13:12] <Phydbleep> ROFLMAO! "GOT CHUTE?"
[10:14:17] <Phydbleep> * Phydbleep wants to sneak up on the local 50" lumberjack statue with a "GOT WOOD?" banner..
[10:18:14] <Phydbleep> Jymmm: Get it to work?
[10:20:02] <Jymmm> whats that?
[10:20:09] <Phydbleep> The new idea.
[10:20:14] <Phydbleep> No cam.
[10:20:36] <Jymmm> I think so, Drawing it up now.
[10:21:20] <Phydbleep> Cool. :)
[10:21:51] <Jymmm> just trying to figure out an angle for the slot.
[10:23:03] <Jymmm> See, originally I was trying to "push down" on the bearing shaft. Which won't work, becase I wont have any threads.
[10:23:25] <Phydbleep> 45?
[10:24:04] <Jymmm> Now, what I've done is left the bearing shaft sit in a angled channel, then have a bolt puch againest it to tighten down.
[10:24:16] <Jymmm> it being the bearing shaft
[10:24:42] <Jymmm> I think 45 is too steep. maybe 30
[10:24:53] <Phydbleep> How big is the shaft?
[10:25:00] <Jymmm> ~8mm
[10:25:15] <Jymmm> diam
[10:25:21] <Phydbleep> Too small for what i was thinking.
[10:25:36] <Phydbleep> crossdrill annd tap.. Pull. :)
[10:25:58] <Jymmm> about an inch to an inch and a half long.
[10:26:41] <Phydbleep> Cable nuts/clamps!
[10:26:53] <Jymmm> KISS
[10:27:21] <Phydbleep> Like a itty bitty muffler clamp / U-bolt..
[10:28:02] <Jymmm> wrong direction though.
[10:28:41] <Phydbleep> That's 4 holes to do both ends of the shaft and is a pull which is easier to adjust.
[10:30:25] <Phydbleep> Is this for a drive belt/pulley set?
[10:31:03] <Jymmm> No, 3 skat bearing 120 deg apart riding on a rail
[10:33:07] <Phydbleep> Ah.. OK. :)
[10:34:32] <Phydbleep> * Phydbleep was in shock after seeing Johnny Depp in Willy Wonka makeup... Scarey.. Looks like Michael Jackson.. *SHUDDER*
[10:35:39] <Phydbleep> Jymmm: What have you got for a mount?
[10:36:12] <Jymmm> thats actually what I'm designing, the rest just bolts up to it.
[10:36:24] <Phydbleep> * Phydbleep had a very rude thought about bearing adjusters..
[10:36:46] <Jymmm> rude?
[10:37:17] <Phydbleep> What about.. Make the shaft ~1/2" longer and reverse the setscrews with a lever arm.
[10:38:08] <Phydbleep> Cut the arms from 1/4" plate and make the pivot closer to the shaft.. Give you fine control. :)
[10:39:06] <Phydbleep> Hehe.. Big 3 lobed cam around the slide rod would get all 3 at once. :)
[10:39:18] <Phydbleep> s/3/6
[10:40:04] <Jymmm> Well, I'm trying to keep it simple. If I get too far out there, it'll be a mfg nightmare.
[10:41:27] <Phydbleep> What i'm thinking is pretty simple..
[10:47:54] <Jymmm> Well, so far between cutting, drilling, and tapping, this already is getting a bit rough.
[10:48:02] <Jymmm> s/rough/complex
[10:49:43] <Phydbleep> This should be (per bearing) 2 arms, 1 pivot bolt, 2 adjuster screws, 2 tabs for screws.
[10:50:28] <Phydbleep> Using angle re-bent to 120
[10:50:35] <Phydbleep> degrees
[10:50:39] <Phydbleep> ?
[10:51:14] <Jymmm> only one bearing will be adjustable, the other two are fixed and using a screw as the shaft and mount.
[10:51:30] <Phydbleep> * Phydbleep re-invents the cat-apult and removes a keyboard fault.. MROW!
[10:52:32] <Phydbleep> So.. 2 arms, 1 pivot bolt, 2 adjuster screws, 2 tabs for screws. per bearing unit. :)
[10:52:55] <Jymmm> one arm total
[10:53:37] <Phydbleep> 2 arms.. Need to move both ends of the shaft or use a yoke to hit both.
[10:54:38] <Jymmm> the shaft will sit in a groove/channel. Then at the end of the chanel will be a screw to push againest the shaft.
[10:55:20] <Phydbleep> You want to keep the bearing square/centered or it will bind.
[10:55:59] <Jymmm> * Jymmm nods
[10:58:32] <Jymmm> Well, I think I need to sleep on this a bit. thanks for the ideas, appreciated!
[10:59:33] <Jymmm> hasta!
[12:05:55] <anonimasu> morning everyone
[12:33:30] <Phydbleep> Morning? Oh.. Time for me to fall over then. :)
[12:47:19] <anonimasu> heh
[12:47:38] <anonimasu> * anonimasu has begun working
[14:51:10] <alex_joni> greetings
[14:51:13] <alex_joni> anyone home?
[15:00:50] <anonimasu> yeah
[15:01:06] <alex_joni> hey an0n
[15:01:13] <alex_joni> * alex_joni is working on kbuild.. neat stuff
[15:01:41] <anonimasu> nice
[15:01:51] <alex_joni> yup
[15:02:38] <anonimasu> I just finished with some work going to slack now
[15:03:10] <alex_joni> slackware?
[15:03:11] <anonimasu> I am consideting trying emc2 once more
[15:03:14] <anonimasu> nope slacking ;)
[15:03:19] <alex_joni> heh
[15:05:55] <rayh> kbuild is good. Thanks Alex.
[15:06:06] <alex_joni> hey rayh
[15:06:12] <alex_joni> no need to thank me for ;)
[15:06:19] <rayh> Hi Alex.
[15:06:20] <alex_joni> I ain't got it working yet :D
[15:06:40] <alex_joni> but .. with paul's help I think I'll get it there (not to forget JMK's work)
[15:06:46] <rayh> I like the stuff that you and SWP did on that for testing.
[15:07:13] <rayh> I'm editing a tkio for this lathe.
[15:07:14] <alex_joni> oh on the aunt tillie config?
[15:07:23] <alex_joni> nice
[15:07:23] <anonimasu> :)
[15:07:24] <rayh> Matt has a plan.
[15:07:29] <alex_joni> how's Matts
[15:07:42] <rayh> Yes the aunt tillie stuff.
[15:07:50] <alex_joni> rule the world?
[15:07:55] <alex_joni> :D
[15:08:18] <rayh> I think that we can impose it both on the emc make and the configure.
[15:08:27] <alex_joni> (that's from some cartoons, there was a dude called The Brain, who always had a plan to rule the world)
[15:08:32] <anonimasu> alex_joni: isnt that the omnipresent plan ^__^
[15:08:38] <anonimasu> pinky & the brain
[15:08:42] <alex_joni> an0n: should be
[15:08:48] <alex_joni> yup.. that's them
[15:09:02] <alex_joni> rayh: care to explain on that plan?
[15:09:03] <rayh> Yup. That's em.
[15:09:52] <rayh> I've always thought that a developer or integrator should only have to compile the parts of EMC that were needed for a specific project.
[15:10:27] <rayh> That way if something like ppmc or vital did not build it would not bother someone making for Servo-to-go.
[15:10:35] <alex_joni> so you think on a 'make' we should first run a 'make configure' (with kernel tools: xconfig, qconfig, menuconfig) to figure out what the user wants?
[15:11:10] <rayh> gnau
[15:11:11] <alex_joni> ideally this would also produce a valid .ini file for his new build
[15:11:17] <anonimasu> * anonimasu nods
[15:11:36] <alex_joni> maybe with hal & all other components already configured
[15:11:44] <rayh> You got it exactly.
[15:11:57] <alex_joni> well.. nice to have
[15:12:03] <alex_joni> difficult to get there :D
[15:12:23] <alex_joni> we shall call it the BDC
[15:12:31] <rayh> I've not thought very far into the hal config but believe that it can be handled by kbuild as well.
[15:12:36] <alex_joni> the Brain Dead Compile (and Config)
[15:12:37] <alex_joni> :D
[15:12:45] <rayh> Nice.
[15:12:48] <alex_joni> I think so..
[15:12:56] <alex_joni> was kidding ;)
[15:13:09] <rayh> Kbuild allows for limited HTML in it's help screen.
[15:13:16] <alex_joni> * alex_joni has got emc2 to compile on 2.6 :)
[15:13:22] <alex_joni> commiting the Makefiles now
[15:13:26] <alex_joni> but.. it's only userlevel stuff till now
[15:13:33] <alex_joni> (that was the easy part)
[15:14:01] <rayh> Stuff like a HAL mod, it's parms and such could easily be displayed in the help.
[15:14:13] <rayh> Hey that is great news.
[15:14:23] <alex_joni> not really ;)
[15:14:29] <alex_joni> didn't do much
[15:14:36] <alex_joni> just ifdef'ed the RTMODULES
[15:14:40] <alex_joni> :D
[15:14:51] <rayh> Oh yea. JMK spent half a day frustrating over emc2 and 2.6
[15:15:04] <alex_joni> for HAL I think it's a bit much to configure it from kbuild
[15:15:23] <alex_joni> I think kbuild should choose a working hal-config (based on a number of presets)
[15:15:29] <rayh> Probably.
[15:15:37] <alex_joni> and if the user really wants to mess with that (has more custom needs)
[15:15:46] <rayh> At least at the start. Mini or bridgeport
[15:15:48] <alex_joni> he'll use halgui (the gui for configuring HAL)
[15:15:57] <alex_joni> kinda like an schematic editor
[15:16:14] <rayh> and then build up a tillie interface.
[15:16:20] <alex_joni> whith all the hal-componets (pins, etc) and you can drag those around and connect them either way you like
[15:16:28] <alex_joni> yup
[15:16:33] <rayh> If we create a way to do it.
[15:17:04] <rayh> that allows incremental construction
[15:17:17] <rayh> others can add the specifics.
[15:17:19] <alex_joni> how do you mean that?
[15:17:36] <alex_joni> the modules?
[15:17:54] <rayh> I was thinking of kbuild help again.
[15:18:04] <rayh> If a module is added to help,
[15:18:05] <alex_joni> ahh
[15:18:14] <alex_joni> one thing I didn't like on kbuild...
[15:18:20] <alex_joni> it get's hairy as it grows
[15:18:26] <alex_joni> at least that tillie stuff
[15:18:37] <anonimasu> * anonimasu nods
[15:18:48] <rayh> and there is a way to take the answers and send to halgui or halconfig.
[15:19:11] <alex_joni> sure.. the answers get written as .config
[15:19:17] <alex_joni> like on the linux kernel
[15:19:50] <rayh> Yes. We need to add some test stuff or a way to pass .config throug a verification program.
[15:20:34] <rayh> verify will test hal stuff and give a go/nogo.
[15:21:23] <rayh> If we can do that by adding a module at a time IMO it will be easier to manage.
[15:22:08] <alex_joni> maybe keep it in separate files (one for each module)
[15:22:12] <rayh> But I'm not thinking about the software required to do this.
[15:22:19] <rayh> That may be huge.
[15:22:28] <rayh> That would help.
[15:23:03] <rayh> kbuild has the ability to hide or reveal whole sets of questions or options
[15:23:05] <alex_joni> maybe in the future
[15:23:09] <rayh> based on answers.
[15:23:12] <alex_joni> right now I think it should work
[15:23:29] <alex_joni> and it's more important to have it running on 2.6
[15:23:40] <alex_joni> then the TP stuff paul & les are working on
[15:24:01] <anonimasu> I think the tp stuff is more important
[15:24:02] <anonimasu> :)
[15:25:07] <alex_joni> yup
[15:25:17] <alex_joni> a quintic 6-axis interpolator would be great
[15:25:19] <rayh> On the slow machines I work with I don't see the problems...
[15:25:31] <alex_joni> but in 2-3 years it would be minimum
[15:25:35] <rayh> But I'm certain that they are very real at high speed.
[15:26:42] <alex_joni> high speed is the future <.9
[15:26:44] <alex_joni> :)
[15:26:48] <anonimasu> * anonimasu nods
[15:27:15] <rayh> Yes it is.
[15:27:26] <alex_joni> rayh: wouldn't you want for anonimasu to finish his parts in under 1 minute (so he can be here most of the time to bug us?)?
[15:27:36] <anonimasu> lol
[15:27:47] <anonimasu> they take 4 minutes now ;)
[15:27:53] <alex_joni> I know I would... not :D
[15:28:09] <rayh> certainly.
[15:28:16] <alex_joni> ok.. if I knew there was a kbuild branch I would have worked there
[15:28:22] <alex_joni> moving my changes now :)
[15:28:29] <anonimasu> not that the time really matters..
[15:28:44] <anonimasu> but there isnt a single commercial machine running at slow speeds nowdays..
[15:37:40] <CIA-4> 03alex_joni 07kbuild-0-1 * 10emc2/src/ (7 files in 7 dirs):
[15:37:40] <CIA-4> modified the Makefiles to allow emc2 to compile on 2.6 kernels using kbuild. the
[15:37:40] <CIA-4> kernel modules will be handled by Kbuild, so all RT-stuff has been ifdef'ed out
[15:37:40] <CIA-4> from the Makefiles. Right now emc2 actually compiles cleanly on my bdi-4.20, but
[15:37:40] <CIA-4> without ANY RT stuff. I hope it still works for 2.4 kernels too
[15:44:02] <nevyn> ?
[15:44:29] <alex_joni> nevyn: something unclear?
[15:45:03] <nevyn> how are the RT modules built normally?
[15:46:12] <alex_joni> till now they were build from the Makefile (works only < 2.6)
[15:46:24] <nevyn> from the emc makefile?
[15:46:30] <alex_joni> yup
[15:47:03] <nevyn> eww.
[15:47:05] <nevyn> :)
[15:47:05] <alex_joni> from all over the source code (emc, hal, rtapi produces rtapi.o which gets linked, etc)
[15:47:16] <nevyn> double eww.
[15:47:17] <alex_joni> well.. since 2.6 this doesn't work anymore
[15:47:32] <alex_joni> nevyn: got a better ideea?
[15:47:55] <alex_joni> remember big part of emc is RT
[15:48:05] <alex_joni> and it pretty integrated with the non-RT
[15:48:11] <nevyn> it just strikes me as ugly.. the modules should be quite seperate..
[15:48:33] <alex_joni> well.. it's been like this since 2.0.x afaik
[15:48:51] <alex_joni> but it'll be separate using Kbuild
[15:49:00] <nevyn> hrm. have emc generate a sparse tree.. oh wait.. kowens kbuild got dropped ;(
[15:49:26] <nevyn> keith owens had a solution for this around 2.4 but linus hated it :(
[15:49:49] <alex_joni> well..
[15:50:25] <nevyn> make-kpkg ;)
[15:51:05] <alex_joni> what's that?
[15:53:04] <nevyn> a debian package to build out of tree modules.
[15:53:22] <nevyn> why did it stop working?
[15:54:03] <alex_joni> no ideea..
[15:54:12] <nevyn> it's not a solution really for a bunch of reasons not least of which is it only works on debian.
[15:54:34] <alex_joni> right
[16:05:44] <rayh> I've got an old EMC software problem here... an interaction between lube timer and estop...
[16:06:11] <rayh> does the head of emc1 build on Live rc46
[16:06:57] <alex_joni> should build
[16:07:01] <alex_joni> what's it saying?
[16:07:06] <rayh> k I'll try it.
[16:07:33] <rayh> I blinks estop off and on every few seconds.
[16:07:59] <rayh> Lube causes..
[16:08:27] <rayh> Matt and I fixed it a year or so ago but it crept back into Jon's software.
[16:08:46] <rayh> I'll download emc1 and try
[16:10:23] <les_away> les_away is now known as paul_c
[16:11:03] <alex_joni> yo paul_c
[16:11:56] <alex_joni> good thing you're around.. wanted to ask you smthg
[16:12:01] <paul_c> morning Alex
[16:12:09] <paul_c> * paul_c hides again
[16:12:14] <alex_joni> lol
[16:12:24] <alex_joni> I compiled emc2 on bdi-4.20 :)
[16:12:34] <alex_joni> but without the RT stuff :D
[16:12:35] <paul_c> * paul_c scrolled up and saw...
[16:12:44] <alex_joni> started to figure kbuild
[16:12:58] <alex_joni> anyways.. would anyone mind if I continue implementing this?
[16:13:21] <paul_c> It's going to have to be done at some stage
[16:13:35] <paul_c> either by you & JMK, or by me...
[16:13:44] <alex_joni> I saw you did bdi-4 by adding the Kbuild stuff into the Makefile
[16:13:54] <paul_c> yup
[16:14:07] <alex_joni> but from what I've read it's best to do it by Kbuild (included from Makefile)
[16:14:21] <alex_joni> --> filename: Makefileifneq ($(KERNELRELEASE),)include Kbuildelse# Normal Makefile
[16:14:37] <alex_joni> darn paste
[16:15:00] <paul_c> just tell kbuild what sources go to make up a module, and let it get on with it.
[16:15:14] <alex_joni> I know that
[16:15:37] <alex_joni> but seems the Makefile (as a file, may not be checked by future versions of kbuild)
[16:15:43] <alex_joni> only Kbuild will
[16:16:29] <alex_joni> In recent versions of the kernel, kbuild will look for a file namedKbuild and as second option look for a file named Makefile.
[16:16:46] <paul_c> where did you hear that ?
[16:16:58] <alex_joni> docs in the kernel source
[16:17:19] <paul_c> OK... I need to have a read of the latest then..
[16:17:36] <alex_joni> BUT.. I might have gotten it wrong...
[16:17:52] <paul_c> But we will still need backwards compatability with 2.6.5-10 kernels.
[16:18:10] <alex_joni> yup.. that's why I'd go with the include version
[16:18:13] <paul_c> what branch tag are you using ?
[16:18:20] <alex_joni> use the Kbuild stuff in the Kbuild file
[16:18:24] <alex_joni> kbuild-0-1
[16:18:27] <alex_joni> on emc2
[16:18:41] <alex_joni> and include the Kbuild from the Makefile (for older kbuild's)
[16:19:37] <alex_joni> "The preferred name for the kbuild files is 'Kbuild' but 'Makefile' will continue to be supported. All new development is expected to use the Kbuild filename. "
[16:20:33] <paul_c> ifeq ($(KERNELRELEASE),2.4) is wrong.
[16:20:59] <paul_c> ifneq ($(MODULE_EXT), ko)
[16:21:13] <paul_c> is the only way of doing it...
[16:21:34] <paul_c> KERNELRELEASE doesn't get set until kbuild is called.
[16:21:42] <nevyn> is the RT stuff in emc using the standard RTAI infastructure or is the infastructure itself customised?
[16:22:04] <paul_c> so the RT_SRCS will get skipped for all builds as you have it.
[16:22:34] <paul_c> nevyn: RTAI for 2.6 kernels uses kbuild
[16:22:51] <alex_joni> bugger that
[16:23:44] <rayh> Hi Paul
[16:24:06] <paul_c> Hi Ray
[16:24:37] <rayh> Seems Jon-univpwmmod.o uses old rc46 code
[16:25:12] <rayh> It still has Fred's hardcoded lube loop.
[16:25:25] <paul_c> I just used what ever was the latest in CVS..
[16:25:36] <rayh> Right.
[16:26:21] <paul_c> If Jon has done some tweaks without committing (or committed over "fixes"), take it out on him...
[16:26:55] <rayh> I was thinking of offering you a drive to ST Louis with a big hammer.
[16:27:28] <paul_c> I need to get back to the DC area by Tuesday at the latest....
[16:27:50] <paul_c> wouldn't have time to drive to St Louis
[16:27:55] <rayh> I'm compiling sf today on Live. If that goes I'll add Jon's version of ppmc and univ stuff and try it.
[16:28:46] <rayh> I guess I'm stuck with sending him a hammer and a note that says, "use this to hit head."
[16:28:51] <paul_c> You guys still need a hand up there ?
[16:28:59] <rayh> We may.
[16:29:15] <paul_c> lemme know asap
[16:29:32] <paul_c> 'cos I will be making a move north tomorrow
[16:29:34] <rayh> Matt's got an IO plan. Some like collet open/close is based on m101
[16:30:43] <rayh> If I get us a room, wanna stay in sykesville?
[16:31:16] <rayh> No limit to the work day at Matt's.
[16:31:18] <paul_c> where the ** is sykesville ?
[16:31:36] <rayh> Near where Matt's home is.
[16:31:57] <rayh> I'm totally lost with this MD map stuff.
[16:32:25] <nevyn> * nevyn checks out emc and sighs
[16:32:43] <paul_c> got a zip code ?
[16:34:50] <rayh> 21784
[16:35:04] <CIA-4> 03alex_joni 07kbuild-0-1 * 10emc2/src/ (7 files in 7 dirs): changed the check from KERNELRELEASE to MODULE_EXT, as systems prior to kbuild don't set KERNELRELEASE (as pointed out by PC)
[16:35:13] <rayh> 2528 Arthur AVE
[16:35:38] <nevyn> 2.95 is so 2001
[16:36:57] <paul_c> nevyn: IF _YOU_ want to compile a kernel with RT patches AND EMC with gcc-4.0 and ensure it functions perfectly with ALL hardware, go right ahead.
[16:37:08] <nevyn> sure.
[16:37:14] <nevyn> that's what I'm looking at.
[16:37:24] <nevyn> the kernel won't be a problem.
[16:37:49] <alex_joni> paul_c: got any complaints on using Kbuild?
[16:38:06] <alex_joni> I think that would split things up nicely
[16:38:29] <paul_c> I need to get the kbuild-0-1 branch on my dev/test box
[16:38:52] <paul_c> then I can do the initial work for rtapi
[16:39:17] <alex_joni> next week I guess
[16:39:33] <paul_c> next weekend would be the earliest, yes.
[16:40:07] <alex_joni> ok.. I'll go on till then ;)
[16:40:15] <paul_c> at the moment, I'm logged into the box at home, but that doesn't have the dev system installed.
[16:40:29] <alex_joni> then I'll hide
[16:40:58] <paul_c> I don't think it warrants a separate makefile just for kbuild.
[16:41:23] <paul_c> rayh: A room in Sykesville looks fine to me.
[16:41:38] <alex_joni> it does separate RT stuff from non-RT stuff
[16:42:30] <paul_c> There isn't that much RT stuff to separate out.
[16:43:14] <paul_c> rtapi is a single source module
[16:43:26] <alex_joni> isn't it a 2 source lib?
[16:43:42] <paul_c> most of the HAL module directories do not contain any usr space stuff...
[16:43:44] <alex_joni> rtai_rtapi.c and mathstubs.c ?
[16:44:04] <alex_joni> or rtl_rtapi.c
[16:44:23] <paul_c> rtai_rtapi.c gets compiled in to rtapi.[o|ko]
[16:44:41] <alex_joni> right
[16:45:00] <paul_c> mathstubs.o is an optional extra that may or may not get linked.
[16:45:33] <paul_c> I would go as far as to say you can ignore it completely for 2.6 builds
[16:46:07] <paul_c> (mathstubs.c is only needed when a suitable libm is not available.)
[16:47:15] <alex_joni> alex_joni is now known as alex_joni_right_
[16:52:56] <dmess> hi all
[16:59:26] <alex_joni_right_> alex_joni_right_ is now known as alex_joni
[17:31:49] <alex_joni> paul_c: still around?
[17:31:56] <paul_c> yup
[17:32:06] <alex_joni> got rtapi.ko to insmod
[17:32:19] <alex_joni> but ..
[17:32:35] <paul_c> guess you don't need my help then...
[17:32:37] <alex_joni> I was only able to build it properly if I build it as rtai_rtapi.ko
[17:32:53] <alex_joni> that means you need to rmmod it as rtai_rtapi
[17:33:09] <alex_joni> tried to rename it ;) (that only works during loading, not unloading)
[17:33:26] <paul_c> We can do some tricks to fix that....
[17:33:44] <alex_joni> I tried:
[17:33:50] <alex_joni> obj-m := rtapi.o
[17:33:58] <paul_c> either in the source file, or with a kbuild rule
[17:33:59] <alex_joni> rtapi-y := rtai_rtapi.o
[17:34:15] <alex_joni> but that outputs lots of warnings during linking
[17:34:19] <paul_c> rtapi_m - Never 'y'
[17:34:30] <alex_joni> well rtapi.o is module
[17:34:34] <alex_joni> obj-m
[17:35:11] <paul_c> darn - I need my kbuild notes...
[17:35:44] <alex_joni> nope, doesn't work
[17:35:44] <paul_c> Commit the stuff you've done, and I'll take a look.
[17:35:55] <alex_joni> if you have a multiple source file then you need -y
[17:36:00] <alex_joni> even if you build a module
[17:36:11] <alex_joni> is it ok if it builds as rtai_rtapi.ko ?
[17:36:30] <alex_joni> and we use that from the emc.run script ?
[17:36:38] <paul_c> It breaks the run scripts....
[17:37:01] <alex_joni> the run scripts get broken no matter what
[17:37:03] <alex_joni> I think
[17:37:08] <paul_c> It is better if we stick with rtapi.ko
[17:37:13] <alex_joni> ok..
[17:37:24] <alex_joni> then I'll try some more
[17:37:33] <paul_c> Do a commit.
[17:37:42] <alex_joni> maybe a pre-rule to cp rtai_rtapi.c to rtapi.c ?
[17:37:50] <alex_joni> based on $(RTPREFIX) ?
[17:38:02] <alex_joni> then build rtapi.ko from rtapi.c ?
[17:39:03] <paul_c> one sec while I grab some notes.
[17:39:37] <alex_joni> works like a charm like this
[17:40:50] <CIA-4> 03alex_joni 07kbuild-0-1 * 10emc2/src/rtapi/Makefile: first shot at building the kernel module rtapi.ko, may not be the best way to do it and it may break things
[17:51:03] <CIA-4> 03paul_c 07kbuild-0-1 * 10emc2/src/rtapi/Makefile: Add a rule to create a hard link to one of the *_rtapi.c sources for kbuild - This needs testing on a real build system..
[17:51:04] <paul_c> Try that.
[17:51:26] <alex_joni> just a moment.. just building hal_lib.ko
[17:51:41] <alex_joni> ln ?
[17:51:58] <paul_c> cp -fl creates a hard link.
[17:55:58] <alex_joni> yup
[17:56:00] <alex_joni> works
[17:56:23] <CIA-4> 03paul_c 07kbuild-0-1 * 10emc2/src/rtapi/Makefile: We might be cross-compiling and not actually be running the RT kernel - So need to use the kernel tree as supplied by configure.
[17:56:24] <paul_c> another minor change...
[17:57:38] <paul_c> One of the things we need to look at is cases where the kernel has been built outside the source tree.
[17:58:12] <paul_c> kbuild has some funky foo to handle this, but it does require a little extra work on our part.
[17:58:50] <alex_joni> lemme get a working emc2 first
[17:58:54] <CIA-4> 03alex_joni 07kbuild-0-1 * 10emc2/src/rtapi/Makefile: removed the first cp, as the explicit rule now takes care of that, added modules_install rule
[18:00:03] <paul_c> gah... Didn't see that line...
[18:00:27] <alex_joni> darn module_install doesn't work :(
[18:01:13] <rayh> Hey we got Hardinge motion with today's sf -- Thanks Paul.
[18:01:16] <alex_joni> configure finds kernel-headers as KDIR
[18:01:23] <alex_joni> that's BAD
[18:01:33] <paul_c> Are you using RTAI's module loading script in the run files ?
[18:01:47] <alex_joni> not loading anything yet
[18:01:52] <alex_joni> using modprobe / insmod
[18:02:04] <paul_c> rayh: Great news indeed.
[18:02:04] <alex_joni> first I want to have all modules compileable
[18:02:31] <alex_joni> KERNELDIR is not ok
[18:02:41] <paul_c> Go back to the original KDIR incantation if that is what works for you.
[18:02:51] <alex_joni> looking at configure now
[18:03:02] <rayh> Now we can move forward.
[18:03:12] <paul_c> and back..
[18:03:20] <paul_c> in both X and Z
[18:03:22] <rayh> paul_c were you saying we ought to move the lathe to 4.20?
[18:03:28] <alex_joni> rtai-config reports /usr/src/kernel-headers-2.6.10-adeos
[18:04:43] <alex_joni> might be from when you compiled rtai ?
[18:05:06] <paul_c> Ah, yes... Debian's make-kpkg
[18:05:35] <alex_joni> maybe one thing for 4.21 ? ;)
[18:06:05] <paul_c> Carry on with the way you had it, and I'll look at the fixes needed for make-kpkg next week (maybe)
[18:06:10] <alex_joni> ok
[18:08:42] <paul_c> configure will probably need a few additions to handle the "out of source tree" kbuilds
[18:08:49] <alex_joni> yup
[18:09:21] <alex_joni> ok.. moving on
[18:13:32] <CIA-4> 03alex_joni 07kbuild-0-1 * 10emc2/src/hal/Makefile: added kbuild support for hal_lib, to compile it use 'make modules' and 'sudo make modules_install'
[18:15:18] <paul_c> You probably want to pass a module directory variable to kbuild with module_install
[18:15:46] <alex_joni> well.. it installs it in /lib/modules/KVER/extra
[18:15:49] <alex_joni> I think that's ok
[18:17:26] <paul_c> Looks like Les is taking me on a tour of the area - Be back in a couple of hours.
[18:17:34] <alex_joni> ok.. have fun
[18:17:47] <alex_joni> hope I'll have smthg to show you when you'll be back
[18:18:41] <paul_c> paul_c is now known as les_away
[18:21:12] <Imperator_> hi alex
[18:21:14] <alex_joni> meep?
[18:21:16] <alex_joni> hey Martin
[18:22:08] <Imperator_> * Imperator_ is still tired
[18:22:30] <Imperator_> wat was up the last week
[18:22:43] <Imperator_> see that you are working hard on 2.6
[18:23:05] <alex_joni> trying to ;)
[18:23:38] <Imperator_> i don't know anything about that stuff, but mybe you need somebody for some stupid work, then let me know
[18:23:44] <alex_joni> heh
[18:23:51] <alex_joni> it's not that hard
[18:23:58] <Imperator_> god
[18:24:02] <alex_joni> it's a LOT easier than normal Makefiles
[18:24:06] <alex_joni> god is a DJ
[18:24:11] <alex_joni> faithless says
[18:24:11] <Imperator_> good
[18:24:14] <alex_joni> :P
[18:24:22] <Imperator_> :-)
[18:24:28] <alex_joni> wie war's in den Staaten?
[18:24:36] <Imperator_> new York is cool
[18:25:23] <Imperator_> speziell spazierengehen, weil man sich nicht so arg um die Autos k�mmern muss, die m�ssen eher auf die Fu�g�nger aufpassen
[18:25:30] <alex_joni> lol
[18:25:35] <alex_joni> yay
[18:25:43] <alex_joni> ich hab schon paar module ;)
[18:25:48] <alex_joni> hal ist fast fertig
[18:25:59] <Imperator_> cool
[18:26:15] <Imperator_> i make apizza, then i start my linux box
[18:27:33] <alex_joni> jmk: hello
[18:27:38] <alex_joni> you spoiled my surprise
[18:28:00] <jmkasunich> no I didn't... just looking at my emails. looks like you've been busy
[18:28:42] <rayh> Hi Martin
[18:28:50] <jmkasunich> hi ray
[18:28:55] <alex_joni> well you did.. you came in too early
[18:29:01] <jmkasunich> how's the lathe conversion going
[18:29:05] <alex_joni> wanted to surprise you with a working 2.6 emc2 :D
[18:29:07] <rayh> Hi John
[18:29:55] <jmkasunich> alex_joni: I can go away for a while
[18:30:04] <alex_joni> lol
[18:30:05] <alex_joni> nyh
[18:30:06] <alex_joni> nah
[18:30:09] <jmkasunich> I have to fix an outdoor waterpipe that froze over the winter
[18:38:12] <alex_joni> if I would have known this 2.6 stuff is so easy.. I would have done it a long time ago
[18:38:33] <jmkasunich> I'm glad you think it's easy
[18:38:38] <alex_joni> it really is
[18:38:47] <alex_joni> you know what you need to compile a module?
[18:38:53] <alex_joni> say scope_rt.c
[18:39:06] <alex_joni> all you need is: obj-m := scope_rt.o
[18:39:18] <jmkasunich> in a pure 2.6 environment, true
[18:39:28] <jmkasunich> (you also need a kernel source tree tho)
[18:39:33] <alex_joni> yeah
[18:39:36] <alex_joni> and extra cfalgs
[18:39:43] <alex_joni> cflags even
[18:40:36] <alex_joni> can you try if hal works?
[18:40:41] <jmkasunich> you're keeping the compile farm busy, nice to see that
[18:40:47] <alex_joni> heh
[18:40:52] <alex_joni> will do all day
[18:40:54] <CIA-4> 03alex_joni 07kbuild-0-1 * 10emc2/src/hal/ (Makefile components/Makefile utils/Makefile drivers/Makefile): added kbuild support for hal drivers, components, utils
[18:41:20] <jmkasunich> you want me to test under 2.4 or 2.6?
[18:41:24] <alex_joni> 2.6
[18:41:30] <alex_joni> 2.4 _should_ work :)
[18:42:02] <jmkasunich> did you notice that BDI-2.18 failed the most recent compile attempt?
[18:42:08] <alex_joni> yes
[18:42:12] <alex_joni> unfortunately
[18:42:21] <alex_joni> but I thought 2.18 worked with rcslib
[18:42:44] <jmkasunich> what does rcslib have to do with it?
[18:42:53] <alex_joni> oops
[18:43:02] <alex_joni> thought you were talking about emc1/rcslib
[18:43:05] <alex_joni> looking now
[18:43:10] <jmkasunich> nope, the kbuild branch
[18:43:28] <alex_joni> on emc1/rcslib pretty much all fail
[18:43:33] <alex_joni> that's not ok
[18:44:28] <jmkasunich> looks like the $(PWD)/../Makefile.inc didn't work
[18:44:40] <alex_joni> yup
[18:44:42] <jmkasunich> the $(PWD) part expanded to nothing
[18:44:46] <alex_joni> already fixed that
[18:44:47] <alex_joni> :D
[18:44:59] <anonimasu> hm..
[18:45:07] <anonimasu> * anonimasu loves zsh for that kind of stuff
[18:45:08] <anonimasu> :)
[18:45:12] <alex_joni> there is a special combination that works
[18:45:43] <robin_sz> sigh
[18:45:53] <jmkasunich> * jmkasunich kicks off slot 2 again to see if it works better now
[18:46:03] <alex_joni> I didn't commit yet
[18:46:04] <robin_sz> so ...
[18:47:01] <jmkasunich> oh well, you did commit something recently
[18:47:14] <robin_sz> which motor driver do support quadrature drive for steppers? freqmod? steppermod? segmotqueue?
[18:47:16] <alex_joni> just did ;)
[18:47:18] <CIA-4> 03alex_joni 07kbuild-0-1 * 10emc2/src/hal/Makefile: fixed a problem including Makefile.inc from multibuild, make and kbuild
[18:47:33] <alex_joni> freqmod & steppermod
[18:47:41] <alex_joni> SQ is not a motor driver
[18:47:54] <robin_sz> well, steppersegmod then
[18:48:02] <alex_joni> should
[18:48:09] <alex_joni> depends on the sw-version
[18:48:42] <robin_sz> hmm
[18:49:14] <robin_sz> STEPPING_TYPE = 1 I think
[18:50:14] <robin_sz> this is really turning out to be painful
[18:50:34] <robin_sz> perhaps I'll try a later BDI
[18:51:12] <alex_joni> you should ..
[18:51:13] <alex_joni> :D
[18:51:29] <robin_sz> my mate wants me to hook this up to his mill for him
[18:51:41] <alex_joni> use emc2 :D
[18:51:42] <robin_sz> a series 1 bridgeport
[18:51:43] <alex_joni> it's easier
[18:51:53] <alex_joni> hmmm..
[18:52:03] <alex_joni> well then .. Live?
[18:52:07] <alex_joni> or the 4.20
[18:52:16] <alex_joni> did install like a charm
[18:52:19] <robin_sz> ive never had ANY success with the live distros at all
[18:53:27] <jmkasunich> well that's a new one... take a look at the slot 3 compile farm log
[18:53:34] <jmkasunich> (near the end)
[18:53:52] <jmkasunich> "kernel has modules disabled" my ass
[18:53:59] <alex_joni> huh
[18:54:02] <alex_joni> :D
[18:54:07] <rayh> Just compiled SF today with Live rc46.
[18:54:37] <jmkasunich> rayh: which one from SF? emc1, emc2 head?
[18:55:11] <rayh> emc(1)
[18:55:29] <rayh> John's ppmc seems to run fine.
[18:55:30] <anonimasu> hm, you should compile/run emc2
[18:55:37] <anonimasu> very easy to compile
[18:55:52] <anonimasu> if you dont need segmentqueue for some reason
[18:55:58] <robin_sz> we tried BDI 2.18 today
[18:56:03] <jmkasunich> alex_joni: both slot 2 and slot 3 failures were before your latest commit, I just kicked those two slots off again so they are compiling the newest
[18:56:03] <alex_joni> jmk: seems it's trying to compile kbuild-like
[18:56:15] <alex_joni> it will fail again
[18:56:25] <alex_joni> let me finish messing it up completely
[18:56:30] <alex_joni> then I'll look at it
[18:56:30] <alex_joni> :D
[18:56:33] <jmkasunich> OK
[18:56:37] <alex_joni> lol
[18:56:41] <jmkasunich> if there's anything I can do here, let me know
[18:56:52] <alex_joni> try the hal stuff on 2.6 if you can
[18:56:56] <jmkasunich> I believe I can IRC from any of the compile farm slots, if you need me to check things
[18:56:57] <alex_joni> the modules should build
[18:57:10] <robin_sz> I think the P90 is a touch slow for running it though
[18:57:22] <alex_joni> well only HAL
[18:57:27] <alex_joni> no GUI, no EMC
[18:57:28] <jmkasunich> ok, just booted that box
[18:57:31] <alex_joni> should work
[19:06:44] <alex_joni> hey jmk2
[19:10:27] <rayh> jmkasunich Can you describe the slaving module in Hal?
[19:25:03] <alex_joni> darn
[19:25:24] <alex_joni> seems rtapi.ko gets loaded, but when I load hal_lib.ko it doesn't see some symbols
[19:26:48] <CIA-4> 03alex_joni 07kbuild-0-1 * 10emc2/src/emc/Makefile: added motmod to kbuild
[19:27:04] <jmkasunich> sorry guys, was kvm'ed away
[19:27:15] <jmkasunich> rayh: what slaving module?
[19:27:33] <CIA-4> 03alex_joni 07kbuild-0-1 * 10emc2/src/Makefile: added make modules and make modules_install rules
[19:27:37] <rayh> encoder_ratio.c
[19:27:57] <jmkasunich> uhhh... lemme take a look at it and refresh my memory
[19:28:26] <rayh> k
[19:29:34] <jmkasunich> did you look at the comment block at the beginning of encoder_ratio.c?
[19:29:43] <jmkasunich> that describes it better than I can
[19:30:12] <rayh> Yes i did.
[19:30:37] <jmkasunich> what else do you want to know?
[19:31:38] <rayh> If I were to try it on a gear hobbing machine where there were five ratios, it should work?
[19:31:54] <jmkasunich> I think so. you'd use five of them
[19:31:57] <rayh> Two of the axes are spindle, three are linear.
[19:32:11] <jmkasunich> (do you mean there are six axis, five slaved to one?
[19:32:25] <rayh> probably four slaved to the fifth.
[19:32:31] <jmkasunich> ok
[19:32:53] <jmkasunich> we talked about this once before
[19:32:59] <jmkasunich> the hob is the master, right?
[19:33:01] <rayh> Yes we did.
[19:33:05] <rayh> Yes
[19:33:16] <rayh> Part or blank is the slave spindle
[19:33:21] <jmkasunich> and you slave the gear rotary to it to set the number of teeth
[19:33:27] <jmkasunich> yeah, what you said ;-)
[19:33:57] <rayh> the slideways do things like depth of the hob pass and crowning and such.
[19:34:28] <jmkasunich> so the linear slides don't _really_ have to be slaved, they could just be very slow normal moves
[19:34:54] <rayh> For crowning they would have to slave to get proper crown.
[19:35:16] <rayh> It is a bit more than just coordinated motion.
[19:35:44] <roltek> also when doing helical gears they would all have to be slaved to keep timing
[19:35:55] <rayh> Ah right.
[19:36:29] <jmkasunich> crowning is gears that are a little bigger in the middle than the edges (like old flatbelt pulleys)? or something else?
[19:37:01] <roltek> yes you are correct
[19:37:54] <jmkasunich> that HAL modules was a step, but it would take quite a bit more for a proper hobber
[19:38:11] <jmkasunich> not the least of which is the calculation of all the proper ratios for a given cear
[19:38:11] <alex_joni> jmk: any luck on HAL ?
[19:38:16] <jmkasunich> gear
[19:38:34] <jmkasunich> fighting my BDI-4.20 install
[19:38:48] <jmkasunich> clock's all screwed up, so Make things some files are from the future
[19:38:57] <alex_joni> lol
[19:38:59] <jmkasunich> dam ting things it's in London
[19:39:12] <alex_joni> let's not do the time warp again.. shall we?
[19:42:13] <jmkasunich> well the clock problem seems to be under control
[19:42:27] <jmkasunich> still thinks it's in london, but at least it knows the correct time in London
[19:42:38] <jmkasunich> the make had some warnings, no errors tho
[19:43:05] <jmkasunich> no modules in rtlib though
[19:43:11] <alex_joni> nope
[19:43:15] <alex_joni> there won't be any there
[19:43:18] <alex_joni> anymore
[19:43:20] <jmkasunich> where are they then?
[19:43:26] <alex_joni> you need to sudo make modules_install
[19:43:45] <alex_joni> the modules go to /lib/modules/`uname -r`/extra
[19:43:53] <alex_joni> that's the kbuild way :(
[19:43:54] <jmkasunich> well that sucks elephant dick
[19:43:59] <alex_joni> yup
[19:43:59] <alex_joni> :D
[19:44:19] <alex_joni> well.. maybe there's a way to trick it
[19:44:22] <jmkasunich> so you mean after the "make" step the modules don't exist at all, anywhere?
[19:44:30] <alex_joni> but for now I am looking at functionality
[19:44:36] <alex_joni> they exist.. all over the place
[19:44:36] <alex_joni> :D
[19:44:37] <jmkasunich> and "make modules_install" links them as well as installing them
[19:44:45] <alex_joni> nope.. just installs them
[19:44:56] <alex_joni> they are besides the sources
[19:45:00] <jmkasunich> so there is *.ko lurking somewhere
[19:45:04] <alex_joni> encoder.c -> encoder.ko
[19:45:30] <alex_joni> encoder.mod.c, encoder.mod.o
[19:46:03] <alex_joni> and encoder.ko.cmd, encoder.mod.o.cmd, encoder.o.cmd
[19:46:14] <alex_joni> that just makes a mess.. but that's it
[19:46:25] <jmkasunich2> I see the .ko, not the .cmd ones tho
[19:46:38] <alex_joni> sorry...
[19:46:50] <alex_joni> it's .encoder.*.cmd
[19:47:21] <jmkasunich2> I see encoder.c, encoder.ko, encoder.mod.c and encoder.mod.o
[19:47:32] <jmkasunich2> and encoder.o
[19:47:37] <alex_joni> the others have an . in front
[19:47:40] <alex_joni> so you need ls -al
[19:47:43] <jmkasunich2> ls -A
[19:47:44] <jmkasunich2> oops
[19:47:56] <alex_joni> wrong window :D
[19:48:30] <jmkasunich2> what a mess
[19:48:47] <alex_joni> no .. really?
[19:48:53] <jmkasunich2> ;-)
[19:49:01] <alex_joni> you think so?
[19:49:06] <jmkasunich2> yes
[19:49:11] <alex_joni> * alex_joni too
[19:51:10] <jmkasunich> I _really_ don't like the idea of being forced to install the modules before you can test them
[19:51:26] <alex_joni> you can test them
[19:51:30] <alex_joni> with insmod
[19:51:49] <jmkasunich> you just have to tell insmod where to find them?
[19:51:54] <alex_joni> yup
[19:51:58] <alex_joni> insmod ./foo.ko
[19:52:41] <jmkasunich> I don't suppose it's possible to tack our own commands on after the kbuild part... commands that would move the modules to rtlib
[19:53:19] <alex_joni> it is.. but it's not nice ;)
[19:53:21] <robin_sz> ah yes
[19:55:08] <jmkasunich2> the problem is that kbuild was made to build modules that are part of the kernel, not part of an external program like EMC or hal
[19:55:28] <robin_sz> what exactly is wrong withthe standard way of putting them in /lib/modules/`uname -r`/extra ??
[19:55:32] <alex_joni> well.. I think 2.6 kernels are more kernel related
[19:55:57] <alex_joni> if you recompile part of the kernel, you need to recompile all the modules too
[19:56:05] <alex_joni> well.. I think 2.6 modules are more kernel related
[19:56:10] <alex_joni> not the first one
[19:56:49] <alex_joni> jmk: about that stuff that fails on the farm
[19:56:59] <jmkasunich> yes?
[19:57:01] <alex_joni> I know what it is, but I don't have the energy to fix it
[19:57:16] <alex_joni> it's the new rules I added (modules and modules_install)
[19:57:30] <alex_joni> those shouldn't be visible by any other system but kbuild
[19:57:37] <alex_joni> so they need to get ifdefd
[19:57:45] <jmkasunich> I should be able to handle that
[19:58:01] <jmkasunich> where are the rules, in Make.rules, or in the individual Makefiles?
[19:58:17] <alex_joni> individual Makefiles
[19:58:23] <alex_joni> not very many
[19:58:28] <alex_joni> the ones in HAL
[19:58:35] <alex_joni> one in rtapi
[19:58:40] <alex_joni> and one in emc/
[19:58:47] <les_away> hi guys
[19:58:52] <alex_joni> hello
[19:58:57] <les_away> just in for a sec
[19:59:03] <alex_joni> how was the tour?
[19:59:34] <les_away> was mowing...paul is at the machine in the shop trying a few things
[19:59:45] <alex_joni> let paul_c know I finished building all the modules (probably they don't work yet), but we'll get there
[20:00:02] <les_away> ok
[20:00:08] <A-L-P-H-A> I need some help... please. i can't make this into a CAM file. http://www.lloydleung.com/gallery/current/bracket.zip (autocad 2000 dwg files,zipped)
[20:00:16] <jmkasunich> strange stuff with the farm... all four slots say they succeeded on the logs there, but the results aren't on the website
[20:00:21] <les_away> hmm I just ran over a copperhead with the tractor
[20:00:21] <A-L-P-H-A> The cyan, is where I plan to hold the stock. So those don't get to be machined.
[20:00:25] <alex_joni> heh
[20:00:31] <jmkasunich> and the logs on the slots say the build only took 2 mins or less
[20:00:33] <A-L-P-H-A> copperhead snake?
[20:00:35] <alex_joni> I screwed up the main Makefile
[20:00:42] <alex_joni> removed the recursive build :)
[20:00:45] <alex_joni> fixing it now
[20:00:45] <les_away> yes poisonous snake
[20:01:07] <les_away> didn't see it
[20:02:06] <les_away> well out to the shop
[20:02:12] <alex_joni> jmk: seems like I'm getting tired
[20:02:13] <CIA-4> 03alex_joni 07kbuild-0-1 * 10emc2/src/Makefile: fscked the main Makefile, removed by mistake the rules to descend to lower dirs, restored them (should work now)
[20:02:21] <A-L-P-H-A> no help from les? :/
[20:02:44] <les_away> paul is the software guy.
[20:02:46] <les_away> heh
[20:03:20] <les_away> later
[20:03:23] <A-L-P-H-A> I just would like someone to teach me how to take a 3dsolid, to a program, that can output me a gcode file.
[20:03:36] <A-L-P-H-A> be that mastercam, or visualmill.
[20:03:52] <les_away> whoops I saw that
[20:03:57] <les_away> rhino
[20:04:13] <A-L-P-H-A> I can draw in 3d with autocad very profeciently.
[20:04:36] <A-L-P-H-A> just can't get past that part. Mastercam, keeps telling me something about boundaries, which I don't have a clue.
[20:04:48] <A-L-P-H-A> visualmill seems to do some funny things for me as well.
[20:04:56] <les_away> ? don't know
[20:05:30] <alex_joni> jmk: doesn't the farm rerun?
[20:05:45] <jmkasunich> ?
[20:06:00] <jmkasunich> normally it does a cvs up every hour, if there are changes it trys to compile
[20:06:07] <alex_joni> right
[20:06:21] <alex_joni> didn't see it run yet (since my last commit 3 minutes ago :D)
[20:08:03] <jmkasunich> I'll kick them off manually (just kill the "sleep 1 hour" process
[20:08:16] <alex_joni> heh
[20:08:23] <robin_sz> A-L-P-H-A: visualmill is pretty easy to use
[20:10:10] <jmkasunich> I finally got the clocks synchronized on all 4 slots
[20:10:21] <jmkasunich> the timestamps in the farm log will make more sense now
[20:10:22] <alex_joni> nice
[20:10:43] <alex_joni> maybe to you :D
[20:11:25] <jmkasunich> actually those times are in UTC
[20:11:42] <jmkasunich> (I think)
[20:11:50] <alex_joni> whatever :)
[20:12:06] <jmkasunich> what time is it where you are?
[20:12:09] <A-L-P-H-A> robin_sz mind giving me a quick tutorial on it?
[20:13:10] <alex_joni> GMT +2
[20:13:29] <alex_joni> [23:13] <alex_joni> GMT +2
[20:13:55] <jmkasunich> so GMT is 21:13 then?
[20:14:30] <alex_joni> ask robin ;)
[20:14:32] <alex_joni> bu t
[20:14:37] <alex_joni> but i think so
[20:14:37] <jmkasunich> so I'm still screwed up here.. by boxes think GMT is 20:15
[20:15:22] <jmkasunich> robin_sz: what time is it in the UK?
[20:15:38] <jmkasunich> and are you guys on GMT right now, or some kind of daylight savings time
[20:19:22] <jmkasunich> well all three non-2.6 slots failed this time... I expect that is the stuff that needs ifdef'ed out
[20:19:25] <jmkasunich> I'll look at it
[20:30:20] <alex_joni> yup
[20:30:53] <jmkasunich> seems like if we're not on a 2.6 system, the modules and modules_install targets should do nothing
[20:31:08] <alex_joni> yup
[20:31:19] <alex_joni> on 2.4 with kbuild they should
[20:31:53] <jmkasunich> right - wrong choice of conditional, it's not 2.4 vs 2.6, its normal vs kbuild
[20:32:09] <alex_joni> yes
[20:32:17] <alex_joni> question is.. how does that get tested?
[20:32:21] <jmkasunich> KERNELRELEASE is the test you use to decide if it is kbuild?
[20:32:37] <alex_joni> yes, but that's used when doing the actual kbuild
[20:32:44] <alex_joni> called by make from the make modules
[20:33:04] <alex_joni> if you get my point?
[20:33:11] <jmkasunich> I think so
[20:33:26] <alex_joni> so if we have an system with kbuild
[20:33:27] <jmkasunich> we need ./configure to decide if kbuild is used or not and set a variable
[20:33:37] <alex_joni> sounds reasonable
[20:34:42] <jmkasunich> the trick is how
[20:35:21] <alex_joni> kernelversion > 2.4.27 ?
[20:35:33] <jmkasunich2> not neccessarily
[20:35:50] <jmkasunich2> I think that you could still choose to use the old system for any 2.4 kernel
[20:36:27] <alex_joni> hmm..
[20:36:52] <Phydbleep> Use the old "does this file exist" trick with the hsell?
[20:36:59] <Phydbleep> shell
[20:37:10] <jmkasunich2> trick is figuring out what file to test for
[20:37:18] <Phydbleep> kbuild?
[20:38:28] <jmkasunich2> i'm not sure there is actually a file called kbuild
[20:39:07] <Phydbleep> There has to a at least one file that allows you to test for it.
[20:39:22] <Phydbleep> s/a at/at
[20:39:22] <jmkasunich2> ls
[20:39:26] <jmkasunich2> oops
[20:42:59] <jmkasunich> well, one idea down the drain
[20:43:20] <Phydbleep> Oops indeed... Went to browse the kbuild cvs and there's squat all there..
[20:43:39] <jmkasunich> I was thinking about "grep KBUILD $(KERNELDIR)/Makefile" as a test
[20:44:12] <jmkasunich> but even this 2.4.18 Makefile passes that test: it contains $(CC) $(CFLAGS) $(CFLAGS_KERNEL) -DUTS_MACHINE='"$(ARCH)"' -DKBUILD_BASENAME=$(subst $(comma),_,$(subst -,_,$(*F))) -c -o init/version.o init/version.c
[20:45:30] <alex_joni> heh
[20:45:31] <alex_joni> yup
[20:46:01] <Phydbleep> cat /proc/self/environ ?
[20:46:29] <Jymmm> rm /*
[20:46:59] <Phydbleep> * Phydbleep is all in favor of using /proc to resolve identity issues.
[20:48:06] <Jymmm> * Jymmm steals Phydbleep identity
[20:48:34] <Phydbleep> * Phydbleep waits for the screams when the bill collectors call..
[20:48:39] <Phydbleep> SUCKER! :)
[20:49:30] <Jymmm> heh
[20:51:22] <A-L-P-H-A> anyone know how to change the origin point in visual mill?
[20:51:42] <alex_joni> didn't you already ask that?
[20:56:11] <A-L-P-H-A> no
[20:56:17] <A-L-P-H-A> found it though
[20:57:38] <Phydbleep> jmkasunich: Can you ID it from the kernel, gcc or libc version ??
[20:58:27] <jmkasunich2> I have no idea
[20:59:01] <jmkasunich2> part of the problem is a desire to compile for kernels other than the one you are running at the time
[20:59:18] <Phydbleep> /proc/self/maps gives the libc and ld versions.
[20:59:28] <jmkasunich2> for instance, you may have both a 2.4 non-realtime kernal, and a 2.6 one with realtime patches, on the same box
[20:59:30] <alex_joni> jmk: seems RTAI uses CONFIG_KBUILD to figure this out
[20:59:38] <alex_joni> can't find from where it gets it yet
[21:01:03] <alex_joni> darn
[21:01:11] <alex_joni> case "$RTAI_LINUX_VERSION" in
[21:01:12] <Phydbleep> alex_joni: The only place I can find it is as an ifdef.
[21:01:18] <alex_joni> 2.4.*)
[21:01:25] <alex_joni> unset CONFIG_KBUILD
[21:01:28] <alex_joni> ;; 2.6.*)CONFIG_KBUILD=y
[21:01:41] <alex_joni> seems rtai assumes KBUILD only for 2.6
[21:01:57] <alex_joni> at least rtai-3.2-test2 does
[21:02:20] <alex_joni> jmk: I think this should do for now, and we'll fix it properly later
[21:02:26] <jmkasunich2> well we already have MODULE_EXT which is .o for 2.4 and lower, and .ko for 2.6 and up
[21:02:29] <Phydbleep> Will kbuild from 2.6.x work with 2.4.x?
[21:02:37] <jmkasunich2> dunno
[21:02:42] <alex_joni> that's ok too
[21:02:55] <jmkasunich2> I've been told that kbuild can be used on 2.4.27 and higher
[21:03:10] <alex_joni> yes, afaik it has been backported
[21:03:53] <jmkasunich2> I think we should add one more variable to Makefile.inc:
[21:04:02] <Phydbleep> So.. If kernel = 2.6 and target > 2.4.27 use kbuild.
[21:04:06] <jmkasunich2> BUILD_SYS=normal or
[21:04:16] <jmkasunich2> BUILD_SYS=kbuild
[21:04:41] <jmkasunich2> for now ./configure can set it simply based on .o vs .ko, or on <2.6 vs 2.6
[21:04:53] <alex_joni> right
[21:05:06] <jmkasunich2> if later we find a way to deal with the 2.4.27 situation, we change it in ./config, and the makefiles are untouched
[21:05:28] <alex_joni> know this fellow : https://mail.rtai.org/pipermail/rtai/2004-April/007288.html ?
[21:05:28] <Phydbleep> --BUILD_SYS==kbuild, default to normal?
[21:05:51] <jmkasunich2> the nasty part about 2.4.27 is that I think kbuild is optional there, so you can't assume one way or the other
[21:07:32] <jmkasunich2> yeah, I've talked to that guy once or twice
[21:08:21] <alex_joni> heh
[21:08:24] <Phydbleep> So assume normal for <2.6 unless specified on the command line.
[21:08:32] <jmkasunich2> alex: should I add BUILD_SYS to ./configiure.in, ./configure, and Makefile.inc.in, or are you doing it?
[21:08:35] <alex_joni> works as a quick fix for now
[21:08:44] <alex_joni> lemme check if I got autoconf ;)
[21:08:58] <jmkasunich2> if you haven't started it, I'll do it
[21:09:21] <alex_joni> let me.. I'll do it fast :D
[21:09:26] <alex_joni> try the HAL stuff instead
[21:09:27] <jmkasunich2> ok
[21:09:42] <jmkasunich2> try it as in try running it?
[21:09:48] <alex_joni> yup
[21:09:59] <jmkasunich2> I know halcmd loadrt is busted, cause the modules aren't where they're supposed to be
[21:10:12] <alex_joni> try loading the modules manually
[21:10:20] <jmkasunich2> I expect the realtime script is busted too, for the same reason
[21:20:07] <jmkasunich2> crap... the afternoon is almost over
[21:20:14] <jmkasunich2> I need to fix a pipe before it gets dark
[21:20:26] <alex_joni> it's pretty dark over here
[21:20:26] <alex_joni> :D
[21:20:26] <jmkasunich2> I'll tackle this a little more later tonight
[21:20:32] <alex_joni> ok
[21:20:42] <alex_joni> last I tried I could insmod rtapi.ko
[21:20:51] <jmkasunich2> that's a good sign
[21:21:00] <alex_joni> but when I insmod'd hal_lib.ko it complained about missing symbols
[21:21:07] <jmkasunich2> all the scripts are gonna need fixed so they can find things
[21:21:11] <alex_joni> (symbols that should be in rtapi.ko)
[21:21:22] <alex_joni> I know that ;)
[21:21:32] <jmkasunich2> 2.6 may require explicitly exporting the symbols... I'll look into that
[21:21:38] <alex_joni> commiting that BUILD_SYS now
[21:22:05] <jmkasunich2> I have the 3rd edition of LDD which covers symbol exports, if changes are needed in xxx_rtapi.c I'll take care of them
[21:22:18] <alex_joni> btw.. there is an extra rule now
[21:22:25] <alex_joni> before kbuild takes over
[21:22:36] <alex_joni> rtai_rtapi.c gets hardlinked to rtapi.c
[21:22:44] <alex_joni> so the module is called rtapi.ko
[21:22:58] <alex_joni> rtai_rtapi.c would produce rtai_rtapi.ko
[21:23:04] <alex_joni> that would be bad ;)
[21:23:11] <alex_joni> or ugly
[21:24:17] <jmkasunich2> why hardlink instead of symlink?
[21:24:28] <alex_joni> dunno...paul_c did it
[21:24:35] <alex_joni> maybe gcc complains on symlinks?
[21:24:49] <jmkasunich2> could be, I don't know much about links
[21:25:15] <alex_joni> afaik a hardlink can't be told from a normal file
[21:25:19] <alex_joni> a symlink is visible
[21:28:49] <Phydbleep> Hardlink allows locking.. Symlinks are iffy about it.
[21:29:08] <alex_joni> see.. I knew hardlinks are better
[21:30:30] <alex_joni> jmk: hal_motenc produces some warnings about uninitia
[21:30:35] <alex_joni> unused variables
[21:31:36] <Phydbleep> alex_joni: Ignore them for now and rip them out later? It's just a few bytes of memory.
[21:31:44] <alex_joni> sure
[21:32:01] <alex_joni> but.. the NICE & CLEAN build system gets interrupted by warnings
[21:32:05] <alex_joni> not very nice ;)
[21:32:14] <alex_joni> with emc2 you can count the warnings
[21:32:21] <alex_joni> on your fingers that is
[21:32:22] <alex_joni> :D
[21:32:57] <Phydbleep> Ahh.. Thought this was an operational test, not a console de-spam. :)
[21:33:08] <alex_joni> lol
[21:33:59] <Phydbleep> Console spam is easy to deal with.. '/bin/sh ./foo >> /dev/null' :)
[21:34:43] <alex_joni> heh
[21:34:45] <Phydbleep> Hehehe.. Or just turn hte monitor off for a while. :)
[21:36:39] <alex_joni> or switch console
[21:36:53] <alex_joni> I use make -s ;)
[21:44:17] <Imperator_> * Imperator_ had a nice phone talk with a nice girl
[21:44:55] <alex_joni> heh
[21:45:02] <alex_joni> does she write modules?
[21:45:02] <alex_joni> :D
[21:45:47] <Imperator_> hope not :-)
[21:48:35] <Imperator_> ok, have to do a cvs update
[21:48:46] <alex_joni> wait a bit
[21:48:51] <alex_joni> * alex_joni is just commiting
[21:49:19] <Imperator_> k
[21:53:35] <alex_joni> any minute now
[21:53:43] <alex_joni> btw.. does the splash work for you on emc2?
[21:56:11] <alex_joni> hmmm.. seems CIA doesn't report updates on IRC anymore
[21:56:13] <alex_joni> :(
[21:56:55] <alex_joni> Hey Stephen
[21:57:01] <Imperator_> fighting a bit withbdi-4.18
[21:57:12] <Imperator_> hi stephen
[21:57:16] <SWPadnos> ni there - just in for a few minutes (I'm in Dallas on business)
[21:57:34] <SWPadnos> logger_aj, bookmark
[21:57:34] <SWPadnos> See http://193.226.12.129/irc/irc.freenode.net:6667/emc/2005-05-07#T21-57-34
[21:57:45] <SWPadnos> I just couldn't remember the address for your logger :)
[21:58:20] <alex_joni> it's actually solaris.cs.utt.ro
[21:59:18] <A-L-P-H-A> dmess, metalsupermarkets in oshawa, is now "metals plus". damn.
[22:00:04] <SWPadnos> see ya
[22:00:10] <alex_joni> bye
[22:01:32] <A-L-P-H-A> wow. my sister got into med school.
[22:01:52] <alex_joni> nice
[22:02:07] <A-L-P-H-A> I'm actually happy for her.
[22:02:21] <alex_joni> hope it's not psych med school..
[22:02:31] <alex_joni> * alex_joni is afraid for A-L-P-H-A
[22:02:37] <A-L-P-H-A> uhuh.
[22:02:40] <alex_joni> she might figure out what's wrong with u
[22:02:41] <alex_joni> :D
[22:02:42] <A-L-P-H-A> I'm more affraid of mastercam!
[22:02:46] <A-L-P-H-A> it's soooo not user friendly.
[22:02:46] <alex_joni> lol
[22:03:20] <A-L-P-H-A> I've got two tool processes. one to machine a pocket, and the other to surface rough out the remainder of the part.
[22:03:28] <Phydbleep> * Phydbleep is more afraid of med students.. They tend to develop a really sick sense of humor..
[22:03:34] <alex_joni> heh
[22:03:34] <Imperator_> use TEBIS
[22:03:48] <alex_joni> Hey Martin.. still around?
[22:03:51] <A-L-P-H-A> she's in Boston... a good MANY hours drive.
[22:03:52] <Imperator_> jep
[22:04:00] <A-L-P-H-A> Imperator_, what's tebis?
[22:04:09] <Imperator_> www.tebis.de
[22:04:15] <alex_joni> did you co ?
[22:04:25] <Imperator_> the BEST CAM tool on this planet
[22:04:42] <alex_joni> heh
[22:04:51] <alex_joni> * alex_joni meant checkout emc2
[22:04:58] <Imperator_> maybe in a other galaxi there is a beter one
[22:05:02] <Imperator_> �h nope
[22:05:12] <Imperator_> need one more moment
[22:05:48] <Imperator_> BDI4-18 does not start up kde as non root here
[22:06:08] <alex_joni> install 4.20 :D
[22:06:25] <Phydbleep> * Phydbleep switched to TWM on his 4.20 test system.
[22:06:46] <alex_joni> TWM?
[22:06:50] <alex_joni> why is that?
[22:07:16] <alex_joni> why do you like to torture yourself? :D
[22:07:18] <Phydbleep> Loads in ~1/10'the the time it takes kde on this P-II 300.
[22:07:34] <alex_joni> I use windowmaker on slow machines
[22:08:31] <Phydbleep> I default back to twm because that was the wm I started with way back when. :)
[22:09:20] <Phydbleep> * Phydbleep has been running linux since kernel 0.96b. :)
[22:09:22] <alex_joni> heh .. yeah
[22:09:25] <alex_joni> nice
[22:09:35] <alex_joni> early starter :D
[22:10:23] <alex_joni> I only started with RH5 or so
[22:10:25] <Phydbleep> WTH was i supposed to run? 3.1/3.11 was a wreck and wouldn't run for more than 5-6 hours without a crash.
[22:10:40] <alex_joni> lol
[22:11:13] <robin_sz> ive never really got on with KDE
[22:11:17] <robin_sz> bloated.
[22:11:27] <robin_sz> although, kmail is nice.
[22:11:28] <alex_joni> take a pill :)
[22:11:34] <robin_sz> red or blue?
[22:11:44] <robin_sz> ahh, stuff it
[22:11:47] <alex_joni> take the red pill
[22:11:48] <robin_sz> I'll take both
[22:11:54] <alex_joni> lol
[22:12:01] <Phydbleep> I wanted an alarm clock on the pc.. (When I wasn't madly fragging in DOOM) and then slip/ppp made it multitask through a modem. :)
[22:12:11] <alex_joni> btw.. robin: care to look at my site ?
[22:12:18] <alex_joni> was wondering what you think of it
[22:12:22] <alex_joni> www.robcon.ro
[22:12:37] <alex_joni> probably you won't understand anything of it.. but still ;)
[22:12:39] <robin_sz> * robin_sz looks
[22:12:50] <Phydbleep> * Phydbleep looks too.
[22:13:52] <Imperator_> A-L-P-H-A: whats your problem with mastercam
[22:14:11] <Phydbleep> Bleah.. Flash.. :\
[22:14:16] <robin_sz> mmmm ... nice grpahics
[22:14:20] <alex_joni> only on the first page
[22:14:42] <Phydbleep> * Phydbleep locates the sitemap link.
[22:14:48] <robin_sz> yeah, thats OK, they are not for navigation (which is a sin)
[22:15:16] <alex_joni> what is a sin?
[22:15:35] <alex_joni> Phydbleep: that was hard ;)
[22:16:15] <Imperator_> * Imperator_ has forgotten how to checkout a branche
[22:16:31] <alex_joni> co -r kbuild-0-1 emc2
[22:16:48] <Imperator_> thx
[22:17:08] <Phydbleep> alex_joni: Hey man.. If I want any crap out of you, I'll send you an mp3 of the "Brown Noise".. <JK> :)
[22:17:20] <robin_sz> alex_joni: using flash for navigation is mostly a sin
[22:17:24] <alex_joni> brown noise?
[22:17:34] <alex_joni> I don't use any flash for navigation
[22:17:40] <robin_sz> I know
[22:17:41] <alex_joni> ;)
[22:17:48] <Phydbleep> alex_joni: Sub-sonic pants filler. :)
[22:17:58] <alex_joni> I am aware that there are people who don't have flash
[22:18:06] <robin_sz> right
[22:18:13] <robin_sz> rare, but it happens
[22:18:22] <alex_joni> http://www.nedstatbasic.net/s?tab=1&link=1&id=2071331
[22:18:26] <robin_sz> apart from that, it is graphically nice
[22:18:31] <robin_sz> I like it
[22:18:43] <alex_joni> 71% of my visitors do have it
[22:18:49] <alex_joni> so it's not that many ;)
[22:18:49] <Phydbleep> * Phydbleep uses lynx for a lot of browsing just to get away from all the crap sometimes.
[22:19:05] <alex_joni> lynx is nice
[22:19:08] <alex_joni> w3m too
[22:19:13] <Phydbleep> FAST! :)
[22:19:18] <alex_joni> I use them both
[22:19:25] <alex_joni> mostly on ssh's ;)
[22:19:39] <alex_joni> last time I checked it worked with lynx too
[22:19:43] <robin_sz> some of the fonts are a bit small to read ...
[22:19:49] <Phydbleep> Yeah, Like a charm. :)
[22:20:28] <alex_joni> robin: glad you like it
[22:20:44] <robin_sz> looks nice and consistent all the way through too
[22:20:45] <alex_joni> there are 2 sections (sudura - welding & vopsire - coating)
[22:21:00] <robin_sz> I found em
[22:21:10] <robin_sz> airless spraying is neat technology
[22:21:14] <alex_joni> yeah
[22:21:23] <alex_joni> poweder coating is pretty much missing
[22:21:29] <alex_joni> I need to add a lot of info there
[22:21:33] <robin_sz> yeah, messy stuff :)
[22:21:39] <alex_joni> heh
[22:21:45] <Imperator_> alex_joni: is it normal that it don't find the realtime enviroment ?
[22:21:55] <alex_joni> hmmm.. not really
[22:21:57] <Imperator_> on BDI4-18
[22:21:57] <Phydbleep> alex_joni: Whats a 'vopsire' ?
[22:22:01] <alex_joni> smthg must be messed up
[22:22:10] <alex_joni> vopsire = coating
[22:22:14] <alex_joni> or painting
[22:22:24] <Phydbleep> Ah powder coat/paint?
[22:22:35] <alex_joni> powder / spray
[22:22:39] <robin_sz> alex_joni: a friend just picked up a nioce contract to desing a powder oven, someone saw the one he built for himself and liked it so much, they want one for their factory
[22:22:47] <alex_joni> nice
[22:22:59] <robin_sz> infra-red,
[22:23:05] <alex_joni> heh.. reminds me of a customer of mine
[22:23:08] <robin_sz> now .. theres a nice little product
[22:23:15] <Phydbleep> * Phydbleep needs to build a pizza oven..
[22:23:19] <alex_joni> uses a bread oven to cook his parts
[22:23:20] <alex_joni> :D
[22:23:24] <robin_sz> heh
[22:23:28] <alex_joni> one of those industrial pastery
[22:23:33] <alex_joni> pretty big
[22:23:36] <alex_joni> but nice
[22:23:41] <Phydbleep> Pizza oven works better that the bread oven..
[22:23:46] <robin_sz> this is a big box I have .. say 1m x 1m x 2m
[22:23:48] <Phydbleep> s/that/than
[22:23:50] <alex_joni> yeah.. but it's small
[22:24:10] <robin_sz> it has 50 of those 500W halogen lamps
[22:24:14] <alex_joni> kinda like that (2m tall, 1.5 wide, 0.75 deep)
[22:24:26] <robin_sz> you know, the ones used for domestic flood lights?
[22:24:27] <alex_joni> heh.. PWM it for a tanning saloon
[22:24:31] <alex_joni> yeah
[22:24:39] <robin_sz> wired in series
[22:24:39] <Phydbleep> * Phydbleep is thinking 2m W x 1m D x .5m H
[22:24:40] <alex_joni> ultra fast tanning
[22:24:46] <robin_sz> so they run at ha;f volts
[22:25:01] <alex_joni> get somebody inside, run it for 30 secs... done ;)
[22:25:07] <robin_sz> yeah
[22:25:16] <robin_sz> very very effective for powder coat
[22:25:23] <alex_joni> run it for 5 mins. and they're toast :)
[22:25:33] <Phydbleep> Hehehe... Sell that puppy to the fast food places for a warmer. :)
[22:25:40] <robin_sz> the peak emmission of the lamps is about right for the powder
[22:25:47] <alex_joni> cool
[22:25:56] <alex_joni> * alex_joni plans to add more graphics to the site
[22:26:07] <alex_joni> I want almost every page to have it's own graphic on top
[22:26:09] <robin_sz> has a lot of methyl <mumble> which soaks up the IR like a sponge
[22:26:10] <Phydbleep> alex_joni: That your company?
[22:26:17] <alex_joni> based on the products on the page
[22:26:24] <alex_joni> Phydbleep: yup
[22:26:32] <alex_joni> well.. not mine ;) but I work there
[22:26:35] <Phydbleep> robin_sz: Cl?
[22:26:38] <alex_joni> it's my dad's actually
[22:27:02] <robin_sz> alex_joni: lots and lots of small producers wold love a small, efficient powder oven
[22:27:15] <alex_joni> I agree
[22:27:24] <Phydbleep> alex_joni: Hehehe.. You can send me one of anything 250V < 30A for testing. :)
[22:27:29] <alex_joni> seems root is around.. watch your language
[22:27:42] <root> :-)
[22:27:52] <robin_sz> alex_joni: I'll take some pictures of my oven, it might be interesting
[22:27:55] <root> root is now known as Imperator_on_BDI
[22:28:08] <alex_joni> you know it's not safe to run as root
[22:28:11] <alex_joni> don't you Martin
[22:28:15] <robin_sz> he does
[22:28:19] <Imperator_on_BDI> jep thats me alex
[22:28:22] <alex_joni> robin: sure.. send em over
[22:28:25] <Phydbleep> * Phydbleep whacks Imperator_on_BDI for irc'ing as root.
[22:28:42] <alex_joni> who else could that be with such a nice address: p549DEDAB.dip.t-dialin.net
[22:28:43] <Imperator_on_BDI> kdi don't starts up on theis bdi-4.18 box
[22:28:59] <Imperator_on_BDI> heh
[22:29:12] <alex_joni> well.. I'm going to bed
[22:29:13] <Phydbleep> Imperator_on_BDI: Start as a different user and "su" in a console.
[22:29:18] <alex_joni> I'll be back later
[22:29:28] <Imperator_> * Imperator_ this is Imperator on doze
[22:29:30] <Phydbleep> G'nite alex_joni
[22:29:42] <alex_joni> yay.. 2.18 builds again ;)
[22:30:06] <alex_joni> http://www.linuxcnc.org/compile_farm/
[22:30:29] <robin_sz> alex_joni: my only comment on your stylesheets is watch those 10px fonts ... its VERY small on my 1600x1200 screen
[22:31:17] <alex_joni> >= 1600 x 12002.6 %
[22:31:35] <alex_joni> seems you are a VERY small minority ;)
[22:31:40] <alex_joni> but I take the point
[22:32:09] <robin_sz> the only time it is OK to specify fonts in pixels is when they are used in combination with soem grapics elements
[22:32:23] <Phydbleep> Woohoo! I'm a minortity now. :)
[22:32:32] <robin_sz> ie a the font needs to fits with soem elelemtn of a gif/png/whateever
[22:32:38] <alex_joni> LOL
[22:33:03] <robin_sz> otherwise, use pt
[22:33:03] <alex_joni> who figures out where: I'm zestier nob. comes from ?
[22:33:12] <alex_joni> ok
[22:33:14] <alex_joni> will do
[22:33:43] <robin_sz> alex_joni: that also means windows users can do the ctrl-mousewheel to zoom them up and down in size if they are hard to read for them etc
[22:34:15] <robin_sz> but that doesnt work for px fonts
[22:34:24] <alex_joni> right
[22:34:51] <alex_joni> ctrl + works in Firefox
[22:36:08] <Imperator_on_BDI> hm what is the path to the realtime stuff on bdi4.18 ?? thought it is /usr/lib/....
[22:36:19] <alex_joni> usr/lib/realtime
[22:36:34] <alex_joni> try : configure --with-rtai=/usr/lib/realtime
[22:37:03] <alex_joni> Hyped pleb
[22:37:19] <alex_joni> Hey! Bled PP
[22:37:20] <A-L-P-H-A> Imperator_, I don't know... just that I haven't done much with it yet. I've created a few tool paths, just wondering if I can get away with just using one tool, to do the whole thing. like a 1/4" endmill, and just mill out the whole part. http://www.lloydleung.com/gallery/current/bracket.zip is the part I'm trying to mill out.
[22:37:44] <alex_joni> http://www.220.ro/gimme_the_stuff.php?lid=1671&cn=Anagrame
[22:38:12] <robin_sz> hmmm .. now I know my laser cuts 8mm plate so well, I want to try 10mm
[22:38:44] <Phydbleep> robin_sz: Hehehe.. want a test pattern?
[22:38:59] <robin_sz> well ...
[22:39:13] <robin_sz> you are inthe US?
[22:39:41] <alex_joni> LOLOL
[22:39:41] <alex_joni> 'Paul Corner'
[22:39:42] <alex_joni> anagrams to
[22:39:42] <alex_joni> 'Pro-nuclear.'
[22:40:53] <alex_joni> anyways
[22:40:57] <alex_joni> going to bed now
[22:40:59] <alex_joni> night guys
[22:41:04] <robin_sz> C U real porn?
[22:41:11] <Phydbleep> G'nite.
[22:41:29] <Imperator_> night alex
[22:41:29] <Phydbleep> c porn u lear
[22:42:43] <Phydbleep> Hmm... Time to go out in the fron yard and mow the lumps.. bbiaw.
[22:42:54] <robin_sz> k
[22:43:15] <robin_sz> * robin_sz wonders how hard a 5 axis mill would be to make
[22:43:52] <Phydbleep> Not as much of a pita as a 8 axis. :)
[22:43:58] <Imperator_> can't import that dwg stuff
[22:44:34] <Imperator_> if you have a iges or vda file, maybe i can help, but dwg and DXF is terrible
[22:44:57] <Imperator_> Pro/e does not read it
[22:48:32] <robin_sz> * robin_sz prefers solidworks
[22:50:37] <robin_sz> dxf is only a text version of dwg and is not a solid model language
[22:50:42] <robin_sz> its wireframe
[22:51:03] <robin_sz> no real way to determine what is solid easily
[22:51:38] <robin_sz> thers 3 basic sorts of modeler
[22:51:58] <robin_sz> wirefram (autocad) which is basically 2d that has been extended in a crap way
[22:52:09] <robin_sz> surface modelers (like Rhino)
[22:52:19] <robin_sz> and true 3d modelers like Solidworks
[22:52:37] <robin_sz> or solid modelers I should say
[22:53:11] <robin_sz> tebis looks neat
[22:53:35] <Imperator_> dxf and dwg are making a lot of trouble if you use it as a exchange format with 3d stuff
[22:53:59] <Imperator_> tebis is only a surface modeler
[22:54:16] <robin_sz> yeah
[22:54:26] <robin_sz> dxf and dwg are basically extended 2d
[22:54:35] <robin_sz> tebis can do 5 axis though
[22:54:41] <robin_sz> thats someting
[22:54:45] <Imperator_> because it is made to produce good and high quality surfaces and to mill that parts
[22:54:48] <robin_sz> bet it is VERY expensive
[22:55:06] <Imperator_> yup basic version 20000EUR
[22:55:12] <robin_sz> gulp
[22:55:22] <robin_sz> thats without 5 axis?
[22:55:26] <Imperator_> 30000-60000 for a version you can use
[22:55:35] <robin_sz> wow
[22:55:48] <robin_sz> makes solidworks look cheap!
[22:56:35] <Imperator_> but the price is ok
[22:56:44] <Imperator_> you get a lot for it
[22:57:26] <Imperator_> and they say for customers who produce high class moulds and so on it is not that much
[22:58:43] <dave-e> yes, it makes a difference whether you do one-off and the code needs to constantly change or you a program and use
[22:58:46] <dave-e> it forever
[22:59:06] <Imperator_> but they have a bit a problem with selling it, because the way they write software is not so goot for the people who has to sell the product
[22:59:22] <robin_sz> well
[22:59:28] <robin_sz> in business ...
[22:59:29] <dave-e> user issues?
[22:59:39] <robin_sz> sales are the no1 driving force
[22:59:52] <robin_sz> everything else must come 2nd place
[23:00:07] <Imperator_> the problem is that when tebis offers a new module it is stable and well tested, and that takes time
[23:01:22] <Imperator_> all the others implement it, that the seller can go to the customer and can say here we have what you need, then he buys it and after some weeks he noticed that it dont work
[23:01:46] <dave-e> oh, like MS
[23:01:55] <Imperator_> in ProE half of the features are not working
[23:02:41] <dave-e> compare solidworks, pro-E and Gibbs..
[23:02:56] <Imperator_> the problem of tebis is that you only figure out how good it is when you use it, thats why it is not good for the sellers
[23:03:07] <Imperator_> Gibbs ???
[23:03:13] <dave-e> cam
[23:03:52] <punk84> wow google's down
[23:04:16] <dave-e> up here
[23:04:40] <punk84> really? thats strange
[23:04:43] <Imperator_> looks like of one of this low end cam programms
[23:06:46] <dave-e> so solidworks doesn't have a cam component
[23:06:52] <dave-e> ?
[23:07:37] <Imperator_> they have solidcam
[23:07:48] <dave-e> oh...
[23:07:49] <Imperator_> or it is a standalone company
[23:07:59] <Imperator_> but they sell tis one
[23:08:03] <Imperator_> this
[23:08:18] <Imperator_> but tebis is another class like this
[23:08:45] <Imperator_> you can more compare it with mastercam, worknc and so on
[23:09:06] <Imperator_> but i don't know how strong the CAM part of mastercam is
[23:09:13] <dave-e> maybe tebis and catia are in the same class?
[23:09:30] <Imperator_> tebis is also very good for designing complicated surfaces
[23:09:58] <Imperator_> catia is one of that all in one solutians, i don't trust them
[23:10:03] <Imperator_> like proE
[23:10:22] <Imperator_> they bought there stuff from everywhere
[23:10:44] <dave-e> Boeing and their contractors tend to use Catia
[23:10:51] <Imperator_> tebis makes everything by themself, every codeline is writem by themself
[23:11:21] <Imperator_> for example PTC they don't know there code anymore
[23:11:45] <Imperator_> they fix one bug in ProE and produce five more
[23:12:19] <Imperator_> ProE 2000i was the best, every week another adventure
[23:15:55] <Imperator_> PTC makes every two or three weeks a new relise of ProE, but tell me how can they test the software so fast !!! -> they don't
[23:16:43] <Imperator_> i know it from Siemens that there programming software for there PLCs has about 30 000 test points, only to run the test takes about two weeks
[23:17:03] <Imperator_> without fixing the bugs
[23:17:21] <Imperator_> and ProE is much !!! more complex
[23:31:50] <Phydbleep> Bleah! Remind me never to plug the lawn mower into the living room circuit again.. :\
[23:33:53] <Phydbleep> Can anyone hit http://68.35.143.93 ?
[23:39:21] <Jymmm> plug?
[23:39:29] <Jymmm> you wuss! gas
[23:40:11] <Imperator_> Phydbleep: whats with that page ?
[23:41:28] <Phydbleep> Hehehe.. Just what it says. :)
[23:41:51] <Imperator_> the java pligin doesnt work
[23:42:40] <Phydbleep> dOMAIN NAME LAPSED.
[23:42:48] <Phydbleep> Argh.. !
[23:42:49] <robin_sz> hehe
[23:43:05] <robin_sz> well, you probably lost it then
[23:43:23] <Phydbleep> * Phydbleep wonders if a wireless kb in a high rf enviroment is such a good idea after all..
[23:43:58] <robin_sz> anyting with many good search engine hits will b picked up by a link-far, in under 10 minutes from de-registering
[23:44:12] <robin_sz> link-farm
[23:45:13] <Jymmm> happen to me, I was/so pissed about that.
[23:45:14] <robin_sz> hmm .. I must studdy how 5 axis head work
[23:45:45] <robin_sz> yeah
[23:45:58] <Phydbleep> I must find a different outlent and finish mowing.
[23:46:03] <robin_sz> they only warn you a month or so before it expires, and then hold it for a further 90 days
[23:46:06] <Phydbleep> outlet
[23:46:17] <robin_sz> I mean, thats only like 120 days,
[23:46:22] <Jymmm> robin_sz up to 30 days now
[23:46:51] <robin_sz> Jymmm: for .coms?
[23:46:55] <Phydbleep> * Phydbleep is not really worried about it..
[23:46:57] <Jymmm> yeah
[23:47:37] <Jymmm> Now, I have some of my domains registered for like 10 years.
[23:47:47] <robin_sz> I use ukreg
[23:48:02] <robin_sz> leave em the CC, they warn you and then do it automatically
[23:48:12] <Jymmm> this was back in the verisgn days
[23:48:15] <robin_sz> ick
[23:48:22] <robin_sz> verisign. now .. they suck
[23:48:34] <robin_sz> all those silly forms
[23:48:41] <Jymmm> yeah, submitted an email change that never went thru, so I missed the reminders till it was too late.
[23:49:01] <robin_sz> that company deserves to die
[23:49:10] <Jymmm> tell me about it.
[23:49:33] <Jymmm> at least it's better now.
[23:50:21] <robin_sz> better yes
[23:50:28] <robin_sz> but mainly because I dont use it
[23:50:55] <robin_sz> I pulled my last domains from them when they did that DNS stupidity
[23:51:07] <Jymmm> I did it long before then.
[23:51:59] <robin_sz> now I fancy building a 5 axis router
[23:52:32] <Jymmm> you wuss.... 6 axis!
[23:53:14] <robin_sz> 8mm plate an a welding head
[23:53:36] <Jymmm> how do you even design something to be produced on a 5 axis machine?!
[23:53:44] <Jymmm> or 6 axis
[23:53:53] <robin_sz> easy
[23:54:16] <robin_sz> like the rifle handgrips Im doing at the moment
[23:54:25] <robin_sz> they would come out so much quicker on 5 axis
[23:54:56] <robin_sz> they take 30 minutes on 3 axis
[23:55:44] <Jymmm> not an entire gunstoke?
[23:55:46] <Jymmm> stock
[23:56:02] <robin_sz> no, just the pistol grip
[23:56:21] <robin_sz> the stick is another long job on the Hass
[23:56:28] <robin_sz> stock
[23:57:53] <Jymmm> when you get a design down for a Ruger 10/22 let me know
[23:57:57] <robin_sz> * robin_sz searches for a picture
[23:58:07] <robin_sz> hmm
[23:58:12] <robin_sz> this has the old grip ..
[23:58:14] <robin_sz> http://www.hps-tr.com/images/ultraStocks/fr703.jpg
[23:58:21] <robin_sz> the new grip is more complex
[23:58:49] <robin_sz> ach, the 10/22 is a toy
[23:59:15] <Jymmm> why, becasue it's .22 ?
[23:59:15] <robin_sz> fun, but low accuracy
[23:59:38] <robin_sz> nah, because its got a poor barrel, and a semi auto action
[23:59:39] <Jymmm> toss on an aftermarket barrel