Back
[00:00:41] <dmess> them somme serious redneck's though
[00:49:48] <jepler_> yay, home again.
[00:55:29] <dmess> w/c home
[01:04:54] <mark_aulfinger> mark_aulfinger is now known as Alf
[02:00:08] <cradek> hi jepler_!
[02:13:09] <DanielFalck> hi cradek
[02:13:34] <DanielFalck> elm nucut plus works for the lathes
[02:13:48] <DanielFalck> the extra light is for grinders
[02:14:53] <crotchetyGuy> Hi DanielFalck-
[02:15:03] <DanielFalck> crotchetyGuy: hi
[02:15:05] <crotchetyGuy> have you looked at sketchflat?
[02:15:18] <DanielFalck> what's that?
[02:15:19] <crotchetyGuy> works well in wine
[02:15:38] <crotchetyGuy> http://cq.cx/sketchflat.pl
[03:32:03] <JymmmEMC> whoever came up with using crimp rings in electrical outlet boxes need to be seriously bitchslapped!
[04:04:55] <tomp3> hah /dev/hda8 has gone 46279 days without being checked (what you get building boxes with old emc drives :)
[04:06:52] <tomp3> morphix emc cool
[04:13:32] <tomp3> JymmmEMC: the agp card allowed me to get to BIOS and now running the PCI ok. 2 of 8 mem sticks bad ( so still didnt get vid they were sorted out ) and all 8 stix labeled 256M are really 128!! but it runs! thx!
[04:13:55] <tomp3> vid/until/they
[04:15:39] <JymmmEMC> =)
[04:22:13] <tomp3> while at tiger direct saw new cool hp touch-smart an all-in-one media center desktop touchscreen 1080p wired for cable thingy ( drool) 1388$
[04:22:36] <tomp3> http://www.hp.com/united-states/campaigns/touchsmart/#/Main/
[04:23:03] <tomp3> oh yeah, 22" ( but no slots, just usb )
[04:26:03] <JymmmEMC> SOB... the motion light I bought only allows for 300 Watts! and I need 400Watts.
[04:27:38] <tomp3> whats a motion light? tracking?
[04:28:35] <JymmmEMC> you walk near something, the light turns on
[04:28:56] <tomp3> ah, like x10 stuff. can you use 2 lights?
[04:30:48] <JymmmEMC> No, just the kind you put on you front door
[04:32:04] <JymmmEMC> http://cache.smarthome.com/images/4650b.jpg
[04:33:29] <tomp3> gotcha ( x10 has similar, mine made a dog bark whensomeone got near ... x10 'robo-dog') so maybe a similar switch could handle 400 W ... inductive load?
[04:36:51] <tomp3> leviton 500W 30$
http://www.conservastore.com/03-0143-lite-switches.htm
[04:37:03] <JymmmEMC> I have relays =)
[04:37:18] <tomp3> just switch (use stock outdoor light assy)
[04:40:57] <tomp3> all in one 500W dual lamp and sensor
http://www.leviton.com drill down to All Leviton Products > Lighting Controls (Box Mounted) > Occupancy Sensors > Outdoor
[08:20:15] <anonimasu> heh.. I cant get a price for thoose bearings without having them dig for them :/
[08:23:45] <archivist_ub> enve mooooooore $
[08:24:22] <anonimasu> hehe, looks like they cost 500eur in italy..
[08:24:23] <anonimasu> :p
[08:24:46] <pjmcabbb> good morning
[08:24:55] <pjmcabbb> pjmcabbb is now known as pjm
[08:25:25] <anonimasu> well, we'll see what kind of price they give me on them
[08:25:42] <archivist_ub> be prepared to fall off chair
[08:26:09] <anonimasu> actually 500 dosent shock me..
[08:28:42] <archivist_ub> anything beyond my means shocks me at the moment :(
[08:29:49] <anonimasu> but im not buying them if they are over 300 :p
[08:50:06] <archivist_ub> hmm videos get a lot of views on youtube
[08:51:16] <anonimasu> :)
[08:51:25] <anonimasu> I wish you made cash from views ;)
[08:51:28] <anonimasu> that'd rock :p
[08:52:08] <archivist_ub> perhaps worth stuffing a web url on the end
[08:53:45] <anonimasu> crap..
[08:53:56] <anonimasu> I missed a bidding on a 1µm dial gauge
[08:54:04] <anonimasu> 42 eur -_-
[08:54:42] <archivist_ub> I cant afford to bid on a rotary at the moment and missed a probe
[08:55:17] <anonimasu> :/
[08:55:36] <anonimasu> I reckon a probe when properly used pays off fast
[08:55:36] <anonimasu> :)
[09:02:26] <archivist_ub> my probing need is a little odd as I want to measure tool shape and cut width and center line
[09:05:31] <fragalot> archivist_ub: so you just get a 4-point probe like most new lathes have
[09:06:09] <fragalot> quite fun, all you do is gently ram it and the tool settings are automatically set, really speeds things up
[09:06:33] <archivist_ub> er just think of a gear milling cutter for .2 module
[09:07:06] <fragalot> m'kay,.. yeah, that should be fun :p
[09:08:02] <archivist_ub> not seen anything yet except laser and some machine moving around with software
[09:09:11] <archivist_ub> and most of the cheap laser diodes have too large a beam
[09:16:49] <fragalot> add a lens infront of it then
[09:16:51] <fragalot> :p
[09:20:03] <archivist_ub> Or I need to measure the cut gear in the machine to know the next cut depth
[09:37:48] <fragalot> go with your gut
[09:37:54] <fragalot> :p
[09:39:31] <archivist_ub> currently a pain in the a as I run prog measure move a few thou touch off run ..... till done
[09:40:12] <fragalot> O.O
[09:52:57] <anonimasu> :(
[09:53:11] <anonimasu> did anyone try to make custom insert cutters?
[09:53:13] <fragalot> http://www.boingboing.net/2008/09/26/walmart-shutting-dow.html
[09:53:16] <fragalot> Owned.
[09:53:59] <anonimasu> lol
[09:54:59] <archivist_ub> anonimasu, we often make custom cutters here, "near enough" most of the time
[09:55:18] <anonimasu> like tool holders..
[09:56:00] <anonimasu> * anonimasu nods
[09:56:01] <archivist_ub> I made an insert holder to fit the mill the other day
[09:56:57] <archivist_ub> so I can use lath screw cutting inserts for thread milling
[09:57:14] <fragalot> that's what rules about CNC machines,.. depending on what you're missing, or what broke, they can regenerate themselves with some effort on your end.
[09:57:35] <archivist_ub> sure is
[09:58:01] <fragalot> build one DIY machine, use that to make a new, better one.
[09:58:01] <anonimasu> hehe
[09:58:12] <anonimasu> the idea was to make a tool so I can use the threadmilling inserts in the mikkl
[09:58:13] <anonimasu> mill..
[09:58:56] <archivist_ub> perhaps I should take a pic of this one for you
[10:00:24] <anonimasu> please do
[10:00:25] <anonimasu> :)
[10:03:03] <archivist_ub> http://www.archivist.info/cnc/p1010245.jpg
[10:03:54] <archivist_ub> fits in a 12mm collet
[10:04:57] <anonimasu> nice :)
[10:04:59] <archivist_ub> slightly forward of center to make sure it clears when rotating
[10:06:29] <archivist_ub> brass for ease of making
[10:07:49] <archivist_ub> and next time Ill try and get the screw hole in the right place , but its near enough :)
[10:07:57] <anonimasu> * anonimasu nods
[10:08:02] <anonimasu> didnt you cnc it?
[10:08:15] <anonimasu> :p
[10:08:33] <archivist_ub> yes but some dimensions were a guess
[10:08:44] <anonimasu> ah ok :)
[10:09:06] <anonimasu> I were thinking of using the seco data for the insert for mine I think they have dimensions
[10:09:50] <anonimasu> maybe I should make mine in brass..
[10:10:52] <archivist_ub> I milled the pocket with a 3mm slot end mill
[10:12:25] <anonimasu> tapered walls?
[10:12:34] <anonimasu> (I cant remember if the inserts are tapered
[10:15:46] <archivist_ub> I did 90 deg walls
[10:16:15] <archivist_ub> this insert looks 90
[10:17:31] <anonimasu> ok
[10:24:15] <anonimasu> :)
[10:30:17] <anonimasu> I wish mine was :)
[10:30:36] <anonimasu> I think seco uses taper to make the insert center in the right place
[10:31:09] <archivist_ub> this is Sandvik
[10:32:05] <anonimasu> ok :)
[10:41:56] <fragalot> http://omploader.org/vczlq <-- this is what weekend his keyboard looks lik
[10:42:00] <fragalot> wups, wrong channel
[10:45:44] <anonimasu> hey dushantch
[10:46:19] <dushantch> Hi anonimasu
[10:46:36] <anonimasu> what's up?
[10:46:38] <dushantch> have the quotes for spindles came?
[10:46:48] <anonimasu> bearings, no.. but it seems 500eur-ish
[10:46:53] <anonimasu> from what google tells me
[10:47:11] <dushantch> anonimasu: I can't find oil of viscosity 5-10 API GL5 for my machine :)
[10:47:18] <anonimasu> :/
[10:47:25] <dushantch> only on drum, but I don't need 220l
[10:47:51] <dushantch> I had a coupling stick so my rapids were overloading the motor
[10:48:03] <dushantch> because of too dense oil
[10:48:35] <dushantch> what gerbox oil do you use?
[10:48:45] <fragalot> dushantch: find a local bigger company that can buy that big drum, and let you tap from it when you need it,.. both of you should save money that way,.. they can take it out with taxes, and you don't need to pay as much
[10:49:00] <anonimasu> for the spindle?, just grease
[10:49:16] <anonimasu> for my big mill I dont know, I've never changed it yet
[10:49:26] <dushantch> btw. got prices for servo drives, 1400eu for 750W with brakes motor+amp
[10:49:37] <anonimasu> sounds about right
[10:49:40] <anonimasu> :/
[10:49:42] <fragalot> who needs brakes °_°
[10:49:52] <dushantch> well this machine has central lubricating, and it has a dripper above those couplings
[10:49:57] <anonimasu> arent you the guy with the Z axis that would fall down on power failure?
[10:50:03] <anonimasu> oh, I use something called glideway
[10:50:04] <anonimasu> by omega
[10:50:16] <anonimasu> no wait.. shell
[10:50:33] <anonimasu> statoil glideway..
[10:50:51] <anonimasu> http://www.statoillubricants.com/mar/lu/sto00131.nsf/UKProductsWeb/glideway68/$FILE/Statoil_GlideWay_68.pdf
[10:51:06] <dushantch> yeah, I can buy special oil for slide guides, we have 2 factories here, but this machine uses same oil for guides, gearboxes, bearings...
[10:51:39] <anonimasu> have a look at that
[10:52:12] <dushantch> fragalot: I'm trying to find it, but this oil is rare :)
[10:52:39] <dushantch> anonimasu: I'm using an equivallent of that but it's too dense :(
[10:52:51] <anonimasu> they have lower viscosity too
[10:53:12] <dushantch> anonimasu: yeah, but I have to find it in serbia :)
[10:53:16] <anonimasu> hehe
[10:53:20] <anonimasu> dont you have statoil there?
[10:53:51] <dushantch> no, we have 3 local rafineries, bp, shell, etc.
[10:53:56] <anonimasu> we buy 10l at a time..
[10:54:00] <anonimasu> shell has a equvivalent
[10:54:08] <anonimasu> well, you should look for resellers..
[10:54:14] <anonimasu> places that sells huydralic oil and such :)
[10:54:30] <anonimasu> they can order it for you(that's how we do)
[10:54:38] <anonimasu> but we sell that kindof stuff ourselves
[10:56:00] <dushantch> anonimasu: the problem is local manufacturers produce everything you need for machining purpose, so those importing oils import only automotive oils :(
[10:56:44] <dushantch> I found some special catterpillar oils, but's that's it :(
[10:57:28] <anonimasu> call Statoil, and ask them for a local reseller
[10:57:42] <anonimasu> or dig at their web :)
[10:58:44] <DaViruz> first you marry, then you statoil
[10:58:53] <dushantch> anonimasu: I found a 5 and 10 l cans but they're of viscosity 15 at 40 deg C, and I need 5 at 50deg C (I hate these specs), now pounding should I try to find it localy
[10:59:15] <anonimasu> 5l goes by pretty quickly(I think)
[11:00:50] <dushantch> anonimasu: true, but better than buying 200l :)
[11:01:08] <anonimasu> hehe
[11:02:58] <dushantch> anonimasu: now trying to see what chinese drives prices are here, same 750W ones
[11:03:38] <anonimasu> if you find a nice source for them im very interested in buying that too :)
[11:04:35] <anonimasu> if they are sane enough
[11:04:51] <archivist_ub> hmm /me wants to know as well
[11:05:22] <dushantch> anonimasu: well they usually ship minimum 10, but a friend of mine told me we have a guy here who can supply them in lower quantities, screws and nuts too, but those I'd rather buy from europe :)
[11:05:35] <anonimasu> :)
[11:06:02] <dushantch> something like this I understand
http://www.ms-motor.com/acservo80.htm
[11:06:24] <anonimasu> if they are 1/10 the price of the ones we can buy in europe I can buy 10..
[11:06:25] <anonimasu> :p
[11:06:50] <anonimasu> ~1400eur per axis is steep.
[11:07:38] <dushantch> well my friend bought machine vices, 2 of them and I remeber that they costed 1/3 of the price localy but because of plane shipping :), they would be like 1/2 of that if shipped by ship
[11:07:40] <archivist_ub> and become cheap servoman for us poor emc retro fitters
[11:07:51] <anonimasu> lol
[11:08:19] <dushantch> and we have a good container terminal here, lots of chineese containers, so no problem
[11:08:32] <dushantch> just 2 months waiting :)
[11:08:35] <anonimasu> hehe
[11:09:13] <anonimasu> it seems my request about the bearings was a tricky one :p
[11:09:21] <anonimasu> "uh we've never sold that before"
[11:09:23] <archivist_ub> I just got a BT30 collet chuck and collets from hong kong seems ok
[11:12:31] <anonimasu> :p
[11:13:22] <archivist_ub> I was amazed at speed, got email on monday in post, was here friday
[11:13:42] <dushantch> here we can buy from local manufacturers, from knuth , hahn+kolb (pricey) or on flea market :)
[11:14:38] <archivist_ub> ebay seems nearest to flea market at the moment
[11:15:28] <dushantch> well our machinist flea markets are not so bad, a lot of decomissioned equipment from eastern europe, russia gets there
[11:16:02] <dushantch> and from local factories
[11:16:40] <archivist_ub> base of my mill is ex factory auction
[11:18:35] <anonimasu> :)
[11:18:40] <anonimasu> dushantch: that's nice
[11:23:56] <dushantch> anyone had any experience with those granite measuring tables from knuth? or other measuring equipment?
[11:29:34] <dushantch> like this:
http://www.knuth.de/?SESSION_intSite_ID=3&intProdukt_ID=10248
[11:33:48] <archivist_ub> that looks a nice heavy lump
[11:35:01] <dushantch> archivist_ub: should be. I already made a stand for it :)
[11:35:06] <archivist_ub> we may have available one of abused workshop grade here in uk
[11:36:03] <dushantch> archivist_ub: I'm spoiled. I only buy new measuring equipment, because if my etalons are bad, everything else is bad :)
[11:36:37] <archivist_ub> yes true, I use second hand but test carefully
[11:37:16] <archivist_ub> so I have a few calibration grade bits
[11:39:12] <dushantch> I like granite ones, but hate as i can't fix stands on them with magnet, so I'm still undecided should I buy cast iron one
[11:39:27] <dushantch> or granite one
[11:40:53] <dushantch> I think that 200eu for new 400mm ruler 2,7um is steep, what do you think?
[11:41:04] <archivist_ub> I had use of granite at last job but have my own cast iron, I prefer the smoothness of iron
[11:41:42] <anonimasu> tomp: awake?
[11:42:10] <dushantch> I'm trying to get some measuring gear now as you see, table, ruler,planparallels etc :)
[11:58:38] <anonimasu> :)
[12:11:31] <jepler_> http://forgetomori.com/2008/science/weti-wait-for-extraterrestrial-intelligence/
[12:12:40] <anonimasu> lol
[12:29:33] <alex_joni> http://www.techamok.com/forum/viewtopic.php?t=8107
[12:30:58] <dushantch> LOL
[12:33:17] <fragalot> that pretty much nails it :D
[12:33:22] <fragalot> debtclock.com
[12:33:23] <fragalot> :p
[12:38:36] <fragalot> y'know, I don't get the whole "global economy" crash thing,;.. if it's really plunging down everywhere, do what monopoly does,.. just let everyone add a 0 to their current account. :p
[12:38:54] <fragalot> put all that then in one big pot,.. and realize that money really is just a piece of paper..
[12:39:08] <fragalot> well, used to be, now it's pretty much all digital, making it even easier to do this
[12:39:11] <fragalot> :p
[12:39:41] <archivist_ub> I need two 0's on my wages
[12:40:10] <fragalot> I need a wage.
[12:40:12] <fragalot> that would help.
[12:40:51] <fragalot> had somebody offer me 7k a month,.. Conditions on that were a) drop out of uni b) move to north carolina c) 5 year contract
[12:44:48] <fragalot> I didn't like either 3 of those conditions, lol
[12:47:08] <archivist_ub> main need of uni qualification is get the first job, then experience counts
[12:51:24] <fragalot> archivist_ub: And the wage of the frist job
[12:52:06] <fragalot> Granted, 7k won't be topped,.. but,.. the (5 year contract" is kinda.. limited to 5 years, and, even tho it's in the field i'm studying in uni,.. it's not what i want to be doing for the rest of my life
[12:52:26] <archivist_ub> at the last job noob uni leavers were amusing
[12:53:35] <anonimasu> what are you studying?
[12:53:48] <fragalot> anonimasu: Electronics-ICT (networking, programming,... )
[12:53:55] <anonimasu> I see
[12:53:57] <fragalot> ICT would be informations & Communications tech
[12:54:57] <anonimasu> well, if all of the worlds economies are dropping.. what's the point in being worried about it?
[12:55:05] <anonimasu> everything's dropping as much in value :p
[12:55:52] <fragalot> lol
[12:56:22] <archivist_ub> heh /me thinks fragalot should do a USB2 interface for emc2 for his thesis
[12:56:32] <anonimasu> and as economy is realative to other economies that's pretty irrelevant..
[12:56:33] <anonimasu> :p
[12:56:42] <anonimasu> * anonimasu hates "stocks"
[12:56:57] <fragalot> archivist_ub: Already suggested that in here, .. most people said that it wouldn't really be possible
[12:56:57] <anonimasu> they are just imaginary prices for imaginary parts of companies
[12:57:05] <fragalot> archivist_ub: discussed for a while, gave up,... lol
[12:57:17] <fragalot> then found usbcnc .. which does it the exact same way as i had in mind
[12:57:20] <archivist_ub> fragalot, I read the spec I think it can be done
[12:57:29] <fragalot> i /KNOW/ it can be done :p
[12:57:41] <anonimasu> well, we put people on the moon.
[12:58:20] <fragalot> USB is more than fast enough, and asfar as the "realtime" goes,.. just bitbang the end output everytime, should work fine with steppers
[12:58:20] <archivist_ub> then its worth doing as it will get rid of the parport crapage
[12:58:25] <fragalot> nfc how servo's work, imho
[12:58:33] <dushantch> anonimasu: getting them back is the problem :)
[12:58:40] <fragalot> archivist_ub: Aye,.. the parport is the only thing i had real issues with,.. well, still do
[12:59:22] <archivist_ub> well packets will need building both sides of the useb interface in a deterministinc way for realtime to work
[12:59:58] <archivist_ub> an fpga on the outside for that
[13:00:19] <archivist_ub> realtime driver on the inside
[13:00:41] <fragalot_> sorry, running Konsole in windows.. it crashed
[13:01:51] <fragalot_> archivist_ub: I was thinking of temporarilly creating a virtual parallel port, which just translates it to a USB signal, out to an µC or something, which converts it back,.. sorta like a normal usb->parallel adapter,.. but something that works when bitbanged
[13:02:06] <archivist_ub> an fpga on the outside for that
[13:02:09] <archivist_ub> realtime driver on the inside
[13:02:12] <fragalot_> FPGA then
[13:02:25] <fragalot_> altho i don't have FPGA's with USB capabillities laying about
[13:04:00] <fragalot_> ANYWAYS, I did plan on trying to get this project to end up as my end project thingy for school
[13:04:24] <fragalot_> problem is tho that you need to work in groups of 3,.. meaning the other 2 would just leech off of me
[13:04:25] <archivist_ub> fpga can have have stuff thats in pluto/mesa cards
[13:04:43] <anonimasu> uh.. you still do not have realtime feedback to emc..
[13:04:51] <anonimasu> but burst's of data..
[13:04:56] <fragalot_> anonimasu: no, thats true
[13:05:03] <anonimasu> that's the real issue..
[13:05:05] <fragalot_> depends on how often you poll for it though
[13:05:14] <anonimasu> you will have to have the PID loops on the fpga.. if you want that working
[13:05:15] <archivist_ub> anonimasu, nothing in a cpu is really real time
[13:05:22] <fragalot_> also
[13:05:36] <fragalot_> the defenition of "realtime" is just that something is executed within a certain timeframe
[13:05:36] <anonimasu> archivist_ub: we arent talking about cpu's we are talking about positioning loops.
[13:06:05] <archivist_ub> I know and the delay via usqb2 will be small and known
[13:07:14] <archivist_ub> Im assuming at the moment that only one usb realtime device will be allowed
[13:07:59] <anonimasu> well, the stuff I see says 6ms of latency
[13:08:43] <fragalot_> the lil' thing i'm making probably won't even HAVE feedback to emc
[13:08:45] <archivist_ub> that sounds usb1
[13:09:10] <anonimasu> no.. that's usb2 practical.
[13:09:15] <anonimasu> err real measurements..
[13:09:20] <anonimasu> not theoretical
[13:09:38] <fragalot_> Something buggered up my pc
[13:09:58] <fragalot_> owell, ttyl, 2 hrs of µC class (toying about with the PIC18F4550)
[13:10:15] <fragalot_> (eg. what we're talking about now.. USB interfacing)
[13:10:16] <fragalot_> cyah
[13:11:35] <archivist_ub> anonimasu, is that standard non realtime stuff as once the comms are up on usb2 it should be far better
[13:12:23] <anonimasu> well, whatever you do over usb it will suck..
[13:12:32] <anonimasu> :/
[13:12:39] <anonimasu> it seems that it just has alot of latency.
[13:18:20] <archivist_ub> where are you getting the latency info from
[13:18:44] <anonimasu> from some pages dealing with audio effects
[13:18:47] <anonimasu> in swedish
[13:20:15] <archivist_ub> perhaps they are not using it properly as min packet size and data rates are ok
[13:20:51] <dushantch> LOL the usual response when not wanting to reveal source: it's in suomi :) (I'm just kidding ofc)
[13:21:20] <archivist_ub> swedish is as bad for me
[13:24:48] <anonimasu> http://www.jamshop.se/html/PCFAQ.htm
[13:25:11] <anonimasu> ah sorry 6ms was worst case latency
[13:26:09] <archivist_ub> hmm I can just read the numbers :)
[13:27:11] <archivist_ub> one partial cure for latency is to add a timestamp to the data
[13:27:55] <anonimasu> 0,000125s is the minimum latency
[13:27:57] <anonimasu> 125µsec
[13:28:11] <anonimasu> 0.125ms..
[13:28:23] <anonimasu> but that's theoretical max.
[13:28:27] <anonimasu> err min latency..
[13:28:49] <fragalot_> And here I am. :p
[13:28:56] <fragalot_> fragalot_ is now known as fragalot
[13:30:50] <anonimasu> fragalot: you missed the other discussion
[13:31:04] <anonimasu> 125µs is the theoretical max latency
[13:32:16] <archivist_ub> but they seem to be using normal operating systems as far as I can see amongst the funny spelt words
[13:32:20] <anonimasu> and 6ms is the number i've found for the max latency in practice
[13:32:45] <fragalot> I'll ask arround here in 15
[13:32:54] <fragalot> waiting for class to start, :p
[13:33:17] <fragalot> I'm sure it must be possible, maybe sacrifice some speed,...
[13:33:53] <fragalot> any1 ever thought about SCSI? :p
[13:34:15] <fragalot> owell,.. if I ping out, the lappy lost the signal while i walk arround, brb
[13:34:38] <archivist_ub> I would expect 6ms for normal operating systems but way better for a realtime driver designed around our needs
[13:39:29] <anonimasu> but 6ms is still quite a bit of time
[13:39:40] <anonimasu> wel, even half if a lifetime..
[13:46:16] <archivist_ub> I imagine part the problem may be usb1 support, but once a driver is up and running in usb2 and in the realtime kernel and just working for emc2 I would expect far better
[13:48:56] <jepler_> http://developer.berlios.de/projects/usb4rt <- dead since 2005?
[13:49:08] <jepler_> or just without useful releases in the last 3 years?
[13:49:43] <archivist_ub> could be
[13:53:18] <anonimasu> *yawns*
[13:53:55] <fragalot_> back!
[13:55:21] <fragalot_> mm, apparently running the app to drive my USB interface board i made in a VM gives quite a bit of latency :p
[13:55:27] <fragalot_> that, and the app sucks
[14:00:59] <dimas_> dimas_ is now known as dimas
[14:40:37] <archivist_ub> pjm_, see
http://cq.cx/sketchflat.pl for microwave horn folded flat
[14:44:07] <pjm_> archivist_ub interesting, i will check that out
[14:44:40] <archivist_ub> could be
[14:45:40] <cradek> bal-tec's secret pricing structure: for 60 balls, .75 each. for 120 balls, .43 each
[14:45:56] <cradek> so, I project that for $150 you can have an infinite number of balls
[14:47:26] <archivist_ub> your not used to qty pricing are you
[14:47:59] <skunkworks_> I would have to bet it isn't linear ;)
[14:48:19] <cradek> well I'm not surprised, but I wish I knew their rules, so I could smartly decide how to make my order
[14:48:28] <archivist_ub> often worth going to next price break
[14:48:43] <cradek> I hate "call us for a quote, it'll be a surprise, and aren't surprises fun?"
[14:49:13] <archivist_ub> I hate the call/email us as well
[14:50:30] <stuste1> is that per size or will they allow you to mix and match to reach the quantity break?
[14:51:27] <archivist_ub> * archivist_ub imagines per size because they likely will be bagged in 100's
[14:51:59] <stuste1> I say if that logic prevails they have bags of 60
[14:53:27] <archivist_ub> your part been inspected yet stuste1 ?
[14:54:17] <stuste1> if their 'handling charge' is per line item then mixing and matching will not help but if it is per 'PO' then mix and matching will help
[14:54:42] <fragalot_> * fragalot_ casts a stare into infinity as he can't get his USB board into bootloader mode via vmware
[14:55:19] <stuste1> archivist_ub: I have checked the points in my cam system and get +/- .0035 (seven total) the cmm shows .023 and verisurf shows .021 - we are still evaluating
[14:55:44] <archivist_ub> ew
[14:56:45] <archivist_ub> best of luck finding the errors
[14:58:00] <fragalot_> so.. no major misalignments.. *cough* :/
[14:58:13] <stuste1> that is how I came up with .007 total - I was trying to find the error so I could work on the machine - I found a few points that are obviously bogus. I asked them to remove those points and reevaluate. I am waiting on the new evaluations.
[14:59:41] <archivist_ub> I found a lot more backlash in my toy compared to what I saw when I built it
[15:01:16] <cradek> stuste1: I should have asked her what the rules are, but I didn't. I could hear all her other lines ringing and she put me on hold three times...
[15:02:16] <cradek> I expect to have paid a couple hundred dollars before this is done - and that's a fine price for a fixed screw and a nice learning experience.
[15:03:26] <skunkworks_> the last set of balls where too big?
[15:03:36] <cradek> yes, unfortunately
[15:05:02] <skunkworks_> yeckey
[15:14:36] <archivist_ub> file them down a bit
[15:15:17] <archivist_ub> or do it how they do polish and measure till right
[15:19:18] <cradek> or order the size I want next...
[15:21:03] <archivist_ub> building a ball polishing machine would take..... a while
[15:23:03] <jepler_> last night I spent about 1 1/2 hours soldering my surface-mount board .. everything but the connectors and 3 of the LEDs are done. it successfully talks over USB and I uploaded a simple "turn on an LED" program to it over USB.
http://emergent.unpy.net/files/sandbox/tqfpboard-composite-medium.jpg
[15:23:42] <jepler_> before I plugged it in the first time I had a solder bridge that shorted an LED from vcc to gnd. I didn't know that a green LED driven too hard would seem to be yellow/orange
[15:23:56] <jepler_> .. for a split second before the current limit of the power supply kicked in
[15:24:26] <archivist_ub> green plys red from the heat
[15:25:50] <jepler_> I need to figure out a better technique -- right now I really need 3 hands: one to hold the iron, one to apply the solder, and one to hold the part down with the tip of a straight screwdriver
[15:26:27] <archivist_ub> bit of glue(softish) under part
[15:28:20] <jepler_> if I could get better at applying just a little bit of solder to bare pads, then re-heating it after placing the part, I think that would work nicely too
[15:32:47] <cradek> with the two sizes I ordered, I can make five useful combinations of sizes (two circuits, three sizes of balls) - I should get either a very usable result, or plenty of data to find the right size in one more shot.
[15:38:14] <cradek> jepler_: that's how I do it (last way you described)
[15:39:57] <cradek> add a tiny bit of solder to one pad (two opposite corners for an IC), press part down with fingernail and reheat solder until I feel the part drop into place, then solder whatever's left
[15:44:12] <jepler_> I have trouble getting a nice domed pad .. the solder always pulls away with the iron and hardens that way. maybe my iron is not hot enough?
[15:45:34] <archivist_ub> hot iron(not too hot that the solder oxidises) and good flux and clean copper
[15:46:12] <archivist_ub> * archivist_ub hates the new lead free safety rubbish
[15:46:46] <archivist_ub> and real rosin flux :)
[15:47:25] <cradek> jepler_: more heat, clean the board better, use lead solder?
[15:47:26] <jepler_> I have proper lead/rosin solder
[15:47:46] <jepler_> I freshly sanded the board right before I started soldering
[15:47:59] <cradek> did you shine up the board before starting? smearing a tiny bit of paste flux over all of it can help a lot too
[15:48:09] <jepler_> hm I don't have flux paste
[15:48:21] <archivist_ub> sanded! 1000 grit wet and dry
[15:48:56] <cradek> I have a little can of it. remind me to give you some.
[15:49:26] <jepler_> OK, though I'll probably be making another digikey/mouser order soon so I might as well pick up my own
[15:49:54] <jepler_> unless it's the kind of thing where one can is expensive and lasts a lifetime
[15:50:03] <jepler_> or two lifetimes
[15:52:46] <cradek> no more than one lifetime, and it's not expensive
[16:00:38] <anonimasu__> anonimasu__ is now known as anonimasu
[16:35:14] <Paragon> Hello All how do I view irc history?
[16:35:27] <cradek> logger_emc: bookmark
[16:35:27] <cradek> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2008-09-29.txt
[16:35:52] <fragalot> hehe, perky bot
[16:36:00] <Paragon> Thanks Cradek
[16:39:46] <Paragon> Cradek I asked the following on the 27th but I did not get a reply at the time could you shed some light on it?
[16:39:47] <Paragon> Question:
[16:39:49] <Paragon> I have a question regarding digital control of mill spindle via EMC pwm. I currently am using a an SCR controller that take 240vac and converts it to 0 - 90vdc by way of a potentiometer that connects to three pins on the SCR speed control board. The pins are also floating. How could I replace the pot for digital control via EMC?
[16:40:24] <cradek> what do you mean "the pins are also floating"
[16:40:47] <archivist_ub> I imagine some opto and a high voltage fet
[16:41:08] <fragalot> cradek: I'd assume he means that it's nor 1, nor 0
[16:41:28] <archivist_ub> floating and also mean isolated
[16:41:29] <cradek> ?
[16:41:44] <Paragon> As in floating gnd (I found this out the hard way when connecting my scope to a previous controller it shorted out.
[16:41:58] <cradek> oh you mean "not isolated"
[16:41:59] <fragalot> Paragon: ouch
[16:42:15] <Paragon> Yeah pretty stupid huh ...
[16:42:31] <cradek> yes ground clips on scope leads aren't for clipping just anywhere, we all learn that (usually several times over)
[16:42:32] <Paragon> But we live and learn...
[16:42:47] <cradek> is it a KBIC controller?
[16:43:08] <Paragon> Is that a make?
[16:43:15] <cradek> yes
[16:43:18] <archivist_ub> often the earth lead on the scope had a switch (not health and safety)
[16:43:25] <cradek> it's what sherline uses on their 90v DC spindle motor
[16:44:05] <Paragon> No I bought it off of ebay and can't remember the make.
[16:44:33] <cradek> have a schematic for it?
[16:45:12] <Paragon> I just searching google with the hope I can locate the controller
[16:45:26] <cradek> what voltage is across the outside terminals on the potemtiometer?
[16:45:35] <cradek> use a battery operated voltmeter, NOT the scope
[16:46:03] <Paragon> Cradeck it is kbic type controller ....
http://www.kbelectronics.com/manuals/kbic.pdf
[16:46:10] <cradek> aha
[16:46:31] <Paragon> but not made by them ... it's the same type though
[16:46:31] <cradek> KBIC makes a very nice isolator board that takes 0-5 or 0-10v in. you can get that and it just plugs on and gives you screw terminals
[16:47:29] <fragalot> isn't that thing just a matter of hooking a potmeter directly onto the controller?
[16:47:49] <cradek> ?
[16:47:53] <archivist_ub> no he wants emc control
[16:47:57] <fragalot> ah
[16:48:11] <fragalot> put a servo or stepper on the potmeter ^_^
[16:48:11] <Paragon> Yeah that works fine but I wish to controll it via EMC
[16:48:42] <Paragon> Basicly I need to replace the pot for something else
[16:48:58] <fragalot> hold on, lemme check which chip i used when i built my ICD2 for microchip pics
[16:49:22] <Paragon> OK thanks fragalot
[16:49:26] <fragalot> X9C103
[16:50:18] <jepler_> I doubt that output is isolated
[16:50:26] <fragalot> then put an opto infront of it
[16:50:36] <Paragon> That what I was thinking
[16:51:20] <fragalot> all that chip is really is 100 resistors in series, which can be shorted seperately
[16:51:37] <archivist_ub> I assume cradek was one about this
http://www.galco.com/scripts/cgiip.exe/wa/wcat/itemdtl.r?pnum=KBICSI-5-KB&mfgr=KB%20ELECTRONICS
[16:51:53] <fragalot> the 102 is 1k, 103 is 10k, 104 is 100k depending on what you need
[16:52:11] <fragalot> it doesn't like much current though... 3mA
[16:52:25] <cradek> archivist_ub: yes that's it
[16:52:45] <jepler_> fragalot: or much voltage for that matter
[16:52:46] <cradek> fragalot: but pwm/pdm/analog in would probably be best in this case
[16:53:06] <fragalot> cradek: No argument on that :)
[16:53:30] <cradek> you can probably replace it with an optoisolator, but you need to be smart about it - start with measuring what's going on there, like the voltage across the pot as I suggested.
[16:54:01] <cradek> if it's a real KB, getting the isolator board archivist_ub found is the safest sure thing
[16:54:10] <cradek> I got one on ebay for $20 or so
[16:55:16] <Paragon> I was thing about using PWM to switch a fet this would be easy if it used varible resisor but its using a pot so I am not to sure.
[16:55:32] <cradek> opto opto opto
[16:55:50] <cradek> if you don't isolate it, you'll nuke your computer
[16:55:57] <archivist_ub> * archivist_ub would opto as well
[16:56:04] <Paragon> It's not an original KB but similiar design
[16:56:18] <fragalot> opto ftw
[16:56:30] <Paragon> Sure thing ... opto I have a few of these laying around...
[16:56:42] <fragalot> with a fet you'd need a fet driver first to ensure it switches on nicely
[16:57:10] <Paragon> I have some of those too :-)
[16:57:11] <jepler_> http://timeguy.com/cradek-files/cnc/lathe/DSCN6292.JPG
[16:58:15] <fragalot> jhehe, that works too xD
[16:59:17] <cradek> it's surprisingly linear - big offset though - easy to fix in HAL
[16:59:59] <cradek> the right one is obviously 100k - not sure about the left one - something appropriate for the LED running on 5v.
[17:00:05] <Paragon> Just looking at the image ... So the opto basical sits in between one of the legs of the speed control pot and is driven by PWM from EMC...
[17:00:15] <jepler_> yes that's the short summary
[17:00:31] <fragalot> cradek: would be 1k
[17:00:43] <cradek> no, I bet it's 150
[17:00:52] <fragalot> well,.. that's what I've used.. (the LED's I have are /VERY/ sensitive to current)à
[17:01:00] <fragalot> they run very bright at 5mA.. :p
[17:01:35] <fragalot> cr250
[17:01:42] <fragalot> cradek: 250* for default leds
[17:01:56] <fragalot> so you prolly used 270 if you use the E12 series
[17:02:22] <Paragon> Thanks guys.. I like the idea of the opto I will give it a try...
[17:02:57] <cradek> Paragon: don't do it blindly. figure out what you have first. your drive is a clone of mine, the pot does not necessarily work the same way.
[17:03:42] <archivist_ub> parport likely wont drive opto direct use a transistor
[17:04:14] <cradek> bbl
[17:04:16] <jepler_> yeah -- if I remember the details of that machine there's a driver, it's not direct from parport.
[17:05:00] <fragalot> parports only give 2.4V 2.6mA don't they?
[17:05:06] <archivist_ub> I have a bunch of ttl before my stepper drivers to get good levels
[17:05:26] <Paragon> Sure thing cradek. Basicaly I am going to leave the 10k control pot on the machine and use the opto to break and complete the circuit.
[17:05:43] <fragalot> archivist_ub: hehe, I just used negative logic to get arround that problem ^_^
[17:06:07] <fragalot> the parport can sink way more than it can source
[17:06:11] <archivist_ub> still need to get to switching point
[17:06:33] <fragalot> archivist_ub: yeah,.. hex inverter used as buffer
[17:07:51] <Paragon> I have a basic question with regards to the Z axis ... After homeing the Z AXIS what direction should a positive move give?
[17:08:03] <Paragon> Up or Down?
[17:08:29] <fragalot> positive should go up
[17:08:33] <fragalot> in theory
[17:09:38] <Paragon> I thought so. I have just rewired the stepper drives after sometime of the machine in storage so I was a little confuesed .. lol
[17:10:03] <Paragon> Thanks again ... I'm off the workshop :-)
[17:10:08] <dushantch> or back, or front depends on machine architecture :)
[17:10:15] <archivist_ub> no need to rewire to change direction
[17:10:34] <Paragon> Do it HAL?
[17:10:48] <dushantch> Paragon: yes
[17:10:59] <Paragon> Good stuff..
[17:11:00] <archivist_ub> if using stepconf then also there
[17:11:03] <Paragon> CU
[17:11:14] <Paragon> CU Soon ...
[17:11:35] <archivist_ub> we await cut parts
[17:14:47] <anonimasu> :)
[17:21:13] <dushantch> anonimasu: found oil at wurth :), now have to call them tommorow and see how much will they rip me off :)
[17:26:45] <fragalot> damnit why didn't
http://www.instructables.com/id/SXCIEH6F3HY3SOB/ <-- he give proper dimensions on his machine
[17:27:18] <fragalot> atleast the DXF opens
[17:28:02] <anonimasu> dushantch: probably alot
[17:28:16] <anonimasu> they even rip us off as a retailer of their stuff.
[17:29:18] <dushantch> anonimasu: for 20l, dunno, my brother works there, I'll see if he can make me some deal :)
[17:32:39] <fragalot> sigh, all imperial :p
[17:59:33] <BigJohnT> http://i47.photobucket.com/albums/f163/johnplctech/GW1500.jpg
[17:59:40] <BigJohnT> sure is smooth
[18:00:16] <fragalot> does anyone here know an app to tile a huge PDF to print it out in scale,.. tiled?
[18:00:29] <fragalot> w/o random sections overlapping w/o markers on those spots..
[18:01:01] <BigJohnT> do you have acad fragalot ?
[18:03:08] <fragalot> BigJohnT: no. I use progecad
[18:06:56] <fragalot> I already have a tiled version, but it randomly overlaps,.. and my paper cutter thingy doesn't cut straight :/
[18:07:50] <fragalot> BigJohnT: also, nice ride ;)
[18:08:21] <fragalot> lmao, even has an arm rest on the back
[18:31:20] <BigJohnT> yep only thing missing is the beer fridge :)
[18:32:16] <BigJohnT> fragalot I only know how to tile in ACAD :(
[19:19:52] <tomp> jepler: usb4rt
http://unix.freshmeat.net/redir/rtai/60645/url_homepage/usb4rt Updated: Fri, Sep 5th 2008 17:46 UTC (24 days ago)
[19:24:39] <jepler_> I think that date actually reflects when the rtai 3.6.1 release was posted to freshmeat -- for some reason usb4rt is organized on freshmeat as a "branch" of rtai
[19:25:11] <jepler_> 05-sep-2008 17:46 is the date the 3.6.1 rtai release was posted
http://unix.freshmeat.net/projects/rtai/?branch_id=49551
[19:27:27] <jepler_> http://www.orocos.org/node/783
[19:29:52] <SWPLinux> aaaahhhhhh - eastern time again :)
[19:30:34] <jepler_> hi SWPLinux
[19:30:46] <alex_joni> hey SWPLinux, how was photokina?
[19:30:52] <SWPLinux> big
[19:30:56] <alex_joni> nice
[19:31:14] <SWPLinux> I didn't get out of the booth much, so I didn't really see too much of the other 7 or 8 halls
[19:31:43] <SWPLinux> we had several distributors/dealers from Romania stop by :)
[19:31:57] <SWPLinux> (all from Bucharest though)
[19:33:18] <alex_joni> probably nothing serious :D
[19:34:58] <SWPLinux> hh
[19:35:01] <SWPLinux> heh
[19:37:24] <SWPLinux> huh - 60 users. that's quite a few
[19:38:21] <anonimasu> yes.. but we are more like 30
[19:38:28] <anonimasu> lots of doubles
[19:38:38] <SWPLinux> who, me? :)
[19:41:13] <LawrenceG> stay away from tall buildings..... the stock markets are crashing
[19:41:58] <anonimasu> hehe
[19:42:01] <dushantch> :)
[19:42:02] <anonimasu> shit happens
[19:42:25] <LawrenceG> buy...buy buy...
[19:42:25] <anonimasu> war cant keep the economy spinning forever :(
[19:42:51] <SWPLinux> don't worry, I'm in an airport - there are no tall buildings around
[19:42:51] <SWPLinux> though I'm looking at going to LA or NY in a few weeks
[19:42:58] <SWPLinux> no, we're on borrowed (literally) time at the moment
[19:43:17] <dushantch> every ww started like this :)
[19:43:23] <LawrenceG> ya got that right.... probably some CEO positions opening up today
[19:43:51] <SWPLinux> at least the house voted down the bail-out. maybe madness won't prevail this time
[19:44:05] <SWPLinux> hahahahahaha. I'm too funny
[19:44:20] <anonimasu> :)
[19:44:22] <SWPLinux> I guess we just don't know which madness yet
[19:44:55] <SWPLinux> brb - gotta get more coffee before my next flight
[19:45:46] <LawrenceG> lucky for the US, nobody wants to invade them
[19:46:30] <SWPLinux> and soon there won't be enough resources for it to be profitable
[19:46:30] <dushantch> LOL, nobody wanted to since first settlers :)
[19:47:45] <dushantch> war or the US?
[19:47:54] <SWPLinux> war on the US ;)
[19:48:14] <dushantch> but it's never profitable :)
[19:48:21] <anonimasu> maybe I should buy some stocks soon.
[19:48:25] <SWPLinux> depending on who you are
[19:48:38] <SWPLinux> yes, but which ones? that's the question.
[19:48:47] <dushantch> food nad wather?
[19:48:53] <anonimasu> hehe.. oil probably
[19:48:53] <dushantch> water :)
[19:48:54] <SWPLinux> heh
[19:49:29] <SWPLinux> well, on that note - I should probably head out for my next flight. See you all later (tonight or tomorrow morning)
[19:49:46] <SWPLinux> (enter, stir pot, leave - good M.O. :) )
[20:08:17] <dushantch> for those chinese servo drives, shipping is 7eu/kg by plane, here's the link www.gsk.com.cn
[20:09:00] <dushantch> I'm going to try to choose the right drives and ask for quote for 3x750w
[20:22:22] <tomp> jepler: wow the katholik uni at leuven ( lotsa edm work done there) ( blender-orocos-milling)
[21:06:43] <anonimasu> night
[21:10:13] <dushantch> what do you think about tool life management and tool life compensation in machine controller? in emc2 perspective how hard it is?
[21:14:11] <jepler_> in my understanding, you're asking for the software to do tool radius compensation based on a measured value. G38.x probing allows you to measure this value, and G41.1/G42.1 allow you to use this value for cutter radius compensation using a measured/calculated value instead of a tool table value.
[21:15:59] <jepler_> however, emc has strict requirements for the gcode that can be run during tool radius compensation, specifically that it forbids any concave corners sharper than the current tool. I don't think any(?) cam software will write code that is going to work consistently inside G41.1/G42.1
[21:20:49] <jepler_> if you want to do work in this area, learning the gcode interpreter and completing the work that has been started on the "concave_comp" branch of CVS. My impression is that the theoretical work is largely done, but there is a bunch of practical work to be done, mostly regarding when non-motion codes are interspersed with motion codes while tool compensation is in effect
[21:22:20] <dushantch> Hrmpf, I was under the impression that they do it indirectly, monitoring machining time for every tool, and based on that invoking tool compensation from time to time. well for starters I know of two indirect ways to control tool sharpness: 1. monitor motor amperage, pretty rough; 2. statistical analysis
[21:22:39] <dushantch> for 2 you need to know the type of material
[21:23:27] <dushantch> I'm more asking about this "tool life management"
[21:24:23] <jepler_> regardless of how you measure or approximate the worn tool's diameter or radius, you're going to bump into this problem with the limitation of emc2's tool compensation code
[21:27:38] <dushantch> and what about using plain G41?
[21:28:09] <jepler_> the difference between g41/g42 and g41.1/g42.1 is just whether the value comes from the gcode or from the tool table
[21:28:17] <jepler_> both have the same limitations such as concave corners
[21:28:32] <dushantch> ahh, I understood that you said plain g41 hasn't
[21:29:38] <dushantch> I'm not getting that limitation, do you want to say that tool path can't be sharp, but has to be as dull as tool?
[21:30:04] <jepler_> have a look at the thing labeled "figure 8":
http://linuxcnc.org/docs/html/gcode_tool_compensation.html#r1_4_1_7
[21:30:06] <dushantch> what do you do with spherical mills?
[21:31:14] <dushantch> this is the key: "When cutter radius compensation is on, it must be physically possible for a circle whose radius is the half the diameter given in the tool table to be tangent to the contour at all points of the contour." I understood that, thought it natural
[21:31:39] <jepler_> I think you'll find that cam systems don't generate code that meets that requirement
[21:32:42] <dushantch> ahh, that's the problem, I thought of this emc's implementation as feature
[21:32:43] <jepler_> for instance, they'll break up a surface into hundreds of small straight segments. If you squint it will look like an arc, but mathematically it's still got concave corners where the tool doens't fit.
[21:34:01] <dushantch> but what do you do for tools with round inserts, spherical mills etc?
[21:35:23] <jepler_> I think you use tool length offset to put the tip of the tool at the depth you desire, and use the widest part of the tool as the diameter
[21:36:25] <dushantch> btw. great text at that link, I learned that in school, but this is nicely explained
[21:37:51] <jepler_> oh, are you looking at 3-axis or 5-axis milling? there will be more limitations when it comes to 5-axis -- length compensation is only in the development version, and there's no useful diameter compensation yet.
[21:39:27] <dushantch> I know :), btw. this is more like a bad postprocessor output and code generation, than emc's fault
[21:40:25] <dushantch> because they should use g02/3
[21:40:30] <jepler_> wellllll... there are all sorts of different opinions about that
[21:41:46] <dushantch> but postprocessor makes the code that machine can use, bad ones only use linear interpolation, and have to give machine what is POSSIBLE to make and not what they want :)
[21:41:47] <jepler_> here's mine, fwiw: I hand-write a lot of code. It would be very convenient if I could write code to mill an internal rectangular pocket using g41/etc without making any calculations with the tool radius
[21:42:06] <dushantch> looks like the difference between designer and manufacturer :)
[21:42:10] <jepler_> all I'd need to do is know that based on the tool I choose, the corners are not "too rounded"
[21:42:45] <jepler_> if emc's tool radius compensation algorithm were improved to make that possible, it would also mean that a lot of this cam code could start being acceptable too
[21:43:01] <jepler_> because it also just wants you to get as near as you can to that path with the edge of the tool at all times
[21:43:24] <dushantch> I mean by this logic if you give a machine a command to make a 1 mm dia pocket with 40mm tool it should do it :)
[21:43:56] <dmess> it'll try??? i guess right
[21:44:15] <dushantch> 50mm deep :)
[21:45:07] <jepler_> you're right that trying to accept more things might mean accepting some things that are "clearly" wrong. I don't know offhand what the unfinished new cutter comp code would do in that case
[21:45:35] <jepler_> a 41mm round hole, for all I know
[21:46:12] <jepler_> or maybe it'll invoke the "vise seek" mode and crash the tool into it
[21:46:38] <dushantch> jepler_: but how do you decide if that "imprecision by design" is needed or not? sometimes you need precision, sometimes you don't, but only higher levels have the knowledge to decide
[21:48:25] <jepler_> I wish I could find the link -- this summer chris wrote a great mailing list post about this. He explains what one group of people thinks about this question, and he says they're right. Then he explains what the other group thinks, and he says they're right too.
[21:48:26] <dushantch> it could be made more robust against that problem I gave, but then the machine would have to have it's own internal preprocessor, which will scan all the code to see if some unwanted collisions/machining will happen
[21:49:25] <dushantch> that would be nice btw. as yopu could then put the dimensions of machine, additional toolings etc. and simulate the collisions
[21:49:48] <jepler_> that's why, if it's contributed, I'd like to see code in emc to work in either the strict mode it has today (as you say, the theoretical basis for the current code is good), or the lax mode (for the reasons I've talked about)
[21:49:57] <dushantch> or that preprocessor could change those concaves to radiuses with tool diam?
[21:50:46] <dushantch> but look, I emhasize preprocessor, as I think that current implementation is correct :)
[21:51:23] <dushantch> so that PP will output modified gcode, it doesn't have to be anything RT, just plain script
[21:51:29] <dushantch> what do you think?
[21:52:10] <dushantch> that way you can have both worlds :)
[21:52:32] <jepler_> you're right that the current implementation is correct (or at least on a sound theoretical basis -- there are probably still bugs). But other people are right that they have the cam software they have, or that they want to hand-write gcode in a certain way, and that the control could give them the results they want
[21:52:50] <jepler_> that group wouldn't care about distinctions like preprocessor vs "in the interpreter"
[21:54:12] <toastydeath> * toastydeath the g-code troll peeks out from under bridge
[21:56:15] <dushantch> well the upsides of preprocessor are: 1. can be a simulation run, so you'd know if your machine will make the part before machining;
[21:56:16] <dushantch> 2. runs only once per program made as interpreter would run again for every run of program
[21:56:18] <dushantch> 3. It outputs standard g-code that you can aditionaly modify
[21:56:19] <dushantch> 4. it keeps both parties happy without modifying base emc interpreter
[21:56:21] <dushantch> 5. it keeps interpreter cleaner - a good thing AFAIK :)
[21:57:12] <dushantch> 6. it could be integrated in "machine simulator" in which you could check for collisions
[21:57:33] <dushantch> please hack away at these arguments :)
[21:58:07] <toastydeath> uh, i am trying to scroll up and figure out what is being discussed and i can't
[21:58:24] <jepler_> toastydeath: we started way back at the question of how emc deals with tool lifetime
[21:58:39] <toastydeath> oh.
[21:58:47] <jepler_> toastydeath: I don't know much about that, but I do know about tool radius compensation, and I know part of tool lifetime is a decrease in tool diameter compared to nominal, as the tool wears
[21:58:59] <jepler_> and since then we've been talking about diameter/radius compensation
[21:59:09] <toastydeath> cool.
[21:59:27] <jepler_> dushantch: the main problem is that your "preprocessor" has to be exactly the same as the interpreter -- so it should *be* the interpreter.
[22:00:11] <jepler_> dushantch: originally AXIS had its own gcode interpreter -- rs274.py -- because I thought the difficulty of writing a gcode interpreter was less than "wrapping" emc's existing interpreter into Python .. I decided a few months later that I was wrong
[22:00:18] <dushantch> jepler_: the problem is do you want to make interpreter to look forward to infinite number of lines?
[22:00:24] <jepler_> (but not before writing a nearly-compatible interpreter for gcode arithmetic and parameters)
[22:00:55] <jepler_> so you have to get a lot of details the same -- this code is stiky, that one is not, and so forth
[22:00:57] <jepler_> sticky
[22:01:01] <toastydeath> why does something need an infinite look ahead
[22:01:07] <dushantch> btw, I think that this could be just a wrapper
[22:01:58] <dushantch> toastydeath: what about 1mm wide 50mm deep groove made out of 100's lines by some inteligent CAM to be made with 40mm dia tool
[22:02:23] <jepler_> later problems I ran into concerned the question of exactly when degenerate arcs became unacceptable, exactly when arcs with nearly-equal start and end points were treated as full circles and when they were treated as nearly zero-length moves, and so on
[22:02:28] <toastydeath> okay, that still only requires a finine look ahread
[22:02:29] <toastydeath> *ahead
[22:03:07] <dushantch> sorry then, I change my statement to very large finite number of lines :)
[22:03:19] <toastydeath> most controls do 10-5000 lines of look ahead
[22:03:22] <toastydeath> depending on what you're doing
[22:03:28] <toastydeath> and how fast it's trying to move
[22:03:30] <jepler_> yes, using the existing interpreter as a library to turn any gcode into a sequence of primitives is an approach I endorse heartily -- it is what axis eventually did, and it is very good at showing accurate gcode previews
[22:03:56] <jepler_> from the interpreter you get a series of calls "canonical machining functions", such as STRAIGHT_FEED, ARC_FEED, DWELL, and so on
[22:04:21] <jepler_> those are fairly easy to turn back into obvious and simple gcode
[22:04:30] <dushantch> what about this implementation: run the interpret on gcode, on first such error, round with next element by tool radius, run again, round again etc.
[22:04:53] <cradek> http://thread.gmane.org/gmane.linux.distributions.emc.user/8679/focus=8680
[22:04:54] <jepler_> possibly with tweaks
[22:04:55] <toastydeath> dushantch: what problem are you solving with that, i am still catching up
[22:05:13] <dushantch> toastydeath:
http://linuxcnc.org/docs/html/gcode_tool_compensation.html#r1_4_1_7
[22:05:20] <jepler_> time for me to go
[22:05:27] <toastydeath> bai jepler_
[22:05:31] <jepler_> please carry on the argument^Wfriendly discussion in my absence
[22:05:44] <toastydeath> what's wrong with cutter comp?
[22:06:31] <dushantch> bye
[22:07:00] <toastydeath> what problem are you trying to solve, dushantch
[22:07:26] <dushantch> toastydeath: I think that it's correct, but also that sometimes people want it to be "incorrect" as per this thread
http://thread.gmane.org/gmane.linux.distributions.emc.user/8679/focus=8680
[22:07:48] <dushantch> s/correct/precise
[22:08:14] <dushantch> I offered a makeshift solution idea, not implementation :)
[22:08:26] <toastydeath> oh
[22:09:01] <dushantch> the solution is to leave the interpreter precise as it is, but make the g-code imprecise as the postprocessor should made it :)
[22:09:37] <dushantch> so every side can have it's way
[22:10:06] <dushantch> toastydeath: have you lost me? :)
[22:10:42] <toastydeath> nope
[22:10:44] <toastydeath> just reading
[22:10:48] <toastydeath> all our controls do it the second way
[22:11:25] <toastydeath> where sharp->sharp just goes
[22:12:00] <toastydeath> fors g1, anyway
[22:12:19] <toastydeath> it will whine if you have something that is g2/g3 and the radius is smaller than the comp rad
[22:12:41] <toastydeath> the trickster way around that, of course, is to program to the nominal tool diameter, and leave the cutter comp blank
[22:12:45] <toastydeath> at 0
[22:13:03] <toastydeath> and just enter the comp value as the cutter's deviation from nominal
[22:13:05] <dushantch> toastydeath: what about 1mm wide 50mm deep groove to be made with 40mm dia tool? what would happen then?
[22:13:30] <toastydeath> on the controls I use at work, if you were using pure g1 moves, it would go without a problem
[22:13:53] <dushantch> but most CAM's go with plain g1's
[22:13:57] <toastydeath> it calculates the point of tangency for the next move
[22:14:00] <dushantch> :)
[22:14:03] <toastydeath> right
[22:14:30] <toastydeath> i don't understand what you're trying to point out
[22:14:50] <toastydeath> you'd get a slot 50mm wide, with whatever radius the cutter was in the corners
[22:14:54] <dushantch> so I propose to make it more robust, with checks like these and to offer to change g-code for you, like "Say yes to all for rounding of all sharps" :)
[22:15:01] <toastydeath> why?
[22:15:56] <toastydeath> the "no internal sharp corners" problem is one of complexity, in my opinion
[22:16:00] <dushantch> because CNC machines are to be precise and do what you tell them :)
[22:16:26] <toastydeath> uh, that doesn't have any meaning in this context
[22:16:40] <toastydeath> it's a matter of semantics, not precision
[22:17:05] <toastydeath> it's a headache for me to program a bunch of arcs at every sharp internal corner where i'm using cutter comp
[22:17:21] <dushantch> but idea is that you don't have to :)
[22:17:24] <toastydeath> obviously i'd like it to just do what i told it to, stop at the line, and take off in the new direction
[22:17:31] <toastydeath> what's the idea that i don't have to?
[22:17:32] <dushantch> I agree
[22:17:53] <dushantch> idea is that you don't have to program a bunch of arcs
[22:18:03] <toastydeath> right, i'm saying all the machines at work behave that way
[22:18:34] <toastydeath> i don't have any experience on machines that require you explictly call an arc for a sharp corner
[22:18:37] <dushantch> so I'm saying that emc should be made to behave that way as an option
[22:19:00] <toastydeath> i suppose, what's the counterpoint to having it as the default?
[22:19:19] <toastydeath> why does someone want it to stop and freak out if there's no radius specified
[22:19:55] <dushantch> quote cradek: "I have heard that a lot of cam-generated code doesn't work with emc's
[22:19:56] <dushantch> cutter compensation because it depends on certain behavior in concave
[22:19:58] <dushantch> corners. Some will argue (just wait!) that the cam should give a path
[22:20:00] <dushantch> that can be cut with the given tool. That means there cannot be sharp
[22:20:01] <dushantch> inside corners. They are right.
[22:20:03] <dushantch> Others will say lots of other controls will leave the round inside
[22:20:05] <dushantch> corner automatically and not error. They are also right. I would
[22:20:07] <dushantch> personally also like this behavior."
[22:20:21] <toastydeath> cam outputs whatever you, the user, have it set up to postprocess
[22:20:43] <dushantch> toastydeath: as that to be the default or not is of no importance to me
[22:21:14] <toastydeath> i guess i just don't understand the counterpoint.
[22:21:14] <dushantch> but to be able to work both ways, transparently and modifyable is
[22:21:31] <toastydeath> where is the functional advantage to requring radii?
[22:21:41] <toastydeath> i'm not like, trying to nail you here, i just don't see it
[22:21:48] <dushantch> ok
[22:21:50] <dushantch> :)
[22:22:18] <dushantch> because you get different parts for different tools made by same program
[22:22:26] <dushantch> and machine
[22:22:33] <toastydeath> explain
[22:22:54] <toastydeath> different parts in the same program?
[22:23:10] <dushantch> ofcourse if you don't do some do-it-yourself tool compensation :)
[22:23:22] <toastydeath> i think you are missing what i am arguing against
[22:23:39] <dushantch> because you get different !machined parts for different tools made by same program
[22:23:42] <toastydeath> there's no reason to have to specify radii in sharp g1 corners
[22:23:53] <dushantch> I agree
[22:24:05] <toastydeath> the only reason i can see is because the control lacks the programming to handle that situation, and thus dumps it on the user
[22:24:44] <toastydeath> * toastydeath shrug
[22:25:18] <dushantch> yeah, and I proposed a way to solve it
[22:25:34] <toastydeath> which was?
[22:25:41] <dushantch> :)
[22:26:12] <dmess> hi all
[22:26:19] <toastydeath> hay dmess
[22:26:35] <dushantch> wrapper around interpreter, run before machining time, which on every such error automagicaly rounds the corner
[22:26:56] <toastydeath> that seems to defeat the purpose of having the control do it?
[22:27:06] <dushantch> that way interpretter stays lean and clean, purists happy, as users
[22:27:12] <toastydeath> that should, in my opinion, be native behavior on any control
[22:27:28] <toastydeath> again in my opinion, the "purists" are people who don't have parts to make
[22:27:44] <dushantch> it is, but why should it do it on every run when the program is the same?
[22:28:14] <toastydeath> why should i have to have something modify my g-code after i've written it?
[22:28:24] <dushantch> the idea is that it outputs : "I've round up 28 of your corners to 4mm diam"
[22:28:40] <dushantch> toastydeath: all the controls do it :)
[22:28:59] <toastydeath> no, they have it as part of their native cutter comp implementation
[22:29:29] <dushantch> and this is it :), a part
[22:29:42] <toastydeath> i can program things in MDI with cutter comp on, and it works
[22:29:56] <dmess> Iv never personally liked those features/ controls
[22:30:07] <toastydeath> dmess: which
[22:30:28] <dmess> heidenhein, A-B
[22:30:44] <toastydeath> no i meant which behavior
[22:30:44] <dmess> some old siemens
[22:30:57] <toastydeath> i've never used those controls, just fanuc, meldas, and haas
[22:30:57] <dmess> auto rounding of corners
[22:31:15] <dmess> meldas should have it
[22:31:16] <dushantch> dmess: may I ask why?
[22:31:38] <dmess> becz what if i want a sharp corner
[22:31:53] <toastydeath> pockets, dmess
[22:31:56] <toastydeath> not sharp corners
[22:32:16] <dushantch> concave survaces
[22:32:32] <toastydeath> like if you wanted to program a pocket with each wall being a g1
[22:32:37] <dmess> i believe all programming should happen offline and the machine tool should NOT deviate from its instructions
[22:32:59] <toastydeath> i agree with you on that, but that's not what we're talking about
[22:33:27] <dushantch> dmess: what about all these CAM output that aproximates with g1's between which no tool can go in?
[22:34:00] <dmess> yeah that type of output sucks..
[22:34:01] <dushantch> dmess: what about when you tell the machine to make what is not possible?
[22:34:23] <dmess> but usually there is no c/c on that sort of stuff
[22:34:43] <toastydeath> dmess, we're not talking about that
[22:35:04] <toastydeath> think of a pocket, on any random block.
[22:35:10] <dmess> it doesnt know... as long as it can read the math it rolls
[22:35:19] <dushantch> should it tell you: 1. no way go ....
[22:35:21] <dushantch> 2. should it try to make something, whatever it is?
[22:35:22] <dushantch> 3. should it yell : it's not possible, but I modified this and that and now it is?
[22:36:18] <toastydeath> i'm trying to think of a way to make it clear
[22:36:48] <dmess> i understand what your on about
[22:37:17] <dushantch> this is the thread that's about this:
http://thread.gmane.org/gmane.linux.distributions.emc.user/8679/focus=8680
[22:37:23] <dmess> on the fanuc you just add ,r3.0 at the end of each g1
[22:38:17] <toastydeath> it's an issue of what do you do when there's no r word
[22:38:27] <dushantch> dmess: and when you change the tool with some roundish inserts? or if you have too small pocket like 1x1mm
[22:38:31] <toastydeath> you come to a sharp corner. does it stop at the wall, and follow it
[22:38:40] <toastydeath> or does it alarm out, and demand you put a g2/g3 in?
[22:39:08] <dushantch> or does it put those itself and notify about that?
[22:39:52] <toastydeath> i would throw a control away that did that, dushantch
[22:40:01] <dushantch> :)
[22:40:21] <dushantch> toastydeath: then just turn off the warnings in ini :)
[22:40:27] <toastydeath> a machine should never, ever touch the gcode
[22:40:38] <toastydeath> if there's a problem, it needs to stop
[22:41:11] <toastydeath> because if there's a problem with that, and I have a 125,000 dollar rail on the machine, i do not want code I did not write being run
[22:41:23] <dushantch> and it stopped and gave you the solution :), nvm it can modify it's internal representation
[22:41:45] <toastydeath> dushantch, there's a fundimental difference between how the machine interprets code
[22:41:54] <toastydeath> and actually changing what's there to insert things
[22:42:23] <dushantch> so yo trust all those haas mills that treat sharp edges as round?
[22:42:30] <toastydeath> no, i don't
[22:42:37] <toastydeath> and that's an option in haas
[22:43:03] <dushantch> so I believe this should be an option too, as you rember I said at the begining
[22:43:19] <toastydeath> i don't think so.
[22:43:51] <toastydeath> by saying g1, i am telling the machine "make this corner regardless of radius."
[22:43:57] <dushantch> modifying internal representation or gcode... wel atleast you can read gcode to see what's the diff, and that happens only once, not at every runtime
[22:44:14] <toastydeath> by putting in radii, you are altering what i am telling the machine to do
[22:44:34] <toastydeath> it doesn't make an arc, it stops, and then moves off in the new direction.
[22:44:35] <dushantch> but that radii=tool radii
[22:44:42] <toastydeath> no, it doesn't
[22:45:04] <toastydeath> bring a machine in from 400 ipm in a cut to a 90 degree corner you programmed to .001 over your comp radius
[22:45:17] <toastydeath> the tool won't be there when it comes out of the corner
[22:45:40] <toastydeath> with g1, it will
[22:45:54] <toastydeath> dead on is even worse
[22:46:23] <toastydeath> the machine does not interpolate the arc with g1 intersections
[22:46:30] <toastydeath> it stops, and takes off
[22:46:51] <toastydeath> it will interpolate the arc if you specify an R word at the end of the g1, or if you specify g2/g3
[22:47:20] <toastydeath> and the closer that radius is to the cutter comp, the less accurate the part becomes because of burning and chatter.
[22:48:50] <dushantch> so you say coming fast to low radius g2 is bad?
[22:49:08] <toastydeath> not low radius, a radius that very closely matches or is identical to your cutter radius
[22:49:30] <toastydeath> think about what the control tries to do in a corner - it tries to interpolate a whole bunch of arc segments
[22:49:38] <spasticteapot> Does anyone here know an especially cheap way to build a CNC machine?
[22:49:57] <dushantch> toastydeath: I understang that argument, and I think I agree
[22:50:04] <toastydeath> depending on how that math is written, what you wind up with is a bunch of segments that are RIGHT on top of one another
[22:50:06] <dushantch> toastydeath: thanks for clarifying
[22:50:13] <toastydeath> np, sorry i get passionate about this
[22:50:14] <spasticteapot> Could a non-CNC router be modified with some surplus stepper motors, a PIC, and some motor drivers?
[22:50:28] <dushantch> spasticteapot: www.cnczone.com
[22:52:12] <dushantch> toastydeath: this is about singularities, hmm that requires smarter interpreter
[22:52:42] <toastydeath> i don't think so
[22:53:02] <toastydeath> it's a matter of machine resolution, it's bad practice to program an arc with a cutter that's 3/4 the size of the arc
[22:53:24] <toastydeath> most cnc programming books, and almost all manuals, mention it
[22:53:55] <toastydeath> the accuracy is just not there to get something that resembles a circle
[22:54:42] <toastydeath> if you had ultra-precise screws and encoders, and had your spindle running very slow, you might be able to get it done
[22:54:58] <dmess> the closer the rads get together the more trouble you run into and i have 20 yrs of experience(trouble) to attest to that..
[22:56:22] <dushantch> could the controls be made more inteligent to make it less bad? and how?
[22:56:31] <toastydeath> no, the control isn't the issue so much
[22:56:45] <toastydeath> it's the hardware that limits it, so the controls don't even bother trying to address it
[22:57:31] <toastydeath> you could hack the numbers in the control, but you aren't going to get a smooth contour.
[22:57:56] <toastydeath> and that counter to the idea of using a machine tool.
[22:59:38] <toastydeath> i think it comes down to an issue of notepad vs. vim
[22:59:52] <dushantch> now that came out of the blue :)
[22:59:56] <toastydeath> you can modify the behavior to make it more "user-friendly" on the surface
[23:00:18] <toastydeath> but it just is going to cause you headaches later on when you aren't expecting it.
[23:01:26] <dushantch> so may I ask how do you use non cylindrical mills in emc?
[23:01:43] <toastydeath> like, ball and copy mills?
[23:01:47] <toastydeath> spherical?
[23:01:48] <dushantch> yep
[23:01:57] <cradek> mill cutter compensation doesn't care about the tool shape
[23:01:57] <toastydeath> i dunno, i don't use emc
[23:02:17] <cradek> for mills, all you tell emc is the diameter
[23:02:18] <dushantch> ROFL
[23:02:19] <toastydeath> but cam, mostly
[23:02:30] <toastydeath> if you are asking about making complex contours of stuff
[23:02:55] <toastydeath> the cam software knows what shape the tool is, and dumps the toolpath so that the right part of the tool is contacting the work
[23:02:57] <dmess> what cam Toast
[23:03:05] <toastydeath> any old cam
[23:03:12] <jepler_> * jepler_ curses surface-mount technology.
[23:03:15] <dushantch> no, I'm asking what happens when you mill something with emc with some round mill? and come to the corner
[23:03:34] <dmess> it will follow the code
[23:03:35] <jepler_> my board now trips the power supply over-current as soon as I power it on .. but I can't find the problem
[23:03:46] <cradek> emc does not know or care what shape the mill is, it runs the compensated path the same way
[23:03:58] <cradek> jepler_: shine light through it
[23:04:03] <dareposte> jepler_: be glad your power supply has overcurrent... i smoked my parport board yesterday :(
[23:04:09] <dushantch> tool compensation?
[23:04:10] <jepler_> dareposte: indeed
[23:04:27] <dareposte> now i need a $0.35 chip, which costs $4 to ship here.
[23:04:28] <jepler_> cradek: I've been using my meter on continuity mode and haven't found it yet .. I don't even know which pair of traces it is
[23:04:42] <jepler_> I've tested nearly every trace to GND and VCC..
[23:04:42] <toastydeath> dushantch: i think everyone is answering a different question, can you be more specific
[23:04:54] <jepler_> I'll try using the light, though
[23:04:58] <cradek> jepler_: usually with back lighting I can see it right away
[23:06:05] <dushantch> toastydeath: how do you program to not get into this:
http://linuxcnc.org/docs/html/gcode_tool_compensation.html#r1_4_1_7
[23:07:12] <toastydeath> uh, again i don't use emc, but to me that says emc doesn't know how to handle g1/g1 intersections
[23:07:15] <jepler_> jepler_ is now known as jepler
[23:07:18] <toastydeath> with cutter comp on?
[23:07:26] <toastydeath> but someone who is from emc should probably clarify
[23:08:25] <dushantch> toastydeath: thanks for your time :)
[23:08:30] <toastydeath> sry
[23:09:17] <dushantch> cradek: may I ask you something about tool compensation and sharp corners?
[23:11:30] <cradek> of course
[23:15:35] <jepler> toastydeath: no, it's well specified how emc handles g1-g1 moves during cutter compensation. if the cutter "doesn't fit" in the corner, the move is rejected because the specified shape can't be cut. that's what the image at
http://linuxcnc.org/docs/html/gcode_tool_compensation.html#r1_4_1_7 is showing.
[23:15:52] <jepler> that's different from the behavior some people want, but it's not simply an oversight that it behaves in this way
[23:15:54] <dushantch> cradek: I started this mile long discussion, which you can read above, with following question: if we give a machine to make a sharp corner (radius=0) should it:
[23:15:55] <dushantch> 1. complain and do nothing
[23:15:57] <dushantch> 2. give its best shot and make what it thinks is ok
[23:15:59] <dushantch> 3. telss us it's impossible (sharp corners with r=1 tool HAHA), and give us the solution (I've made these 26 corners as r-1 radiuses)?
[23:16:23] <jepler> * jepler gets disgusted with his board and throws it across the room
[23:16:37] <dushantch> all this BEFORE it starts machining
[23:16:43] <cradek> dushantch: I think I spelled out my feelings on that thread whose url I posted
[23:17:04] <cradek> this comes up every few months :-)
[23:17:38] <dushantch> cradek: ahh, but what about the solution I offered?
[23:17:55] <dushantch> cradek: idea more than solution
[23:18:16] <dushantch> because I agree with you
[23:18:22] <toastydeath> jepler: i see it as an oversight
[23:19:04] <cradek> dushantch: I see #2 and #3 as about the same, with just an added warning
[23:19:15] <toastydeath> because g1/g1 in a sharp produces a different real world result than g1/g2|3/g1
[23:19:50] <jepler> toastydeath: I'm not saying you're wrong to want a different implementation; I'm just saying that the current implementation does what it set out to do.
[23:20:23] <dushantch> cradek: but #3 allows us to go on with our "imprecise" machining
[23:20:53] <cradek> maybe I don't understand. I see #2 and #3 as giving the same path, except #3 warned first.
[23:20:57] <toastydeath> jepler: but I am saying it's wrong, that's my only point. not that it didn't set out to be that way.
[23:21:17] <jepler> toastydeath: OK, just use a different term than "oversight", and I'll stop trying to get the last word about this
[23:21:24] <toastydeath> sure.
[23:21:40] <toastydeath> if that's the intended behavior, it's not an oversight.
[23:21:41] <cradek> toastydeath: I hope you can see that it's a matter of opinion. I know I do, and I sympathize with both sides
[23:21:49] <toastydeath> i don't see it that way, cradek
[23:22:09] <toastydeath> because they produce two radically different real world results.
[23:22:14] <dushantch> cradek: but you can view! and modify! #3 only once and then it'll be executed 100 times again without warning
[23:22:31] <cradek> toastydeath: I must not understand your argument then.
[23:23:11] <toastydeath> if you require the arc to be specified, that means i have to use a substantially smaller tool than the arc or i risk breaking the tool.
[23:23:37] <toastydeath> and have, in the past
[23:24:02] <cradek> toastydeath: I'm not seeing it.
[23:24:22] <toastydeath> you take a R.25 tool into a R.25 programmed arc
[23:24:41] <cradek> that's a degenerate arc
[23:24:54] <toastydeath> okay. a .2499 tool into a .25 arc.
[23:25:06] <cradek> ok, that will give you a sharp corner in emc.
[23:25:18] <toastydeath> yes, if you look at it from a simulation point of view.
[23:25:32] <toastydeath> in practice, it causes hesitation in the corner and geometry problems.
[23:26:03] <cradek> it's true emc will round that corner less. I don't know about any other control's degenerate behavior
[23:26:22] <cradek> I think this is not particularly related to the question at hand
[23:26:36] <toastydeath> it is - one method runs the risk of breaking a tool, the other doesn't.
[23:26:54] <jepler> toastydeath: is it different than the problem you'd have if you offset the path by hand and just had two G1 moves without any cutter comp in the gcode?
[23:27:02] <cradek> no, not particularly because of whether a g1-g1 concave corner errors or not
[23:27:25] <toastydeath> jepler: no, that move works great
[23:27:33] <toastydeath> no tool breakage.
[23:27:42] <toastydeath> walls come out in the right place, radius in tolerance.
[23:28:29] <toastydeath> obviously "in tolerance" is dependant on using the right size cutter, but it doesn't give you a nonround radius like the g1/g2/g1 move does.
[23:28:36] <cradek> I think you've had a problem with a peculiarity of a certain control and are arguing the issue more generally than it really is
[23:28:55] <toastydeath> cradek, no it's an issue with all controls that i'm aware of.
[23:29:10] <cradek> if the arc and tool radius is the same, a smart control will just discard the arc
[23:29:37] <dushantch> if emc does deceleration for straight to round case then it shouldn't be a problem
[23:30:03] <toastydeath> a smart control doesn't require a g2/g3 where there shouldn't be one.
[23:30:11] <cradek> :-)
[23:30:26] <cradek> "shouldn't" is still a matter of opinion of course
[23:30:34] <toastydeath> no, it's pretty explicit to me
[23:30:42] <toastydeath> if i tell the control g2/g3, i want it to interpolate.
[23:31:08] <cradek> but (one might argue) that in cutter comp mode, you are not programming the tool path. you are programming the part shape.
[23:31:08] <toastydeath> if i tell it g1, i want it moving in straight lines. i don't want it dropping, adding, or requring things that are not necessary for the toolpath to run.
[23:31:24] <cradek> uh-oh, here lies madness
[23:31:28] <toastydeath> haha.
[23:31:57] <toastydeath> g1/g1, the control won't break your tool. g1/g2/g1, you risk breaking your tool.
[23:31:59] <dushantch> * dushantch runs crazy yelling:"the egg came first"
[23:32:11] <toastydeath> that's my bottom line.
[23:32:20] <cradek> I'm off to dinner, bbl
[23:32:53] <dushantch> I'm off to bed, here's 0135 AM :)
[23:32:57] <toastydeath> bai
