Back
[00:35:20] <Jymmmm> SWPadnos 1900 - 0300
[00:35:57] <Jymmmm> SWPadnos Off on Th & Fr
[00:36:41] <Jymmmm> SWPadnos Coming into town?
[01:42:45] <crepincdotcom> * crepincdotcom just exported to NC code from eagle and is eager to mill his board
[01:45:34] <crepincdotcom> heh its my shopping-cart locking transmitter
[01:46:01] <crepincdotcom> with the milled board as opposed to proto board I can make it much smaller and easier to hide in my pants
[01:46:13] <jmkasunich> troublemaker
[01:46:17] <crepincdotcom> :-p
[01:46:25] <crepincdotcom> at least its nerd trouble making
[01:46:33] <crepincdotcom> i have the un-lock functionality built in as well
[01:48:37] <crepincdotcom> jmkasunich: do you have a website I could look at?
[01:48:46] <crepincdotcom> like, of your own.
[01:48:56] <crepincdotcom> i think you linked me before but like an idiot i didnt bm it
[01:49:00] <jmkasunich> http://jmkasunich.dyndns.org/cgi-bin/blosxom/index.html
[01:49:04] <crepincdotcom> thanks
[01:49:59] <SWPadnos> Jymmmm, yep - ESC is April 1-5 this year, so I'll be getting into town on March 31, and leaving on April 6th
[01:52:12] <SWPadnos> tomp, your pyvcp-dro4.hal file has a problem with naming. you tell pyvcp to name the DRO "fred", but halcmd is looking fora component named "pyvcp"
[01:53:36] <Jymmmm> SWPadnos: Ok, cool! But remind me when we get closer to that date... My mind is a teribble thing to waste =)
[01:56:03] <SWPadnos> heh
[01:56:13] <SWPadnos> or "a mind is a terrible thing, wasted"
[01:56:20] <Jymmmm> lol
[01:56:56] <tomp> SWPadnos: thanks, i dont see why halcmd is looking for a comp named pyvcp, that was the idea of naming the comp 'fred, so there were no issues with that name ( is it waitusr? i thought waitusr would use pyvcp , not fred )
[01:57:06] <Jymmmm> I'll upload pics when I get to work, but need ideas on mounting the energy chain.
[01:57:29] <SWPadnos> you told pyvcp to name the conponent fred, but didn't tell halcmd that the name should be anything other than pyvcp (the name of the program)
[01:57:47] <SWPadnos> you need loadusr -Wn fred pyvcp -c fred pyvcp-dro4.xml
[01:58:03] <tomp> ah, i thought waitusr waited for pyvcp, not the comp, got it thanks!
[01:58:17] <SWPadnos> try that, then thank me if it works ;)
[01:59:57] <Jymmmm> back in 90
[02:16:33] <tomp> SWPadnos: ok, despite i name the comp fred & ask waitusr fred, it waits for pyvcp ( and never gets done ... wrong argv? )
http://pastebin.ca/354647
[02:17:01] <tomp> i checked several times, cat ing the files, to see if i had the right ones...
[02:17:22] <tomp> can someone else try it?
[02:21:21] <tomp> oh, i see i didnt say i killed it, used ^C
[02:22:53] <jmkasunich> tomp: loadusr -Wn fred pyvcp -c fred pyvcp-dro5.xml
[02:23:00] <tomp> k
[02:23:06] <jmkasunich> -c fred tells pyvcp to creat a comp called fred
[02:23:20] <jmkasunich> and -Wn fred tells halcmd to wait for a comp called fred
[02:23:40] <tomp> k, i looked at that & didnt get the diff, thanks
[02:25:32] <tomp> clean, nice, thank you!
[02:34:22] <tomp> jmkasunich: SWPadnos: i put those cmds into the original code, and it 'runs' the dro appears, but the pins dont get created/or get created with names that I dont expect pyVCP: Creating widgets from pyvcp-dro.xml ... Done. <panel appears, i close it , then > HAL: ERROR: pin 'fred.Xdisplay' not found HAL:128: link failed
[02:34:22] <tomp>
[02:34:35] <tomp> this is GoSloJymbo's dro app
[02:36:14] <jepler> tomp: put a 'show pin' into the hal file above the link line -- that will show you what pins exist
[02:36:37] <tomp> great, will do
[02:40:03] <tomp> jepler: it shows after the panel is closed, and there's no fred pins at all, just encoder, mux, parport & sum pins
[02:40:58] <tomp> and no Xdisplay of any parentage
[02:49:50] <jepler> sounds like you need to figure out why pyvcp is exiting, then
[02:50:15] <jepler> in halrun, just 'loadusr ... pyvcp ...'
[02:50:15] <tomp> why it exits when we dont get pins?
[02:50:41] <tomp> (you mean we gotta figger that out )
[02:51:29] <tomp> will look at the loadusr ... pyvcp ... but just pasted the last simplification , made 1 pin
[02:51:49] <tomp> http://pastebin.ca/354691
[02:52:22] <jepler> you're still using 'waitusr' inappropriately
[02:52:35] <jepler> 'waitusr fred' means 'continue when the 'fred' component has exited
[02:53:06] <tomp> ok, what is wait until loaed & processed ?
[02:53:14] <tomp> loaded & procesed?
[02:53:20] <jepler> "loadusr -W" waits for the component to *initialize*
[02:53:27] <jepler> "waituser" waits for the component to *exit*
[02:53:31] <jepler> "waitusr"
[02:54:03] <jepler> but that still doesn't explain why your pyvcp is immediately exiting -- I would expect it to get 'stuck' at the waitusr and never link the signal until you manually closed the pyvcp window
[02:55:02] <tomp> and i should do what? i gotta wait for the pins to be created before i connect them
[02:56:03] <jepler> you should troubleshoot pyvcp to find out why it is exiting immediately
[02:56:04] <David35LA> David35LA is now known as DavidMTL
[02:56:11] <tomp> and the explanation of loadusr -W and waitusr is understood, thanks
[02:56:12] <DavidMTL> Hi, does EMC2 run on a 386 or 486 ,500-800 MHZ CPU (using hardware generated pulses)? Not worried about pulse train since it is hardware generated. I am only wondering if EMC2 depends on Pentium specific hardware features.
[02:56:51] <tomp> ok i can put dbug prints in pyvcp
[02:57:13] <jepler> DavidMTL: almost all users are on pentium and newer machines. I believe that our code uses 'rdtsc' which is not available on pre-pentium machines
[02:57:49] <jepler> DavidMTL: and the ubuntu realtime kernel package we distribute is also compiled for pentium-and-newer machines
[02:58:09] <DavidMTL> that is ok since I build my own package and kernel
[02:58:56] <jepler> DavidMTL: in emc, 'rtapi_get_clocks()' is implemented by calling 'rdtscll' which appears to come from <asm/msr.h>
[02:59:08] <jepler> I think that most or all uses of rtapi_get_clocks are just for accounting purposes
[02:59:20] <DavidMTL> I saw that
[02:59:30] <jepler> other than that, I don't know of any problems with pre-pentium systems, but like I said few if any users are running on these systems
[02:59:31] <DavidMTL> I could not see any other dependency yet
[03:00:06] <DavidMTL> ok, will get my hands on a 486 and try
[03:00:27] <jepler> good luck
[03:00:38] <DavidMTL> thanks
[03:03:59] <jmkasunich> tomp: are _you_ terminating halvcp? or is it terminating itself?
[03:04:27] <jmkasunich> you wrote: pyVCP: Creating widgets from pyvcp-dro.xml ... Done. <panel appears, i close it , then > HAL: ERROR: pin 'fred.Xdisplay' not found HAL:128: link failed
[03:04:29] <tomp> i kill it during the endless wait dots with a ^C
[03:04:46] <jmkasunich> I thought so - jepler misunderstood what was happening
[03:05:08] <tomp> ? (u bet i misunderstood 2x as much he did )
[03:05:17] <jmkasunich> your link commands need to be _before_ the waitusr
[03:05:25] <tomp> ah!
[03:05:32] <jmkasunich> they way it works is:
[03:05:41] <jmkasunich> loadusr runs and starts pyvcp
[03:05:50] <tomp> k
[03:05:59] <jmkasunich> loadusr -W means it waits until pyvcp is _started_
[03:06:12] <tomp> got it
[03:06:14] <jmkasunich> then it continues with your hal script (link commands)
[03:06:24] <tomp> oh
[03:06:26] <jmkasunich> then after everything is set up, it hits waitusr
[03:06:32] <jmkasunich> and waits for pyvcp to exit
[03:06:46] <jmkasunich> when you are all done (20 mins later, or whatever), you close pyvcp
[03:06:49] <jmkasunich> and the waitusr stops
[03:07:00] <jmkasunich> at that point halrun cleans up everything
[03:07:01] <tomp> ok
[03:07:14] <tomp> thanks
[03:07:22] <jmkasunich> np
[03:07:30] <jmkasunich> those waits are confusing
[03:07:51] <tomp> (tomp takes out debug prints in file parser of vcpparse :-$
[03:08:59] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[03:12:33] <tomp> jmkasunich: looking good, exits clean & while alive, show pin sez the pin was created, and it's connected ( moved show pin after the linksp ) :)
[03:12:53] <jmkasunich> cool
[03:17:46] <tomp> jmkasunich: very cool, the debug show pin shows all the pins and connections are made, the panel runs, GoSloJymbo can pick it up & take it home :) & i got to learn how ;)
[04:39:27] <CIA-19> 03cradek 07TRUNK * 10emc2/configs/sim/check_constraints.hal: fix wildly wrong comments
[04:57:16] <tomp> added halrun demo with GoSlowJimbo's DRO
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?PyVCP
[05:07:11] <ejholmgren_> tomp: looks great@
[05:07:18] <ejholmgren_> s/@/!
[05:07:22] <Jymmm> SWPadnos ping
[05:07:27] <SWPadnos> pong
[05:10:09] <Jymmm> SWPadnos I'm Baaaaaaaaaaaaaack =)
[05:10:20] <SWPadnos> time to go
[05:10:24] <SWPadnos> I mean, hi
[05:10:37] <Jymmm> lol
[05:10:59] <tomp> alex_joni: this is like being inside beryl
http://www.youtube.com/watch?v=qTwcageiJnM
[05:11:00] <Jymmm> SWPadnos: You've seen pics of my machine, right?
[05:11:10] <SWPadnos> I don't think so
[05:11:20] <Jymmm> SWPadnos: ah, hang on...
[05:12:22] <ejholmgren_> newest beryl update on ubuntu broke my cube :(
[05:12:29] <Jymmm> SWPadnos, ok this is close to mine.... Not as tall, and mine is 24", not 36" as shown here.
http://www.k2cnc.com/DuportalPro343Access/Pictures/detail.asp?iData=29&iCat=636&iChannel=3&nChannel=Pictures
[05:12:42] <SWPadnos> oh - I saw the k2cnc photos
[05:13:34] <Jymmm> Ah, well not TOO much different than mine, other than mine has steppers.
[05:13:42] <Jymmm> and I'm ading energy chain atm
[05:13:57] <SWPadnos> what's that?
[05:14:03] <tomp> ejholmgren: i dont have the cpu/mem/video oomph for beryl, but i like the direction ui's are taking ( wave in the air :) )
[05:14:21] <Jymmm> SWPadnos: middle pic
http://www.aboveboardelectronics.com/igus/echain/index.html
[05:14:31] <tomp> energy chain = kabeltrager, kabelsclepp, wireway
[05:14:43] <Jymmm> SWPadnos but mind doens't have thos nift remioovable clips
[05:14:43] <ejholmgren_> tomp: it was nice while it lasted
[05:14:49] <tomp> schlepp
[05:14:56] <SWPadnos> ah ok
[05:15:17] <Jymmm> SWPadnos: Yeah, no more tie wraps and rubber bands =)
[05:15:22] <SWPadnos> bummer
[05:15:32] <SWPadnos> :)
[05:15:37] <tomp> i installed DamnSmallLinux on a P150 laptop w 48meg ram laste nite, really snappy!
[05:16:06] <Jymmm> SWPadnos let me resize these pics and I'll upload them somewhere
[05:16:07] <SWPadnos> I really should either fix my server machine or decide once and for all that it'll never work
[05:16:27] <Jymmm> SWPadnos it'll never work, so send me the ram.
[05:16:47] <SWPadnos> can you use EDO or FPM SIMMS?
[05:17:03] <Jymmm> SWPadnos I can use PC100/133 DIMMS
[05:17:10] <Jymmm> 512MB specifically
[05:17:17] <SWPadnos> well, SIMM != DIMM, so you're out of luck
[05:17:24] <SWPadnos> this uses 72-pin SIMMS
[05:17:37] <Jymmm> SWPadnos how many you need? I have shitloads of them
[05:17:52] <SWPadnos> the only person who's seen those in the last couple of years is jmkasunich (I know, because he gave me a couple ;) )
[05:18:01] <ejholmgren_> that bar is amazing sober ... imagine in real life after a few martinis
[05:18:06] <SWPadnos> if you have 128M 60 ns ECC SIMMS, I'd love some
[05:18:33] <Jymmm> SWPadnos 128MB?! in SIMMS?! Did they even make em that big?
[05:18:38] <SWPadnos> yes
[05:18:58] <Jymmm> I can look, but I think the max I have is 32 or 64
[05:18:59] <SWPadnos> this motherboard can take 8 SIMMS, for a total of 1GB
[05:19:07] <SWPadnos> which is pretty amazing, considering that I bought it in 1996 or so
[05:19:47] <Jymmm> no doubt
[05:20:15] <SWPadnos> and the dual PPro-overdrive chips make it r0xx0rz
[05:20:42] <SWPadnos> 666MHz combined. w00t!!!!!
[05:21:03] <SWPadnos> it should be able to download email and serve files for me and my wife though :)
[05:22:02] <Jymmm> lol
[05:24:44] <Jymmm> Do you know what REALLY SUCKS about having an obscene amount of bandwidth?????
[05:29:53] <SWPadnos> not having a really fast computer on which to play games?
[05:29:57] <Jymmm> Nobody else does and their websites are slow as hell!
[05:30:08] <SWPadnos> or not having enough storage ;)
[05:30:29] <Jymmm> SWPadnos I'm on multiple 10GigE pipes =)
[05:30:40] <SWPadnos> sucks to be you, I guess
[05:30:47] <Jymmm> lol, Yeah don't it =)
[05:31:00] <SWPadnos> it must really suck to go home to puny DSL/cable
[05:31:21] <Jymmm> Only a little bit....
[05:31:35] <SWPadnos> you could probably use my 9 MP monitor with google maps pretty effectively there
[05:31:43] <SWPadnos> it's a little slow updating here
[05:32:06] <Jymmm> google is fast, that I'll admit
[05:32:41] <SWPadnos> it takes a little while to update screens of this size:
http://www.cncgear.com/images/bigscreenshot.png
[05:33:03] <Jymmm> SWPadnos url ?
[05:33:10] <SWPadnos> that was a URL
[05:33:22] <Jymmm> no that was a scrncap of a url
[05:33:35] <SWPadnos> no, that was a screencap of a google map that shows all of the US
[05:33:53] <SWPadnos> but it's useless for you to try to replicate it unless you have a 9MP monitor
[05:34:06] <Jymmm> SWPadnos: Y Axis
http://farm1.static.flickr.com/125/389857545_d4e09a4c12_b.jpg
[05:34:17] <SWPadnos> nice
[05:34:45] <SWPadnos> it seems that you use the machine in the middle of Y travel more often than at the edges :)
[05:34:46] <Jymmm> I had to make that lil bracket
[05:35:08] <Jymmm> why's that?
[05:35:16] <SWPadnos> the screw is shiny in the middle
[05:35:22] <SWPadnos> but not so shiny at the end
[05:35:32] <Jymmm> Oh, that's lack of grease
[05:35:34] <SWPadnos> that could mean that it's clean also
[05:35:36] <SWPadnos> :)
[05:35:55] <Jymmm> no that's where it hasn't wrapped sawdust into the grease yet =)
[05:36:20] <Jymmm> if I jog it to the right, the ther side would be shiny
[05:36:56] <SWPadnos> see how much I know? :)
[05:37:09] <SWPadnos> sorry - I'm a little distracted looking at coffee machines
[05:37:22] <Jymmm> SWPadnos: PAY ATTENTION DAMNIT!!! =)
[05:37:39] <SWPadnos> shaddap - my coffee mmaker is broken and I don't care what you say
[05:37:45] <Jymmm> SWPadnos: Ok, potential location OUTSIDE for Y axis echain
http://farm1.static.flickr.com/187/389857551_08530e27d7_b.jpg
[05:38:08] <Jymmm> I still need to upload the INSIDE pics
[05:38:22] <SWPadnos> that whole gantry moves, right?
[05:38:29] <Jymmm> nods
[05:39:00] <SWPadnos> what are the cables that lay in this energy chain supposed to go to?
[05:40:36] <Jymmm> router (120VAC), Y and Z axis
[05:40:54] <SWPadnos> ok. lots of cords in that one
[05:41:24] <Jymmm> well, 3
[05:41:52] <Jymmm> Y & Z are not any bigger than CAT5 cable
[05:42:36] <SWPadnos> ah
[05:45:04] <Jymmm> ok photos uploaded
[05:47:38] <Jymmm> heh...
http://farm1.static.flickr.com/150/389868988_c3f723a7f0_b.jpg
[05:47:55] <SWPadnos> I think I like the outside locations better. don't really know why
[05:48:35] <Jymmm> See, I mount that top to the machin permanently, so it would cover up the chain below it
[05:48:56] <SWPadnos> if something goes wrong, it's ahrder to get to
[05:49:05] <SWPadnos> if chips fly, it's harder to get cruddy ...
[05:49:18] <SWPadnos> six of one, sqrt(36) of the other
[05:49:50] <Jymmm> let me see if I can find a pic of what I'm talking about...
[05:50:10] <Jymmm> here we go....
http://www.k2cnc.com/DuportalPro343Access/Pictures/detail.asp?iData=9&iCat=651&iChannel=3&nChannel=Pictures
[05:50:17] <SWPadnos> I understand that the MDF would cover the interior area
[05:52:14] <Jymmm> http://www.k2cnc.com/DuportalPro343Access/Pictures/detail.asp?iData=43&iCat=651&iChannel=3&nChannel=Pictures
[05:54:53] <SWPadnos> yep - that's basically what I was thinking
[05:55:02] <SWPadnos> though the wires all over the place are still ugly as hell
[05:55:26] <Jymmm> which part are you talking about?
[05:56:00] <Jymmm> which ugly part are you talking about?
[05:56:40] <Jymmm> I can always use split loom tubing for where the cabling is not in the eChain
[05:57:18] <SWPadnos> just the wires draped/stretched from the ends of the echain to the actual motors (especially on the Z motor)
[05:57:28] <Jymmm> See, with it on the outside, I fear it's just easier to get broken and just collect swarm
[05:57:54] <SWPadnos> yep - it can get cruddy easier, though you could cover it with a paper / plastic / rubber sheet
[05:57:58] <Jymmm> Yeah, Mine will be better than shown there, but not much
[05:58:14] <Jymmm> or I could mount it INSIDE =)
[05:58:26] <SWPadnos> that will be a real pain if a wire breaks ...
[05:58:27] <Jymmm> where it can't be bubbed or catch stuff
[05:58:38] <Jymmm> Just four screws to remvoe the table top
[05:59:04] <Jymmm> I just dont like moving the table top as I have it aligned.
[05:59:18] <Jymmm> no registration pins =(
[06:21:54] <lerman_> lerman_ is now known as lerman
[06:28:44] <Jymmm> hi cradek, bye cradek (bbiab)
[09:20:26] <paragon36> Morning All.... Could someone tell me what the correct name for the rubber insollation pads that sit in between Mosfets and heatsinks? Can't seem to find the correct name for them on google....
[11:40:56] <xemet> hello
[12:53:11] <jepler> paragon36: I'm familiar with mica transformer insulators, as shown on this page of the mouser electronics catalog:
http://www.mouser.com/catalog/626/1115.pdf
[15:51:11] <CIA-19> 03jepler 07TRUNK * 10emc2/docs/html/gcode.html: I always forget which arc is which direction
[16:12:40] <tomp> jepler: last nite jmkasunich helped get GoSloJimbo's dro to run, it was just small changes. WIth your stuff & his, the app runs and is at
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?PyVCP, thanks again :)
[16:35:35] <paragon36> Thanks for the info Jeple, Just saw your reply.... Since posting I've also found that kapton tape, mica and sil-pad can be used
[16:36:11] <paragon36> Oooops s/Jepe/Jepler ;-)
[16:47:01] <jepler> tomp: glad to hear it
[16:47:17] <jepler> paragon36: haven't heard of "kapton tape", I'll have to look
[17:02:46] <jepler> http://emergent.unpy.net/files/sandbox/arcs.py
[17:03:36] <tomp> creates 'tangential' paths ? so no 'angle'
[17:03:51] <tomp> between elements?
[17:03:54] <jepler> right, every corner is rounded
[17:05:25] <tomp> nice!, that allows tool offset to work on machines without the infamous 'fishtail' errors ( i wrote something like that called blech :) ... blend changer, forced stuff to be tangential :)
[17:05:27] <jepler> http://emergent.unpy.net/files/sandbox/arcs.png
[17:05:45] <tomp> nice
[17:06:44] <tomp> we used a test, a maltese cross ( like red cross cross ), checks every direction, inside & outside
[17:07:26] <SWPadnos> digi-key sells kapton tape - I bought some to wrap the connections I made on my transformer
[17:07:47] <jepler> well -- if you give these paths as the input to tool shape compensation I doubt that the tangential condition will be maintained
[17:09:23] <tomp> oh, you begin with a list of points? even nicer for jewelry tracing
[17:10:18] <jepler> tomp: yes, you give it a list of points (and optionally the tangent to use at the start), and it finds the arcs and lines that go through those points and satisfy the tangent condition
[17:10:55] <jepler> you can (hopefully) see that both of those superimposed paths in the png pass through (0,0), (2,0), (4,1), (4,2), (2,3), (0,3), (0,0)
[17:11:21] <jepler> but the path is different because the second path is reversed (goes from 0,0 to 0,3) and thus all the tangents are different
[17:13:08] <tomp> thats very interesting, i have to 'ture' those points to see it
[17:13:14] <tomp> are you thinking a G8xx canned gcode? 'autopath'?
[17:14:46] <jepler> no I don't envision changing the interpreter just to support this
[17:15:15] <jepler> the algorithm in the python function 'r' is not hard, you could convert it to the language of your choice, presumably including o-code
[17:19:59] <tomp> i can see a use for a 0 tickmark on the scale displayed in Axis, i have to estimate where the origin is when i imagine the points ( or a mouse readout to examine the location near my pointer )
[17:22:11] <tomp> ok , i ture'd it both directions, now i have to understand how you determine the start direction... reading
[17:23:30] <tomp> ok, just the 1st 2 points in the list determines direction vector
[17:24:33] <jepler> yes -- you could specify the initial tangent if you like, but if you don't the first thing is always a line, never an arc
[17:25:03] <SWPadnos> tomp, the XYZ axis lines are on the origin
[17:25:19] <tomp> doh!
[17:25:19] <SWPadnos> though they move sometimes, with G54 or such things
[17:28:10] <tomp> ok, will try it, then edit a new point list, and see what happens. sanook di! this is fun
[17:56:21] <tomp> jepler: sweet
http://imagebin.org/7294 will look at why i didnt get it to close later , thanks
[18:09:51] <lerneaen_hydra> 'lo
[18:23:01] <skunkworks> vista is odd. You click on the network properties. It asks you if your sure you wanted to do that.
[18:32:47] <SWPadnos> well, you could be a virus - it has to ask
[18:33:12] <skunkworks> :0
[18:57:54] <jepler> tomp: looks good for a start though
[19:22:01] <a-l-p-h-a> hehe... embarrassed the GF at her work.... brought her lunch, a box of candies, and a rose+baby's breath+vase.
[19:24:49] <skunkworks> I bought my wife a house near the river - in her favorite town..
[19:24:54] <skunkworks> ;)
[19:25:15] <skunkworks> should be good for a few missed aniveseries.
[19:27:13] <fenn> did you put a giant bow on the roof?
[19:27:27] <fenn> made from sheet metal perhaps
[19:32:11] <skunkworks> cnc'ed out of solid 2ton block of chocolate
[19:32:22] <skunkworks> billet chocolate?
[19:34:26] <fenn> cvd (chocolate vapor deposition)
[19:35:37] <skunkworks> mmmmmm chocolate.
[19:35:54] <fenn> i think i just overdosed on ghirardelli again
[19:38:17] <lerneaen_hydra> anyone here do TIG?
[19:41:17] <skunkworks> lerneaen_hydra: not yet
[19:47:22] <anonimasu> heh
[19:58:55] <skunkworks> rewired half of my breaker box last night - went well.. No melted tools or deaths.
[20:00:06] <anonimasu> nice
[20:07:01] <lerneaen_hydra> oh O_o
[20:07:01] <lerneaen_hydra> intersting
[20:07:01] <lerneaen_hydra> *interesting
[20:07:18] <skunkworks> It looks considerably more profesional
[20:08:25] <lerneaen_hydra> is chanserv this moody every now and then?
[20:08:25] <skunkworks> he doesn't talk much ;)
[20:10:41] <anonimasu> skunkworks: you mean you dont have a screwdriver as bus bar in professional installations?
[20:15:26] <lerneaen_hydra> 'night all
[20:32:45] <alindeman> [Global Notice] Hi all .. Services (e.g., ChanServ and NickServ) were down for about 20 minutes. We've put them back online, but unfortunately had to revert to a backup approximately 4 hours old. Hopefully this should not cause many problems, but if it does, please contact
[email protected] with your specific issue and we'll review it on a case-by-case basis. Sorry for any inconvenience and thanks for using freenode.
[20:40:46] <fenn> do "pro" cad programs output svg usually?
[20:41:52] <anonimasu> no
[20:42:07] <fenn> just dxf?
[20:42:21] <anonimasu> yeah..
[20:42:28] <SWPadnos> STEP, Parasolid, STL, IGES, ACIS ...
[20:42:31] <anonimasu> well I dont know about the most recent versions of solidworks..
[20:42:35] <anonimasu> or slidedge..
[20:42:47] <SWPadnos> does SVG even support 3D?
[20:42:57] <fenn> no, but it ought to :)
[20:43:15] <fenn> i was thinking for blueprints really
[20:43:20] <SWPadnos> heh
[20:43:34] <SWPadnos> oh, in that case add PDF and possibly PS to the list
[20:43:47] <fenn> webpage stuff.. PDF is sucky
[20:43:49] <SWPadnos> documentation formats aren't the same thing as model formats
[20:43:55] <fenn> yeah
[20:44:19] <fenn> blueprints (2d part drawings) are often done in dxf though right?
[20:44:25] <anonimasu> they do pdf..
[20:44:32] <anonimasu> and tif..
[20:44:33] <anonimasu> and jpg
[20:44:36] <anonimasu> and dxf/dwg
[20:44:38] <SWPadnos> and bmp (screenshots :) )
[20:45:11] <fenn> and papt (pencil and paper tracing)
[20:45:30] <SWPadnos> heh
[20:45:37] <fenn> for when the printer's busted
[20:45:44] <SWPadnos> or AVI - just set up a camera to capture what you do ...
[20:46:14] <fenn> but - think of all the electrons you're wasting!!11
[20:46:44] <SWPadnos> screw the electrons. I'm a Human and I have dominion over the Earth
[20:47:04] <fenn> talking to god again eh
[20:47:14] <SWPadnos> who, me?
[20:47:28] <SWPadnos> not talking, just reading the "transcripts" ;)
[20:47:32] <fenn> why is it god always tells people what they want to hear?
[20:48:00] <fenn> never "calm down, pay your car insurance, dont do anything stupid"
[20:48:39] <SWPadnos> "thou shalt calm down and pay your auto insurance bill on time" doesn't have the same ring as "thou shalt not kill"
[20:49:05] <SWPadnos> though it's just as practical
[20:50:34] <fenn> nobody listens either way
[20:51:05] <SWPadnos> indeed
[20:51:44] <SWPadnos> wow - Hitachi has a 1TB hard drive that's supposed to retail for $399. So you could have a 2TB (available) raid-5 array for $1200
[21:07:49] <skunkworks> like you would ever use up that much space... (remeber saying that about my 40mb hd)
[21:07:55] <skunkworks> remember
[21:10:05] <christel> [Global Notice] Happy Valentines Day to all! If you're good with web design or graphics and you wish to share some love with freenode and the PDPC, head over to
http://freenode.net/news.shtml and have a look.
[21:11:13] <skunkworks> hmm maybe printing 15000 invoices to a pdf file was bad.
[21:12:12] <skunkworks> up to 35mb so far...
[21:12:52] <jepler> 1TB is nothing when you have a porn addiction^W^Wperfectly normal enjoyment of video "entertainment"
[21:13:50] <tomp> svg3d
http://www.lutanho.net/svgvml3d/index.html http://www.kevlindev.com/geometry/3D/js3d/index.htm
[21:14:29] <tomp> i use kevlindev a lot as svg reference
[21:22:17] <pier_> jepler, are arcs in emc a sequel of segments?
[21:26:42] <tomp> pier_: on monday , concerning how arcs were executed: "cradek: it moves in a circular/helical path - it does not split it up into straight moves"
[21:27:10] <fenn> eventually it turns into line segments in the base thread (happening really really fast in real time)
[21:27:25] <fenn> <mumble jumble>
[21:27:45] <pier_> tomp: yes I read that but now wasn't sure to remember that right
[21:27:50] <pier_> thanks
[21:28:05] <tomp> np: now I dont know which it rue :)
[21:28:09] <tomp> truw
[21:28:15] <tomp> true dangit
[21:29:59] <pier_> so an arc is swept along a cilindrical coordinate?
[21:31:32] <fenn> that svg vml is pretty lame
[21:32:13] <fenn> there should be a way to render svg with opengl commands
[21:32:18] <tomp> pier_: yes, but fenn's point was (i think) the motion is executed point to point at a lower lever, meaning its planned on a curve, executed in teeny lines (fenn , is that rightit?)
[21:32:24] <fenn> 2d opengl is way fast
[21:33:04] <tomp> fenn: what you saw was javascript and svg via xml, might be the lameness you say
[21:33:03] <fenn> yes tom, and it does go along a cylinder (the orientation is controlled by defining which plane it's perpendicular to)
[21:34:16] <fenn> seems to have crashed konqueror too :(
[21:34:59] <tomp> i'm impressed that it runs that well on firefox, (oh sorry bout knoq)
[21:35:12] <tomp> konq dangit
[21:35:24] <fenn> kinq konq
[21:35:43] <pier_> so there is a granularity in the tetha sweeping? I mean ... a minimum resolution in cutting arcs, circles and so on...
[21:35:49] <fenn> got his tail chopped off by prince vegeta
[21:36:40] <jepler> pier_: emc computes a position on the arc each servo cycle, typically 1ms
[21:36:56] <cradek> each traj cycle
[21:37:02] <jepler> yes, sorry
[21:37:17] <cradek> those are interpolated for every servo cycle
[21:37:50] <pier_> servos or stepper are handled the same way?
[21:38:04] <jepler> yes, emc has no idea at that level what kind of motors you have
[21:38:07] <anonimasu> yeah
[21:38:12] <pier_> ok
[21:39:53] <pier_> sorry for being dumb... but is there a minimum resolution in moving along an arc in the end?
[21:40:45] <cradek> sure, one step or encoder count
[21:40:46] <anonimasu> wouldnt that be how small you can make your traj period?
[21:40:53] <pier_> shouldn't it be the resolution of the st
[21:40:55] <pier_> ok
[21:41:02] <anonimasu> or well what cradek said..
[21:41:37] <skunkworks> I would think it would mainly depend on scale, how fast your moving and your traj/servo cycle time
[21:42:02] <tomp> i was just in a thrift shop & was looking for overhead projectors, no luck, but on the way out saw 'projector clock', it's an lcd with a fresnel lense and a bight light, displays on ceiling... nice hack for a remote dro :)
[21:42:54] <tomp> pier_: maybe you can zoom in enough with axis to see the effect of speed and radius
[21:43:12] <tomp> look for a chord i suppose
[21:43:13] <cradek> the real motion will be much smoother than what AXIS can show
[21:43:13] <jepler> axis draws arcs in a very stupid way, using a small number of segments
[21:43:31] <tomp> k, skip that
[21:43:40] <pier_> and regarding the ramp... does emc ramp at every movement?
[21:43:45] <cradek> (opengl can't draw arcs except as lines)
[21:44:11] <cradek> pier_: not unless it has to
[21:44:17] <pier_> cradek: ok I fancied that...
[21:44:20] <cradek> pier_: see the TrajectoryControl wiki page
[21:44:25] <pier_> ok
[21:45:32] <tomp> will jepler's new tangential path experiments, allow higher constant velocities? ( no blending needed )
[21:47:07] <jepler> my code is simply a different way to generate arc (g2/g3) moves
[21:47:18] <jepler> it does not change the interpreter or the traejctory planner
[21:47:26] <skunkworks> why couldn't STEPGEN_MAXACCEL be set to some very large number?
[21:47:56] <fenn> it could
[21:47:58] <jepler> skunkworks: because in the case of a bug in the trajectory planner that causes a wildly out-of-spec acceleration to be used, it's nicer to get a following error than a stalled motor
[21:48:00] <skunkworks> wouldn't motion limit it?
[21:48:01] <fenn> but jmk doesnt trust emc's trajectory planner
[21:48:15] <skunkworks> ah
[21:48:24] <cradek> more like jmk wants stepgen to work apart from emc
[21:48:54] <fenn> yea that's a better way to put it
[21:49:32] <jepler> skunkworks: not if there are bugs there (and there frequently have been)
[21:50:07] <skunkworks> I understand - a bit of redundency (sp)
[21:51:32] <tomp> my point was that the resulting code cannot need any blending, and i think that may influence the maximum velocity that can be achieved while maintaining the exact programmed path ( right now the exact path has a tolerance that will limit the max velocity )
[21:52:27] <anonimasu> I wonder how that works with commercial controls..
[21:52:50] <anonimasu> I think some machine has a mode for it.. precision vs speed..(I think I saw fanuc had some triangle thing)
[21:53:12] <tomp> the tangential velocity is set in parameters, and the machine tool will try that, or judder. it's up to the installer to set it correctly
[21:53:49] <tomp> tangential acceleration sorry
[21:55:15] <tomp> doh! i can just experiment with a tangential program in Axis, nice tools you guys built! :)
[21:56:30] <jepler> tomp: the trajectory planner doesn't have a special case for subsequent moves having the tangential property, and I don't know how hard it would be to add
[21:57:49] <tomp> oh, i dont want to change anything, i just wondered the result tangential-ity an max velocity, trying now, the system can tell me
[21:58:19] <anonimasu> jepler: that probably would speed up contouring lots
[21:59:38] <jepler> http://emergent.unpy.net/files/sandbox/biarc-arc-interpolation-of-spline-4-8-16.png
[21:59:58] <jepler> ^^ approximation of a spline with varying number of arcs
[22:00:28] <jepler> despite the name, I think it's actually 3, 7, and 15 arcs (touching the spline at 4, 8, or 16 points)
[22:01:20] <cradek> we could put spline support in the interpreter and use this algorithm as a first shot
[22:03:57] <jepler> it's written as o-words right now
[22:04:11] <jepler> O110 call [1] [7] [3] [1] [4] [4]
[22:04:22] <jepler> (spline to 4,4 with control points 1,7 and 3,1)
[22:05:01] <jepler> you have to tell it where you started, though, if you got there with a g-code: O101 call [-1] [4]
[22:05:05] <skunkworks> * skunkworks never thought he would see jepler using o-words so much. ;)
[22:05:42] <jepler> I'm a very slow and clumsy python->o-word compiler
[22:06:41] <pier_> night all
[22:06:44] <pier_> thanks
[22:06:56] <skunkworks> I have a very slow brain -> computer compiler.
[22:07:00] <skunkworks> night
[22:08:59] <jepler> actually there was a 32-point approximation in there too, but it was so close to the 16-point one that you can't even see the difference
[22:13:22] <anonimasu> jepler: that's really neat stuff
[22:13:25] <cradek> I hate irc clients that advertise themselves
[22:14:39] <jepler> anonimasu: thanks
[22:15:16] <anonimasu> jepler: though I have no idea how to generate arc output from a cam program :)
[22:16:05] <jepler> anonimasu: me either -- it seems to involve buying a cam program, and I'm uninterested in doing that
[22:17:13] <anonimasu> yeah.. writing g-code by hand is nice and fast:)
[22:17:46] <fenn> 0.o
[22:21:26] <jepler> I don't believe that either but I spend most of my time being a cheapskate and an open-source software bigot
[22:22:12] <anonimasu> :)
[22:23:05] <anonimasu> jepler: is it faster to calculate and move by a spline then multiple short segments for the tp?
[22:23:59] <awallin> anonimasu: sure, it would be simpler at some level
[22:24:17] <anonimasu> like for contouring..
[22:24:18] <awallin> don't remember what it's called, theres trajectory control tc, and trajectory planner tp
[22:24:25] <jepler> anonimasu: for good performance in emc, lines and arcs shouldn't be "too short" (where "too short" depends on the requested velocity and the machine's acceleration capability)
[22:24:34] <awallin> one maintains a list of canon commands
[22:24:50] <awallin> the other steps through this list outputting positions every servo period
[22:24:50] <jepler> at the realtime level there are no splines, just lines and helical arcs
[22:25:02] <anonimasu> hm, ok
[22:25:08] <anonimasu> im kind of curious..
[22:25:15] <fenn> there's no real good reason why you couldnt have splines though
[22:25:17] <anonimasu> have we seen any machine to push the tp to the limit yet?
[22:25:21] <anonimasu> the new tp..
[22:25:42] <jepler> anonimasu: it's easy to write g-code that has bad performance on the emc trajectory planner
[22:25:45] <anonimasu> * anonimasu would be really anxious to see how it would work with brutal accelerations and high speed..
[22:25:55] <tomp> hmm, re: tangential paths... i dont see sim axis running the path any faster. I raised F to 100000, and in the .ini file maxv and each axis v to 10000. is there a current velocity display?
[22:25:56] <anonimasu> jepler: real world case, such as 3d contouring of something..
[22:25:57] <fenn> the current tp only looks ahead 1 segment
[22:26:02] <jepler> anonimasu: use lots of extremely short segments
[22:26:12] <fenn> or maybe its 2 or 4 or something
[22:26:55] <fenn> anonimasu: make a voice coil SCARA out of hard drives
[22:27:02] <anonimasu> fenn: haha ;)
[22:27:06] <anonimasu> zipzip
[22:27:13] <tomp> quick
[22:27:13] <anonimasu> fenn: im just curious
[22:27:23] <anonimasu> I'd like to see a damn fast machine doing something cool with emc:D
[22:27:35] <fenn> galvanometer based laser thingy
[22:27:41] <tomp> pickNplace
[22:28:03] <tomp> galvos- christmas light show on garage door
[22:28:22] <fenn> hard to get quicker than that, no mass to accelerate really
[22:28:25] <anonimasu> fenn: all my robot plans are on hold(puma style) for now, I dont have time and I dont have enough cash to pay for 5 steppers and drives..
[22:28:59] <fenn> you dont have time, that's the real proble
[22:29:10] <anonimasu> that's the other issue..
[22:29:37] <anonimasu> fenn: though I love toying with the thought ;)
[22:29:44] <fenn> dont we all :)
[22:30:45] <jepler> anonimasu: it is mostly g-code with short segments that causes trouble with emc (speeds markedly lower than requested), but exactly what is a "short segment" depends on the requested velocity and machine accel, there's not a fixed definition (like "under .01 mm") of what is a short segment.
[22:31:02] <anonimasu> yep
[22:31:20] <anonimasu> jepler: when I do that I usually turn on the blending at 0.002
[22:31:23] <anonimasu> or so :)
[22:31:28] <jepler> so don't, for instance, build a machine with a top speed of 1 km/s but an accel of 1 mm/s^2 and then send .01mm segments to it
[22:32:02] <anonimasu> that's too bad :/
[22:32:22] <anonimasu> ^_^
[22:33:19] <tomp> what limits max velocity in sim axis? i opened up the gcode file's F, and the [TRAJ] MAX_VELOCITY and each per axis MAX_VELOCITY but it doesnt plot faster, isnt plot speed an representation of programmed speed?
[22:39:55] <fenn> i'd guess -> # set PID loop output limits to max velocity
[22:40:30] <fenn> in servo_sim.hal
[22:40:52] <tomp> thanks!
[22:42:55] <jepler> arc and spline code posted:
http://axis.unpy.net/index.cgi/01171492370
[22:44:11] <jepler> (hm how absurd that the scaled screenshot thumbnail is smaller than the original!)
[22:45:51] <jepler> * jepler replaces the thumbnail with a crop
[22:45:57] <tomp> biarc, new vocab ( aka contiguous, tangential )
[22:46:45] <jepler> yeah a lot of these papers talk about "planar biarcs"
[22:46:45] <fenn> hey, isnt that the idea behind thumbnails in the first place?
[22:47:01] <jepler> fenn: I said the opposite if what I meant -- it was bigger (in bytes)
[22:47:52] <tomp> ooh, so we can try 3d biarcs ( triarcs ? ) the filleted path around a 'jack' ( from ball and jack )
[22:48:19] <jepler> emc doesn't do arcs in arbitrary planes, so I don't think that will work out
[22:48:39] <tomp> not arbitrary, those would be strict cartesian
[22:48:52] <tomp> normal to a std plane
[22:48:57] <jepler> ah, you want "helical splines"
[22:49:33] <tomp> like an 'immelman turn' like old airplanes aka loop de loop
[22:49:49] <jepler> that's a toughie, because it gets back to the problem of spline length -- you have to know what fraction of the spline length you've traversed to find out what Z value to use
[22:51:19] <tomp> my bad , triarc was a wrong thing to say, cuz if in a single xy/ yz/ zx plane, they're still biarc
[22:51:19] <fenn> cant you just make an arc with endpoints somewhere on the spline and pick the standard plane with the least error?
[22:52:09] <tomp> i just meant 3d in context of in each plane G17 G18 G19
[22:52:16] <cradek> at the lowest levels of emc, arbitrary arcs are supported - as you get further towards gcode, they aren't anymore
[22:52:28] <cradek> since (of course) there's no way to specify them in gcode
[22:52:35] <fenn> *boo hiss*
[22:52:54] <fenn> oh i was supposed to be fixing that situation wasnt i
[22:53:18] <tomp> ellipse b4 spline :)
[22:53:34] <fenn> eh?
[22:54:09] <fenn> why make something specific (ellipse) when its just as easy to do the general case?
[22:54:18] <tomp> we have the specialized gcode for circle, but not the more general ellipse ( circle is subset )
[22:54:32] <fenn> ellipse is a subset of cubic spline
[22:54:47] <fenn> well, elliptical arc
[22:54:56] <tomp> and cubic spline is subset of ??? :)
[22:55:07] <jepler> fenn: if you want to be at Z=0 at the start of the spline and Z=1 at the end, the problem is to determine what intermediate Z value to use for a particular spline parameter t. I think the correct answer is l(t)/l(1) (Z is the same as the fraction of the distance along the spline so far) but l(t) is difficult to evaluate for splines
[22:56:00] <jepler> I don't believe that a cublic spline can exactly follow any circular arc or elliptical arc
[22:56:11] <fenn> i'm probably wrong
[22:57:29] <jepler> http://www.tinaja.com/glib/ellipse4.pdf discusses approximating arcs with beziers, and says that the error can be quite low, but it's still not exactly an elliptical arc
[22:58:42] <erDiZz> look at this:
http://en.wikipedia.org/wiki/B%C3%A9zier_curve
[22:58:48] <erDiZz> there's a clear parametric definition
[23:00:00] <erDiZz> and a code snippet in C even, which returns a point for t from 0 to 1
[23:00:00] <tomp> i'm still not seeing the throttle on max vel, i use sim axis and it doesnt use servo_sim as far as i can tell
[23:00:02] <jepler> yes, but the time parameter is not a distance parameter
[23:00:20] <erDiZz> ah, ok
[23:01:00] <tomp> erDiZz: nice, i saw the java bezier examples listed there
http://www.ibiblio.org/e-notes/Splines/Bezier.htm
[23:01:07] <fenn> isnt t distance along the spline?
[23:01:36] <jepler> "The exact length of a spline is very difficult to find."
http://www.tinaja.com/glib/nubzlen1.pdf
[23:01:51] <tomp> don lancaster!
[23:02:08] <jepler> "Connect given points with arcs or lines such that the direction of motion
[23:02:08] <jepler> is the same at the end of a segment and the beginning of the subsequent
[23:02:09] <jepler> s"
[23:02:11] <jepler> er
[23:02:12] <fenn> tomp: he gets around eh?
[23:02:25] <jepler> 'The "t" parameter is in general nonlinear and tends to change faster along the "more bent" curve portions.'
[23:03:10] <tomp> fenn: ala ttl cookbook. he's into vector cuz of his work in postscript
[23:03:23] <erDiZz> binary search to find the next point maybe?
[23:04:04] <fenn> jepler: why does it matter if you have gone a highly accurate length along the spline or not?
[23:04:41] <fenn> i mean i can't even see any difference between the points
[23:05:25] <erDiZz> the points will tend to be very close to each other
[23:05:37] <fenn> t is whatever you want it to be
[23:05:36] <erDiZz> so that the spline looks almost like a line between them
[23:05:46] <fenn> you can increment by 1 or 0.0001
[23:06:04] <erDiZz> and so it is possible to try several t's to get a good distance of approximately 1
[23:06:12] <jepler> fenn: the trajectory planner assumes that you can find the location on the curve given the distance into it
[23:06:21] <jepler> fenn: tc.c:tcGetPos()
[23:06:55] <tomp> ah, catch 22, gotta know to long to get there
[23:07:09] <jepler> but that assumes that the functions x(t) y(t) z(t) are constant velocity
[23:08:12] <jepler> one paper I read suggests finding a spline that approximates l^-1(t) (distance to spline 't' parameter)
[23:08:18] <jepler> others suggest using arc approximiations to splines
[23:08:51] <fenn> arc approximation seems like a step backwards
[23:09:36] <erDiZz> with arc one trades speed accuracy for trajectory accuracy...
[23:10:28] <fenn> what i'd want eventually is a parametric equation for each joint axis in terms of temporal time (as opposed to some other "t")
[23:11:33] <fenn> then you just solve for t each realtime period
[23:11:49] <fenn> er, solve for j(t)
[23:11:56] <erDiZz> and it has to be fast
[23:12:05] <fenn> well, computers are fast
[23:12:24] <erDiZz> not all of them :)
[23:13:06] <jepler> elliptical arc length is also a lot less easy than circular arc length.
http://en.wikipedia.org/wiki/Ellipse#Circumference
[23:13:31] <fenn> jepler: so the problem is that "t" on the cubic spline isnt the same as time?
[23:13:38] <fenn> did i get that right?
[23:13:44] <erDiZz> the best approximation for elliptical integral I've found is by Chebishev's method
[23:13:51] <jepler> it's not the same as length
[23:14:05] <fenn> but its really close to length
[23:14:23] <jepler> I think you can find arbitrarily yucky cases
[23:14:53] <fenn> i think you shouldnt generate arbitrarily yucky cases in your tp
[23:15:08] <erDiZz> this is for ellipses:
http://mync.svn.sourceforge.net/svnroot/mync/trunk/grlib/grlib/util.c
[23:16:00] <erDiZz> the numbers are from a math book, I couldn't find anything better at reasonable time back then
[23:16:39] <fenn> heh i get excited every time i see text rendered cleanly in a foreign alphabet
[23:17:17] <erDiZz> fenn, it's a bibliographic reference anyway
[23:21:40] <fenn> erDiZz: what does this do?
[23:22:18] <erDiZz> I'll try to find something on the net
[23:22:39] <erDiZz> it looked really smart at the moment, but I remember nothing
[23:23:02] <fenn> well it looks like it returns the length along an ellipse, given (something)
[23:23:14] <erDiZz> yes, of cource
[23:23:19] <erDiZz> *course
[23:24:58] <fenn> a and b are points that define an angle?
[23:25:11] <fenn> a point that defines an angle
[23:26:19] <erDiZz> a and b are the axes
[23:26:28] <erDiZz> that one is for a full ellipse
[23:26:39] <erDiZz> but it's just a case
[23:27:25] <fenn> what are the numbers in cheb_x then?
[23:29:12] <fenn> ok will stop pestering you about it
[23:29:22] <erDiZz> fenn, no that's ok
[23:29:33] <erDiZz> I'm trying to find something about it right noe :)
[23:30:03] <erDiZz> the numbers are coefficients for an approximating polynomial
[23:30:19] <fenn> anyway i dont see why evaluating an ellipse is really useful
[23:30:31] <erDiZz> there is an interesting special case, which stays only for the power of at most 9
[23:30:39] <erDiZz> yep
[23:30:55] <fenn> i mean how many ellipses do you draw in a given year?
[23:30:57] <erDiZz> I was drawing an ellipse by some weird method, hence that function
[23:31:11] <erDiZz> :)
[23:31:28] <fenn> good for orbital mechanics maybe
[23:31:31] <tomp> if you blend ( make tangent ) many lines and arcs,a single ellipse will work, where several circular arcs may be needed
[23:31:37] <erDiZz> I was investigating into the case when the tool has elliptic form
[23:31:48] <tomp> titled wire
[23:31:52] <erDiZz> was drawing ellipses all the time then
[23:31:56] <tomp> tilted wire
[23:32:07] <erDiZz> yes
[23:32:38] <fenn> oh i see
[23:33:54] <tomp> btw: the limit on velocity was len of line and accel as jepler & cradek said. i upped the acc & got lots faster . but didnt stay on path as i suspected
[23:40:55] <tomp> erDiZz: the 1st agie wire edm's had special punched code (not gcode ) and used ellipse not arc, you described 2 radii ,
http://www.drahterosion.com/english/frames_e.htm, if you wanted a circular arc, you entered the same radius twice
[23:42:29] <erDiZz> I'm not sure that the speed was constant in that case
[23:42:40] <erDiZz> a side-effect probably
[23:43:32] <fenn> tomp: did you write that page?
[23:43:48] <tomp> fenn: which? where?
[23:43:52] <erDiZz> fenn, it's an automatic translation
[23:44:09] <fenn> ok.. some other thomas then
[23:44:10] <erDiZz> I like google's translation more than that one
[23:44:31] <tomp> fenn: not the agie stuff that's Thomas Doerpinhaus, old friend
[23:50:59] <erDiZz> oh, got that in English
[23:51:00] <erDiZz> http://mathworld.wolfram.com/ChebyshevQuadrature.html
