Back
[00:39:02] <skunkworks> I love compression style f-connectors.
[00:40:58] <anonimasu> hm
[01:17:56] <CIA-8> 03cradek 07v2_1_branch * 10emc2/debian/rules.in: don't put objects in the source tar
[01:18:26] <CIA-8> 03cradek 07TRUNK * 10emc2/debian/rules.in: don't put objects in the source tar
[01:48:54] <CIA-8> 03jepler 07TRUNK * 10emc2/src/hal/components/stepgen.c: get rid of rtapi_print_msg from the HAL realtime function
[04:27:51] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/src/hal/utils/meter.c: backport: fix possible race conditions
[04:28:11] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/src/hal/ (hal_lib.c hal_priv.h): backport: better checks when linking pins, especially bidirectional ones
[04:30:25] <CIA-8> 03jmkasunich 07v2_1_branch * 10emc2/src/hal/utils/halcmd.c: backport: add 'net' command, fix possible buffer overflows, fix behavior of 'loadusr -W', add comments, misc other tweaks.
[05:34:53] <ds3> those 7x12 lathes just does not compare to a decent engine lathe :/
[06:10:00] <SWPadnos> ds3, this lathe might be big enough:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120076235173
[06:11:22] <ds3> hahahaahahahahahaha
[06:11:42] <jmkasunich> I like the stairs up onto the saddle
[06:11:55] <SWPadnos> heh - yep. "Ride'em cowboy!"
[06:12:02] <ds3> just down in LA
[06:12:16] <ds3> but but it has a 4jaw
[06:12:50] <SWPadnos> and it's ony a 60" 4-jaw
[06:13:02] <ds3> and it probally won't close enough to do those 1/4 peices
[06:13:12] <SWPadnos> hmmmm
[06:13:24] <SWPadnos> it would be very funny if it did
[06:13:36] <SWPadnos> like someone smoking dental floss or something
[06:15:29] <jmkasunich> http://www.metalworking.com/Dropbox/_2001_retired_files/greenwood3.jpg
[06:15:55] <jmkasunich> read the description at
http://www.metalworking.com/Dropbox/_2001_retired_files/greenwood3.txt
[06:16:41] <jmkasunich> speed range, 28 RPM down to 6 MPR
[06:17:28] <SWPadnos> wow O_O
[06:17:41] <SWPadnos> you could just about turn a locomotive engine on that
[06:17:51] <jmkasunich> takes a 1-3/8 x 1/16" chip
[06:18:08] <tomp> did it cut on both sides & both ends to get the 1 ton/hr removal rate?
[06:18:08] <SWPadnos> yeah -over 1 ton/hour metal removal rate
[06:18:10] <jmkasunich> oops, 1-3/4 x 1/16
[06:18:17] <SWPadnos> 8 cutters, 4 platforms
[06:18:24] <ds3> now if I there is a big enough ingot of Titanium for a rocket from billet ;)
[06:18:44] <SWPadnos> yeah, but it would only weigh 30 pounds ;)
[06:19:22] <jmkasunich> can you imagine trying to load a workpiece
[06:19:32] <jmkasunich> I think thats why vertical boring mills came along
[06:19:39] <SWPadnos> heh
[06:19:57] <SWPadnos> you'd need a 3-foot I-beam to support the crane
[06:20:04] <SWPadnos> maybe more
[06:20:13] <jmkasunich> not really
[06:20:44] <SWPadnos> oh right - I'm looking at the lathe weight (350 tons), not workpiece weight
[06:20:47] <jmkasunich> I've seen 100 ton overhead cranes, maybe 18" beams on both sides
[06:21:21] <jmkasunich> wow, cutting speed 6 feet per minute
[06:21:26] <jmkasunich> that was well before HSS tooling
[06:21:44] <SWPadnos> yeah, and with the 1-3/4 depth ...
[06:22:22] <jmkasunich> with HSS tooling, you could remove twice the metal with only one tool instead of eight
[06:22:49] <jmkasunich> assume same depth and width of cut, up the speed to 16x (100 SFPM)
[06:23:03] <jmkasunich> and get a bullet proof shield to deflect the chips
[06:23:08] <SWPadnos> HSS + coolant + coatings - even better
[06:23:21] <jmkasunich> carbide better yet
[06:23:48] <SWPadnos> yeah. carbide or cobalt.
[06:25:28] <jmkasunich> I wonder how many foot lbs of torque you need to make eight tools take a 1-3/4 x 1/16" chip at once
[06:25:34] <jmkasunich> foot tons probably
[06:26:28] <SWPadnos> that's got to be a face turning application. I don't see how you could shave off a 1-3/4 deep chip
[06:26:36] <jmkasunich> why not?
[06:26:46] <SWPadnos> too thick?
[06:26:59] <SWPadnos> think about bending a flat bar the long way
[06:27:04] <jmkasunich> 1-3/4 deep (3.5" diameter reduction), and 0.060 inches per rev feed
[06:27:17] <jmkasunich> the chip is bending the easy way
[06:27:33] <jmkasunich> the side of the cutter is doing the work, not the nose
[06:27:42] <SWPadnos> right, so it's essentially face milling - 1/16 chip and 1-3/4 depth of cut
[06:28:02] <SWPadnos> not lke parting at 1-3/4 depth per turn ...
[06:28:07] <jmkasunich> to me, face turning is when you are making the bar shorter instead of skinier
[06:28:10] <jmkasunich> skinnier
[06:28:38] <SWPadnos> right. I'm not a lathe person (yet), so I don't get a lot of stuff, or call it the right thing even if I do get it :)
[06:28:43] <jmkasunich> oh
[06:28:49] <jmkasunich> ok, you're forgiven ;-)
[06:28:54] <fenn> sinner!
[06:29:06] <SWPadnos> so to me, when they say 1-3/4 depth, I don't immediately know that they're doing it the easy way ;)
[06:29:17] <SWPadnos> I am probably a siunner
[06:29:27] <SWPadnos> actually, I'm probably a sinner in most religions
[06:29:38] <fenn> you must cut a 1/4" whitworth double start thread as penance
[06:29:48] <SWPadnos> vey well
[06:30:04] <SWPadnos> * SWPadnos looks that up in Machinery's Handbook, 27th edition (Large Print)
[06:30:17] <jmkasunich> large print?
[06:30:22] <SWPadnos> the big version
[06:30:28] <jmkasunich> you don't look that old
[06:30:33] <SWPadnos> rather than the pocket size 4-point-type version
[06:30:39] <SWPadnos> I prefer 10-point type :)
[06:31:11] <SWPadnos> this way I can read it across the room under glass, so it doesn't get dirty
[06:33:07] <tomp> machinery's handbook is on cd rom now, hook it to the help menu of AXIS
[06:33:24] <SWPadnos> too bad the CD-ROM version is like $120
[06:35:04] <fenn> * fenn puts on a trench coat and wanders around suspiciously... "hey man.. wanna see my book collection?"
[06:35:47] <jmkasunich> did the pyvcp DRO files ever wind up in CVS?
[06:35:56] <SWPadnos> I don't think so
[06:36:06] <jmkasunich> oh
[06:36:17] <jmkasunich> I just added a new command to halcmd that will make things like that nicer
[06:36:19] <jmkasunich> waitusr
[06:36:23] <SWPadnos> there's a pyvcp_demo.{hal,xml} in configs/sim
[06:36:31] <jmkasunich> you do loadusr pyvcp <stuff>
[06:36:43] <jmkasunich> (with -W so it waits for the pins to be exported)
[06:36:52] <jmkasunich> then load your rt stuff, link pins, etc
[06:37:06] <jmkasunich> then invoke waitusr <name-of-your-pyvcp-comp>
[06:37:17] <jmkasunich> and it waits until you kill the pyvcp
[06:37:25] <SWPadnos> hmmm
[06:37:29] <jmkasunich> then the next line of the hal file runs (probalby "unload all")
[06:37:42] <SWPadnos> how about a waitready <compname>?
[06:37:58] <SWPadnos> then you could loadusr a bunch of stuff first, then wait for it all later
[06:38:14] <jmkasunich> maybe later
[06:38:14] <SWPadnos> parallel init, sort of
[06:38:29] <jmkasunich> thats an optimization, not an additional capability
[06:38:44] <SWPadnos> it is?
[06:39:00] <jmkasunich> sure, parallel init just saves a little time (maybe)
[06:39:08] <jmkasunich> you can do loadusr -W and get the same result
[06:39:14] <SWPadnos> oh sorry - I thought you said "this is an optimization ..."
[06:39:24] <SWPadnos> ie, waitusr
[06:39:28] <jmkasunich> waitready is the optimization
[06:39:33] <tomp> could the next hal line begin some other thing to be waited for?
[06:39:36] <ds3> the 25th edition was $25 for the CD version
[06:39:43] <SWPadnos> right. I misread what you wrote,
[06:39:47] <jmkasunich> tomp: the next line can be any hal command
[06:39:54] <tomp> nice
[06:39:55] <SWPadnos> but that's 2 editions old :)
[06:40:16] <tomp> did you you all of the old edition already?
[06:40:25] <tomp> :)
[06:40:29] <SWPadnos> I I did did
[06:40:47] <ds3> that was $25 two years ago at KBC
[06:40:46] <jmkasunich> sometimes the older ones have stuff they've dropped from the newer ones
[06:40:57] <ds3> I'd be happy to sell that if I can find a 26th edition
[06:41:11] <jmkasunich> dropping things like trig tables is no big deal, but I like the older versions
[06:41:55] <ds3> I think the CD version has a chapter/extra that includes some of the dropped stuff
[06:42:49] <jmkasunich> ok, what other tests can I do to abuse waitusr before I commit it
[06:43:04] <jmkasunich> I tried giving it no name, a non-existent name, and RT comp name
[06:43:13] <jmkasunich> tried ctrl-c on halcmd while it was waiting
[06:43:30] <tomp> wait for itself?
[06:43:56] <SWPadnos> heh - nasty :)
[06:44:10] <jmkasunich> it will just wait until you get disgusted and hit ctrl-C
[06:44:30] <fenn> * fenn pokes ds3
[06:44:37] <SWPadnos> right - it's not loading anything, just waiting for it to exit
[06:44:39] <jmkasunich> the only test is that when you hit ctrl-C you don't shut down holding the mutex or whatever
[06:44:40] <ds3> =)
[06:45:19] <jmkasunich> ah, I know
[06:45:22] <jmkasunich> completion
[06:45:54] <SWPadnos> hmmm. can someone briefly point out the reasons why one would us a 3-jaw, 4-jaw, or 6-jaw chuck?
[06:46:00] <SWPadnos> s/us/use/
[06:46:19] <jmkasunich> 3 jaw: quick and easy, pretty decent but not perfect centering of round things
[06:46:47] <jmkasunich> 6 jaw: like 3, but won't distort things like thin-walled tubes as much when you clamp down
[06:47:16] <jmkasunich> 4 jaw: square stuff, or precise centering (or off-centering, like making an execentric)
[06:47:18] <ds3> 3/6 works on Hex
[06:47:39] <SWPadnos> ok. I thought the 6 was for better holding, especially for small / fragile parts
[06:47:49] <jmkasunich> 4-jaw has individually adjustable jaws, 3/6 the jaws move together
[06:47:52] <jmkasunich> like a drill chuck
[06:47:55] <SWPadnos> ok
[06:48:11] <ds3> prefer a collet instead
[06:48:19] <tomp> neat mechanism, lookup 'scroll'
[06:48:36] <tomp> controls the 3 & 4 jaw
[06:48:39] <SWPadnos> starngely, I actually know how they work, just not why to use them :)
[06:48:50] <SWPadnos> and they are cool
[06:49:32] <SWPadnos> I just wish I knew what thread will be on the HNC I'm getting (I know it takes 5C collets, but I think there's also a thread for a chuck)
[06:49:50] <jmkasunich> might not be a thread
[06:49:58] <ds3> does it take HLV accessories?
[06:50:01] <SWPadnos> yeah. may not be
[06:50:03] <SWPadnos> dunno
[06:50:13] <jmkasunich> I doubt it would be a thread actually
[06:50:20] <ds3> if so, those are not threaded; and does not like to be reversed
[06:50:23] <SWPadnos> I didn't look that closely at it, and it was a couple of months ago :)
[06:50:24] <jmkasunich> Hardinge has their own favorite spindle nose
[06:51:19] <SWPadnos> hmm
[06:52:05] <SWPadnos> I know there are chucks for 16C spindle, I think there may be small ones for a 5C spindle as well
[06:52:28] <SWPadnos> I'd probably like a chuck for easier setup changes, but it's not really necessary
[06:52:33] <ds3> the HLV at the local JC has a chuck on the 5C spindle
[06:52:43] <SWPadnos> ok
[06:53:08] <ds3> threading is a bit odd on the hardinge
[06:53:38] <jmkasunich> SWPadnos: if no chuck, are you gonna do everything in collets?
[06:53:42] <jmkasunich> seems rather limiting
[06:53:58] <SWPadnos> it does seem limiting, that's why I'm looking into chucks
[06:54:01] <ds3> other then size reasons, is there any other reason to use a chuck?
[06:54:28] <SWPadnos> ease of changing setup. this is an NC machine, but I don't expect to be mass producing things on it
[06:54:35] <fenn> you can turn off-center, like eccentric cams and stuff
[06:54:58] <SWPadnos> I think I'm going to try and set up a polygon turning system, actually :)
[06:55:07] <fenn> wheee
[06:55:07] <jmkasunich> you can turn things that don't match your collets
[06:55:13] <ds3> I find it just as quick to change out 5C's but they have a royal collet closer on it
[06:55:17] <fenn> i think i have some carbide inserts for a polygon cutter
[06:55:29] <jmkasunich> got a 0.5432 inch part and no 0.5432 inch collet, chuck it
[06:55:44] <ds3> SWPadnos: how do you plan to sync the spindles?
[06:55:46] <fenn> jmkasunich: that's what ER collets are for :)
[06:55:57] <SWPadnos> his will be retrofitted with EMC2, of course :)
[06:55:57] <fenn> but realistically, a chuck is more useful than a collet
[06:56:01] <ds3> ERs are so neat
[06:56:01] <SWPadnos> s/his/this/
[06:56:06] <jmkasunich> I don't want to afford a set of ERs
[06:56:18] <ds3> SWPadnos: but what mechansism?
[06:56:23] <SWPadnos> that's what "emergency collets" are for :)
[06:56:37] <SWPadnos> the mechanism will be spindle sync via emc ....
[06:56:38] <ds3> they sell cheap ERs
[06:56:46] <fenn> not _that_ cheap
[06:56:52] <ds3> Hmmm must find better way of asking the question...
[06:56:52] <SWPadnos> ds3, have you seen the footage? (on YouTube)
[06:56:55] <tomp> make a small faceplate to fit in your biggest collet, but dont overload it
[06:57:01] <fenn> ugh
[06:57:09] <jmkasunich> I have two sets of collets for my lathe
[06:57:11] <fenn> tomp: that's an awful idea
[06:57:19] <ds3> SWPadnos: yes, and thought of doing it myself but I don't know what to drive the live tooling spindle, stepper? PM motor? or ??
[06:57:30] <SWPadnos> DC motor, probably
[06:57:31] <jmkasunich> some nice small swiss screw machine collets, 1/16 thru just under 1/2" by 64ths
[06:57:40] <jmkasunich> and 5C from 1/16 to 1/18 by 16ths
[06:57:58] <ds3> assuming you will tolorate import accuracy, you can get a set of ER's (11 peices + chuck) for $70ish
[06:58:01] <SWPadnos> 1/16 to 1-1/8, right?
[06:58:10] <jmkasunich> ds3: wow
[06:58:18] <ds3> let me find link
[06:58:29] <fenn> ds3/swpadnos: the polygon cutter is synched to 1/2 the spindle speed.. it can be done with a simple gear train
[06:58:44] <SWPadnos> 1/2 - are you sure?
[06:59:01] <fenn> according to some random document i read, yes
[06:59:05] <SWPadnos> heh
[06:59:16] <SWPadnos> I guess I'll have to derive it for myself
[06:59:18] <ds3> don't the ratio depend on the number of sides?
[06:59:26] <SWPadnos> (or let google or my mother do it for me :) )
[06:59:36] <SWPadnos> no - the number of tools decides that, I think
[06:59:41] <jmkasunich> of course, I have a Sjogren/Hardinge 5C speed chuck that I got from HGR, so import would probably be a dissipointment
[06:59:41] <fenn> a little of both
[06:59:53] <fenn> i think if they're synched 1:1 and 1 tool, you'd get 1 flat
[06:59:54] <ds3> guess the set has gone up in price... right now itis $160 :/
[07:00:07] <SWPadnos> fenn, right, 1:1 and 2 tools = 2 flats ...
[07:00:09] <fenn> but in practice its 1:2 with 3 tools to get 6
[07:00:23] <tomp> j&l? m&m? enco?
[07:00:30] <ds3> lms
[07:00:40] <ds3> http://www.littlemachineshop.com/products/product_view.php?ProductID=2228&category=
[07:00:40] <SWPadnos> well, after a little prodding from jmkasunich, this was my thought experiment:
[07:00:50] <fenn> http://www.remsales.com/pages_blocks_v3_exp/images/links/POLYGON_MILLING_[Read-Only].pdf
[07:00:55] <SWPadnos> at one extreme, the spindle is stopped and the toolholder is spinning
[07:01:03] <SWPadnos> that gives you a concave cutout
[07:01:08] <ds3> would it work to do 1:4 w/1 tool to get 2 flats?
[07:01:21] <SWPadnos> at the other extreme, you're doing normal turning and get a convex cutout
[07:01:34] <fenn> no you'd get 4 flats? or maybe some other curve
[07:01:46] <SWPadnos> so somewhere in the middle, you get flat surfaces
[07:01:58] <ds3> cuz fixed tool + variable speed is easier to do
[07:02:12] <SWPadnos> that's likely to be either 1x or pi-x the spindle speed ;)
[07:02:40] <ds3> was hoping to do something like threading; PM motor w/index pulse but then I chickened out ;)
[07:03:02] <fenn> that would be more versatile for sure
[07:03:38] <ds3> except this probally has to go faster then threading :(
[07:04:12] <fenn> yeah will have to be a powerful motor, since it's doing half the cutting
[07:04:37] <SWPadnos> synchronization is no big deal for any multiple (or fraction), as long as the motors in question are capable of handling the accel/decel needed
[07:05:00] <ds3> more worried about the EMC side since a parallel port has alow pass on the inputs (caps)
[07:05:09] <SWPadnos> actually, I think they're both doing all the cutting. normally, the cutting force is "handled" by the lathe bed/toolpost
[07:05:17] <ds3> I see
[07:05:23] <fenn> parport is plenty fast for this
[07:05:33] <SWPadnos> I wouldn't use software step generation
[07:05:45] <SWPadnos> I have Mesa and Pico controllers ...
[07:05:52] <fenn> heh i wouldnt use steppers at all, personally
[07:05:57] <SWPadnos> (plus a G-Rex, if I want to write a driver)
[07:06:20] <SWPadnos> right - I'm thinking of a DC motor with the skunkworks/jmkasunich driver and the Mesa card
[07:06:34] <ds3> not steps, just the index input from a PM motor
[07:06:47] <ds3> and maybe a PWM output on another pin
[07:06:55] <SWPadnos> I'd probably use something with an encoder with index, maybe even with a tach
[07:06:57] <jmkasunich> "we found that we simply could not chuck the material tight enough in the main spindle to avoid slipping during the polygon cut" ;-)
[07:07:05] <SWPadnos> heh
[07:07:07] <ds3> hahaha
[07:07:37] <jmkasunich> also, the interrupted cut hammers on things
[07:07:54] <jmkasunich> their cutterhead screws onto the aux spinde, and they almost couldn't get it off
[07:08:00] <fenn> they are also doing stuff as hard and fast as possible..
[07:08:05] <jmkasunich> tightened by impact wrench
[07:08:11] <ds3> then there is a thought that a 7xXX class of machine may just not be rigid enough
[07:08:52] <ds3> hmmmm why not use a dog to drive it? maybe a cross pin on the bar stock?
[07:09:41] <jmkasunich> that doesn't do anything about the hammering
[07:09:50] <jmkasunich> you will need a very rigid machine
[07:09:57] <ds3> but it avoids a thread to get suck
[07:10:11] <fenn> light cuts, small cutter radius, high speed
[07:10:21] <fenn> acute angles, sharp tools, etc
[07:10:50] <fenn> prolly better to use hss cutters since it's interrupted
[07:11:15] <jmkasunich> small parts in easy to machine materials, if you are using a home class lathe
[07:11:21] <fenn> naturally
[07:11:33] <jmkasunich> for a 7xXX I'd try 1/4" diameter nylon ;-)
[07:11:37] <fenn> bah
[07:11:39] <ds3> hahahah
[07:11:45] <jmkasunich> then work your way up
[07:11:51] <jmkasunich> 1/4" brass, maybe 3/8"
[07:12:03] <ds3> the 7xXX did do a decent job on delrin =)
[07:12:04] <fenn> nylon would make lots of burrs
[07:12:12] <SWPadnos> I bet the speed ratio is proportional to the ratio of diameters
[07:12:18] <jmkasunich> s/nylon/your-favorite-plastic/
[07:12:23] <SWPadnos> effective tool diameter vs. cut diameter
[07:12:35] <fenn> SWPadnos: it's just 2:1
[07:12:55] <SWPadnos> no - if you read further, they talk about using different speeds
[07:12:59] <jmkasunich> SWP: its gotta be an integer tho
[07:13:08] <fenn> http://video.google.com/videoplay?docid=-7831550688320827327&q=polygon+cutter+animation
[07:13:59] <SWPadnos> in the fastcut video, they did multiple diameters - remember the pyramid thing?
[07:14:18] <jmkasunich> right, which proves that it can't be proportional to the ratio of diameters
[07:14:34] <fenn> they probably changed the speed though to keep sfm constant
[07:14:47] <SWPadnos> unless the ycan sync that fast ... (I'm not disagreeing, just pointing out that it's possible to do that, maybe)
[07:14:50] <jmkasunich> bet they didn't have to change it much
[07:15:11] <jmkasunich> the tookhead contributes the majority of the surface speed, and its diameter is constant
[07:15:15] <fenn> right
[07:15:23] <jmkasunich> toolhead
[07:15:55] <jmkasunich> SWPadnos: you mean accel and decel within a single revolution?
[07:16:01] <jmkasunich> "sync that fast"?
[07:16:12] <SWPadnos> well, it does sound unreasonable when you put it that way :)
[07:16:24] <jmkasunich> there are applications that do that
[07:16:31] <SWPadnos> not within 1 rev, but as the effective diameter of the cut changes, along the curve
[07:16:33] <fenn> but not at 3000 rpm :P
[07:16:40] <jmkasunich> but at a few revs per second, not the speeds we saw in the video
[07:18:17] <SWPadnos> I was thikning about a proof earlier. basically if you take a flat of T degrees, and place it from -T/2 to +T/2 (parallel with the Y axis), then you need to figure out the projection onto the X axis as a function of rotation
[07:18:37] <SWPadnos> that varies from cos(r) to r, and back to cos(r)
[07:18:45] <jmkasunich> did you read the paper fenn linked to?
[07:18:50] <jmkasunich> not really a paper, but..
[07:18:52] <SWPadnos> yes, mostly :)
[07:18:57] <tomp> crap, 1:30 again, night guys!
[07:18:58] <jmkasunich> it says the toolpath is an ellipse
[07:19:18] <SWPadnos> I saw that
[07:19:33] <SWPadnos> with flatness determined by the effective diameter of the tooling
[07:19:37] <jmkasunich> I think the thing to do would be to plot the toolpath in the work reference frame
[07:19:57] <jmkasunich> heh, I know what it would look like if you did that
[07:20:03] <jmkasunich> a spirograph drawing
[07:20:07] <SWPadnos> yep
[07:20:15] <fenn> 3 ellipses at 60 degree angles
[07:21:16] <SWPadnos> ah - OK. 2:1 it is
[07:21:38] <fenn> here are some more videos to get your gears turning:
http://www.profilator.de/dienstleistungen/videos_animation.html
[07:22:05] <fenn> hinterlegen aka "spline cutting" looks interesting
[07:22:14] <SWPadnos> hmmm. wait. no - I'm not perfectly convinced :)
[07:22:22] <fenn> i wonder if you can cut any spline form with that method
[07:22:26] <SWPadnos> yeah - I saw that link before. the face gear cutting is pretty cool
[07:22:49] <SWPadnos> did you take a look at the FastCut something-200 video on YouTube?
[07:23:02] <SWPadnos> they cut U-joints from the end of a pipe ...
[07:23:05] <fenn> yeah
[07:24:58] <fenn> * fenn wonders how to implement a g-code verifier for a polygon cutter
[07:25:19] <SWPadnos> * SWPadnos thinks it's time to go to bed :)
[07:25:29] <fenn> quite possibly
[07:26:01] <jmkasunich> yeah
[07:26:12] <jmkasunich> if you guys didn't talk so much, I would have committed this code an hour ago
[07:26:18] <jmkasunich> its all your fault!
[07:26:25] <SWPadnos> oh sure. blame it on us
[07:26:35] <SWPadnos> just because your computer beeps every time I type jmkasunich
[07:26:41] <SWPadnos> (if it has a speaker, that is)
[07:26:43] <jmkasunich> actually it doesn't
[07:26:57] <jmkasunich> beep that is, I think it has a speaker
[07:27:10] <SWPadnos> hit ctrl-G in a terminal to find out
[07:27:16] <SWPadnos> or tab twice :)
[07:27:27] <jmkasunich> yeah, it can beep if it wants to
[07:28:49] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/docs/man/man1/halcmd.1: added 'waitusr' command, handy for standalone HAL applications using pyvcp as the user interface - backport candidate
[07:28:50] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/src/hal/utils/halcmd.c: added 'waitusr' command, handy for standalone HAL applications using pyvcp as the user interface - backport candidate
[07:31:50] <jmkasunich> goodnight
[07:32:40] <SWPadnos> yeah - good night
[10:12:22] <lerneaen_hydra> 'morning
[10:58:07] <alex_joni> hello
[11:14:57] <anonimasu> morning
[11:16:03] <anonimasu> I've been looking at vtk..
[11:16:11] <anonimasu> seems like a good way to do visualization.
[11:16:19] <anonimasu> pyopengl/the other gl stuff sucked..
[11:16:31] <anonimasu> it depended on 20 packages :)
[11:56:54] <A-L-P-H-A> just 20?
[11:57:04] <A-L-P-H-A> MORNING!
[11:57:11] <A-L-P-H-A> lerneaen_hydra, alex_joni, anonimasu
[11:57:29] <lerneaen_hydra> 'lo A-L-P-H-A
[11:58:57] <A-L-P-H-A> what's up?
[11:59:01] <A-L-P-H-A> lerneaen_hydra? how's UT2k4?
[11:59:05] <A-L-P-H-A> kicking ass yet? :)
[11:59:16] <lerneaen_hydra> haha, sure :p
[11:59:46] <lerneaen_hydra> I'm just a bit pissed off at 1) really fucking stupid people playing it and 2) spawn-campers
[12:00:01] <A-L-P-H-A> spawn-campers suck.
[12:00:05] <lerneaen_hydra> yeah
[12:00:11] <A-L-P-H-A> flag campers I don't so mind...
[12:00:17] <lerneaen_hydra> that's not nearly as bad
[12:00:33] <lerneaen_hydra> spawn campers in a manta that smoosh you all the time too
[12:00:32] <A-L-P-H-A> but in certain mods... there's spawn protection, which i don't mind.
[12:00:37] <lerneaen_hydra> yeah, that's good
[12:00:58] <A-L-P-H-A> in ut99, it's fun playing zark.
[12:01:13] <A-L-P-H-A> zark is like 120bullet rapid sniper rifle, with no delay.
[12:01:32] <A-L-P-H-A> everyone has the best weapon right off the bat... love it... so fast paced... based on skill instead.
[12:01:44] <A-L-P-H-A> I love snipering... when they can't find you. heh.
[12:02:16] <A-L-P-H-A> hid in a super high up spot, where they couldn't see my shells, it was so much fun... heh.
[12:02:41] <A-L-P-H-A> stupid sniper nest had fast respawning ammo too. heh
[12:07:17] <lerneaen_hydra> oh my
[12:07:27] <lerneaen_hydra> sort of like istagib
[12:07:31] <lerneaen_hydra> that's really fun
[12:07:47] <A-L-P-H-A> nono... instagib has a huge ass delay between fires.
[12:07:58] <lerneaen_hydra> unless you're playing against people that don't do anything else can shoot you when you're about 1 pixel in size
[12:08:01] <A-L-P-H-A> I love fast hits... as I can track a user with my cross hairs.
[12:08:05] <A-L-P-H-A> but the delay kills me.
[12:08:17] <lerneaen_hydra> oh, between fires
[12:08:28] <lerneaen_hydra> so the mod you played was basically as fast as you can click?
[12:08:35] <A-L-P-H-A> lerneaen_hydra... find ut99... just much faster game play.
[12:08:44] <A-L-P-H-A> lerneaen_hydra, you can hold it down... autoreload.
[12:08:51] <lerneaen_hydra> oh, nice
[12:08:52] <lerneaen_hydra> what about ammo?
[12:09:00] <A-L-P-H-A> 120bullets.
[12:09:17] <A-L-P-H-A> same damage as regular sniper rifle
[12:09:25] <A-L-P-H-A> there should be a zark mod for ut2k4.
[12:10:16] <A-L-P-H-A> yeah, there are zark mods.
[12:10:35] <lerneaen_hydra> oh, I see
[12:10:40] <A-L-P-H-A> http://www.xtremetop100.com/unreal-tournament
[12:10:44] <lerneaen_hydra> hmm, maybe ut99 would be worth looking into
[12:10:46] <A-L-P-H-A> http://www.zarksfallenangels.com/
[12:11:11] <A-L-P-H-A> I play both... I like onslaught... power nodes, but UT99 is just fast game play.
[12:11:20] <lerneaen_hydra> oh, nice
[12:11:37] <lerneaen_hydra> native linux support too
[12:11:40] <lerneaen_hydra> sounds good
[13:07:12] <robin_sz> hmm .. whats a good bittorrent search engine these days?
[13:07:22] <robin_sz> piratebay seems crap ... again.
[14:13:25] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/man/man9/ (blocks.9 counter.9 debounce.9): new manual pages
[14:13:45] <CIA-8> 03jepler 07v2_1_branch * 10emc2/docs/man/man9/ (blocks.9 counter.9 debounce.9): merge from HEAD: new manpages
[14:33:11] <CIA-8> 03jepler 07TRUNK * 10emc2/debian/control.in: bwidget is needed at build time so that it can be detected
[14:34:17] <CIA-8> 03jepler 07v2_1_branch * 10emc2/debian/control.in: backport from HEAD: bwidget is needed at build time so that it can be detected
[14:35:41] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/man/man9/debounce.9: marup fixes
[14:35:46] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/man/man9/weighted_sum.9: new manpage
[14:37:23] <CIA-8> 03jepler 07v2_1_branch * 10emc2/docs/man/man9/ (weighted_sum.9 debounce.9): backport from HEAD: doc improvements
[14:38:12] <anonimasu> *yawn*
[14:39:30] <CIA-8> 03jepler 07v2_1_branch * 10emc2/docs/src/Submakefile: include all man9 pages in the html documentation, not just those generated by comp
[14:39:53] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/src/Submakefile: merge rev 1.28.2.3: include all man9 pages in the html documentation, not just those generated by comp
[14:54:15] <lerneaen_hydra> robin_sz, mininova?
[14:54:46] <lerneaen_hydra> isohunt tomorrow/the day after when they're back
[14:54:50] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/man/man9/ (genhexkins.9 kins.9 rotatekins.9 tripodkins.9 trivkins.9): new manpages
[14:54:55] <CIA-8> 03jepler 07v2_1_branch * 10emc2/docs/man/man9/ (genhexkins.9 kins.9 rotatekins.9 tripodkins.9 trivkins.9): merge from HEAD: new manpages
[14:58:39] <lerneaen_hydra> brb
[15:11:40] <tomp> hello
[15:12:29] <tomp_> hello2
[15:19:02] <lerneaen_hydra_> lerneaen_hydra_ is now known as lerneaen_hydra
[15:39:01] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/man/man9/skeleton.9: skeleton gives the general form of a hal component manpage
[15:39:05] <CIA-8> 03jepler 07TRUNK * 10emc2/docs/man/man9/encoder_ratio.9: new manpage
[15:39:25] <CIA-8> 03jepler 07v2_1_branch * 10emc2/docs/man/man9/encoder_ratio.9: merge from HEAD: new manpage
[15:50:26] <CIA-8> 03jepler 07v2_1_branch * 10emc2/debian/ (emc2-dev.files emc2.files.in): add new man pages to packages
[15:58:30] <CIA-8> 03jepler 07TRUNK * 10emc2/src/Makefile: do not install 'skeleton' manual pages
[15:59:23] <CIA-8> 03jepler 07TRUNK * 10emc2/debian/ (emc2-dev.files emc2.files.in): put new manpages in packages. get rid of skeleton manpages from packages
[16:00:11] <CIA-8> 03jepler 07v2_1_branch * 10emc2/src/Makefile: merge rev 1.194: do not install 'skeleton' manual pages
[16:00:38] <CIA-8> 03jepler 07v2_1_branch * 10emc2/debian/emc2-dev.files: do not put skeleton manpages in packages
[16:04:25] <CIA-8> 03jepler 07v2_1_branch * 10emc2/docs/src/config/stepper.lyx: merge rev 1.6: new sections: Maximum step rate, Changing the polarity of a signal, PWM spindle speed control.
[16:33:34] <lerneaen_hydra> jepler, are the axis-sim (non-rt kernel) .debs released yet?
[16:34:57] <jepler> lerneaen_hydra: I'll put one online for you -- give me a few minutes
[16:35:03] <lerneaen_hydra> ooh, yay!
[16:35:13] <jepler> "Note: this is still an experimental package, it doesn't exist in the repository. If you don't know how to recover from installing this package, please don't proceed further."
[16:35:51] <lerneaen_hydra> could you define recover
[16:36:20] <jepler> if you were already using emc 2.0, "recover" would mean going back to the 2.0.x package
[16:36:55] <lerneaen_hydra> well, this would be on my main computer to use EMC to play with/test programs
[16:37:03] <jepler> I suppose since you're interested in the simulator only, it means you don't have any other version of emc installed
[16:37:21] <lerneaen_hydra> yep
[16:45:33] <jepler> lerneaen_hydra:
http://axis.unpy.net/index.cgi/emc2.1-simulator-experimental-packages
[16:46:59] <lerneaen_hydra> jepler, any reason that you've got instructions to add the debs to the apt-sources rather than use one of the (usually) included install-app programs?
[16:47:28] <lerneaen_hydra> (k)ubuntu ships with one that lets you install it without modifying the sources.list
[16:47:57] <jepler> lerneaen_hydra: I copied alex's advice from the wiki
[16:48:03] <lerneaen_hydra> oh, ok
[16:48:10] <lerneaen_hydra> and what's the point of the third step?
[16:48:13] <jepler> lerneaen_hydra: if you know a better way, go ahead
[16:48:26] <lerneaen_hydra> read from /dev/null and output to a file?
[16:48:50] <jepler> lerneaen_hydra: I don't know if the thing you're talking about will fetch the other dependencies -- but if it will, then do that and skip these steps
[16:49:10] <lerneaen_hydra> (ps you might want to change the meta-info on your site to prompt the browser to download, rather than display a .deb)
[16:49:13] <jepler> according to the manpage, /dev/null names the "override file" -- I guess there isn't one
[16:50:40] <lerneaen_hydra> btw, your site seems to be transferring the file slowly, 10kb/s
[16:50:45] <jepler> it's dsl
[16:50:46] <jepler> stop whining
[16:51:00] <lerneaen_hydra> what, you're hosting it yourself?
[16:51:52] <jepler> yes it's the computer in my basement
[16:52:02] <lerneaen_hydra> oh, that changes things ;)
[16:52:27] <lerneaen_hydra> considering the circumstances the site seems to load quite snappily then
[16:57:24] <jepler> mime type problem should now be fixed
[16:57:31] <jepler> Length: 1,544,320 (1.5M) [application/x-debian-package]
[16:59:23] <Martin_Lundstrom> Hello folks
[16:59:40] <Martin_Lundstrom> I have a internet question...
[16:59:51] <jepler> good morning Martin
[17:02:07] <Martin_Lundstrom> I presume that it is ilegal to resell bandwidth from the operator if you have a normal adsl connection, but would it also be ilegal to sell another type of service that depend on the connection, for example to relay a telephone call or host a web server?
[17:02:54] <jepler> I doubt "illegal" is the right term. It may violate the contract you made with the provider of your internet connection, though.
[17:03:17] <Martin_Lundstrom> yes, that it what i mean
[17:03:34] <Martin_Lundstrom> s :)
[17:05:38] <jepler> my ISP has a pretty broad right to terminate my connection, according to the agreement: "Abuse of the Internet Nebraska system will not be tolerated. Internet Nebraska reserves the right to immediately terminate the account of any Customer deemed to have abused the Internet Nebraska system."
[17:05:38] <cradek> sounds like you should ask your ISP, or carefully read your particular agreement
[17:06:00] <jepler> "The determination of what constitutes abuse of the Internet Nebraska system shall be at the sole discretion of Internet Nebraska."
[17:06:10] <jepler> "Internet Nebraska reserves the right to modify these Terms and Conditions without notice."
[17:06:17] <cradek> (yeah, it'll probably have something like that)
[17:06:31] <cradek> anything else is just a guess
[17:07:13] <Martin_Lundstrom> thats good advice, thanx
[17:07:32] <jepler> in practice, my ISP is the independent ISP (they're not the telco or the cable company) and they haven't raised a fuss just because I host some services on my DSL
[17:07:37] <Martin_Lundstrom> I have to get a second ISP :P
[17:07:38] <jepler> I don't think they're likely to
[17:09:01] <Martin_Lundstrom> reading the fineprint and kepping a low profile :)
[17:09:17] <cradek> an ISP usually has either a very restrictive terms of service agreement, or a transfer quota. pick your poison - if you have the quota I suspect they're going to be less picky about the particular types of traffic.
[17:09:46] <Martin_Lundstrom> ok
[17:10:41] <cradek> that's not a hard rule - just my experience
[17:10:48] <cradek> bbl
[17:20:46] <DanielFalck> jepler, got any screenshots of your experimental simulator?
[17:21:43] <DanielFalck> I don't want to bog down your dsl : )
[17:24:10] <lerman> Hi. Does anyone here know about openGL limitations on number of triangles?
[17:25:07] <lerman> If I want to do a cutting simulator and generate a few million triangles will openGL croak, work, or slow to a crawl?
[17:25:47] <skullworks> I think the limits are purely hardware.
[17:26:18] <jepler> DanielFalck: it's emc2 and axis, but running without realtime kernel or the ability to control hardware
[17:26:28] <lerman> I saw a comment about certain apps running faster if hardware acceleration is turned off.
[17:28:04] <jepler> lerman: opengl just gets slower as you draw more triangles. For each triangle there's some fixed cost plus additional cost proportional to the area of the transformed & projected triangle ("triangle rate" and "fill rate")
[17:29:44] <DanielFalck> jepler, mind if I download a copy?
[17:30:30] <jepler> DanielFalck: go ahead, just be patient and don't blame me if it doesn't work
[17:30:41] <lerman> If I had a surface measuring 10x10 with a resolution of .005, I might have 10 million triangles.
[17:31:12] <DanielFalck> jepler, ok, thanks
[17:32:08] <lerman> Since my display is only a million pixels (more or less), I could average a lot of triangles -- until I zoomed. That could be tricky.
[17:32:40] <lerman> I would be easier if I could just draw them all and let the hardware do its thing.
[17:35:05] <jepler> lerman: this nvidia card has a claimed speed of 34 million triangles per second and 1.2 billion texels per second (fill rate), but software that is not obsessively optimized rarely reaches those levels of performance.
http://www.nvidia.com/page/geforce4mx.html
[17:35:51] <jepler> so if you have 10 million triangles, you would get at best 3fps. Each one would have to have a projected size of about 35 screen pixels, or the fill rate becomes the limiting factor.
[17:36:44] <lerman> That specifies the rate, but not the maximum number. At some point, we would run out of display memory.
[17:36:44] <jepler> more likely you'll get 10-25% of the theoretical maximum, or from 1 frame per 3 seconds to one frame per second
[17:37:42] <lerman> That might not be too bad.
[17:37:53] <jepler> triangle data can come from main memory but at a performance penalty.
[17:37:58] <lerman> If we were clever.
[17:40:42] <jepler> for instance, it's easy to lose 2/3 of the triangles-per-second number right off the bat. That number assumes you are using large GL_TRIANGLE_STRIPs which means that each triangle shares 2 of its 3 vertices with an earlier triangle. If you do the much easier to code GL_TRIANGLES mode, you do three times as many vertices and drop to 11 million triangles per second
[17:41:41] <lerman> It's not clear what optimizations can be done with marching cubes.
[17:42:50] <lerman> Another approach might be to draw polygons by just tracing (planar) surfaces. For convex surfaces, you could use "fan" mode.
[17:43:34] <lerman> (Does openGL already do that?)
[17:43:57] <jepler> and this is all assuming you will have available hardware acceleration -- if you remember the discussion from the other day, nvidia drivers cause "unexpected realtime delay" messages in emc2.
[17:44:27] <jepler> yes, OpenGL has GL_TRIANGLE_FAN and GL_POLYGON
[17:44:39] <lerman> Yeah. But I wouldn't necessarily want to run this during RT operation.
[17:45:23] <lerman> The purpose of this is to validate the path. If I want to see what is happening in real time, I can just look at the stock I'm cutting.
[17:46:07] <jepler> you would have to reboot or at least restart the X server (close all apps) to switch from the nvidia accelerated driver to the safe non-accelerated driver
[17:46:38] <lerman> Thanks for your time. I've got to get back to work. Yeah, that's true. -- restart the server.
[17:46:45] <robin_sz> is it possible to upgrade XP home to XP pro?
[17:46:58] <jepler> robin_sz: it's possible to upgrade XP home to Ubuntu
[17:47:13] <robin_sz> hardly a solution
[17:48:15] <robin_sz> and anyway, i prefer Debian
[17:48:53] <jepler> I prefer Debian to Windows XP too
[17:49:18] <lerneaen_hydra> jepler, my ubuntu dist is complaining that there are unmeetable dependancies
[17:49:30] <robin_sz> indeed, but, since our office applications need xp ...
[17:49:36] <robin_sz> id still like xp pro
[17:49:39] <lerneaen_hydra> libpth2 and python2.4-numarry are not installable
[17:50:14] <jepler> lerneaen_hydra: you need to enable the "universe" repository
[17:50:25] <lerneaen_hydra> I've done that
[17:51:29] <jepler> you're using ubuntu dapper right?
[17:51:38] <lerneaen_hydra> kubuntu edgy
[17:51:50] <lerneaen_hydra> hmm, could edgy be breaking things?
[17:51:52] <jepler> oh -- these packagesa re for dapper
[17:52:00] <lerneaen_hydra> ah, ok
[17:52:06] <lerneaen_hydra> are there sim packages for edgy?
[17:52:25] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#Why_aren_t_there_packages_for_Ubuntu_6_10_Edgy_Eft
[17:52:52] <lerneaen_hydra> hmm, so that even applies to the sim packages?
[17:53:02] <lerneaen_hydra> I guess I could just compile it from source
[17:53:07] <jepler> I don't plan to ever have a machine installed with "edgy"
[17:53:24] <lerneaen_hydra> not even for your desktop computer?
[17:54:05] <jepler> nope
[17:54:43] <lerneaen_hydra> oh, ok
[17:55:21] <lerneaen_hydra> any idea of whether compiling from source would work (--enable-run-in-place and some sim tag)
[17:56:10] <jepler> it'll still need "libpth"
[17:56:33] <lerneaen_hydra> that's what I was thinking
[17:56:33] <lerneaen_hydra> ah well
[17:58:01] <jepler> looks like they've changed the package names around in edgy.
https://launchpad.net/ubuntu/+source/pth/2.0.7-2ubuntu2
[17:58:35] <jepler> if /usr/bin/python is python2.5, then you may run into additional trouble -- someone reported that there are python 2.5 problems but didn't give a good enoug bug report for me to actually fix anything
[17:58:46] <lerneaen_hydra> bleh
[17:58:55] <lerneaen_hydra> guess I'll skip that then
[17:59:11] <lerneaen_hydra> if I need to do any emc testing I'll do it on the real machine
[18:21:37] <skullworks> so - whats the general feel about a v2.1 release, how far off?
[18:23:27] <awallin> my guess is by the end of the month AlexBot et al will have the packages out
[18:23:51] <lerneaen_hydra> AlexBot?
[18:24:09] <lerneaen_hydra> you mean cia-8?
[18:24:18] <lerneaen_hydra> it doesn't really do that much dev-work ;)
[18:25:18] <cradek> I told the emc-users list it would be done this month, and we're all taking that pretty seriously
[18:25:31] <skullworks> so will it have support for rigid tapping or just lathe single point?
[18:25:38] <lerneaen_hydra> ooh, nice
[18:25:40] <cradek> no rigid tapping yet
[18:26:06] <cradek> maybe by summer (after fest)
[18:26:10] <lerneaen_hydra> what's the difference between rigid tapping and single-point?
[18:26:15] <cradek> lerneaen_hydra: reversing
[18:26:17] <skullworks> OK - cause I was wondering about what hardware I would need to add for that function
[18:26:21] <lerneaen_hydra> just the reversing, right?
[18:26:43] <lerneaen_hydra> seeing as how G33 can/should be in effect all the time it doesn't sound too hard to implement
[18:26:50] <cradek> skullworks: good control of a reversing spindle
[18:27:15] <skullworks> specifically - what rez the spindle encoder, and shluld it have an index?
[18:27:39] <skullworks> <<< cheap kyb
[18:27:49] <lerneaen_hydra> by rigid tapping, how rigid do you mean? is it in a floating holder?
[18:27:51] <cradek> skullworks: resolution depends on the spindle speed you need, and whether you are counting with software or hardware. yes, it should have index
[18:27:55] <lerneaen_hydra> with 10mm of travel
[18:28:06] <cradek> lerneaen_hydra: no, rigid means rigid
[18:28:11] <lerneaen_hydra> oh
[18:28:20] <lerneaen_hydra> high-res seems like a prequesite then
[18:28:26] <cradek> lerneaen_hydra: that's what makes it challenging :-)
[18:28:34] <lerneaen_hydra> like at least 4096 inc/turn or so?
[18:28:39] <skullworks> No - rigid as in the tap is held in a collet - with no float
[18:28:40] <lerneaen_hydra> I can imagine
[18:29:23] <cradek> I expect it to work nicely enough with 500 counts/rev or so
[18:29:34] <cradek> but remember it's not written yet!
[18:29:37] <lerneaen_hydra> oh, that coarse?
[18:30:48] <skullworks> Will you put it under a G84 with a M code switch to enable the sync?
[18:30:49] <cradek> 1/500ths of a revolution of a 20tpi tap is only .0001" axis travel
[18:31:03] <lerneaen_hydra> that's true
[18:31:18] <cradek> skullworks: it will probably be its own gcode with no M involved
[18:31:28] <skullworks> OK
[18:32:13] <lerneaen_hydra> hmm, one code for down and up?
[18:32:18] <lerneaen_hydra> or one down, one up?
[18:32:26] <cradek> one code per tap
[18:32:48] <lerneaen_hydra> so two codes per completed hole in the part
[18:33:06] <cradek> brb
[18:33:23] <lerneaen_hydra> btw, is helical threading something that's planned to be added?
[18:33:37] <lerneaen_hydra> (single-point cutting threads in mills)
[18:33:45] <skullworks> I run about 20 different brands of machines for the "Employers" and I was hoping EMC would be farely simular to other accepted methods to make POST Processors easier to config
[18:34:03] <lerneaen_hydra> skullworks? O_o
[18:35:00] <skullworks> hydra - threadmilling should allready be usable if you know how to program it.
[18:35:10] <lerneaen_hydra> oh
[18:35:19] <lerneaen_hydra> but, but, but
[18:35:20] <skullworks> its not a special code
[18:35:46] <lerneaen_hydra> threadmilling involves arcs in X, Y, and Z at the same time, and synced to the spindle
[18:35:47] <skullworks> but we could make a multi purpose macro to do it
[18:36:04] <lerneaen_hydra> err, not arc in Z, linear movement in Z
[18:36:05] <skullworks> not sync to spindle
[18:36:19] <lerneaen_hydra> err, are we thinking of the same thing?
[18:36:33] <lerneaen_hydra> a single point cutter
[18:37:04] <skullworks> us like a lathe single point tool as a rotating cutter to mill a helical path to make a thread
[18:37:10] <anonimasu> lerneaen_hydra: eh, no, you dont need spindle sync.. for thredmilling
[18:37:15] <anonimasu> lerneaen_hydra: that's for rigid tapping..
[18:37:28] <lerneaen_hydra> then we're not thinking of the same thing
[18:37:52] <anonimasu> http://www.carbidedepot.com/formulas-threadmilling.htm
[18:37:56] <anonimasu> that's what im talking about.
[18:37:56] <awallin> anonimasu: did you get anything interesting done yesterday?
[18:38:21] <anonimasu> awallin: no, started to look at vtk..
[18:38:35] <anonimasu> awallin: I'm with a puppy so I cant spend any time during the day at the comp
[18:38:49] <anonimasu> awallin: but I've been pondering lots
[18:38:53] <lerneaen_hydra> anonimasu, hmm not exactly the same thing, nearly though
[18:39:03] <lerneaen_hydra> that setup has to be synced to the RPM though, right?
[18:39:21] <anonimasu> no
[18:39:23] <lerneaen_hydra> imagine that instead of a tap you have a cutter (like a boring bar from a lathe)
[18:39:39] <lerneaen_hydra> which always has to face the internal wall at some angle
[18:40:00] <lerneaen_hydra> which also gives that one period/pitch gives one rotation of the spindle
[18:39:59] <anonimasu> lerneaen_hydra: orbital machining?
[18:40:08] <lerneaen_hydra> maybe?
[18:40:11] <anonimasu> or well, orbital boring or whatever htey call it..
[18:40:15] <lerneaen_hydra> I'm not sure of the real name
[18:40:43] <anonimasu> I have some papers from dmess with a description about it..
[18:40:53] <skullworks> I understand what your saying - but why do it the hardest way possible
[18:41:11] <anonimasu> agreed.
[18:41:24] <anonimasu> lerneaen_hydra: why do you want to do it that way?
[18:41:27] <lerneaen_hydra> IIRC it's good becuase the carbide cutters are cheap and effective for that type of setup
[18:41:33] <lerneaen_hydra> I've never done it
[18:41:34] <anonimasu> lerneaen_hydra: you can still single point without a spindle encoder.
[18:41:39] <lerneaen_hydra> just heard of it
[18:42:19] <skullworks> trust me - a small thread mill insert will work much better
[18:42:26] <anonimasu> :)
[18:42:33] <lerneaen_hydra> anonimasu, oh, wait a sec, on the first link you sent, did those "taps" have circular or spiral grooves?
[18:42:43] <anonimasu> it's not taps..
[18:42:45] <anonimasu> they are cutters..
[18:42:49] <lerneaen_hydra> hence "taps"
[18:42:53] <lerneaen_hydra> ;)
[18:42:53] <anonimasu> and they cost 70 eur each :D
[18:43:14] <lerneaen_hydra> ack
[18:43:18] <anonimasu> :D
[18:43:29] <anonimasu> or was that 700?
[18:43:41] <lerneaen_hydra> the grooves are circular though, right?
[18:43:46] <lerneaen_hydra> and not spiral
[18:43:54] <anonimasu> no idea..
[18:44:00] <anonimasu> yeah.. I think so
[18:44:09] <awallin> anonimasu: any good papers on simulation/CAM?
[18:44:13] <lerneaen_hydra> they must be circular, becuase if they're spirals then RPM would affect it
[18:44:30] <anonimasu> http://www.iscar.com/ProductLines/Img/ThreadMill_39_2.jpg
[18:44:37] <anonimasu> awallin: no
[18:44:41] <skullworks> I had a job making a 303 SS part for a shower head - the lathe made the first half - male 1/2" NPT threads - the mill drilled the back side and thread milled a female 1/2" NPT
[18:44:58] <anonimasu> awallin: what's how they look :)
[18:45:07] <skullworks> The mill would do 12 parts to every 2 made by the lathe
[18:45:27] <anonimasu> one kind..
[18:45:57] <anonimasu> that's the kind that needs sync I think
[18:45:58] <anonimasu> http://www.centroidcnc.com/images/intercon/threadmill_600.jpg
[18:46:02] <anonimasu> there you have another kind..
[18:46:10] <anonimasu> the one I'd choose :)
[18:46:46] <lerneaen_hydra> yeah
[18:46:48] <lerneaen_hydra> that kind
[18:46:50] <skullworks> neither of those require sync
[18:46:53] <lerneaen_hydra> nope
[18:47:05] <anonimasu> skullworks: skullworks ok
[18:47:10] <anonimasu> :)
[18:47:28] <lerneaen_hydra> one thing I was thinking of, they have a minimum diameter/maximum pitch, right?
[18:47:39] <lerneaen_hydra> before distortion sets in
[18:47:42] <awallin> anonimasu: do you have the vtk book(s)?
[18:47:47] <anonimasu> awallin: no
[18:48:01] <skullworks> yes - mainly for ID threads
[18:48:06] <anonimasu> awallin: I just looked at some examples that's about it
[18:48:21] <anonimasu> you got them?
[18:48:40] <awallin> anonimasu: I copied about half of the user guide from work
[18:48:50] <awallin> it's for vtk 4.2 so a bit old
[18:49:07] <awallin> can't find them with edonkey or bittorrent either... :)
[18:49:14] <anonimasu> that'd oss
[18:49:14] <anonimasu> odd
[18:49:16] <anonimasu> brb
[18:49:20] <anonimasu> I'll be back in a bit
[18:49:34] <skunkworks> is skullworks my evil twin?
[18:49:51] <skullworks> I build guns not planes
[18:50:13] <skullworks> was Firearms MFG for 12 years
[18:50:18] <skunkworks> Nice
[18:50:20] <skullworks> not anymore
[18:50:41] <skullworks> maybe I should try planes now...
[18:51:10] <skullworks> hmm maybe a BD-5
[18:51:24] <skullworks> or a KR2
[18:52:28] <skullworks> every time I think about finishing my pilots license they rewrite all the rules...
[18:55:16] <CIA-8> 03cradek 07v2_1_branch * 10emc2/debian/ (.cvsignore control.in emc2.files.in emc2-docs.files): merge docs into main package
[18:57:01] <anonimasu> iab
[19:16:19] <CIA-8> 03cradek 07v2_1_branch * 10emc2/debian/changelog: menu stuff for sim breezy
[19:20:51] <lerman> See:
http://www.se-ltd.com/~lerman/files/thread.ngc for a sample of some gcode that does thread milling. In this case, it is an internal thread.
[19:22:44] <jmkasunich> woot! 700va UPS for $5
[19:23:14] <skullworks> good score!
[19:23:22] <jmkasunich> HGR surplus
[19:26:31] <skullworks> yeah - looks like I will have to rewrite alot of my macros
[19:26:31] <tomp_> cradek: did you get my key?
[19:28:11] <skullworks> it appears that (G3 G91) J-.5 Z.1 would not be accepted as valid.
[19:28:34] <skullworks> to Threadmill a 1"-10 thread
