#emc | Logs for 2006-07-26

[01:15:05] <linuxNewbie> help
[01:15:58] <linuxNewbie> h.ello
[01:17:33] <linuxNewbie> I missed a step when I install rtlinux but I think I got it, but when I run make from emc it gives me rtl_ulapi error
[01:40:02] <jmkasunich> logger_aj: bookmark
[01:40:02] <jmkasunich> See
[02:09:21] <cradek> hi jmk
[02:09:28] <cradek> got my switch mounted, just doing the config now
[02:09:50] <cradek> may not sound exciting to anyone but me, but I've never had a home switch before
[02:28:14] <A-L-P-H-4> A-L-P-H-4 is now known as A-L-P-H-A
[02:53:39] <cradek> cool, when I smash the tool into something, I get a following error
[02:55:16] <jmkasunich> and a gouge in the something?
[02:55:46] <cradek> and a broken tool in this case
[02:55:51] <jmkasunich> oops
[02:55:52] <cradek> but no big deal
[02:56:03] <cradek> I learned HOME = 0 is a bad idea
[02:56:06] <jmkasunich> easily replacable tool?
[02:56:10] <cradek> yeah
[02:56:42] <jmkasunich> I busted one of my tools not too long ago, bummed me out
[02:56:48] <jmkasunich> because I'll have to re-grind it
[02:56:56] <cradek> a special one?
[02:56:59] <jmkasunich> it was a grooving tool, about 0.050 wide
[02:57:05] <jmkasunich> ground from HSS
[02:57:33] <jmkasunich> I need 8 such grooves for this project I'm working on
[02:57:49] <cradek> the sherline parting tool is .04, I'd be surprised if you can't get a .05 one
[02:58:03] <jmkasunich> then you need a holder for it...
[02:58:14] <cradek> true
[02:58:16] <jmkasunich> this is just ground out of a 3/8 square toolbit
[02:58:29] <cradek> how deep are the grooves?
[02:58:29] <jmkasunich> probably cuts 0.1 deep max (or it did before I dropped it)
[02:58:35] <cradek> ack
[02:58:50] <cradek> I like to drop center drills
[02:58:51] <jmkasunich> they're for E-ring retainers on 3/4" diameter rods
[02:59:01] <cradek> ah, so not very deep
[02:59:10] <jmkasunich> nope, maybe 1/16 at most
[02:59:38] <jmkasunich> what really bummed me out is that it was one of the tools my dad gave me
[02:59:49] <jmkasunich> he's far better at grinding things than I am
[03:00:10] <cradek> crap
[03:00:49] <jmkasunich> he gave me an old toolbox with about 100 misc pieces of HSS in it
[03:00:58] <jmkasunich> ground into every imaginable shape
[03:01:10] <jmkasunich> (he was a machinist in a steel mill for 40+ years)
[03:01:47] <cradek> cool
[03:02:12] <cradek> so you inherited your machinistism
[03:05:24] <jmkasunich> yeah
[03:05:38] <jmkasunich> except I think you just invented that word
[03:07:07] <cradek> yep
[03:08:45] <jmkasunich> so, are you making use of home_offset now? ;-/
[03:09:20] <cradek> it's HOME that was the problem
[03:09:23] <cradek> that's where it goes at the end
[03:09:44] <jmkasunich> I guess its a matter of perspective
[03:09:45] <cradek> it homes with the tool way out in +x, but then it flew back to x=0 which was inside the work
[03:10:25] <jmkasunich> ah, you want to keep x=0 at the centerline, but you don't want to go there after the homing sequence ends
[03:10:39] <cradek> right
[03:11:31] <jmkasunich> not to distract you from switches, but I'm still procrastating instead of drilling... what did you think of jelper's "screw comp in HAL" idea?
[03:12:45] <cradek> if people have different ideas about how it should be done (lookup table, polygon, ...?), it should be configurable, and that would be the way to do it
[03:12:53] <cradek> polynomial even
[03:13:54] <cradek> his idea of position-in, corrected-position-out does not allow for your backlash stuff
[03:14:05] <cradek> but the idea could be expanded I'm sure
[03:14:11] <jmkasunich> that paper that somebody posted was quite interesting
[03:14:34] <jmkasunich> I'm not interested in neural nets for screw comp, but it covered the entire comp issue well
[03:14:42] <jmkasunich> including existing approaches
[03:14:46] <cradek> nice
[03:14:51] <cradek> sometimes academic papers are very useful
[03:14:57] <jmkasunich> his test data was interesting too
[03:15:13] <jmkasunich> he initially sampled at 1" increments (on a 0.25" pitch leadscrew)
[03:15:21] <jmkasunich> and couldn't get very good results
[03:15:38] <cradek> that means 4tpi?
[03:15:54] <jmkasunich> then he resampled on 0.025" increments, and found that somewhere between 30 and 50% of the error was periodic on the screw
[03:15:57] <jmkasunich> yes, 4 tpi
[03:16:22] <cradek> seems like the first measurements you'd want then would be .25" increments
[03:16:38] <cradek> I wonder if that's typical
[03:16:49] <jmkasunich> hard to say
[03:16:50] <cradek> if so, then the lookup table approach is wholly insufficient
[03:16:54] <jmkasunich> right
[03:17:03] <jmkasunich> although you might combine two lookup tables
[03:17:09] <cradek> yes
[03:17:15] <jmkasunich> one is error as a function of postion along the screw
[03:17:31] <jmkasunich> the other is error as a function of screw angle = position mod pitch
[03:17:38] <cradek> right
[03:22:47] <jmkasunich> wikipedia is fun
[03:22:57] <jmkasunich> Dried mopane worms can be eaten raw as a crisp snack
[03:23:08] <jmkasunich> It is estimated that South Africa alone trades 1.6 million kilogrammes of mopane worm annually
[03:23:17] <jmkasunich> Mopane worms are considered to be a profitable harvest, as a mere 3 kilogramme of feed (mopane leaves) will generally yield 1 kilogramme of mopane worms: in contrast, cattle farming requires 10 kilogrammes of feed to generate 1 kilogramme of beef; thus the worms are a low-cost, low-maintenance, high-protein foodsource
[03:24:39] <jmkasunich> procrastination is evil
[03:24:44] <jmkasunich> * jmkasunich drills holes
[03:25:36] <cradek> bye
[03:37:59] <jmkasunich> 6 holes drilled and tapped 3/8-16
[03:38:26] <jmkasunich> now to drill 14 holes 13/32
[03:48:38] <A-L-P-H-A> jmkasunich, what are you making?
[03:51:48] <jmkasunich> a jig used for testing tile flooring
[03:51:55] <A-L-P-H-A> neat
[03:51:55] <jmkasunich> (paying customer wants two of them)
[03:52:16] <A-L-P-H-A> woohoo! paying customers are only second to RICH paying customers.
[03:52:43] <jmkasunich> except these jigs eat up so much time that I really don't like doing them
[03:53:13] <jmkasunich> assuming I don't waste time, the hourly rate is about the same as my day job
[03:53:29] <jmkasunich> but the time comes out of my personal time
[03:57:26] <cradek> sounds like you're not charging enough
[03:58:06] <A-L-P-H-A> that was what I was thinking.
[03:58:12] <cradek> I think emc-users isn't working again
[03:58:16] <cradek> I sent a post some time ago
[04:02:41] <jmkasunich> looks that way
[04:02:45] <jmkasunich> ain't SF wonderfull
[04:03:00] <cradek> the lists usually work pretty well...
[04:03:01] <jmkasunich> was the post about screw comp?
[04:03:20] <cradek> no, in response to craig about feed modes
[04:03:28] <jmkasunich> ok
[04:03:45] <cradek> I tried to make it "fair and balanced", hope it doesn't set off Mark again
[04:04:01] <jmkasunich> as far as I'm concerned the issue is closed
[04:04:13] <jmkasunich> everyone has admitted that nobody is known to use it
[04:04:20] <cradek> true
[04:04:21] <jmkasunich> when somebody shows up wanting it we can re-open
[04:04:53] <cradek> I guess if others are interested in saying their opinion, I'm happy to listen
[04:05:40] <cradek> only two of us have expressed any opinion at all, and we disagree, so that's hardly a good way to decide an issue
[04:06:50] <cradek> but yeah, I bet nobody uses it, so there's not much point worrying about it either way
[04:07:17] <jmkasunich> seems to me that craig agrees with you that inverse time makes no sense if the move isn't going to completion
[04:07:30] <cradek> yes, seems like
[04:11:32] <jmkasunich> damn
[04:12:06] <jmkasunich> I for my stack-o-plates all carefully aligned and bolted together, ready to drill and ream for dowel pins
[04:12:17] <jmkasunich> and I realized I have the two middle plates in the wrong order
[04:12:46] <A-L-P-H-A> how many emc users are there?
[04:12:56] <cradek> A-L-P-H-A: impossible to say
[04:13:02] <cradek> but signs point to "lots"
[04:13:12] <A-L-P-H-A> we should have spyware in it to call home.
[04:13:16] <A-L-P-H-A> that was a j/k
[04:13:25] <cradek> if we were evil, that would be a great idea
[04:13:31] <cradek> http://www.frappr.com/emc2/
[04:13:36] <cradek> some people have put pins on this map
[04:13:41] <A-L-P-H-A> I did
[04:13:43] <A-L-P-H-A> me me me!
[04:13:50] <A-L-P-H-A> I'm like the only one in the T. area.
[04:13:59] <cradek> 75 of them, looks like
[04:14:40] <cradek> so I'm pretty sure there are >= 75 users
[04:44:42] <jmkasunich> there.... two sets of places, aligned, bolted, and doweled together, ready to match-bore the holes for the guide rods
[04:45:07] <jmkasunich> time for bed I think
[04:45:23] <jmkasunich> s/places/plates
[07:00:38] <A-L-P-H-A> so. um.
[07:01:21] <A-L-P-H-A> www.dd-wrt.com is sill v23 sp2, for €20. But it's available in the alpha_unstable section, being a build from 24/7/2006.
[07:01:30] <A-L-P-H-A> sill=selling
[07:05:44] <A-L-P-H-A> freak'n leech. http://tinyurl.com/pcet5
[09:50:56] <lilo> [Global Notice] Hi all. We're going to suspend new connects for just a few minutes while we work on resolving some cloaking issues. Apologies for the inconvenience.
[10:00:32] <NickServ> This nickname is owned by someone else
[10:00:32] <NickServ> If this is your nickname, type /msg NickServ IDENTIFY <password>
[10:01:52] <lilo> [Global Notice] We're open for new connects again. We'll probably need to do this one more time at some point. Thanks!
[10:38:25] <A-L-P-H-A> http://video.google.com/videoplay?docid=1569125216323959688
[10:53:11] <A-L-P-H-A> what a stupid monkey... http://video.google.com/videoplay?docid=8811551493740102634
[12:42:38] <Mess> hello all..
[12:43:37] <^Eugenics> Hi
[12:48:17] <Mess> whats up
[13:00:14] <^Eugenics> I'm writing some gcode
[13:00:55] <^Eugenics> And what are you up to?
[13:17:12] <Mess> i am playing with some s'ware to verify g code
[13:17:27] <Mess> Vericut
[13:18:02] <Mess> and customizing a postprocessor for a customer
[13:36:22] <etla> f
[13:37:38] <etla> anyone else thinking that [emc-devel] is slow/broken lately ?
[13:38:39] <cradek> you mean the mailing lists? yeah I agree they're not working
[13:38:55] <etla> yes the mailing list
[13:39:15] <etla> cradek: btw I sent a message concernig simple_tp. I'm trying to understand it...
[13:40:52] <etla> here: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?Simple_Tp_Notes
[13:41:30] <cradek> what is your eventual goal?
[13:41:45] <etla> first to understand what is going on.
[13:41:55] <etla> both in simple_tp and what you have in HEAD
[13:42:03] <etla> then hopefully to document it
[13:42:14] <etla> then if I have time try to help with whatever I can
[13:42:40] <etla> my milling projects are usually 3D with lots of small segments so I'm interested in the lookahead performance
[13:42:43] <cradek> if you're interested in trajectory planning, it might be better to start over with a different algorithm
[13:43:09] <etla> oh ? but what you have in HEAD is based on simple_tp ?
[13:43:36] <cradek> or, study what matt timmerman wrote for bdi4emc and investigate what it would take to put it in emc2 if it's suitable
[13:43:52] <cradek> yes it is
[13:44:17] <etla> but you think the current algorithm is limited ?
[13:45:08] <cradek> it gives good performance considering its simplicity, but yes it's not a great algorithm
[13:45:47] <etla> I've seen lots of papers and algorithms for off-line ('beforehand') planning. But the problem is then to incorporate an ever changing feed override
[13:46:01] <cradek> yep
[13:46:08] <cradek> that's a big problem
[13:46:31] <etla> do you know anything about the segmentqueue files in CVS ?
[13:46:35] <cradek> slowing down isn't bad, but speeding up is
[13:46:44] <cradek> in emc1? yes a bit
[13:47:08] <etla> is that the one they are using in emc1/bdi ?
[13:47:24] <jepler> no; apparently Matt Timmermans has written an entirely ne one
[13:47:26] <jepler> new
[13:47:38] <cradek> emc1 and bdi4emc are totally different projects, don't get confused
[13:47:46] <etla> ;)
[13:48:00] <cradek> seriously
[13:48:03] <etla> ok.
[13:48:19] <cradek> emc1 has two planners, segmentqueue and the predecessor of simple_tp
[13:48:45] <etla> in emc2, do you think that the interface is general enough to allow replacement of the current simple_tp-based code
[13:48:47] <cradek> there's a good paper on segmentqueue - you can read all about it
[13:49:17] <cradek> sure you can plug in a different planner
[13:49:26] <cradek> the API is pretty well defined
[13:49:48] <jepler> but the "API" changes over time, too
[13:49:58] <etla> basically there are the addline and addcircle functions which get called from the interp, and then tpruncycle which gets called every traj_period ?
[13:49:58] <jepler> it'll probably change when constant-surface-speed machining is added, for instance
[13:50:25] <etla> or am I missing something important ?
[13:50:54] <cradek> that's the general idea
[13:51:11] <etla> did you have a link to the segmentqueue paper ?
[13:51:23] <cradek> no, but it's in the emc1 cvs somewhere
[13:52:57] <jepler> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/~checkout~/emc/doc/segmentqueue.pdf?rev=1.1;content-type=application%2Fpdf
[13:53:14] <cradek> thanks
[13:53:28] <etla> thanks, looking...
[13:54:26] <jepler> none of the emc1 or emc2 TPs fix the limitation that at most one primitive can be transferred from userspace to kernel space each traj_period
[13:55:20] <etla> is that becoming a limitation ?
[13:55:39] <etla> cradek: do you know enough about segmentqueue to say if it would be the correct choice for emc2 in the future ?
[13:56:16] <cradek> etla: it showed a lot of promise in emc1, but I don't know the answer to your question
[13:56:28] <cradek> it would be nice to study it using the new tools we have in emc2 (halscope etc)
[13:57:12] <etla> do you think it is easier to understand than simple_tp
[13:57:14] <etla> ?
[13:57:25] <cradek> definitely not
[13:57:33] <etla> I find the math in tpRunCycle to not be entirely self-explanatory ;)
[13:58:42] <etla> so do you know why segmentqueue was abandoned apparently for both emc1 and emc2 and bdi4emc ?
[13:59:55] <cradek> for one thing, segmentqueue did not support the rotary axes yet
[13:59:59] <cradek> nobody quite finished it
[14:00:24] <jepler> etla: can you send me an example of a program that is "3D with lots of small segments"?
[14:02:57] <etla> jepler: you might remember FDECK.NC, see: http://www.anderswallin.net/2006/04/the-new-deck-takes-shape/
[14:03:21] <etla> I don't have the g-code here right now, but I guess for comparing TPs it would be good to have a set of benchmark files
[14:05:02] <etla> cradek: I need to leave soon, but can I ask you about simple_tp sometime later. If I can document and understand it fully that is at least a start for further development ?
[14:06:07] <jepler> oh yeah, I do rember fdeck
[14:06:08] <jepler> to decide the direction of development, we have to know what the "bottleneck" is
[14:08:53] <etla> for 3D stuff with a lot of segments lookahead is important. I understand that emc2 now has only lookahead of depth=1 into the motion queue. I saw the posts about bdi4emc being better on the mailing lists...
[14:09:18] <jepler> none of us here has used bdi4emc since that stuff went in
[14:09:27] <jepler> so I can't comment
[14:09:53] <etla> btw. with axis/halscope, can you view the motion queue in realtime ?
[14:10:21] <cradek> you can put any data onto halscope pretty easily
[14:10:26] <etla> or, can you color the segments in axis based on instantaneous velocity ?
[14:10:27] <cradek> I used it to watch the queue depth
[14:11:31] <jepler> the 'sim' configuration does compute the instantaneous XYZ velocity to a HAL pin
[14:11:32] <etla> so it would basically be possible to do worthwile development even in sim-mode
[14:12:12] <cradek> definitely
[14:12:16] <jepler> AXIS has an optional speed display but it's intended to give an impression of the average speed and varies because the polling rate varies
[14:12:40] <etla> right.
[14:13:03] <etla> how big is the memory on halscope ? i.e. could save traces on halscope and then plot later ?
[14:14:05] <jepler> it could be changed, but I think it's around 16000 samples
[14:14:55] <jepler> 16188 samples for 1 channel
[14:14:58] <etla> thanks for the chat guys. I will read the segmentqueue paper and continue with trying to understand simple_tp. bye.
[14:15:15] <jepler> http://emergent.unpy.net/files/sandbox/newspeed2.png
[14:15:29] <jepler> btw here's a graph of speed while running one "row" of 3dchips
[14:15:38] <jepler> the bottom graph is from matt t. showing what bdi4emc does
[14:16:16] <jepler> (they're scaled like that so that "1 second" is about the same number of pixels in each graph; I agree that it looks ugly)
[14:16:57] <etla> that's nice. those kind of plots are exactly rigth for comparing TPs I think.
[14:17:17] <etla> maybe also an fft of the acceleration. that would show how 'jerky' the path/machine is
[14:17:26] <etla> I really need to go now... sorry.
[14:17:29] <jepler> see you
[14:56:19] <BradM> Anybody successfully running EMC on Athlon64 hardware? (32 bit mode okay). Neither the puppy based live CD nor the Dapper based install will run correctly. I've had EMC working on other hardware in the past.
[15:04:02] <cradek> what does it do wrong?
[15:13:06] <BradM> The puppy live CD won't play nice with the Nvidia card, so no X in either mode. Dapper is fine until the manga kernel is installed, then the interrupts are all screwy; it doesn't see anything above 15, which breaks all kinds of stuff:
[15:13:17] <BradM> USB, sound, the mouse (critical), etc.
[15:13:57] <cradek> ok
[15:13:57] <^Eugenics> BradM: Have you tried the Ubuntu install?
[15:14:10] <BradM> I've managed to recompile a Dapper kernel that does work (using config settings closer to the default Dapper kernel), and rebuild rtai modules that load, and I'm now off to recompiling emc
[15:14:18] <BradM> I'm using Ubuntu Dapper.
[15:14:23] <cradek> I've seen a problem with ACPI being turned off causing interrupt problems
[15:14:42] <cradek> legend says you have to turn off ACPI for RTAI
[15:14:47] <BradM> Yep, I tried to force ACPI on, no dice. So then I went the custom kernel route.
[15:14:59] <cradek> yes, it's certainly not compiled in
[15:15:09] <cradek> so you think that's what you changed to make it work?
[15:15:16] <BradM> Unfortunately, I'm newish to Ubuntu (old hand at Suse, RedHat, ... back to SLS).
[15:15:26] <BradM> Yes, that's a top candidate for fixing the OS problem.
[15:15:31] <cradek> ok
[15:15:36] <BradM> I'm fighting with the Ubuntu build system, through.
[15:15:41] <cradek> be sure you have cpu speed scaling still turned off
[15:15:47] <cradek> and memory over a gigabyte
[15:18:37] <BradM> Can anybody point me at a step by step for getting the kernel sources, building them into a package, installing that, then the same for rtai, then the same for emc?
[15:19:20] <BradM> I can manually build and copy things in place. But for example, the kernel scripts don't seem to install the modules correctly.
[15:19:35] <cradek> if you change just the acpi options, I think you can use the existing rtai package, but I'm not sure
[15:19:43] <BradM> And as I keep manually working past problems it's getting worse and worse.
[15:19:43] <^Eugenics> would the prekomiled magma rt kernel run diferently on AMD64?
[15:19:50] <BradM> I'll try that, thanks!
[15:19:56] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UbuntuBreezyPackages
[15:20:06] <jepler> this has a copy of an e-mail cradek wrote about building the kernel and rtai
[15:20:16] <BradM> Eugenics, that's what I started with.
[15:20:30] <BradM> It's the one that doesn't get the interrupts right.
[15:20:38] <cradek> the problem is the hardware needs ACPI to route some interrupts or something, and ACPI is disabled in that kernel
[15:20:40] <jepler> I recompiled the kernel with ACPI support (needed for wireless and maybe usb on my laptop) and still use the rtai package
[15:20:54] <cradek> that's very encouraging
[15:21:08] <BradM> Sounds like a consensus on that one. I'll try it. Thanks!
[15:21:13] <jepler> This is the modified config I used: http://emergent.unpy.net/index.cgi-files/sandbox/config-2.6.12-magma
[15:21:36] <BradM> Bonus! Thanks Jepler.
[15:21:45] <jepler> it does have a realtime glitch when I press one of the Fn keys, and I have to manually stop CPU frequency scaling as well
[15:21:54] <jepler> I've never actually run a mill with i
[15:21:55] <jepler> t
[15:22:06] <cradek> this is all for breezy, but maybe some of the clues will help still
[15:23:57] <cradek> especially notable is this instruction at the top: "It's impossible to build a kernel right the first time. It's worth your time to install and configure ccache right now."
[15:24:21] <jepler> cradek: you should change that to be in bold, or maybe in MS Comic, to emphasize it.
[15:24:28] <cradek> haha
[15:24:31] <BradM> <chuckle>
[15:24:34] <cradek> blink obviously
[16:55:09] <Lerneaen_Hydra> 'lo
[16:59:41] <SWPadnos> woohoo - my Ubuntu CDs arrived!
[17:00:51] <Lerneaen_Hydra> Woo!
[17:01:24] <Lerneaen_Hydra> Did you get some ubuntu stickers too? I got some, they were all pink and had... PONIES!!! OMG!!!
[17:01:45] <Lerneaen_Hydra> I hear the next version of ubuntu will be called pink pony
[17:03:18] <Lerneaen_Hydra> * Lerneaen_Hydra notices the utter silence
[17:03:22] <Lerneaen_Hydra> * Lerneaen_Hydra ponders
[17:03:43] <Lerneaen_Hydra> Lerneaen_Hydra is now known as PINK_PONIES
[17:04:35] <PINK_PONIES> PINK_PONIES is now known as Lerneaen_Hydra
[17:04:55] <Lerneaen_Hydra> err. back to reality
[17:05:06] <SWPadnos> I got no ponies :(
[17:05:17] <SWPadnos> that
[17:05:23] <Lerneaen_Hydra> :(
[17:05:25] <Lerneaen_Hydra> too bad
[17:05:28] <SWPadnos> that'll have to wait for a few versions
[17:05:38] <SWPadnos> EFGHIJKLMNO come first ;)
[17:05:53] <Lerneaen_Hydra> Seriosly though, I got some ubuntu stickers, with ubuntu and the logo on them
[17:05:56] <Lerneaen_Hydra> indeed
[17:05:58] <SWPadnos> I think Fidgety Fruitfly" would be good for F
[17:06:13] <SWPadnos> right - the logo, the name, that's it
[17:06:22] <Lerneaen_Hydra> I wonder if they loop back to A after they've done Z
[17:06:45] <SWPadnos> maybe they'll start on another alphabet, like greek
[17:06:48] <Lerneaen_Hydra> It would be rather humorous if they actually called version P pink pony
[17:07:13] <SWPadnos> unfrtunately, pink is an adjective, not an adverb or verb
[17:07:19] <SWPadnos> or "action word" ;)
[17:07:43] <Lerneaen_Hydra> dapper isn't much of a word though, is it?
[17:07:55] <Lerneaen_Hydra> and warty is an adjective
[17:07:57] <SWPadnos> true - it's an adjective as well - phew!
[17:08:24] <SWPadnos> I guess they're all adjectives - I was thrown by the -ly ending, and lack of caffeine
[17:08:25] <Lerneaen_Hydra> Hey... they had warty warthog
[17:08:39] <Lerneaen_Hydra> that means they don't follow A,B,C ordering
[17:08:42] <SWPadnos> see - there aren't even any -ly endings :)
[17:09:06] <SWPadnos> they started the alphabet soup with Dapper, I think
[17:09:37] <Lerneaen_Hydra> oh, ok
[17:23:34] <les_w> afternoon
[17:29:47] <Lerneaen_Hydra> hi
[17:29:55] <SWPadnos> howdy
[17:30:39] <les_w> good day for me.
[17:30:47] <les_w> meetings about a factory.
[17:31:01] <dmess> good show... me too.. ; )
[17:31:10] <les_w> yeah?
[17:32:02] <les_w> It looks like i'll get funding.
[17:32:18] <dmess> yeah... it looks like i'll get WORK...
[17:32:31] <les_w> what kind?
[17:33:03] <dmess> aerospace parts..
[17:33:22] <dmess> mostly landing gear parts..
[17:33:42] <les_w> oh, neat. I'm having to mess with beta titanium stuff right now.
[17:33:51] <dmess> im hoping for a piece of the Eclipse 500 main gear.
[17:33:55] <les_w> have to hot form it.
[17:34:08] <dmess> ewwww
[17:34:21] <dmess> how thick??
[17:34:24] <les_w> let me hunt up the eclipse
[17:34:29] <les_w> just .005
[17:34:55] <dmess> plans are for them to be shipping 4 aircraft per DAY by the end of 2008
[17:36:56] <les_w> hot ship
[17:38:18] <dmess> looks like it
[17:38:23] <les_w> looking at the glass cockpit
[17:38:32] <les_w> i'll guess the price
[17:38:41] <les_w> $5M or so?
[17:46:23] <dmess> 1.5M and they train you up from twin engine instrument rating to jet
[18:49:56] <^Eugenics> Can anyone recomend a PC (small) oscilloscope?
[18:50:17] <SWPadnos> one that plugs into a PC, or one the size of a PC?
[18:50:34] <^Eugenics> :) one that plugs to a pc
[18:51:23] <cradek> well, I recommend you get a scope with a CRT instead
[18:51:27] <SWPadnos> haven't used one in a long time, but I can look up some stuff
[18:52:06] <SWPadnos> what speed and how many channels?
[18:52:45] <^Eugenics> Low budget, but not complete crap.
[18:53:01] <SWPadnos> http://www.picotech.com/oscilloscope.html
[18:53:07] <SWPadnos> never used them, but they look ok
[18:53:47] <^Eugenics> Do you think they will work with linux?
[18:53:51] <SWPadnos> nope
[18:54:08] <SWPadnos> I don't know, but I suspect not, unless you want to write your own software
[18:54:30] <^Eugenics> I would like to have it to work with *nix
[18:54:35] <cradek> what kind of stuff do you plan to do with it?
[18:54:50] <SWPadnos> http://www.bitscope.com/software/dso/
[18:55:33] <^Eugenics> Mainly to trace data signals
[18:56:14] <SWPadnos> speed would be a big thing there
[18:56:31] <SWPadnos> err - it's a big question you have to answer, I mean
[18:57:37] <^Eugenics> My plan is that I want a better tool than a multimeter
[18:57:53] <cradek> how fast are the signals?
[18:58:19] <cradek> all digital?
[18:58:27] <^Eugenics> I would not exactly know now
[18:58:44] <^Eugenics> no, not all will be digital
[18:58:47] <cradek> sometimes a simple logic probe can be just as good or better than a scope
[18:58:53] <cradek> ah ok
[18:59:35] <^Eugenics> what sample rate can I achive with a paralellport probe?
[18:59:58] <cradek> it's true you could use halscope + a parport for some things
[19:00:28] <cradek> about 20us (50kHz) is the practical max
[19:01:25] <^Eugenics> Not bad for beeing almost free
[19:01:37] <cradek> yeah it would be great for some things
[19:01:49] <SWPadnos> only about 3 orders of magnitude slower than a very basic standalone scope ;)
[19:01:58] <cradek> yep
[19:02:16] <cradek> you'll have to pry my Tek CRT from my cold dead hands
[19:02:42] <cradek> digital stuff just isn't the same
[19:06:31] <jepler> I've never used a digital scope
[19:06:50] <cradek> http://cgi.ebay.com/Tek-466-Storage-oscilloscope-100mHz_W0QQitemZ110013727893QQihZ001QQcategoryZ104247QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
[19:07:10] <cradek> ugh "as is untested"
[19:07:17] <cradek> i.e. it doesn't work
[19:07:20] <SWPadnos> some digital stuff is very nearly the same, with the addition of various "Digital-only" features
[19:07:31] <SWPadnos> it's several orders of magnitude more expensive, though
[19:07:44] <cradek> I guess I haven't used a digital scope for 10 years (college)
[19:07:47] <SWPadnos> maybe only one order of magnitude
[19:07:48] <cradek> maybe they were just crap
[19:08:30] <cradek> for anything but a repeating triggerable signal that you already knew what it was so you could find it, they were useless
[19:08:58] <BradM> Actually, I own a bitscope, and it's less expensive than a good analog scope of equivalent speed. I miss the analog, but it does work.
[19:08:59] <SWPadnos> multi-GSample/sec scopes take care of that quite handily
[19:09:14] <^Eugenics> The bandwith is usually more narrow compared to other os
[19:09:17] <SWPadnos> EQTS really sucks for anything real though, I agree
[19:09:29] <jepler> doing a single-channel 8-bit ADC on the parallel port and reading it at the same 20uS period would be very easy
[19:09:37] <jepler> * jepler starts thinking
[19:09:44] <cradek> ugh
[19:12:34] <cradek> I think I'm a luddite (and I'm cheap) so I like the old stuff, also I guess I have never worked with high-dollar new stuff
[19:12:49] <SWPadnos> me either - I just bought it :(
[19:13:15] <SWPadnos> but its very nice, and maybe one of these days, I can trade the scope for a new car
[19:13:26] <cradek> jeez
[19:13:48] <SWPadnos> I love jobs that never materialize
[19:14:13] <cradek> sounds like bad planning to buy equipment before you're sure...?
[19:14:35] <SWPadnos> could well be
[19:15:08] <Mess> but tools dont go bad on the shelf..
[19:15:23] <SWPadnos> true, but they also don't appreciate in value ...
[19:15:32] <cradek> also true
[19:15:36] <SWPadnos> luckily these don't depreciate too quickly either
[19:15:48] <Mess> i dont buy them to sell them.. i buy them to work them
[19:16:16] <Lerneaen_Hydra> I (well, I don't own it, but I use it) have a digital osciliscope, and I can't say it's worse than the analog equivalents
[19:16:21] <cradek> but depreciating helps you buy them (later) if you can put it off
[19:16:49] <Lerneaen_Hydra> has some nice functions, like printing the image, and doing a waveform capture to compare with another later on
[19:17:14] <cradek> that's what the polaroid camera attachment is for, heh
[19:17:49] <Lerneaen_Hydra> One thing that would be really good would be an ability to perform functions on the incoming signal
[19:17:56] <Lerneaen_Hydra> haha
[19:18:22] <cradek> actually I've captured on my Tek and then photographed it with the digital camera
[19:18:47] <cradek> works fine for the rare times I need that
[19:19:14] <Lerneaen_Hydra> hmm, sounds slightly cumbersome though
[19:19:36] <cradek> a cumbersome/price tradeoff
[19:19:44] <cradek> I'm good at "making do"
[19:19:56] <SWPadnos> "measure->waveform 1 risetime" seems so much easier ;)
[19:20:09] <SWPadnos> but not necessarily worth $18k
[19:20:34] <cradek> I'll read off some divs for you, for only $9k
[19:20:48] <SWPadnos> thanks - plus travel expenses? ;)
[19:20:52] <cradek> sure
[19:21:03] <cradek> you'll still save thousands
[19:21:17] <les_w> i'm using an old tek digital
[19:21:25] <les_w> but I have analog ones too
[19:21:51] <les_w> was using it 5 minutes ago
[19:22:04] <les_w> taking a break now while epoxy dries
[19:22:35] <cradek> none of my regularly-used test equipment has tubes anymore (but CRTs I guess)
[19:22:40] <SWPadnos> it's best not to epoxy your scope controls
[19:22:43] <les_w> haha
[19:22:47] <cradek> that's as new as it's going to get for a while
[19:22:59] <SWPadnos> heh - even my scope has an LCD ;)
[19:23:03] <SWPadnos> no tubes at all
[19:23:21] <SWPadnos> though my older scope has a monochrome CRT
[19:23:22] <les_w> I'm making marimbas basically
[19:23:37] <les_w> inch long .062 brass bar
[19:23:44] <les_w> with a resonator tube
[19:24:10] <les_w> slight tap, and you get a nice pulse of 40k ultrasound
[19:24:41] <les_w> but I just replaced the tube with an aluminum tuned diaphram
[19:24:57] <les_w> it's hooked to the tek
[19:26:12] <les_w> ultrasound comms are actually cheaper than wire harnesses in apliances
[19:27:15] <les_w> sender and sensor I am targeting for $.25
[19:27:19] <les_w> perhaps less
[19:27:47] <SWPadnos> though wired comms should be even less, since the wires need to be there anyway for power
[19:28:04] <les_w> one would think so
[19:28:11] <les_w> but not in this case
[19:28:32] <les_w> I am trying to replace a $2 harness.
[19:29:09] <les_w> quntity is 24mm/year so even pennies saved is big bucks
[19:29:45] <SWPadnos> indeed
[19:29:55] <cradek> % units mm/year dollars
[19:29:55] <cradek> conformability error
[19:30:12] <les_w> heh
[19:30:13] <SWPadnos> 24mm/year - can emc move things that slowly? ;)
[19:30:22] <SWPadnos> what about MM/year
[19:30:33] <les_w> I am trying to get $.50/unit savings
[19:30:59] <les_w> uh...I was to lazy to type million
[19:31:05] <jepler> SWPadnos: probably depends on your INPUT_SCALE
[19:31:08] <SWPadnos> heh
[19:31:15] <les_w> also I have epoxy on my hands
[19:31:25] <SWPadnos> that would be epoxxxxxxxxxxy
[19:31:33] <les_w> haha
[19:31:55] <Lerneaen_Hydra> more like epo-oh shit, it's everywhere-xy
[19:32:17] <les_w> it's dry now though so back to the tek scope!
[19:32:24] <Lerneaen_Hydra> ah, perfect
[19:32:35] <Lerneaen_Hydra> not too much spread onto other various objects?
[19:32:47] <les_w> hpoe not
[19:33:13] <les_w> I just never could use those damn twin tube things without getting it on my hands
[19:33:20] <les_w> hpoe?
[19:33:22] <les_w> hmm
[19:41:00] <les_w> worked great!!!
[20:14:34] <Jymmm> * Jymmm hands les_w a box of laytex disposable gloves
[20:14:55] <Jymmm> les_w: That'll be $999,999.99 USD
[20:24:02] <A-L-P-H-A> common, give him a break, give him $10K off.
[20:25:59] <Jymmm> Fari enough... les_w you get a 10% discount
[20:26:25] <Jymmm> eh, make it 50%
[20:27:13] <A-L-P-H-A> given away obfusticated code, is not in the spirit of the GPL, but is it within the GPL?
[20:29:51] <jepler> A-L-P-H-A: is it "the preferred form of the work for making modifications to it"?
[20:29:55] <jepler> A-L-P-H-A: (I'd say "no")
[20:31:14] <cradek> you mean obfuscated on purpose just for distribution? or code that is hard to read but is the only code there is?
[20:31:37] <A-L-P-H-A> I remember reading a few months/years bak
[20:31:39] <A-L-P-H-A> back
[20:31:57] <A-L-P-H-A> someone was doing that shit... obfuscated their code, and sharing that code to conform to GPL.
[20:32:03] <A-L-P-H-A> but I never heard the rest of the story afterwards
[20:32:45] <cradek> I think that clearly doesn't fulfill the requirement
[20:32:49] <jepler> yeah, clearly it's nuts to say "I'd prefer that Linus distribute his kernel to me in Python, because that C stuff is just unreadable"
[20:33:31] <jepler> but if someone passes their source code through an obfuscator before giving it to me, I don't see how it can be the "preferred form": it's not the form the person who gave it to me preferred.
[20:33:37] <cradek> the code doesn't have to be good/pretty/clear, but it does have to be the "preferred form"
[20:34:27] <jepler> here's the middle of an old debian-legal thread about obfuscated code vs the GPL: http://lists.debian.org/debian-legal/2002/08/msg00412.html
[20:44:33] <A-L-P-H-A> reading
[20:50:41] <A-L-P-H-A> so technically no.
[20:53:36] <Lerneaen_Hydra> g'night
[21:36:50] <linuxNewbie> hello, I'm trying to install emc2 but the make command gives me something 'bout "no rule to make target "rtapi/_ulapi.c" needed by depends/rtapi?_ulapi.d" could any1 view my config.log file (i' just started with linux btw, 'm slow but learning)
[22:18:48] <danex> les_w, I hope your meeting went well
[23:14:09] <fenn> * fenn wonders if there's anything worth reading on the mailing list lately
[23:29:41] <Mess> hi all
[23:32:33] <fenn> Mess: i'm just curious, do you actually use emc for anything?
[23:33:12] <Mess> i feed it code to see what it'll do... for now...
[23:34:06] <Mess> i use and abuse all other sorts of cnc machines along the way
[23:34:32] <fenn> indeed
[23:36:35] <fenn> what would you do if you could pick any job in the world?
[23:39:03] <Mess> do what i do best... what i do now... but for myself
[23:39:52] <fenn> doesn't making landing gear get old after a while?
[23:40:53] <Mess> no... always a new widget to make to go with the ne gadjet
[23:41:03] <Mess> new
[23:46:50] <linuxNewbie> Hello, I'm very new to EMC an Linux, and I'm trying to install EMC on slackware and RTlinux (I realize it's not the recommended but this what I already have) I think I'm halfway there, but I hit a snag.
[23:48:20] <linuxNewbie> during make I get this "No rule to make 'rtap/_ulapi.c' needed by depends/rtapi/_ulapi.d" any idea what I missed?
[23:49:04] <fenn> some variable is undefined.. it should refer to one of rtai_ulapi.c rtl_ulapi.c or sim_ulapi.c
[23:49:24] <fenn> this probably happens during configure
[23:49:45] <linuxNewbie> thanks. configure seems pass just the make
[23:50:28] <fenn> look at config.log it _should_ (but probably doesn't) say something like RTPREFIX='rtai'
[23:50:31] <linuxNewbie> fenn: I wonder if you have time to view my config.log?
[23:52:22] <fenn> what does this command output? find /usr/* -maxdepth 3 -name "rtl-config" -o -name "rtai-config" -o -na
[23:52:22] <fenn> me "realtime-config"
[23:52:54] <fenn> erm. find /usr/* -maxdepth 3 -name "rtl-config" -o -name "rtai-config" -o -name "realtime-config"
[23:53:18] <linuxNewbie> is it on the config.log file? I'm on xp right now
[23:53:46] <linuxNewbie> ok, RTPREFIX is empty