#emc | Logs for 2005-12-08

Back
[00:22:39] <djb_rh> scored a 4HP VFD today brand new for $15
[00:22:40] <djb_rh> woot
[00:28:42] <fenn> gratz
[00:54:13] <jmkasunich> lerman: are you here?
[00:59:58] <skunkworks> jmk - putting the extra variables in the emc.ini and the hal file worked as far as jogging and following errors. I am still not sure about the accelleraton but I don't have it hooked up to a machine yet (test machine at work)
[01:00:10] <skunkworks> thaks
[01:00:12] <skunkworks> thanks
[01:00:59] <skunkworks> only one hickup - forgot the = sign in the emc.ini file. swpadnos set me strait. ;)
[01:08:09] <robin_sz> sigh ... almost bedtime
[01:23:26] <fenn> comments, loud jeering criticisms, death threats? http://fenn.dyndns.org/pub/emc/chips2.png
[01:24:02] <robin_sz> not bad
[01:25:17] <robin_sz> personally, I think as a mascot its fine ... as a wallpaper with the various silly rotatin cursors etc on the BDI, it make sit all a bit "unprofessional" .. but as a icon / splashscreen its nice.
[01:25:57] <cradek> his safety glasses are a nice touch
[01:26:03] <robin_sz> * robin_sz nods
[01:26:10] <les_w> hi guys
[01:26:38] <robin_sz> evening router boy
[01:26:41] <Jacky^> hello :)
[01:26:43] <les_w> heh
[01:27:23] <les_w> actually I was on a boxford vsl and arguing with law dogs most of today.
[01:27:29] <Jacky^> hi robin_sz
[01:27:39] <robin_sz> hi
[01:27:47] <les_w> hi jacky
[01:27:49] <robin_sz> almost bedtime here ...
[01:27:59] <les_w> i'm sure
[01:28:07] <robin_sz> been cutting metal all day
[01:28:21] <les_w> I was cutting acetal
[01:28:25] <les_w> a little
[01:28:33] <robin_sz> on a lathe?
[01:28:54] <les_w> yeah. quickie 3 hour job
[01:29:06] <robin_sz> oh thats a quickie?
[01:29:11] <les_w> some adapters for a hot stamp machine
[01:29:58] <les_w> yeah a quickie...often interrupted by phone calls about NDA
[01:30:03] <robin_sz> heh
[01:30:26] <robin_sz> lawyers ... sort of useful I guess
[01:30:38] <robin_sz> I mean, theres a purpose for everything on this earth ...
[01:30:44] <CIA-12> 03cradek * 10emc2/src/emc/rs274ngc/interp_o_word.cc: looks like this file was forgotten during the lerman-interp merge.
[01:30:58] <robin_sz> even genital warts ... so I guess theres a reason for lawyers too
[01:31:38] <les_w> well, I am frustrated. Enough lawyers. I will call the vp technology of morgan tommorow.
[01:31:57] <robin_sz> lay it down on the line
[01:32:19] <robin_sz> or buy them up :)
[01:32:38] <les_w> I don't need an NDA. I just want to buy their stuff. High volume. That's all.
[01:33:03] <robin_sz> I wonder how hard it is to make that stuff from first principles?
[01:33:21] <les_w> I checked . easy.
[01:33:30] <robin_sz> yeah?
[01:33:34] <robin_sz> even the powder?
[01:33:47] <les_w> lots of other firms...they are a major though.
[01:34:15] <robin_sz> ach, just buy up a small but good one then :)
[01:34:19] <les_w> It's just refining and doping and pottery crap
[01:34:51] <robin_sz> I imagine it is VERY sensitive to impurities
[01:35:00] <fenn> what, you're getting into the semiconductor industry now?
[01:35:31] <les_w> I'm not too worried...having been in the semicon industr for years
[01:35:45] <les_w> amazing what a few ppm of sodium can do
[01:36:03] <robin_sz> or chlorine
[01:36:19] <les_w> all sorts of donors or acceptors
[01:36:29] <robin_sz> "oh just wash those suits in the regular stuff then" ;)
[01:36:37] <les_w> haha
[01:37:12] <les_w> all too familiar with 10 megohm cm di water
[01:37:42] <robin_sz> mmm ... how does that relate to uS (micro siemens)??
[01:38:46] <les_w> hmmm
[01:38:55] <robin_sz> and why is it in units of cm?
[01:39:16] <robin_sz> surface resistivity is unitless
[01:39:33] <les_w> this is volume resistivity
[01:39:36] <robin_sz> why does volume resistivity have units?
[01:40:05] <robin_sz> surface resisitance is just "ohms per square" ...no units
[01:40:07] <les_w> in some forms it does not have to
[01:40:18] <les_w> surface ohms per square
[01:40:28] <les_w> volume ohms per cube?
[01:40:35] <robin_sz> shrug
[01:41:16] <les_w> reminds me of an episode in miniteman II project
[01:42:00] <les_w> manager came in preparing for a couple weeks of 7 day/12 hr work for an emergency run of wafers
[01:42:28] <les_w> seems I found two from the previous run in a desk drawer
[01:42:37] <les_w> all dirty and crapped up
[01:42:58] <les_w> had been through silox via etch
[01:43:25] <les_w> I cleaned them up and we metallized them
[01:43:42] <les_w> got a low yield...but enough chips.
[01:43:53] <les_w> now this was for the guidance system
[01:44:09] <les_w> are'nt you glad the cold war is over?
[01:44:12] <robin_sz> noting important then ;)
[01:44:21] <les_w> nah...haha
[01:44:28] <fenn> idaho, siberia, same diff
[01:44:42] <robin_sz> nah, there is intellignet life in idaho
[01:44:55] <robin_sz> siberia is just ducks
[01:45:18] <robin_sz> ok bedtime ...
[01:45:25] <robin_sz> later guys
[01:45:29] <les_w> night
[01:46:19] <les_w> hey fenn what do you think of the josh tread?
[01:47:03] <fenn> well computers have progressed a lot in the last 13 years
[01:47:49] <fenn> seems the only real questions are how many cycles it will take to calculate and who is going to program it
[01:48:22] <les_w> Well I mentioned that the authors tried and couldn't
[01:48:26] <les_w> with emc1
[01:48:38] <les_w> just to hard to change
[01:48:46] <SWPadnos_> there's a problem with the josh thread
[01:48:52] <fenn> i was thinking it would be a total rewrite
[01:49:07] <les_w> I asked if emc2 was different due to better organization
[01:49:13] <les_w> swp what?
[01:49:20] <fenn> there is a lot of emc1 crap floating around that nobody knows what it does
[01:49:24] <fenn> in emc2
[01:49:25] <SWPadnos_> the issue with throughput vs. latency
[01:49:44] <les_w> I was worried about that too
[01:49:47] <fenn> latency= 1 servo loop
[01:49:52] <fenn> ?
[01:50:03] <SWPadnos_> true, if you don't want to run steppers
[01:50:06] <SWPadnos_> in software
[01:50:19] <SWPadnos_> like emc and all the hobby controllers do
[01:50:32] <fenn> steppers can use a different sub-interpolator if it is too much
[01:50:36] <les_w> but wb9 getting 125 microseconds for 3 axes helped me feel better about that
[01:50:53] <les_w> a lot better
[01:51:11] <SWPadnos_> just letting people know the constraints
[01:51:26] <les_w> sure
[01:51:28] <fenn> if you think about it, the change in position between two servo cycles is linear
[01:51:30] <SWPadnos_> one is that you would have to use external hardware to send step pulses or analog control signals
[01:51:40] <fenn> so a linear sub-interp for steppers wouldnt be any worse
[01:51:48] <SWPadnos_> not necessarily - it depends on the interpolator
[01:51:55] <les_w> I feared that really modern servo rates might be impossible using a general purpose up
[01:51:56] <SWPadnos_> which right now is a spline interpolator
[01:52:11] <fenn> swp you output velocity commands once per servo loop right?
[01:52:17] <SWPadnos_> (afaik - I don't know the code that well either)
[01:52:30] <jmkasunich> fenn: yes
[01:52:31] <petev> fenn, position is output
[01:52:32] <SWPadnos_> yes - sorry - was thinking of servo vs. traj loop
[01:52:39] <fenn> then the amp tries to keep the motor going at that velocity.. that is a linear path
[01:52:44] <SWPadnos_> yes
[01:52:51] <fenn> ok
[01:52:53] <les_w> well, trapeziodal (parabolic blending) with sub interpolation at the servo rate
[01:52:58] <jmkasunich> actually, the motion controller outputs position, the pid looks at commanded and feedback and outputs velocity
[01:53:20] <les_w> hi ray
[01:53:32] <SWPadnos_> ok - but we can agree (even though I'm a bonehead) that the servo goes at one rate per servo update
[01:53:36] <rayh> Hi Les
[01:53:40] <jmkasunich> yes
[01:53:41] <les_w> yeah
[01:54:36] <SWPadnos_> there probably isn't an issue with a new interp for stepper machines, since they've never been able to go that fast from software anyway
[01:54:52] <SWPadnos_> (not fast enough to need jerk limiting or hit the traj / interp limits that well)
[01:55:27] <fenn> one thing i'm not clear on.. what is the advantage of parameterizing the paths in terms of distance along the path, and then figuring out t in real time?
[01:55:28] <les_w> good jmk is here. In the post I guessed that emc1 was just not written in a way that you could easily plug things like a new tp into it...the authors put about a man year trying....
[01:55:47] <les_w> but what about emc2?
[01:55:49] <SWPadnos_> it's a tough thing to take a 2GHz CPU, and realize that it will sit and do nothing for 1 microsecond, every time you output to a port
[01:56:06] <SWPadnos_> so you waste 2000 cycles every outb
[01:56:32] <jepler> Is that when talking to ISA bus, or even on PCI?
[01:56:33] <fenn> was that a limitation of the isa bus after all?
[01:56:34] <SWPadnos_> this isn't true on PCI controller cards, so you'd almost require that people use PCI cards for control
[01:56:45] <petev> SWP, what about posted writes?
[01:56:48] <les_w> yeah. but machine control is really not that demanding...
[01:56:52] <SWPadnos_> parport or ISA (parport is on ISA)
[01:57:23] <SWPadnos_> I thikn ISA would be ruled out - consider what needs to happen for a 6-axis machine (the max that emc currently supports)
[01:57:26] <les_w> It seems from wb9's results that the isa STG is a real millstone
[01:57:39] <fenn> i would really like a way to see how many cycles go to which process, ala gprof
[01:57:48] <fenn> s/process/function/
[01:57:49] <SWPadnos_> he ended up using the pci MotenC, right?
[01:58:13] <jmkasunich> hal is supposed to have parameters that report the time used for each realtime thread
[01:58:13] <les_w> yeah and got 5 times the servo rate that an STG can do
[01:58:17] <SWPadnos_> right
[01:58:41] <jmkasunich> but the current implementation of that relys on kernel support that isn't in any of the recent BDIs
[01:58:56] <fenn> jmk what specifically?
[01:59:07] <jmkasunich> my recollection of the details is rusty, its been two years
[01:59:16] <SWPadnos_> for each axis, assuming no overhead (but ISA, so 8-bit transfers), you would need to read 3 or 4 bytes of encoder position, and output 2-4 bytes of command data
[01:59:19] <jmkasunich> stand by...
[01:59:22] <fenn> this is mainly a development thing, but it could be useful for tuning also
[01:59:44] <petev> SWP, ISA can do 16 bits and you can post writes
[01:59:58] <petev> but I agree it's still slow
[02:00:13] <SWPadnos_> posted writes are a hardware transfer mode, no?
[02:00:19] <SWPadnos_> ie, the card has to support it
[02:00:27] <petev> most all modern chipsets support posted writes
[02:00:33] <jmkasunich> fenn: see emc2/src/rtapi/rtai_rtapi.c line 526
[02:00:37] <petev> just because things like ISA are so slow
[02:00:59] <petev> swp: no dependency on card
[02:01:06] <petev> it's a chipset thing
[02:01:46] <SWPadnos_> I suppose it's a moot point, because almost any machine that would have the CPU horsepower for a mega-interpolator probably won't have ISA anyway
[02:02:00] <petev> true
[02:02:08] <petev> and there are plenty of cheap HW options
[02:02:12] <SWPadnos_> you'll either be using a parport and something like a USC, or a PCI card
[02:02:18] <jmkasunich> what do you mean by a "mega interpolator"?
[02:02:24] <petev> for HSM
[02:02:27] <SWPadnos_> the Josh Seaton thread
[02:02:40] <jmkasunich> the Pxyzabc(t) thing Josh was talking about is very low HP on the realtime side
[02:02:58] <les_w> I am noew satisfied that a general purpose pc can do that...I wasn't a few days ago
[02:03:11] <jmkasunich> evalutaing 6 quintic polys can be done in the time of one outb
[02:03:23] <les_w> yeah
[02:03:26] <fenn> swp or a pci parallel port card and a usc.. cheap workaround
[02:03:41] <SWPadnos_> but still makes you wait, I'd bet
[02:03:47] <petev> are we still talking about turning arcs and lines into splines?
[02:03:48] <jmkasunich> usc still takes about 1.3uS per byte sent
[02:04:08] <jmkasunich> I was assuming the arc/line to spline conversion would be done in user space
[02:04:08] <SWPadnos_> I can try it - I have a PCI dual parport card that I can stick in a machine
[02:04:18] <jmkasunich> I keep meaning to reply to Josh, but....
[02:04:23] <SWPadnos_> heh
[02:04:39] <petev> jmk: ok, cause I don't see a good way to deal with splines from CAM and do cutter comp
[02:04:52] <les_w> I am considering proposing to josh that we start by fixing the errors that we partially corrected in august by just #ifdefing some stuff out
[02:05:22] <jmkasunich> splines from CAM is a completely different subject
[02:05:28] <SWPadnos_> cutter comp and feedrate override tend to complicate the works on the RT end
[02:05:29] <petev> agreed
[02:05:37] <les_w> but we also #ifdefed out velocity adaptation beyond triamgular
[02:05:41] <jmkasunich> cuttercomp isn't done in realtime
[02:05:51] <SWPadnos_> no - the canon moves are comped
[02:05:53] <SWPadnos_> ok
[02:05:55] <petev> jmk: was agreeing with u
[02:06:02] <jmkasunich> les: I for one want to have as little to do with that code as possible
[02:06:04] <SWPadnos_> * SWPadnos_ was the bonehead again
[02:06:11] <jmkasunich> heh
[02:06:25] <petev> jmk: which code, the old stuff?
[02:06:32] <petev> I say just re-write
[02:07:03] <les_w> jmk: it's obvious that even the authors can't decypher it anymore...I know...I had them here trying!
[02:07:15] <les_w> petev: right
[02:07:36] <petev> jmk: EMC3 may be closer than u thought ;-)
[02:08:22] <fenn> so would this be better done with FP or integer math?
[02:08:36] <jmkasunich> FP!!!
[02:08:40] <fenn> ok
[02:08:52] <les_w> not sure these days...suspect floats would be fine
[02:09:05] <jmkasunich> pentium and later CPUs are just as fast, sometimes faster, with FP as with int
[02:09:13] <les_w> k
[02:09:22] <jmkasunich> and the bastardization needed to do fixed point is the source of all kinds of stupid bugs
[02:09:32] <petev> agreed
[02:09:33] <les_w> as long as pipelines and caches are not involved...
[02:09:37] <jmkasunich> been there, done that, ain't going back
[02:09:57] <jmkasunich> les: what do you mean?
[02:10:05] <jepler> I should just keep my trap shut since I'm not fit to write TP, but the point of integer is not speed, it's that accuracy and rounding is all explicit, so it never bites you on the ass unexpectedly .. instead it's a constant annoyance
[02:11:25] <les_w> I do math, but only rank amateur programming. I don't know if floats are fast now due to statistical methods like caching
[02:11:30] <fenn> well you yourself were the one who said "are you machining parts 1AU and worried about the 15cm differences"
[02:11:45] <jmkasunich> I'd rather have 50 some bits of precision and 1024 of dynamic range, then 32 bits split between precision and dynamic range
[02:12:18] <jmkasunich> no les, floats are fast now because CPUs have dedicated floating point pipelines
[02:12:22] <jepler> jmkasunich: so mandate amd64 and have 64 bits
[02:12:31] <les_w> ok
[02:12:39] <jmkasunich> you can write the long-long math library
[02:12:53] <fenn> um, what?
[02:13:00] <jmkasunich> you = jepler
[02:13:06] <les_w> so floats are fast in hard realtime?
[02:13:13] <jmkasunich> yes
[02:13:16] <les_w> ok
[02:13:26] <SWPadnos_> it's the context switch that takes a little bit more time
[02:13:26] <jmkasunich> emc1 and 2 both use the FPU for the TP thread
[02:13:58] <jmkasunich> while the RT code is running, it owns the FPU, the FPU state from user space is saved and restored just like everything else on task switches
[02:14:08] <jepler> this does add some time to the task switches
[02:14:16] <jmkasunich> sub-microsecond
[02:14:22] <SWPadnos_> right - that's what I was talking about
[02:14:40] <jmkasunich> FPU state is a few hundred bytes at most, on todays machines that is small and quick
[02:14:45] <les_w> Well,again running emc1 at 125 microsecond servo rate was reassuring
[02:14:57] <les_w> in a p3 700
[02:15:02] <jmkasunich> and still in L2 cache at least when the RT code finishes
[02:15:07] <les_w> slower in a newer p4?
[02:15:07] <SWPadnos_> sure
[02:16:18] <jmkasunich> newer CPUs have worse latency, but better throughput
[02:16:41] <les_w> It seems that the hypothesis that rt/user comms was the bottleneck was not correct
[02:17:23] <jmkasunich> les: ?
[02:17:42] <jmkasunich> what experiment did you run to prove that?
[02:18:30] <les_w> Paul thoght that. But going from ISA STG to PCI mmotemc we saw a 5x ingrease...and that was not even the limit
[02:18:40] <jmkasunich> 5x increase in what?
[02:18:45] <SWPadnos_> servo rate
[02:18:58] <les_w> keyboard changeout time.
[02:19:03] <les_w> again...
[02:19:07] <jmkasunich> well when you increase the servo rate, you automatically increase the rt/user comms...
[02:19:11] <jmkasunich> so that doesn't prove anything
[02:19:22] <SWPadnos_> hmmm - how many bus transfers are needed to do a full update on the STG?
[02:19:24] <les_w> ok if you say so
[02:19:46] <jmkasunich> the RT code can process one "command" every servo period, but only if it is in the buffer
[02:19:48] <SWPadnos_> I think he's saying that the tests conducted by him and Paul just after Fest were wrong
[02:19:48] <petev> jmk: the one Q ent per TP period only seems to be an issue in building up look ahead, no?
[02:20:16] <les_w> right
[02:20:19] <SWPadnos_> though I could be confusing rates again ;)
[02:20:29] <jmkasunich> it would show up if you were trying to follow a path made of 0.001 inch segments at 2 inches per second
[02:20:40] <SWPadnos_> I think the conclusion then was that you couldn't go faster than X because of the communication overhead
[02:20:51] <les_w> exactly
[02:20:55] <jmkasunich> because you simply can't get the segments from user to RT as fast as RT consumes them
[02:21:01] <les_w> I thing that is not the case now
[02:21:21] <jmkasunich> you probably aren't running that particular pathological case
[02:21:31] <jmkasunich> the real limit is probably less, maybe a lot less
[02:21:33] <petev> jmk: I thought the current TP only needed one more point per period once it had enough for look ahead?
[02:22:05] <jmkasunich> pete: we're not talking about points, we're talking about lines
[02:22:20] <petev> ok, lines per period
[02:22:24] <jmkasunich> if you try to do 0.001" lines at 2" per second, you will be using up 2000 of the per second
[02:22:27] <les_w> oh, jmk, the segment thing is the velocity adaptation bug we have not found. It should slow speed until motion is realizable
[02:22:40] <jmkasunich> if you are doing 10" lines at 2" per second, you only need one every 5 seconds
[02:22:44] <les_w> without queue starvation
[02:22:56] <jepler> on my 1.5GHz laptop, fxsave + fxrstor in a tight loop is only 133 cycles per save/restore pair.
[02:22:58] <jmkasunich> there is a huge dynamic range there, and few programs go to the nasty end of it
[02:23:13] <petev> agreed, but what I'm askind is if the TP can process more than one line per TP period? I thought it couldn't
[02:24:00] <petev> so with high enough TP rate, the Q architecture is not really that big a deal although it does waste CPU cycles
[02:24:39] <les_w> one line...and it is an iteger multiple of the servo rate. Changing the ratio of trajectory rate to servo rate changes the cubic sub interpolation s curve smoothing thoug.
[02:24:49] <les_w> though
[02:24:57] <jmkasunich> pete: you mean, assuming they are in the queue, can the TP pull out and process more than one per pass? I don't know that
[02:25:01] <les_w> "quote from fred"
[02:25:07] <petev> jmk: yes
[02:25:09] <fenn> les_w: but that isn't an issue if you have a decent tp in t he first place
[02:25:25] <fenn> les_w: you dont need cubic smoothing because you're already doing quintic paths
[02:26:17] <les_w> fenn: emc is trapeziodal at the trajextory rate, with cubic at the servo rate
[02:26:20] <jmkasunich> IF we were fortunate enough to be feeding the TP with quintic splines, I'd just evaluate the spline every servo cycle, and dump the idea of a "TP rate" completely
[02:26:40] <petev> jmk: that would be nice
[02:26:44] <jmkasunich> les_w: yes, emc IS that, but we ain't talking about what it is anymore
[02:27:01] <fenn> jmkasunich: and re-fit splines in response to changes in userspace?
[02:27:20] <jmkasunich> in response to what changes? feedrate?
[02:27:22] <fenn> yeah
[02:27:35] <jmkasunich> probably
[02:27:43] <jmkasunich> thats where it gets messy
[02:27:43] <fenn> cool
[02:27:56] <jmkasunich> (only in the case where you have straight lines meeting at sharp corners)
[02:28:05] <les_w> Well yeah. Quintic makes for nice dynamics, but it distorts paths. You also need some heuristics for corners and stuff, or all you can make are melted candy bars.
[02:28:10] <fenn> that's what g6(1?) is for
[02:28:27] <jmkasunich> because that gives you zero radius, which you cannot follow at any speed other than zero
[02:28:48] <les_w> kinda. but really exact stop==zero chip load...so is a problem
[02:28:56] <jmkasunich> exactly
[02:29:01] <les_w> look ahead is the answer
[02:29:03] <fenn> you cant have your cake and eat it too
[02:29:06] <jmkasunich> so you must follow a non-sharp path
[02:29:24] <les_w> Fenn: haha sure you can
[02:29:28] <jmkasunich> in user space, before you even run the program, you could concievably fit splines to the path
[02:29:43] <jmkasunich> at that time, you trade off corner sharpness vs speed
[02:29:52] <les_w> yes
[02:30:00] <fenn> that's what he was talking about measuring the length/length ratio
[02:30:04] <jmkasunich> if sharpness is critical, you make a tight fit, if speed is critical, a loose one
[02:30:08] <les_w> RT speed override is an issue though
[02:30:13] <les_w> a big one
[02:30:35] <jmkasunich> the TP would be evaulating curvature, and would slow down 'T' as needed to meet accel lims while following the spline exactly
[02:30:50] <jmkasunich> you would slow down, but remain on the same path - easy to do that in RT
[02:30:59] <SWPadnos_> as long as the interpolator has some notion of the maximum allowed rate through a given curve segment (based on userspace calcs using user-specified tolerances), you can do feedrate override without changing the underlying coefficients
[02:31:20] <jmkasunich> the TP only cares about curvature
[02:31:32] <jmkasunich> for any given radius, there is a maximum velocity
[02:31:34] <les_w> jmk: that is one philosophy. Compute the TP a priori. then scale time for feed override.
[02:31:46] <jmkasunich> scaling time has lots of benefits
[02:31:57] <jmkasunich> for threading, you replace "time" with spindle position
[02:32:00] <petev> jmk: I like scaling time
[02:32:08] <jmkasunich> form EDM backout, scale time negative
[02:32:11] <SWPadnos_> it seems so slooooooowwww at times ;)
[02:32:19] <fenn> les_w: you can re-do the tp calculations while the program is running, just not in realtime
[02:32:29] <les_w> when you do that, things don't get tighter when you go slower because max accel and vel are scaled too. but it is a valid approach.
[02:32:30] <jmkasunich> fenn: not the TP calcs
[02:32:36] <jmkasunich> the spline fit
[02:32:37] <fenn> the spline-fit calcs
[02:32:40] <fenn> what's the diff?
[02:32:44] <jmkasunich> big diff
[02:32:53] <fenn> i must be mangling terms
[02:32:54] <jmkasunich> TP takes a continuous curve (the spline) and samples it
[02:32:58] <petev> fenn: why redo TP calcs? The operator should be using feed override to control path accuracy
[02:33:02] <SWPadnos_> spline fitting is an iterative process
[02:33:07] <SWPadnos_> (or it may be)
[02:33:20] <jmkasunich> spline fit is generating a spline that describes the path you want (or close to it)
[02:33:22] <fenn> petev: what?? feed override concerns feed, not accuracy
[02:33:32] <petev> fenn: exactly
[02:33:34] <fenn> petev: fixing the accuracy loss is a secondary issue
[02:33:40] <SWPadnos_> but attainable accuracy decreases as feedrate increases
[02:33:40] <les_w> RT TP: path following gets tighter if you slow down (possibly)
[02:33:50] <jmkasunich> petev: the way I see it, the operator would not use feed override to improve accuracy
[02:33:55] <les_w> a priori TP: it doesn't
[02:34:00] <les_w> either is valid
[02:34:04] <petev> jmk: correct
[02:34:18] <jmkasunich> the TP would always follow the spline exactly - accuracy is determined when you fit the spline
[02:34:29] <petev> jmk: correct
[02:34:35] <SWPadnos_> a priori has other troubles, such as pause / resume (essentially feed override to 0)
[02:34:51] <jmkasunich> what do you mean by a priori TP?
[02:34:58] <SWPadnos_> precalculated in userspace
[02:35:01] <les_w> It is a matter of scaling accel when you scale feed
[02:35:23] <jmkasunich> its not a priori TP, its a priori spline fit
[02:35:35] <fenn> this is why i wanted to define terms
[02:35:43] <jmkasunich> TP is a sampling process
[02:35:44] <les_w> yeah I guess
[02:35:49] <fenn> jmk i disagree with that
[02:35:59] <fenn> that is the servo-loop
[02:36:06] <jmkasunich> when you send splines down to the TP, that still descpribes a continuous path, no sampling
[02:36:17] <les_w> right
[02:36:34] <jmkasunich> fenn: the servo loop attempts to make the motors track the samples coming from the TP
[02:36:59] <fenn> ok, what rate are the servo loop and the tp running at?
[02:37:06] <fenn> the same?
[02:37:19] <jmkasunich> if we were using splines, yes
[02:37:41] <les_w> yes, but the shape of the splines depend on the max accel...that is a factor in calculasting them
[02:38:12] <jmkasunich> les: yes, we basically move the nasty math and lookahead from the RT world to the spline fitting stage
[02:38:20] <jmkasunich> where it is easier to do, IMO
[02:38:27] <les_w> yes
[02:38:33] <les_w> perfectly valid
[02:38:52] <fenn> les it doesn't matter if your path is sub-optimal for 100ms
[02:39:00] <jmkasunich> you can generate splines that exactly fit a sharp corner (velocity at the corner will be zero, but the path will be correct)
[02:39:13] <jmkasunich> or you can generate splines that round it off and let you keep moving
[02:39:28] <les_w> nowhere is slower== tighter corners rally mandated
[02:39:39] <fenn> that should be user-specified
[02:39:46] <fenn> via g64 or some such
[02:39:48] <les_w> usually fedd OR is to experimentally set chip load
[02:39:54] <les_w> feed
[02:40:07] <les_w> or keep from bogging down the spindle
[02:40:22] <jmkasunich> right
[02:40:55] <jmkasunich> now if you did have a path that was "melted candy bar" rounded, you would probably prefer that when you turn FO down, it goes closer to the ideal path
[02:40:59] <petev> so les, can you write up the curve fitting math for user space?
[02:41:04] <les_w> So user space tp stuff is perfectly valid...have lots of memory though
[02:41:13] <jmkasunich> I'm not proposing that though
[02:41:24] <fenn> jmk that shouldnt be too hard
[02:41:36] <jmkasunich> fenn, it is too hard
[02:41:40] <les_w> I have the math onmy web page....for trapezoidal
[02:41:44] <fenn> if it takes 100 ms to re-fit the splines to a tighter shape, you just deal with it for 100 ms
[02:41:54] <petev> I saw that, but I think we want more than that
[02:42:11] <les_w> can do cubic or quintic at least in pseudocode
[02:42:32] <petev> les: I have another paper that describes some jerk limited circular interpolation
[02:42:42] <les_w> cool
[02:42:45] <petev> I'll send you a copy
[02:42:50] <les_w> thanks
[02:42:59] <jmkasunich> les: my calculus is rusty
[02:43:08] <petev> les: what I really would like to see is the curve fittin part to the lines/arcs
[02:43:35] <jmkasunich> is the derivitage of a 5th order poly 4th, 5th, or 6th order?
[02:43:51] <jmkasunich> derivative
[02:44:08] <petev> it's 6th order isn't it?
[02:44:17] <jmkasunich> was afraid of that
[02:44:26] <SWPadnos_> derivative should go down in order, integral goes up
[02:44:37] <les_w> again. even the current cubic sub interpolated trapezoidal planner would work pretty well (by 1985 standards or so) if we FOUND THE BUG
[02:44:45] <jmkasunich> I hope that the spline can describe only the path , not the speed
[02:45:13] <cradek> les_w: it would be easy to find the bug if we knew the algorithm
[02:45:24] <les_w> yeah. really.
[02:45:27] <jmkasunich> les_w: but we are not going to FIND THE BUG when we can't even figure out what it is doing
[02:45:38] <les_w> yup
[02:45:45] <cradek> les_w: so who still has contacts with the original writers?
[02:46:04] <cradek> does one of us know someone who knows someone?
[02:46:14] <jmkasunich> I don't care - if I spend any significant time on TP issues, it will be on a spline based TP, not on the existing one
[02:46:42] <cradek> I'd sure like a simple fix while emc3 pans out
[02:46:45] <les_w> Chris, I have had Fred P. from NIST down here looking at exactly this stuff
[02:46:48] <jmkasunich> of course, lord knows when I have any time to spend on it, maybe in 2007
[02:46:58] <les_w> 1) he does not remember
[02:47:09] <les_w> 2) he has limited funding
[02:47:30] <jmkasunich> IOW, he can't try to remember on company time ;-)
[02:47:35] <les_w> He knows it's screwed up
[02:47:45] <les_w> he knew it in 1999
[02:47:56] <cradek> les_w: darn. It would be nice to have the paper or book or notes or scratch paper or whatever he used
[02:48:02] <les_w> that's why he started a project to fix it
[02:48:29] <jmkasunich> basically, to fix the existing TP, somebody is going to have to go in there and reverse engineer it (documenting all the way)
[02:48:35] <les_w> He hired a guest researcher to make a new TP.
[02:48:42] <cradek> well it's interesting to note that segmentqueue only has some bugs in it. I think it's fundamentally sound.
[02:48:50] <jmkasunich> frankly, that could be a very productive use of somebody's time
[02:48:56] <les_w> I had him down here too...all the way from holland!
[02:49:08] <cradek> since my hacking a year or so ago, the thing actually runs programs
[02:49:11] <jmkasunich> (reverse engineering the old one, not the guest researcher)
[02:49:21] <les_w> cradek: the math is sound.
[02:49:51] <les_w> it hangs and gives RT timeout messages.
[02:50:03] <les_w> not timeout...
[02:50:12] <les_w> what do you call it?
[02:50:17] <fenn> missed deadline?
[02:50:31] <les_w> RT thread does not have enough time...
[02:50:35] <cradek> I'm pretty sure I didn't get that
[02:50:36] <les_w> yeah
[02:50:43] <les_w> missed deadline
[02:50:46] <cradek> hmm
[02:51:01] <cradek> maybe you'd have to increase the period a bit
[02:51:09] <cradek> it's obviously doing more math
[02:51:12] <jmkasunich> les: is that because of some bug, or is the algorithm not constant running time?
[02:51:15] <les_w> tried. did not help.
[02:51:40] <cradek> les_w: was this on a pathological program? I made many parts with segmentqueue
[02:51:47] <cradek> granted, my machine is slow
[02:51:56] <fenn> how do you guarantee that an algorithm will finish in x seconds?
[02:52:08] <jmkasunich> if its not constant running time (either because it has to look ahead N moves, where N can vary, or because some solver is iterative) then you have troubles in RT
[02:52:28] <cradek> well it's certainly not constant running time
[02:52:42] <cradek> because of the segment linking algorithm
[02:52:50] <jmkasunich> then it doesn't belong in RT, IMHO, unless you can prove it has an upper bound that is acceptable
[02:53:02] <les_w> Bug. We concluded that emc is written in a way that plugging in a new TP is something that requires man hours we don't have.
[02:53:21] <les_w> i.e. a rewrite would be cheaper.
[02:53:40] <cradek> jmkasunich: you're probably right about that.
[02:53:45] <les_w> both are possible though...
[02:53:46] <cradek> jmkasunich: it does have a queue length limit, I guess
[02:54:35] <les_w> Fred messed with really big queues
[02:55:49] <cradek> imagining contouring where you go back and forth over a part, being able to plan the whole length at once would be a nice benefit
[02:56:06] <cradek> but that could be many hundreds of segments
[02:56:13] <fenn> millions
[02:56:25] <jmkasunich> what exactly is a segment for segmentqueue?
[02:56:26] <jmkasunich> an arc?
[02:56:28] <jmkasunich> a line?
[02:56:32] <jmkasunich> part of one of those?
[02:56:41] <fenn> i think it's a series of accel and decel
[02:57:12] <fenn> i should shut up.. know nothink about seqmentqueue
[02:57:13] <cradek> I think it's actually the line or arc from the gcode
[02:57:36] <les_w> jmk: the segmentqueue concept is a novel way of planning variable waypoint blends
[02:57:42] <les_w> the math is sound
[02:58:06] <les_w> it just can't be easily integrated into emc
[02:58:07] <cradek> initially, anyway - they get joined together and planned as one, especially when they're too short for accel/cruise/decel
[02:58:24] <fenn> les_w: so you save the blends until rt time?
[02:58:37] <jmkasunich> cradek: now I start to get it...
[02:58:50] <les_w> segmentqueue was implemented as a RT process.
[02:58:59] <jmkasunich> if you have a crapload of 0.001 moves, merge them into something bigger
[02:59:12] <les_w> It does that.
[02:59:28] <jmkasunich> I'd still prefer it if that "something bigger" was a spline
[02:59:30] <cradek> right
[02:59:39] <les_w> it did that too.
[02:59:42] <petev> what does it merge them to? some type of spline?
[02:59:53] <les_w> yes cubics.
[03:00:24] <jmkasunich> and it is done in RT why? because of feed override?
[03:00:37] <petev> hmm, seems like what we are suggesting doing in user space ahead of time
[03:00:51] <fenn> jmkasunich: because of the way the planner was constructed in 1992.. :)
[03:00:55] <les_w> I think because emc used a RT planner...no other reason
[03:00:56] <cradek> petev: it may be mostly done
[03:01:23] <jmkasunich> so put segment queue in user space and send the splines to RT
[03:01:52] <les_w> you could do that...as long as you were willing to just scale time for feed overrides
[03:02:26] <cradek> we already have a real problem with feed override (in the override-up case)
[03:02:43] <cradek> I don't see how you can override-up with splines
[03:03:07] <fenn> why worry about rt feed override?
[03:03:07] <petev> cradek: would depend on if the splines were calced at max accel
[03:03:10] <les_w> well, currently we scale time and velocity, but not accel.
[03:03:18] <jmkasunich> you can override up, until the curvature of the spline makes you hit a limit
[03:03:25] <les_w> a priori systems must scale all
[03:03:30] <les_w> which is fine
[03:03:32] <jmkasunich> if the spline was originally fit to take you right to the limit, then you can't override up
[03:04:11] <fenn> you should only allow feed to be overridden after the computer has time to re-fit a new spline
[03:04:21] <fenn> in the up direction that is
[03:04:41] <petev> fenn: why? The spline may have been fit at 1/2 mas accel
[03:04:45] <jmkasunich> fenn, that isn't practical
[03:04:46] <petev> max
[03:04:49] <fenn> going down you can scale time, and then switch to the new spline when it's done calculating
[03:05:03] <fenn> petev: why would you fit the spline at 1/2 max accel?
[03:05:20] <les_w> scaling time scales velocity and accel
[03:05:24] <petev> fenn: if that's all it takes for desired path accuracy at 100% feed
[03:05:26] <fenn> to save on ballscrew wear?
[03:05:44] <les_w> scaling in RT allows computing new paths with the same accel
[03:07:25] <les_w> For whatever reason, most TPs are in real time these days, althgough it is not required.
[03:08:05] <les_w> So slow down and splines hug corners more
[03:08:11] <petev> if we limit the size of the user space Q to what's needed to statistically keep up, there would just be a lag before a feed override would affect path
[03:08:36] <les_w> yes
[03:08:47] <petev> would that be so bad?
[03:09:03] <les_w> no not really
[03:09:04] <fenn> (i agree but) how do you know that you are able to finish fitting the spline before the machine gets there?
[03:09:30] <fenn> like say you have 3 parts of a program, a line, a curve, and another curve
[03:09:39] <fenn> you are on the line, and hit feed override
[03:09:39] <petev> u need to take some worst case data, maybe Q depth is adaptive
[03:09:57] <fenn> the program re-fits the rest of the line and the first curve, and so you happily machine the first curve
[03:10:09] <fenn> but it's not done re-fitting the second curve and good lord what then??
[03:10:23] <petev> fenn: I don't want to re-fit any curves
[03:10:36] <petev> just generate new ones taking into account the new feed rate
[03:10:49] <petev> anything already generated runs as generated
[03:10:59] <jmkasunich> fenn: putting re-fitted splines into the queue is very bad
[03:11:02] <fenn> what do you generate the new ones from?
[03:11:14] <jmkasunich> you are cruising along at 100% feedrate
[03:11:17] <petev> from the lines/arcs/current feed rate
[03:11:33] <jmkasunich> the next 4 seconds (or whatever) are in the queue
[03:11:36] <fenn> petev: that is what we are calling fitting a spline
[03:11:38] <jmkasunich> you slow to 50% feeedrate
[03:11:43] <les_w> BTW segmentque (when it worked) had as much as a 30 second delay to feed override commands
[03:12:01] <jmkasunich> the 4 seconds in the queue now take 8, but run at the same "roundness" they had before
[03:12:07] <petev> fenn: yes, fit new splines with new params, but don't change ones that are already fit
[03:12:20] <jmkasunich> meanwhile, you are queueing up more splines that are tighter, because of the lower feedrate
[03:12:33] <jmkasunich> you get say 10 seconds of those in the queue
[03:12:44] <jmkasunich> and then that annoying user turns the FO back up to 100%
[03:13:06] <petev> jmk: exactly
[03:13:06] <jmkasunich> what is gonna happen when those splines you fit for 50% hit the TP that is now running at 100% again!
[03:13:23] <jmkasunich> trust us when we tell you you don't want to do that
[03:13:28] <fenn> jmk that's why i said only allow rt feed override in the down direction
[03:13:38] <les_w> Well, lowering feed by time scaling is not time optimal. But is that bad? you lowered it because you screwed up anyway right?
[03:13:46] <fenn> and wait until it can finish fitting the new splines for up direction
[03:14:03] <petev> fenn, you can't wait
[03:14:10] <fenn> petev: why not?
[03:14:16] <petev> you don't want dwell marks and stutter all over the place
[03:14:22] <fenn> petev: use the old value of feed override
[03:14:34] <fenn> and the old splines that were calculated for that value
[03:14:38] <petev> but you need splines to consume
[03:14:45] <fenn> yes use the old ones
[03:14:49] <fenn> and the old feedrate
[03:14:57] <jmkasunich> I think I get it....
[03:15:01] <petev> so then what are u re-fitting if using the old ones?
[03:15:10] <fenn> a spline further down the path
[03:15:24] <jmkasunich> fenn is saying that each spline in the queue should have an associated "speed limit", based on the FO that it was calcualted for
[03:15:28] <petev> isn't that the same as just limiting the size of the Q?
[03:15:44] <fenn> jmkasunich: yeah that sounds good
[03:15:47] <jmkasunich> if you are executing a spline with a 100% limit, you can turn FO down to 50, no prob
[03:15:57] <jmkasunich> but turning it up would be ignored for the moment
[03:16:14] <petev> jmk: that's fine
[03:16:15] <jmkasunich> the user code would start calcing splines with a 150% speed limit and queueing them
[03:16:34] <jmkasunich> once you consume all the queued 100% ones and see the 150% speed limit, you would speed up
[03:16:58] <petev> right, so the old ones aren't re-fit, u just calc new ones with new feed rate
[03:17:04] <jmkasunich> the user would have fits, because he turns the knob and nothing happens, then 2, 5, 20 seconds later the machine speeds up
[03:17:14] <petev> yes
[03:17:24] <jmkasunich> ugly, ugly, ugly
[03:17:32] <les_w> I would submit that with the demonstration of 125 microsecond servo rates and 500 microsecond trajectory rates in an old p3 computer with a lot ofwhat you guys call "cruft" in the code suggests the tp cold be realtime.
[03:18:04] <fenn> les_w: define tp for clarity
[03:18:09] <petev> les_w: I don't think the problem is through put, it's latency
[03:18:29] <petev> what happens when you get that nasty case that has to join 1000 segments?
[03:18:37] <petev> you can't do it in one period
[03:18:48] <petev> average can keep up, but spikes are the killer
[03:19:09] <les_w> tp= a time parametrized set of equations the define where the end effector is supposed to be
[03:19:25] <les_w> NOT pid stuff or anything like that
[03:20:06] <jmkasunich> les: isn't that exactly what a spline is?
[03:20:33] <les_w> if it is parametrized in time, yeah.
[03:20:40] <petev> jmk: I think les want to cal the splines real time each period
[03:20:45] <jmkasunich> Pxyzabc(t)
[03:20:48] <petev> calc
[03:21:09] <les_w> I'm just saying you can...not that you have to.
[03:21:12] <fenn> ok new idea here
[03:21:31] <jmkasunich> t goes from 0.0 to 1.0, then you load a new set of coeffs and reset t to 0.0 again
[03:21:51] <les_w> yes
[03:22:00] <les_w> exactly
[03:22:02] <fenn> calculate the ideal tool-path ahead of time, then readjust the derivatives in real time to match max accel and velocity
[03:22:29] <les_w> yes you can do that too...
[03:22:40] <petev> fenn: what's the ideal tool path? No error? Highest speed?
[03:22:42] <jmkasunich> I think I would like to see Pxyzabcv(t), where v is a derivative...
[03:22:48] <fenn> that way you never have to deal with 1000 little lines in real time
[03:22:52] <les_w> ivory tower type are working on schemes like that
[03:22:56] <fenn> petev: non error
[03:23:10] <fenn> petev: infinite accel
[03:23:27] <jmkasunich> Pv(t) is dP/dT at any given T (vector or tangential velocity)
[03:23:44] <jmkasunich> the TP just uses that to decide the maximum stepsize for t
[03:24:08] <les_w> petev: the machine lasts a long time and is fast. It makes fairly good corners too sometimes.
[03:24:52] <fenn> q: is it possible to represent a square corner with a set of polynomials?
[03:24:59] <jmkasunich> not with 1 set
[03:25:17] <fenn> so the closest you can get would be the "ideal"
[03:25:21] <jmkasunich> one spline leads into the corner and slows to a stop, the next one accels out of the corner
[03:25:46] <jmkasunich> sharp corners are natural transition points from one spline to the next
[03:26:11] <fenn> but if you can only deal with 1 set of coeffs per cycle..
[03:26:32] <fenn> damn i lost it
[03:26:42] <jmkasunich> each spline would cover many cycles of movement - thats the whole point of splines
[03:27:04] <fenn> jmkasunich: how many splines are there total?
[03:27:20] <fenn> 1?
[03:27:20] <jmkasunich> however many it takes to describe the toolpath
[03:27:29] <les_w> Actually. I am seeing the effects of this because I am car shopping. Simpler NURBS implementation made melted candy bar cars. Now Marketing types want slabsldes again. Engineers don't like the high accels of corners though. Do I get a slabside car or a NURB car?
[03:27:31] <petev> fenn, that depends on the arcs/lines/feed from user
[03:27:31] <jmkasunich> one after another for hours possibly
[03:28:03] <fenn> les_w: get a nurb car.. better aerodynamics == better mileage
[03:28:16] <les_w> I agree
[03:28:29] <les_w> caddys and crysler look goofy.
[03:28:40] <les_w> chrysler
[03:28:51] <jmkasunich> jeez, talk about a sharp, unfollowable turn...
[03:29:05] <les_w> haha
[03:29:15] <fenn> jmkasunich: it makes sense.. NURBS were developed by car companies
[03:29:23] <fenn> Bezier worked at renault
[03:29:56] <jmkasunich> nothing to do with solving our issues tho, purely historical trivia
[03:30:03] <les_w> yup
[03:30:04] <fenn> anyway.. since you can't ever realize a perfectly sharp corner, why bother trying to represent one?
[03:30:23] <petev> fenn: you can if you stop on the corner
[03:30:23] <jmkasunich> you CAN realise a perfectly sharp corner
[03:30:27] <jmkasunich> you just need to stop
[03:30:31] <les_w> We need corners sometimes
[03:30:37] <jmkasunich> and for some parts, thats exactly what you want to do
[03:31:11] <fenn> ok so splines are split up by calls to G61 or whatever?
[03:31:17] <fenn> exact stop mode
[03:31:34] <jmkasunich> its very simple really, maximum feedrate = K * radius of curvature...
[03:31:34] <petev> fenn: could be exact path mode
[03:31:35] <les_w> Higher order TPs usually need a corner heuristic so they won'tsmooth them to much
[03:32:31] <petev> maybe we need something between exact path and continuous to guid spline fitting?
[03:32:36] <jmkasunich> you could have a crapload of G1s that specify a smooth contour, then G61 followed by G63, and another crapload of G1s
[03:33:02] <fenn> petev: the way G64 (continuous contour) is supposed to be implemented, is to take a tolerance parameter
[03:33:03] <jmkasunich> it would stop at the end of the first contour, then continue on the second, possibly at a right angle to the first, with a sharp corner
[03:33:09] <les_w> PeteV: yes a lookahead heuristic
[03:33:33] <les_w> some controls look ahaed hundreds of points
[03:33:40] <petev> G64 with tolerance makes sense
[03:33:53] <les_w> hmmm...yeah.
[03:34:01] <fenn> are we going to try to guess what the user intended?
[03:34:25] <les_w> Some controls certainly do
[03:34:39] <les_w> good or bad
[03:34:42] <fenn> sounds like it could be a source of frustration
[03:34:52] <petev> sounds like MS
[03:34:53] <les_w> yes
[03:35:36] <les_w> and the cache in your box...guessing what you are gonna do
[03:35:44] <fenn> i like tolerance specification.. no ambiguity there
[03:35:53] <les_w> me too
[03:36:09] <fenn> if it rounds the corner and you want a sharp corner, explicity tell it to make a sharp corner
[03:36:23] <fenn> or explicitly define the whole path at that tolerance
[03:36:42] <jmkasunich> the G60whatever should allow a tolerance
[03:36:50] <petev> ok, so we can take a tolerance and fit a path
[03:37:04] <les_w> yes...in woodworking we can use the tool to actually emboss a sharp corner...since chip loads are zero
[03:37:07] <petev> the real problem is changin the path RT for feed rate
[03:37:17] <les_w> in metal...a little tougher
[03:37:20] <jmkasunich> you don't change the path
[03:37:27] <jmkasunich> tolerance reigns supreme
[03:37:33] <les_w> curlyque paths
[03:37:39] <jmkasunich> precompute the fastest path that meets the tolerance
[03:37:40] <petev> jmk: I thought this is what les wanted with RT TP?
[03:38:11] <jmkasunich> and tag it with precomputed "speed limits" that meet the accel limits of the machine
[03:38:12] <petev> jmk: ok, so then G code tolerance overrides operator feed overrirde?
[03:38:29] <jmkasunich> in RT, the FO control can adjust from 0 to whatever the local speed limit is
[03:38:46] <jmkasunich> yes, if the curve is tight enough
[03:38:58] <petev> jmk: right, but if operator want to go faster we just ignore it?
[03:39:05] <jmkasunich> if the spline is a 3" diameter circle, FO will let him speed up
[03:39:32] <jmkasunich> if at the end of the circle there is a sharp bend, and tolerance means the spline has a 0.002 radius, it will force him to slow down
[03:39:43] <petev> sure, I guess what I'm asking is which has priority, G code tolerance setting or feed overrid knob?
[03:39:48] <jmkasunich> tolerance
[03:39:51] <fenn> g code ought to have priority
[03:39:55] <petev> ok, that makes it easy
[03:40:21] <petev> then I see no reason for RT spline fitting
[03:40:31] <fenn> now the question is, do cam programs actually use g64?
[03:40:32] <jmkasunich> the idea of attaching a speed limit to the splines also addresses lookahead
[03:40:59] <jmkasunich> in user space, you can run as far ahead as you need, and if you see something that will force you to slow down, you back up, reducing the speed limit as you go
[03:41:38] <fenn> yay someone else gets it
[03:41:41] <petev> fenn: CAM programs usually match the g code path within some errors u specify
[03:41:56] <jmkasunich> IOW, if I know I need to be stopped at X= 3.0, I can calculate my max speed at X=2.9, X=2.8, etc
[03:42:41] <petev> jmk: there has to be a limit to the look ahead
[03:42:42] <fenn> petev: but do they explicity define tolerance of certain features within the path?
[03:42:50] <jmkasunich> not if you do it in userspace
[03:43:26] <petev> fenn: in the programs I have used, you can set arc fitting tolerance and you can do diffs to the model and adjust/add MOPs accordingly
[03:43:42] <fenn> ok
[03:43:47] <jmkasunich> actually, this can be done in threee completely independent steps
[03:44:26] <jmkasunich> first, fit a curve that meets the tolerance - pay no attention to speed at all, just use the largest radius at each corner that meets your tolerance
[03:44:47] <jmkasunich> second, compute the max speed at each point along the path
[03:44:48] <petev> we could compile the g-code to splines completely ahead of time, then we could have infinite look ahead
[03:45:40] <jmkasunich> read the file from the other end, applying accel
[03:45:55] <jmkasunich> and lowering the limit where needed
[03:46:05] <les_w> what we really need to look at is the ratio of feed to spindle rpm...but spindles have huge moments of inertia so we can't effectively servo them to feed
[03:46:07] <jmkasunich> now you have a path, and a speed limit
[03:46:39] <petev> les, we can replace T with spindle speed
[03:46:52] <jmkasunich> in RT, you can do whatever you want with FO, as long as you stay under the speed limit
[03:47:06] <jmkasunich> yes, "whatever you want" includes T = K*S
[03:47:33] <fenn> k*s?
[03:47:41] <jmkasunich> sorry
[03:47:50] <jmkasunich> feed = spindle speed times some constant
[03:47:54] <jmkasunich> chip load
[03:47:56] <fenn> oh
[03:48:00] <les_w> heh withenough complex KW you can do anything I guess
[03:48:11] <les_w> KVA
[03:48:14] <petev> ok, so the read the file from the other end implies we need to do a 2 pass compile on it then?
[03:48:22] <jmkasunich> not really
[03:48:29] <fenn> with enough TLA's you can obfuscate anything
[03:48:34] <petev> jmk: why?
[03:48:42] <jmkasunich> reading the file from the other end is a straightforward way to do it
[03:49:02] <jmkasunich> but there are lots of points where you know the velocity and can work backwards
[03:49:29] <petev> how do u set the velocity without seeing what is coming ahead?
[03:49:32] <jmkasunich> any local minima in the curvature based speed limit is a lookahead point
[03:49:59] <jmkasunich> you work backwards from there, reducing speed limit if needed to ensure that when you reach the minima you aren't over the limit
[03:50:20] <jmkasunich> once you pass the minima, you begin acceleraing again
[03:50:23] <petev> ok, so you look ahead until u see a minima, then work backwards
[03:50:29] <jmkasunich> right
[03:50:35] <petev> so the look ahead is still unbounded
[03:50:40] <jmkasunich> yes
[03:50:44] <jmkasunich> but in user space
[03:50:48] <petev> which means we don't really want to do this on the fly
[03:50:53] <jmkasunich> right
[03:50:59] <petev> we should process the file before we start running it
[03:51:11] <fenn> yep
[03:51:33] <les_w> at most, tp stuff tends to be closed form. 6x6 cramers rule is about the worst. Inverse kinematics can be much harder, sometimes requiring numerical methods, because they do not involve linerar homogenious time invariat differential equations.
[03:51:37] <jmkasunich> in fact, that preprocssing will give some potentially usefill info
[03:51:55] <jmkasunich> you will know the max deviation from the ideal path in space, and the min velocity as determined by curvature
[03:52:06] <jmkasunich> then you can trade off the two if you want, before you cut
[03:52:43] <petev> ok, so I'm already way deep in the new interp, do we want to try and test any of this?
[03:52:59] <jmkasunich> you know, this approach also works with lines and arcs instead of splines
[03:53:20] <jmkasunich> any sharp corner can be replaced by an arc that is tangent to the two lines
[03:53:22] <petev> I can generate some stand alone code to make spline fitting calls of build a syntax tree of the moves
[03:53:26] <jmkasunich> no sharp bends anymore
[03:53:30] <fenn> how do you find the minimum radius of a line?
[03:53:34] <jmkasunich> (choose arc radius from tolerance)
[03:53:45] <SWPadnos_> it doesn't have to be in the interpreter - it's something that can be done at the canon level
[03:53:49] <jmkasunich> straight lines have no radius, and no speed limit
[03:53:52] <jmkasunich> swp: right
[03:54:05] <jmkasunich> arcs have a constant radius, and a constant speed limit
[03:54:05] <petev> swp: no, because we need to process the whole file ahead of time
[03:54:17] <petev> canon makes the machine do stuff
[03:54:20] <SWPadnos_> interp = gcode -> canon translator
[03:54:27] <les_w> Well, a modern tp would be a good good thing. Fixing the error in the current one would be good too, and prhaps faster.
[03:54:37] <jmkasunich> pete: run the whole thing thru the interp, pipe the interp output (line and arc canonicals) to the next stage
[03:54:43] <SWPadnos_> canon = "canonical commands" -> spline / curve fit / motion control info
[03:54:45] <fenn> petev: interp already does a verify, that would be a good place to do it
[03:54:52] <jmkasunich> les_w: easy for you to say, you don't have to fix it
[03:54:57] <petev> swp: that would imply the canon is not running the machine
[03:55:04] <SWPadnos_> correct
[03:55:05] <les_w> jmk: yeah
[03:55:07] <petev> it would need to see all of the interp output to start
[03:55:09] <SWPadnos_> the TP runs the machine
[03:55:17] <petev> fenn: the current interp is a mess
[03:55:20] <jmkasunich> petev: split the interp from the machine for a moment
[03:55:22] <SWPadnos_> or interpolator
[03:55:25] <petev> I already have a much cleaner faster one
[03:55:26] <jmkasunich> in fact, split the two tasks
[03:55:35] <jmkasunich> even today, you can have the interp write to a file
[03:55:37] <fenn> petev: you do? you wrote it?
[03:55:55] <petev> jmk: I was just saying we could use the interp work to start building some test compilers, etc.
[03:56:04] <petev> fenn: yes, using ANTLR
[03:56:14] <jmkasunich> perhaps
[03:56:29] <jmkasunich> but the two things are unrelated
[03:56:43] <petev> jmk: somewhat agreed
[03:56:51] <jmkasunich> interps job is to convert g-code into a path
[03:56:55] <petev> the interp is either g-code or the new spline output
[03:57:24] <jmkasunich> heh, hows this for an analogy:
[03:57:50] <jmkasunich> interp outputs a series of "wide" lines and arcs - width is determined by tolerance
[03:57:53] <petev> jmk: the interp does more than g-code to path
[03:58:00] <jmkasunich> the result is kind of like a road
[03:58:05] <petev> ok
[03:58:18] <fenn> follow the racing line
[03:58:19] <jmkasunich> the fitter chooses the fastest path down that road (as a race car driver would)
[03:58:32] <petev> sure
[03:58:36] <jmkasunich> right - and along that line, it also puts up speed limit signs
[03:58:43] <petev> sure
[03:58:50] <jmkasunich> so you can slow down even before you see the turn
[03:58:52] <fenn> step 3: hook emc up to a ferrari f1 car
[03:59:17] <jmkasunich> then the TP just follows that path in RT (it may or may not reach the speed limit)
[03:59:31] <les_w> The algo breaks down currently at the triangular (no cruise phase) threshold. Some other massive error was helped by just #ifdefing the thing out. It helped, but we also #ifdefed out the bit that was supposed to handle the triangular regime.
[03:59:31] <petev> ok, but to put up the speed limits, we already said we have unbounded look ahead
[03:59:57] <jmkasunich> on straights, the limit may be astronimical, so we obey the F word * override instead
[04:00:06] <petev> yes
[04:00:21] <jmkasunich> yes, but that whole thing can be done a second, a minute, or a week ahead of time
[04:00:51] <petev> jmk: ok, so you agree its a batch job outside of EMC then?
[04:01:05] <fenn> speed limit should always be the F word
[04:01:07] <jmkasunich> that is the apporach I would take
[04:01:11] <fenn> always less than the F word
[04:01:15] <petev> then we would have a new interp that would take the splines
[04:01:29] <jmkasunich> fenn: not true, suppose I want a feedrate override of 200%
[04:01:41] <fenn> oh sorry, F * F override
[04:01:48] <jmkasunich> ok
[04:01:52] <fenn> my point was not just on straights
[04:02:13] <jmkasunich> limit is the lesser of the precomputed limit (which might be astronomical) and F xFO
[04:02:45] <jmkasunich> in a sharp curve, you might not be able to turn up FO, in fact it might slow down below F
[04:02:47] <petev> ok, so how serious are we? Are we doing to implement/test some of these ideas?
[04:02:58] <jmkasunich> it all comes down to time
[04:03:07] <jmkasunich> manhours that is
[04:03:15] <petev> dole out the tasks, should be too bad
[04:03:21] <fenn> does this stuff have to be in C?
[04:03:24] <petev> should not
[04:03:35] <petev> fenn: C or C++ I would think
[04:03:51] <petev> but pseudo code is a big help
[04:03:54] <jmkasunich> I'm more than willing to handle the RT part
[04:04:01] <petev> it doens't take long to turn to real code
[04:04:17] <fenn> that's what i was thinking
[04:04:27] <fenn> stuff like python is more flexible for prototyping code
[04:04:28] <jmkasunich> the fitting gets interesting
[04:04:35] <petev> ok, can we agree to a plan for how a g-code file would turn to machine motion? let's go through user steps
[04:04:35] <jmkasunich> good point
[04:04:50] <jmkasunich> this should be invisible to the user
[04:05:09] <petev> so you want to compile to be automatic, just a delay?
[04:05:16] <jmkasunich> yes
[04:05:17] <fenn> maybe a progress bar would be nice
[04:05:18] <jmkasunich> I think
[04:05:21] <fenn> :P
[04:05:30] <petev> not running the g-code directly will certainly effect the user interface though?
[04:05:39] <jmkasunich> the I think was to my own previous statement
[04:05:51] <fenn> if it takes 10 minutes to do that super complex mold path the user might get angry
[04:06:00] <petev> yeah
[04:06:11] <jmkasunich> I suspect that both pre-processing and in-line processing would have their place
[04:06:18] <petev> that's why it might be nice to have compile as a separate step and a spline interp
[04:06:36] <cradek> you could use the .py->.pyc scheme where a cache of the compiled version is written out
[04:06:36] <fenn> jmkasunich: they are calls to the same functions though in the end
[04:06:52] <jmkasunich> it would be nice to preprocess that mold, not just to save time, but so that you will know that 5 hours into the job it will slow down to go around a sharp corner and burn the tool
[04:06:52] <cradek> then you only have to regenerate it if the source changes
[04:07:40] <petev> cradek: the compiled output would be machine dependant as the speed limits depend on acell
[04:07:46] <jmkasunich> people would want to be able to do it both ways.... precompute and store, as well as just pipe it right on thru
[04:07:46] <cradek> but this is premature optimization. try not to get trapped worrying about stuff like this.
[04:08:16] <jmkasunich> initial work should be all precompute
[04:08:20] <fenn> cradek: how stable is .pyc stuff? does it crash/hang much?
[04:08:37] <cradek> fenn: I'm not sure what you're asking
[04:08:38] <jmkasunich> because we don't care about running a machine, we care about makeing sure we fit within the tolernace, even on pathalogical cases
[04:09:24] <jmkasunich> first pass: smoothest fit to the g-code that stays within tolerance
[04:09:33] <jmkasunich> that is independently verifiable
[04:09:38] <jmkasunich> and not machine dependenet
[04:09:41] <petev> ok, so we need some math here, can les do that?
[04:09:47] <fenn> cradek: i'm not sure what i'm asking either.
[04:09:50] <jmkasunich> second pass, speed limits - that is machine dependent
[04:09:54] <petev> yes
[04:10:17] <les_w> yeah. and psuedocode.
[04:10:29] <petev> les: that would be great
[04:10:37] <jmkasunich> actually, I missed something
[04:10:45] <petev> les:did you get the papers I emailed
[04:10:53] <jmkasunich> zeroth pass - lines and arcs, with width (tolernace)
[04:11:06] <jmkasunich> that comes from the interp (petes or the old one)
[04:11:11] <petev> oh, we fogot something BIG
[04:11:17] <petev> what about cutter comp?
[04:11:26] <jmkasunich> cutter comp is part of pass zero
[04:11:39] <petev> not if you break a cutter during the job
[04:11:42] <jmkasunich> when its still lines and arcs
[04:11:50] <jmkasunich> fuck
[04:11:57] <les_w> I amhoping that emc2 is more organized. I note that Fred Proctor was nor succesful in integrating a new TP in emc1, because of the way it was written.
[04:12:31] <jmkasunich> the RT code in emc2 that calls the TP is almost completely rewritten (by me)
[04:12:41] <les_w> well, good.
[04:12:43] <cradek> most of the code in kinematics/ is copied straight over.
[04:12:44] <jmkasunich> the TP itself is virtually untouched
[04:12:53] <petev> les: and I have a good start on the higher layer interp and canon stuff
[04:12:59] <jmkasunich> yes, the TP and kins APIs are the same
[04:13:17] <jmkasunich> the TP API should probably be revisited for this
[04:13:36] <cradek> for a while I had a pretty good feel for what the TP API is
[04:13:37] <jmkasunich> (traj thread goes away completely for instance
[04:13:50] <cradek> now I guess that's lost somewhere
[04:13:50] <jmkasunich> tpRunCycle and friends
[04:13:51] <petev> ok, so what about cutter comp? this seems like a problem
[04:13:56] <jmkasunich> not well documented
[04:14:08] <jmkasunich> it is, very bad, which is why we're ignoring it :-(
[04:14:13] <jmkasunich> but we can't
[04:14:16] <jmkasunich> so.....
[04:14:38] <fenn> i see two scenarios, 1) you have a rack of tools, and 2) the user replaces the old tool with a new tool, and informs emc2
[04:15:08] <fenn> for 1) you should have already computed cutter comp for all the tools
[04:15:12] <les_w> We should have a modern controller. The speed is there...my fears of running hard RT on a general purpose processor are unfounded I think.
[04:15:20] <petev> fenn: do u agree that you should be able to replace a tool without a re-compile?
[04:15:31] <fenn> and for 2) you can recalculate the path for that tool
[04:15:33] <jmkasunich> les: it isn't a speed issue, it is a boundedness issue
[04:15:42] <petev> jmk: exactly
[04:15:43] <les_w> k
[04:15:50] <fenn> petev: i dont see how you could do that, since you are changing the path
[04:16:08] <petev> fenn: right, that's why this is a problem
[04:16:17] <jmkasunich> lets back up from splines a sec
[04:16:27] <jmkasunich> assume that we have a path that is all lines and arcs
[04:16:29] <petev> I think any operator wants to change a tool and continue immediately
[04:16:34] <jmkasunich> and that all joints are tangent
[04:16:50] <petev> ok
[04:16:53] <jmkasunich> (non-parallel line-to-line joints have an arc inserted to make them tangent)
[04:17:05] <jmkasunich> max V for a line is infinite
[04:17:14] <jmkasunich> max V for an arc is a trivial calculation from radius
[04:17:29] <petev> ok
[04:17:30] <jmkasunich> still need lookahead
[04:17:55] <jmkasunich> when you replace a tool, the radius of all arcs will change by the change in tool diameter
[04:18:13] <jmkasunich> that will raise the max speed thru some arcs and lower it thru others
[04:18:26] <jmkasunich> widens some turns, tightens others
[04:18:33] <cradek> makes some degenerate
[04:18:53] <jmkasunich> dammit
[04:18:56] <les_w> just consider a simple case of an s curve made by two arcs...tangent at the joining point
[04:19:00] <petev> hmm, so then most controllers are statistically correct?
[04:19:07] <les_w> infinite jerk.
[04:19:28] <jmkasunich> les: any thing based on lines and arcs will have inifite jerk
[04:19:29] <petev> les:seems like accel too, if not enough look ahead
[04:19:45] <jmkasunich> yes, still need lookahead
[04:20:08] <petev> then only thing with lines/arcs is calc speed and more likely to get enough look ahead
[04:20:27] <jmkasunich> the lookahead is the killer
[04:20:31] <jmkasunich> it is unbounded
[04:20:54] <petev> yes, so how do commercial controls work? just statistically correct?
[04:20:56] <les_w> yes...it will...that says you need to have a heuristic to detect some points...large jerk values are ok...as lone as they don't happen at every segment and trash the ballscrews.
[04:21:06] <fenn> petev: statistics should have no place in rt code
[04:21:15] <petev> fenn: I agree
[04:22:25] <jmkasunich> we have two problems
[04:22:29] <petev> I don't see a solution other than re-fitting splines and that's unbounded
[04:22:34] <SWPadnos> just to be sure, jerk is the change in acceleration, right?
[04:22:41] <petev> swp: yes
[04:23:02] <les_w> swp: jerk= d accel/dt
[04:23:04] <SWPadnos> ok - and what happens if you limit jerk?
[04:23:14] <SWPadnos> (rhetorical)
[04:23:25] <petev> swp: smooooth motion for one
[04:23:26] <SWPadnos> A = you limit the accel in the next cycle
[04:23:35] <jmkasunich> one: given a path consisting of lines and arcs with a finite width (tolerance), add arcs where non-tangent lines joint, to make them tangent while remaining inside the tolernace
[04:23:45] <les_w> the machine is happy. and you don't make sharp corners.
[04:24:20] <fenn> les_w: you can make sharp corners with limited jerk
[04:24:28] <SWPadnos> look at it from a signal point of view
[04:24:34] <SWPadnos> the G-code asks for some signal
[04:24:34] <jmkasunich> only if you stop at the corner
[04:24:40] <petev> fenn: true, you have to stop on the corner
[04:24:51] <SWPadnos> the machine has a particular charicteristic curve
[04:25:06] <les_w> The machanics of chip load factors in there...
[04:25:13] <les_w> mechanics
[04:25:22] <SWPadnos> you can almost run the path through a FIR filter before passing the motion to the machine
[04:25:39] <fenn> les_w: that's physics for ya.. no cake for les
[04:25:44] <jmkasunich> but you can't tell if the result will still meet tolerance
[04:25:45] <petev> swp: but I think that could violate the max error param from user
[04:26:09] <SWPadnos> jmk - no - you choose the coefficients so that the machine parameters are met
[04:26:11] <les_w> At kmotion and gecko they are doing exactly that
[04:26:22] <SWPadnos> petev, true - there could be trouble there
[04:26:32] <SWPadnos> yes - smoothing a path
[04:26:49] <jmkasunich> swp: it might meet machine limits, but deviate from the programmed path by more than the specificd tolerance
[04:26:50] <SWPadnos> this is a problem in that there are too many variables and not enough constraints
[04:27:04] <fenn> this is what G61/G64 is for
[04:27:05] <jmkasunich> hey, wait a minute....
[04:27:07] <SWPadnos> yes, if all you do is chop off the HF parts
[04:27:21] <jmkasunich> if we just changed a tool, why can't we precompute again?
[04:27:32] <SWPadnos> because it takes too long to do that
[04:27:35] <fenn> bah
[04:27:39] <petev> jmk: because the operator doesn't want to wait
[04:27:47] <fenn> it will take like 2 seconds for 99% of all gcode
[04:27:49] <jmkasunich> depends on how fast the code is
[04:27:59] <les_w> have a look at a low pass filtered square wave....that's what you get with a FIR low pass spatial filter to the path
[04:28:09] <fenn> it is all in ram because linux does filesystem caching
[04:28:21] <jmkasunich> the 45minute restart problem was not a CPU limit, it was an artifical limit caused by task
[04:28:24] <SWPadnos> I have a g-code file that's 66000 lines long, and it's only one pass over a surface - not including hogging out the bulk of the workpiece
[04:28:36] <jmkasunich> SWP: do you recall how long restarts took after you pulled out that throttling?
[04:28:46] <cradek> I suggest you postpone worry about making it fast enough until later
[04:28:51] <SWPadnos> that file would be 3x as large if it were the full toolpath
[04:28:59] <SWPadnos> yeah - faster ;)
[04:29:01] <fenn> agreed with cradek there
[04:29:12] <petev> swp: how long does it take to go through my interp now?
[04:29:15] <SWPadnos> I don't remember, but the current HEAD of both emc1 and emc2 has that code
[04:29:21] <jmkasunich> cradek: if the algorithm is a couple orders of magnitude too slow, maybe we need a new algoritm - it is appropriate to discuss speed here
[04:29:37] <SWPadnos> interp isn't the issue - you're talking about curve fitting a curve with 100k points
[04:29:38] <cradek> jmkasunich: but you're debating waiting for it twice vs. waiting for it once
[04:29:45] <cradek> jmkasunich: that's not orders of magnitude, that's 2
[04:29:51] <petev> swp: sure, but it will give an idea
[04:29:57] <SWPadnos> no it won't
[04:30:08] <petev> I know that the interp is 1/3 the speed if I build an AST and do a two pass
[04:30:13] <jmkasunich> we're assuming that if it takes 10 mins, they will be willing to do that once, then save the processed file
[04:30:17] <SWPadnos> the interp is O(n), curve fitting is probably O(nlogn) or worse
[04:30:23] <jmkasunich> they won't be willing to do that after a tool change
[04:30:32] <cradek> jmkasunich: ok, point taken
[04:30:43] <jmkasunich> swp: you aren't fitting the whole thing
[04:30:54] <jmkasunich> between every two non-tangent lines, you insert an arc
[04:31:05] <jmkasunich> O(n)
[04:31:26] <jmkasunich> some complication due to cases where the arc is longer than the line, and you wind up replacing multiple lines with one or two arcs
[04:31:42] <SWPadnos> yep
[04:31:56] <SWPadnos> or the pathological case of the CAM that spits out 1000 lines instead of a circle
[04:31:57] <jmkasunich> (we're no talking about splines right now)
[04:32:05] <SWPadnos> ok
[04:32:20] <jmkasunich> two possibilties in that case, one, you have 1000 short lines joined by 1000 short arcs
[04:32:37] <jmkasunich> the other, your code is smart enough to fit an arc to the whole thing
[04:32:38] <SWPadnos> two, youhave an O(n^2) curve fit ;)
[04:32:43] <jmkasunich> yes
[04:33:07] <jmkasunich> thats where les's hueristics come it
[04:33:48] <petev> yeah, it's seeming more like meeting a hard user tolerance may not be possible to do deterministiclly in terms of time
[04:34:13] <jmkasunich> anyway, the removal of sharp corners and merging of adjacent short lines into longer arcs is a challange, but one that can be addressed in a stand-alone way
[04:34:14] <SWPadnos> I'm pretty sure that a filtering / smoothing algorithm would provide tolerable toolpaths
[04:34:25] <fenn> swp no!!!
[04:34:29] <jmkasunich> we can mess with those algorithms today, reading and writing to files
[04:34:42] <SWPadnos> fenn, what? ;)
[04:35:34] <fenn> swp you're saying apply the same smoothing filter to all toolpaths?
[04:35:38] <petev> swp: the fir filter does have some merit, the operator can always adjust feed to get better tolerance
[04:35:50] <SWPadnos> fenn, yes
[04:36:04] <jmkasunich> but he has not clue what tolerance he will get until after he runs the part
[04:36:18] <petev> jmk: true, that's what a test part is for
[04:36:25] <fenn> it will turn your 1 mm sized part into a candy bar
[04:36:38] <SWPadnos> you can tell the max deviation by running a simulation
[04:36:44] <SWPadnos> (at high speed)
[04:36:46] <jmkasunich> test part when it is a 80x40x15" block of mold steel?
[04:37:05] <petev> jmk: good point
[04:37:21] <SWPadnos> here's where the integrated solution people have an advantage
[04:37:28] <jmkasunich> I still think the g-code should specify the allowable deviation (tolerance, probably a parameter to the G64 word)
[04:37:42] <cradek> that would sure be nice
[04:37:54] <SWPadnos> that would be cool
[04:37:55] <les_w> hard coding what machine tools can and can't do is really just a form of feedforward
[04:38:13] <jmkasunich> then you either fit a curve that stays inside, OR you do SWPs approach and run it thru a filter, and see if it stays inside
[04:38:24] <SWPadnos> actually - I'd do both
[04:38:32] <petev> swp: how?
[04:38:33] <SWPadnos> try to get an optimal path
[04:38:34] <jmkasunich> but either way, you need that tolerance info
[04:38:54] <SWPadnos> then filter the path, so you limit jerk (and accel and vel)
[04:39:09] <SWPadnos> in case anything was screwed up, or FO was too high, etc)
[04:39:17] <jmkasunich> swp: as soon as you talk about filtering, you are talking about time
[04:39:27] <jmkasunich> I see two passes here, the first is geometry only
[04:39:37] <SWPadnos> filters are constant time, not many instructions
[04:39:38] <jmkasunich> shape + tolerance
[04:39:48] <fenn> i dont understand how filtering is accomplished in software. swp could you elaborate?
[04:39:53] <petev> it might not be too hard to use a combine approach
[04:40:00] <jmkasunich> I don't mean execution time, I mean adding a time dimesnion
[04:40:12] <SWPadnos> you have to calculate coefficients, then you do a convolution of N samples with the N coefficients
[04:40:13] <petev> jmk: yes, but it's bounded
[04:40:22] <jmkasunich> first you have "line", then you have "line at 3.4 inches per second"
[04:40:32] <petev> fenn: it's like a pipeline
[04:40:40] <SWPadnos> so, for a 32-tap filter (that's a pretty honking good filter, by the way), you have an array of 32 coefficients
[04:40:49] <jmkasunich> the tolerance part can be done in space only
[04:40:53] <SWPadnos> you have the last 32 points in the "input strream"
[04:41:08] <jmkasunich> then you use filtering or other methods to see how fast you can go at any given point
[04:41:10] <SWPadnos> you do a vector dot product on them, and the answer is the output
[04:41:23] <fenn> * fenn looks up "convolution"
[04:41:30] <SWPadnos> dot product - sorry
[04:41:56] <SWPadnos> it's not quite a convolution
[04:42:07] <djb_rh> msg nickserv set email [email protected]
[04:42:09] <djb_rh> grr
[04:42:12] <jmkasunich> can we pause a minute and either all agree on something, or not...
[04:42:31] <SWPadnos> a 32-tap filter would be 32 multiplies, 31 additions, and another multiply for scaling. also, some pointer changes and addressing stuff
[04:42:45] <SWPadnos> hopefully
[04:42:49] <fenn> djb_rh: now you will be spammed forever
[04:42:54] <jmkasunich> can we treat the computation of an smooth path using only the ideal path and a spatial tolernace?
[04:42:59] <djb_rh> oh well
[04:43:04] <djb_rh> I have a good spam filter. :)
[04:43:12] <djb_rh> I think I get a couple hundred spam a day anyway
[04:43:26] <jmkasunich> I can't talk or think straight
[04:43:26] <SWPadnos> jmk - I'm not sure I understand the quesstion
[04:43:33] <SWPadnos> phew - it's you ;)
[04:43:38] <jmkasunich> lemme try again
[04:44:36] <jmkasunich> is it possible to compute the smoothest approximation of a path, using only the ideal path and a spatial tolerance?
[04:44:58] <jmkasunich> definition of smoothest: maximize the radius of any bents
[04:45:01] <jmkasunich> bends
[04:45:10] <les_w> convolutions I suspect could be problematic in RT code. Double loop. Lots of time. EMC ises one noe perhaps: SMOOTH_D. It's #ifdefed...not sure it is even used.
[04:45:21] <jmkasunich> there is nothing here about velocity or a time axis, just a line
[04:45:22] <SWPadnos> as long as you define smoothest as "smothest within those constraints", I think so
[04:45:38] <SWPadnos> it's a dot product, not a convolution, so it would be quick
[04:45:52] <jmkasunich> lets not talk about convolution for a moment
[04:46:00] <SWPadnos> replying to les
[04:46:02] <jmkasunich> I know
[04:46:06] <les_w> yeah dot is quick
[04:46:07] <jmkasunich> I was talking to les too
[04:46:12] <SWPadnos> heh
[04:46:24] <jmkasunich> one "simple" and easily verifiable thing
[04:46:43] <jmkasunich> given an ideal path, smooth it as much as possible without exceeding a tolerance
[04:46:53] <jmkasunich> that can be developed and tested in isolation
[04:47:13] <jmkasunich> then you need to figure out how fast you can follow that path
[04:47:19] <jmkasunich> thats where filtering comes in
[04:47:38] <jmkasunich> because now you bring time into the picture
[04:47:49] <jmkasunich> filtering is one way anyway
[04:48:15] <SWPadnos> hmmm - do you want to calculate the longest radius curve or the shortest radius curve?
[04:48:27] <jmkasunich> the longest radius curve
[04:48:29] <petev> longest
[04:48:33] <jmkasunich> that will have the highest speed limit
[04:48:37] <SWPadnos> ok
[04:48:58] <SWPadnos> yes, as long as neither (or both - not sure) segment isn't shorter than the tolerance
[04:49:03] <jmkasunich> its kinda like fenn said, the task is equivalent to computing the racing line thru a track
[04:49:07] <SWPadnos> s/isn't/is/
[04:49:25] <SWPadnos> right - you end up with problems if you have lines shorter than the track width
[04:49:28] <les_w> You know, all this stuff is pretty much worked out as you will see reading papers. Coding is the issue?
[04:49:50] <petev> les: if it's worked out, coding is not an issue
[04:49:55] <SWPadnos> we just need to work it out in programming terms, not mathematical terms ;)
[04:49:59] <fenn> les it would take as long to read that 150 page paper as coding would
[04:50:10] <les_w> heh
[04:50:16] <jmkasunich> longer in my case, I can't read math notation
[04:50:27] <cradek> what ever happened to the work done by that student?
[04:50:40] <jmkasunich> SWP: regarding the short lines thing
[04:50:47] <SWPadnos> ya
[04:50:48] <cradek> recently
[04:50:54] <jmkasunich> imagine drawing with a fat pen in a plotter
[04:51:01] <les_w> I had him visit here chris.
[04:51:06] <jmkasunich> you can plot lines that are shorter that the pen diameter
[04:51:14] <jmkasunich> when you are done, there is a fat line
[04:51:24] <SWPadnos> yes - a short line is smaller than the smallest dot, so you can't resolve any motion out of it
[04:51:27] <jmkasunich> inside which you would like to lay a smooth one
[04:51:39] <SWPadnos> the ideal path for a "short line" is no motion
[04:51:41] <jmkasunich> the fat pen diameter is the tolerance band
[04:51:45] <les_w> big problems integrating it to the emc coding style.
[04:52:09] <jmkasunich> swp: ? no motion?
[04:52:13] <SWPadnos> but you can't ignore the fact that the motion should have happened
[04:52:24] <fenn> swp yes you can
[04:52:29] <SWPadnos> yes - PD / PU - that's the best thing with a fat pen and a short line
[04:52:33] <jmkasunich> youre the one that said no motion is ideal
[04:52:50] <jmkasunich> were talking contionuous paths here
[04:52:55] <jmkasunich> no PU PD
[04:53:04] <jmkasunich> line, line, line, line,
[04:53:06] <SWPadnos> I know - just using the same metaphor as you
[04:53:23] <SWPadnos> or is that allegory?
[04:53:43] <jmkasunich> suppose I draw a shakey line with fine point pencil, and another with a fat marker
[04:53:49] <fenn> a zig zag
[04:54:04] <jmkasunich> I probably can draw a smooth curve that stays entirely inside the black marker line, but still has soft bends
[04:54:17] <SWPadnos> yes
[04:54:22] <petev> swp: were u on the debate team? ;-) jmk is just trying to define the error band
[04:54:42] <jmkasunich> that is the algorithim I'm talking about - how to generate that smooth line
[04:54:50] <SWPadnos> I know that - I'm trying to figure out if there are any cases where you *can't* calculate the optimal path
[04:55:12] <fenn> say you are following a really fine stepover
[04:55:15] <SWPadnos> and I suspect that a very short line segment might be one of those cases
[04:55:20] <petev> I think we're still looking for the algorithm
[04:55:22] <fenn> and the stepover is less than the tolerance
[04:55:22] <les_w> BTW, josh seems genuinely interested in this bit, and spends a lot of time studying TP stuff. But he won't get on here. SO WHO PISSED HIM OFF?
[04:55:34] <SWPadnos> nobody, AFAIK
[04:55:36] <jmkasunich> won't why?
[04:55:42] <SWPadnos> I think he just doesn't
[04:55:43] <jmkasunich> maybe he just doesn't do IRC
[04:55:48] <les_w> ok
[04:55:55] <fenn> les_w: i think he just thinks about it on his shift, and write to the mail list on his lunch break
[04:55:57] <SWPadnos> you could ask him - send an email
[04:56:06] <jmkasunich> or maybe he (like me) wanted to do some coding tonight, instead of talk for hours and go to bed too late again
[04:56:15] <SWPadnos> heh
[04:56:15] <fenn> mwahahaha
[04:56:16] <les_w> haha
[04:56:18] <djb_rh> not to interrupt, but anyone know for sure how much you need to oversize a VFD? I've got a 2HP 3 phase motor on my mill and a 4HP 3 phase to 3 phase VFD that I'd be giving single phase input to instead of three phase.
[04:56:20] <djb_rh> that work?
[04:56:21] <jmkasunich> back to curves
[04:56:33] <SWPadnos> you should match them
[04:56:36] <jmkasunich> that should be find djb
[04:56:44] <fenn> it will explode
[04:56:54] <djb_rh> that's what a couple folks said on rec.crafts.metalworking, but I thought I'd doublecheck here
[04:57:01] <jmkasunich> derate in single phase input needs to be about 33% of so, you have 50%, perfect
[04:57:04] <SWPadnos> so - curves, and curve fitting
[04:57:21] <jmkasunich> 33% or so
[04:57:27] <djb_rh> I'd probably never be pushing the motor, anyway
[04:57:28] <jmkasunich> gawd I can't type
[04:57:44] <jmkasunich> ok, curves
[04:57:55] <fenn> i guess it's the user's responsibility to make sure that tolerance is less than stepover
[04:57:55] <djb_rh> it's a much bigger mill than I need, and won't be doing production stuff much
[04:58:00] <jmkasunich> swp: I don't get what you mean by a very short line
[04:58:05] <petev> djb: many small VFD have over built input stages and don't need derating (usually to 3HP some to 5HP)
[04:58:20] <les_w> manufacturer usually say 2:1 running 3 phase vfd on single
[04:58:32] <les_w> but opinions vary
[04:58:37] <jmkasunich> petev: if there are single phase ratings on the nameplate, use them, if not, derate
[04:58:46] <petev> jmk: yes
[04:58:55] <jmkasunich> you might not have to, but better to derate and not have to, then the reverse
[04:59:08] <fenn> jmk if your fat marker segments overlap, you might miss a spot where they overlap
[04:59:09] <djb_rh> petev: cool.
[04:59:20] <jmkasunich> fenn: you don't care
[04:59:29] <djb_rh> can you use a VFD to drive a single phase motor?
[04:59:31] <djb_rh> ie. single to single?
[04:59:34] <jmkasunich> as long as your path stays in the black, you are good
[04:59:42] <jmkasunich> djb: no
[04:59:52] <djb_rh> okay
[04:59:58] <jmkasunich> (short answer)
[05:00:04] <djb_rh> that's fine
[05:00:06] <djb_rh> don't need a long answer
[05:00:07] <djb_rh> :)
[05:00:09] <jmkasunich> long answer is longer, but still, 95% fo the time, no ;-)
[05:00:14] <djb_rh> np
[05:00:24] <SWPadnos> (still thinking about how the "optimal path" algorithm might break)
[05:00:31] <SWPadnos> not sure yet
[05:00:40] <petev> swp: I'm still wondering what the algorithm is
[05:00:56] <jmkasunich> right, we don't have an algorithm
[05:01:05] <jmkasunich> we have a goal - draw a line that stays in the black
[05:01:14] <fenn> yay
[05:01:20] <jmkasunich> I could do it with a french curve, but telling a program how to do it is harder
[05:01:36] <SWPadnos> well - start at vector A (position and direction), you want to go to vector B
[05:02:00] <SWPadnos> there's a total linear displacement of X, and a directional displacement of B-A (directions)
[05:02:08] <SWPadnos> degrees, I mean
[05:02:10] <petev> this may or may not help, but it's kinda like bending something straight an springy into the error band
[05:02:17] <jmkasunich> yes pete
[05:02:29] <jmkasunich> actually that does help
[05:02:30] <les_w> read papers. the Sonja one is good. Pal spent a couple weeks reading TP papers here. Once he was reading one and the chicken pecked him, interrupting his train of thought.
[05:02:40] <les_w> Paul
[05:02:52] <jmkasunich> what are the key points - the places where the spring hits the side of the error band
[05:03:15] <petev> yes, and probably some parabolic curve
[05:03:21] <jmkasunich> figure out how to identify those points and they become the control points for splines
[05:03:32] <fenn> minima and maxima of curvature
[05:03:45] <jmkasunich> there could be 1 or 1000 segments inbetween those points, and you don't care
[05:04:25] <petev> I have a friend who is good at algorithms, I'll bounce it off him
[05:04:47] <SWPadnos> would you want to allow for arcs that conceptually cause "bulges" at corners?
[05:05:08] <SWPadnos> because those would be the max radius arcs within the error band
[05:05:08] <jmkasunich> for now, I'll accept any path that stays inside the error band
[05:06:10] <les_w> arcs wiil have bulges at the corners i fjerk is limited.
[05:06:32] <SWPadnos> you need to add constraints from the machine though - you can't get meaningful data without a min radius, for example
[05:06:38] <jmkasunich> not neccessarily les
[05:06:45] <les_w> ?
[05:06:51] <jmkasunich> swp: I'm approaching it the other way
[05:07:09] <SWPadnos> jmk: I don't think you can, in a meaningful way
[05:07:15] <jmkasunich> the part drawing (path and tolerance) defines the radius, the machine just says how fast we can make the turn
[05:07:27] <SWPadnos> there is always a zero radius arc that fits the path perfectly
[05:07:54] <jmkasunich> my goal is the largest radius that fits within the tolerance
[05:07:56] <SWPadnos> or a (tolerance) radius arc
[05:07:58] <jmkasunich> zero isnt it
[05:08:07] <les_w> ok, I am thinking of the constraints of a milling operation and chip load
[05:08:22] <jmkasunich> sorry les, two conversations going on at once
[05:08:28] <les_w> 'heh
[05:08:32] <jmkasunich> ok, turn without bulge
[05:08:38] <jmkasunich> running along parallel to Z
[05:09:05] <jmkasunich> begin to increase accel smoothly from zero (limited jerk)
[05:09:11] <jmkasunich> Y accel that is
[05:09:18] <jmkasunich> assume X accel is constant
[05:09:25] <jmkasunich> the path becomes a parabola, right?
[05:09:43] <jmkasunich> fuck I can't type
[05:09:48] <fenn> maybe this is a little late, but i drew a figure of what we're talking about: http://fenn.dyndns.org/pub/emc/screenshots/racingline.png
[05:09:54] <jmkasunich> running parallel to _X_, then accel in Y
[05:09:58] <SWPadnos> heh
[05:10:34] <jmkasunich> yes fenn, a totaly nasty g-cpde program, with a smooth curve that fits the tolerance
[05:10:44] <SWPadnos> fenn, I thikn it should be the opposite - a smooth thick line, with a zig-zag thin kline inside it
[05:10:57] <SWPadnos> (less typos)
[05:10:57] <jmkasunich> SWP, no
[05:11:07] <petev> fenn is correct
[05:11:16] <jmkasunich> the g-code spec'ed the jerky line
[05:11:22] <SWPadnos> ok
[05:11:25] <SWPadnos> got it
[05:11:30] <fenn> you need to make a new smooth fat line inside the shaky fat line
[05:11:32] <jmkasunich> (you could draw a jerky thin line inside, the ideal path)
[05:11:41] <jmkasunich> no, the smooth line isn't fat
[05:11:51] <jmkasunich> the smooth line is the one we want the machine to follow
[05:11:54] <fenn> how do you know where to put the minima and maxima?
[05:12:01] <jmkasunich> because it meets the specs as determined by the drawing
[05:12:18] <jmkasunich> what minima and maxima?
[05:12:41] <fenn> the control points of the spline must be placed so that the spline doesn't touch any white
[05:12:46] <jmkasunich> right
[05:12:54] <jmkasunich> that in a nutshell is the problem
[05:13:07] <SWPadnos> there are no constraints until you take time into account, in two ways
[05:13:09] <les_w> well after midnight...going to hit the sack. Glad to see discussion about tp and path following. It costs us commercial types a lot of time and money, and lays off our workers.
[05:13:30] <SWPadnos> first, there is a amximum number of control points that can be processes per time period
[05:13:41] <jmkasunich> in fact, if we drew that picture with a cad program that supports thick lines, and saved the coords of each short jerky segment, we'd have a test dataset for our algorithm (the algo we don't have yet)
[05:14:04] <SWPadnos> second, there is a pahntom axis, that you have to linit the first, second, third, and fourth derivatives of
[05:14:11] <SWPadnos> (the pahntom being time)
[05:14:34] <petev> swp: u are over complicating things
[05:14:36] <SWPadnos> without the time axis in there, you won't get meaningful data
[05:14:42] <petev> second pass is time and machine
[05:14:48] <petev> first pass is path
[05:14:53] <jmkasunich> swp: do you agree that the thin line in fenns pic is a legal path?
[05:15:04] <SWPadnos> yes
[05:15:12] <jmkasunich> and that it can be followed faster than the original path?
[05:15:16] <SWPadnos> but is it ideal? -I don't know
[05:15:24] <SWPadnos> it is smoother, yes
[05:15:28] <jmkasunich> no, you don't know that it is ideal
[05:15:36] <petev> swp: ideal is largest radius, just like bending a peice of board
[05:15:39] <jmkasunich> and maybe we don't even need ideal, just good
[05:15:50] <petev> it don't bend tight in some spots and loose in others
[05:15:51] <SWPadnos> but longest radius for how many segments?
[05:15:53] <petev> it bends evenly
[05:15:57] <fenn> petev: actually ideal isn't a large radius, it's a parabola
[05:16:16] <petev> fenn: I mean rargest radius at any point
[05:16:21] <jmkasunich> well, bending a board or thing springy metal strip is the original definition of spline.....
[05:16:27] <jmkasunich> s/thing/thin
[05:16:32] <SWPadnos> and can you vary the entry vector (and exit vector)?
[05:17:01] <jmkasunich> this is assumed to be part of a longer one (either that, or entry and exit is stationary)
[05:17:21] <jmkasunich> IOW, exact stop, followed by a contouring run, followed by a stop
[05:17:30] <SWPadnos> unless you fit the entire curve (the whole program), you will have discontinuities at the junctions of fit curves
[05:17:48] <SWPadnos> unless you constrict the entry and exit vectors
[05:18:00] <SWPadnos> (ie, don't allow changes to them)
[05:18:17] <jmkasunich> it depends on the geometry
[05:18:40] <SWPadnos> If that's true (I'm certainly not a great expert), then the initial conditions in fenn's diagram aren't usable
[05:18:55] <SWPadnos> yes - I should say that you *may* have discontinuities
[05:19:23] <SWPadnos> the entry vector would have to be along the first specified segmend
[05:19:27] <SWPadnos> segment
[05:19:34] <jmkasunich> brainstorming... suppose instead of black ink on paper, fenns black is a milled out groove
[05:19:36] <petev> swp: think about the bent board
[05:19:45] <jmkasunich> toss a string in the groove, and pull it tight
[05:19:57] <fenn> maybe we should read some books on race car driving :)
[05:20:02] <petev> I don't care how long it is, if I stick it inside the error band, it will find 1 solution
[05:20:15] <jmkasunich> eys
[05:20:16] <jmkasunich> yes
[05:20:25] <SWPadnos> I have no problem visualizing the problem - I'm trying to solve the problem ;)
[05:20:44] <petev> make the board longer, and the solution may change for overlapping parts, but that's ok
[05:21:01] <jmkasunich> same with the string - since it isn't springy, it doesn't find the radii for you, but it does tell you (I think) where your spline will hit the walls
[05:21:13] <SWPadnos> and the way I do that is to come up with things that I think won't work, and eother fix them, or throw out the method and look for a new one
[05:21:23] <petev> jmk: I'm not sure about that
[05:21:29] <jmkasunich> and I think the string part might be a first step
[05:21:50] <SWPadnos> what you want is a spring steel wire - it acts like the string *and* the board ;)
[05:22:00] <jmkasunich> yeah
[05:22:20] <jmkasunich> I'm just thinking that the math for the string is simpler, it might be a first pass, then use use the wire to get the curves right
[05:22:51] <SWPadnos> one other thing about this idea - there's no need to smooth things beyond a certain point
[05:22:58] <petev> jmk: the string may touch in places where a board won't
[05:23:08] <SWPadnos> if the machine can follow the path as is, then you shouldn't eliminate all the features for it
[05:23:22] <SWPadnos> that could make some operators angry
[05:23:29] <jmkasunich> swp: true
[05:23:44] <SWPadnos> the curve fit has to take into account the machine capabilities
[05:23:52] <SWPadnos> somehow
[05:23:56] <petev> swp: if the operator has the error band that wide, the features are bogus
[05:24:12] <jmkasunich> damn, I was hoping to decompose the problem into "find path", then "find speed limit along path"
[05:24:16] <SWPadnos> no - if the planner calculates everything for maximum speed, that's bogus
[05:24:45] <petev> swp: no, if small features are important, the error band must reflect that
[05:24:45] <SWPadnos> if I program a complex path at F1, and the machine can do it, the planner shouldn't smooth it for F1000
[05:24:57] <petev> or the part will still be in tolerance without the features
[05:25:15] <jmkasunich> swp: on the other hand, if you calculate a path based at F1, and then do feedrate override up to F10, youre gonna be in trouble
[05:25:25] <SWPadnos> true - but I know that
[05:25:36] <SWPadnos> unless the machine can handle F10 as well
[05:25:36] <petev> jmk: I think the approach is valid
[05:26:00] <petev> you should always run the fasted path within the error band
[05:26:05] <petev> fastest
[05:26:30] <SWPadnos> I disagree - I think you should run the closest path that meets the minimum speed
[05:26:32] <jmkasunich> for a moment you had me agreeing SWP, but I think we should compute the fastest path the meets the part specs
[05:26:44] <jmkasunich> that extra speed becomes the feedrate overide headroom
[05:26:48] <petev> jmk: exactly
[05:26:57] <SWPadnos> but if you can calculate paths, then what the heck - give the operator the option
[05:27:32] <jmkasunich> I'm assuming that you can't calc the path in bounded time (lookahead and such)
[05:27:40] <petev> right
[05:27:42] <SWPadnos> not the full path
[05:27:51] <jmkasunich> so you need to go into RT with a path that will allow whatever FO the operator wants to apply
[05:28:10] <jmkasunich> actually, you can calculate the full path in bounded time
[05:28:39] <jmkasunich> but you might not be able to calcualte the first 1% of it in 1% of that time, and thats where the RT failure happens
[05:28:59] <petev> right, it's the average/peak thing
[05:29:13] <SWPadnos> why would you calculate a path that allows the max feed override rather than one that meets the F spec, and follows the path closely?
[05:29:27] <SWPadnos> you can always pass a "speed limit for this segment" number to the RT code
[05:29:40] <jmkasunich> if you are willing to limit FO to 100%, then you can do that
[05:30:01] <petev> swp: if the machine can make the part within tolerance faster, it should
[05:30:13] <jmkasunich> petev: not true
[05:30:14] <petev> the part tolerance drives the path
[05:30:14] <SWPadnos> I'm saying that the path is more important than the feed override
[05:30:36] <petev> jmk: why not? Use a carbide cuttter, run higer speed, make the part faster
[05:30:37] <jmkasunich> if the F word in the g-code says 10ipm, and the parts is straight so there is no limit, you cant go at 100ipm
[05:30:44] <SWPadnos> and the machine will have other limits (spindle horsepower, material type, tool type, etc) that limit the speed
[05:30:45] <petev> why would I want to take longer to make a part?
[05:30:54] <petev> jmk: agreed
[05:30:57] <SWPadnos> because you can't remove enough metal
[05:30:59] <jmkasunich> that 10ipm was chosen based on the limits of the cutter ahd HP
[05:31:17] <petev> what I mean is the machine shouldn't limit itself to a path that will only run at 100% F
[05:31:17] <jmkasunich> heh,
[05:31:23] <SWPadnos> cutting Inconel with a 1HP spindle - you'll be limiting your feedrate
[05:31:34] <jmkasunich> what it comes down to is who do you trust
[05:31:53] <SWPadnos> realize that most machines cut at significantly lower than max speed
[05:31:58] <jmkasunich> SWP trusts the F word, and says follow the path as closely as possible at F speed
[05:32:17] <SWPadnos> I always trust the F word ;)
[05:32:18] <jmkasunich> we're trying to give the operator latitude to go faster, maybe much faster
[05:32:22] <petev> I like to trust the skilled operator with the feed override
[05:32:33] <jmkasunich> and that is the source of the dispute
[05:32:35] <SWPadnos> I think that's great, but nt at the expense of the path
[05:32:41] <SWPadnos> no!
[05:32:50] <petev> no, the path will still be within error band
[05:32:53] <SWPadnos> well - maybe for a *skilled* operator
[05:33:02] <petev> if that's not good enough, change the error band
[05:33:19] <jmkasunich> you both have valid points
[05:33:27] <SWPadnos> but I can guarantee you that the engineer that did the design and CAM work knows a hell of a lot more than the operator who wants to go home early on a Friday night
[05:33:35] <jmkasunich> but many programs won't neccessarily have good errorbands pete
[05:33:49] <jmkasunich> how about this:
[05:33:50] <petev> jmk: why?
[05:33:56] <SWPadnos> not a single program has error band now, since it isn't part f the language yet
[05:34:00] <jmkasunich> right
[05:34:00] <petev> those are set by the engineer that ran the CAM
[05:34:02] <SWPadnos> of
[05:34:30] <SWPadnos> ok - in that case, the path provided is already at the tolerance limit, and emc can't increase that any more
[05:34:50] <petev> swp: no, u misunderstand
[05:35:04] <petev> I mean the engineer can apply the error band limit in the g-code
[05:35:04] <jmkasunich> how about this: the machine has an ini param that sets the max feed override... assume that is set at 150, and the F word is 3, compute a path at 4.5
[05:35:11] <petev> that can't be violated by the op
[05:35:30] <petev> but the op has the ability to control machining within the error limits
[05:35:41] <SWPadnos> G code has no error limits
[05:35:48] <jmkasunich> IOW, the guy who sets the max override to 150 is determining how much latitude the operator has
[05:35:54] <petev> If you use todays CAM pakages, you get the g-code path within some limit
[05:36:06] <SWPadnos> jmk - one sec
[05:36:15] <petev> it better be less than the part tolerance, because it doesn't take into account path error on the machine
[05:36:24] <jmkasunich> pete - there is another point: the cam package may already be approximating the ideal path
[05:36:33] <petev> we are talking about G64 <tolerance>
[05:36:36] <SWPadnos> yes - that's it in a nutshell
[05:36:48] <petev> jmk: that's what I'm saying
[05:37:02] <petev> that's why in CAM you have to go tighter than the print
[05:37:06] <jmkasunich> so you are stacking tolerances
[05:37:11] <petev> yes
[05:37:20] <petev> and now u have to guess at the machine error
[05:37:31] <petev> with G64 <tol> u don't
[05:37:35] <jmkasunich> hell, the cam might be aproximating a spline with lines, and we're going and fitting a spline to the lines
[05:37:42] <SWPadnos> ther eis no G64 <tolerance> now, right?
[05:37:45] <jmkasunich> and both stages introdude error
[05:37:52] <petev> swp: correct, we'll add it
[05:38:11] <jmkasunich> swp: G64 <tol> is a given for this whole thing to work
[05:38:13] <SWPadnos> and what will you do with the 17 million G-code programs that are already out there?
[05:38:41] <petev> have a default value from INI, etc.
[05:38:51] <jmkasunich> well, by default the tolerance will be zero, so they'll do exact path mode
[05:39:00] <SWPadnos> there are two (or three) tolerances right now, and they all stack
[05:39:06] <petev> sure, u could do that
[05:39:21] <jmkasunich> meaning tangent args and lines will be followed exactly and continuiously, non-tangent lines will force stops
[05:39:26] <petev> swp: u can bound the tol in CAM, why not in the machine?
[05:39:26] <SWPadnos> first is the CAM, second is emc FERROR, (and possibly servo / encoder error)
[05:39:50] <SWPadnos> there's also machine tolerance, but there's not much thta can be done about that
[05:39:58] <CIA-12> 03paul_c * 10emc2-auto/wiki/ (21 files in 13 dirs): "Auto update wiki from a cron job. Thu Dec 8 05:30:01 GMT 2005 "
[05:40:09] <jmkasunich> swp: assume for a moment there is NO tolerance
[05:40:19] <SWPadnos> what a terrible world ;)
[05:40:32] <jmkasunich> would you simply say I'm gonna fit the best path I can follow at the F rate?
[05:40:40] <jmkasunich> even if it causes a huge deviation?
[05:40:51] <jmkasunich> or are you gonna slow down below the F rate on tight curves
[05:40:57] <SWPadnos> I'm not sure what the spec says now
[05:41:24] <jmkasunich> the whole concept of the speed limit thing is that it would slow down as needed to follow the path
[05:41:30] <SWPadnos> it depends on continuous or exact path mode
[05:41:37] <fenn> the spec says follow the best path you can at F rate if G64 is on
[05:41:37] <jmkasunich> but the path would be as smooth as possible, to limit the slowdown
[05:41:42] <SWPadnos> you're talking about continuous
[05:42:27] <jmkasunich> me or fenn?
[05:42:30] <SWPadnos> ok, in continuous mode, I would round corners as needed to maintain speed
[05:42:32] <SWPadnos> you
[05:42:41] <SWPadnos> I should say "we're"
[05:42:43] <petev> fenn: then there is no F > 100% * FO
[05:43:21] <jmkasunich> so you would round corners a huge amount if thats what it takes to maintain speed (the melted candy bar)?
[05:43:32] <SWPadnos> what you're talking about is "pre-rounding" the corners, assuming the maximum possible rate
[05:43:42] <SWPadnos> yes, that's what continuous mode does
[05:43:53] <jmkasunich> pre-rounding as much as I can while staying in tolerance
[05:44:03] <jmkasunich> and slowing down when I can't stay in tolerance
[05:44:10] <petev> then continuous mode isn't that usefull
[05:44:13] <jmkasunich> we're talking about two different modes
[05:44:19] <SWPadnos> so you're making a new mode "closest and fastest approximation of continuous and exact path mode" ;)
[05:44:41] <SWPadnos> "within tolerance"
[05:44:45] <petev> swp: continuous within error band
[05:45:21] <jmkasunich> this is why these things are so tough
[05:45:25] <SWPadnos> heh
[05:45:32] <SWPadnos> too many modes spoil the software
[05:45:40] <jmkasunich> swp is assuming that every jiggle in the g-code is desired
[05:45:51] <petev> yeah, we can't even agree on what path we want, let alone how to acheive it
[05:46:07] <jmkasunich> I'm assuming that many of them are because the CAM is aproximating a smooth curve with line segments
[05:46:23] <Jymmm> jmkasunich ?
[05:46:24] <fenn> G101 the "do what I mean" mode
[05:46:36] <petev> most decent CAM will do arc fitting, I always use it
[05:46:45] <Jymmm> G102:Do what I'm thinking mode
[05:46:48] <jmkasunich> and we are both correct in some cases, horribly wrong in others
[05:46:50] <SWPadnos> hopefully - it would be annoying for someone to try CNC knurling at 100 IPM
[05:47:25] <jmkasunich> swp: which is the case with your 66000 line g-code file
[05:47:39] <jmkasunich> I bet most of those lines are approximating some smooth curve
[05:47:55] <Jymmm> you cant' use an arc?
[05:48:00] <Jymmm> directly?
[05:48:03] <fenn> this is yet another reason why CAM should be integrated with the controller
[05:48:16] <jmkasunich> Jymmm: maybe the curve is an elippse or a parabola
[05:48:18] <SWPadnos> the part is basically the front of the Y bearing bracket on a Bridgeport
[05:48:30] <SWPadnos> just the finish pass though
[05:48:36] <jmkasunich> 3d smooth curves then
[05:48:36] <SWPadnos> with a very fine stepover
[05:48:50] <jmkasunich> ok, 2d smooth curves
[05:48:51] <SWPadnos> mostly flat, but some of a circular sweep
[05:48:58] <Jymmm> jmkasunich: NM me... I've stll baffled at 5 different ways to represent a curve
[05:49:06] <SWPadnos> where the dial goes
[05:49:42] <jmkasunich> I think I can visualise that
[05:50:18] <SWPadnos> just a hump where the bearing would go
[05:50:31] <SWPadnos> swept into a circle
[05:51:13] <jmkasunich> centroid are assholes
[05:51:22] <SWPadnos> the CNC people?
[05:51:29] <jmkasunich> "please upgrade your browser to view this site"
[05:51:32] <SWPadnos> heh
[05:51:32] <jmkasunich> go pound salt!
[05:51:51] <jmkasunich> (google images search for bridgeport Y axis
[05:52:02] <SWPadnos> interesting - centroidcnc works for me, unsing Mozilla
[05:52:32] <jmkasunich> it is some kind of javascript they use for site navigation
[05:52:37] <SWPadnos> ah
[05:52:46] <jmkasunich> I've got that kind of stuff disabled
[05:53:04] <jmkasunich> but to tell people to "go away" isn't very bright
[05:53:33] <SWPadnos> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=7569464462
[05:53:38] <jmkasunich> http://www.surplusmachinetool.com/images/Bridgeport-251547-ways.JPG
[05:53:40] <SWPadnos> but the Y bracket, not X
[05:53:49] <SWPadnos> yep - that one
[05:54:01] <SWPadnos> mostly flat, with a circular hump and hole in the middle
[05:54:15] <SWPadnos> the finish pass for that is 1.6M
[05:54:19] <SWPadnos> 66k lines
[05:54:24] <jmkasunich> and you are machining it going back and forth?
[05:54:42] <SWPadnos> yes
[05:54:43] <jmkasunich> why not around in circles
[05:55:04] <SWPadnos> not like that would matter much - there would be a zillion circles
[05:55:09] <jmkasunich> I guess that would be more vulnerable to backlash
[05:55:26] <SWPadnos> note that a cross section has a slope fromthe bearing hoole
[05:55:31] <jmkasunich> not as many
[05:55:33] <jmkasunich> yes
[05:55:51] <SWPadnos> nonetheless - this is a valid approach, and one used by a lot of people
[05:55:57] <jmkasunich> but assuming it is rotationally symmetric, there is only one circle per stepover
[05:56:00] <SWPadnos> the X r Y scan, as well as "waterline"
[05:56:05] <SWPadnos> x + y
[05:56:09] <jmkasunich> yes, the circle approach wouldn;t work for the X bracket
[05:56:15] <petev> ok, let's not question the choice of MOPs let's talk about what we expect from the machine
[05:56:16] <SWPadnos> it's not symmetric
[05:56:38] <jmkasunich> right, way off topic again
[05:56:43] <jmkasunich> I have to crash
[05:56:50] <SWPadnos> contagious
[05:57:01] <jmkasunich> I really intended to code some tonight, and go to bed by 11pm
[05:57:05] <petev> ok, let's talk more tomorrow
[05:57:09] <SWPadnos> strike two ;)
[05:57:17] <jmkasunich> I wasn't gonna start IRC, because I knew this would happen
[05:57:19] <petev> yeah, we opened another can of worms
[05:57:22] <jmkasunich> It's all lermans fault
[05:57:23] <SWPadnos> no - jmk will code tomorrow, and we should leave him alone
[05:57:42] <SWPadnos> incidentally, was there a tag made before that merge?
[05:57:44] <petev> I was going to add the XML config stuff tonight
[05:58:07] <jmkasunich> I don't know
[05:58:09] <petev> was going to get some feedback on XML parser libs
[05:58:13] <jmkasunich> its not to late tho
[05:58:31] <petev> I can probably load a few packages and get something done
[05:58:38] <SWPadnos> I suppose you can always ask for -D "just before lerman"
[05:58:43] <petev> have u guys used kxmledit?
[05:58:46] <jmkasunich> can do a checkout of yesterday then apply the tag (I think, woule have to read the book)
[05:58:48] <SWPadnos> nope
[05:58:55] <petev> it's for KDE
[05:59:04] <jmkasunich> that way the tag would be there later on
[05:59:07] <petev> I loaded the deb and it integrated nicely
[05:59:16] <jmkasunich> nope pete, never did anything with XML
[05:59:22] <SWPadnos> you'll have to put in some effort on the DTSD I think
[05:59:27] <petev> I was playing with some config stuff for the interp
[05:59:28] <SWPadnos> DTD
[05:59:38] <jmkasunich> 1am, I'm turning into a pumpkin
[05:59:44] <petev> yeah, was making a sample file, then DTD to follow
[05:59:49] <petev> ok, gnight
[05:59:50] <SWPadnos> see ya Cinderella
[06:00:00] <petev> dang he's quick
[06:00:11] <SWPadnos> my bet is that the editors will want a good DTD
[06:00:15] <SWPadnos> I think he's tired
[06:00:22] <SWPadnos> so they can validate
[06:00:25] <petev> I don't think this one uses a DTD
[06:00:33] <petev> that was my first concern
[06:00:35] <SWPadnos> (rather than just hilight)
[06:00:52] <SWPadnos> I should fiddle with it before saying anything
[06:00:59] <petev> it has a tree view and shows element attributes and text in panes to the right
[06:01:17] <petev> it may not be the best, I just tried it because of the KDE
[06:01:42] <SWPadnos> the question is - how does it know what attributes / elements are valid at any given point?
[06:01:46] <petev> I also saw some C++ xml stuff for the gnome xmllib
[06:02:03] <petev> I think it's just an editor, it doesn't check things
[06:02:04] <SWPadnos> there are a lot of libraries around - I looked into it a bit around Fest time
[06:02:07] <SWPadnos> ok
[06:02:14] <petev> it would be nice to have one that did look at the DTD
[06:02:23] <petev> which libs did you like?
[06:02:36] <petev> I started with what was available as a deb
[06:02:50] <SWPadnos> I don't remember anything other than the fact that I looked ;)
[06:02:57] <petev> that's no help
[06:03:02] <SWPadnos> sorry
[06:03:11] <petev> if you search xml on the deb packages will u remember?
[06:03:21] <SWPadnos> probably, but not at this time of night
[06:03:43] <SWPadnos> I don't think I got to anyu coding though - the resistance to XML was staggering
[06:03:47] <petev> ok, let me know tomorrow, I'll look at editors and hold off on coding
[06:04:07] <petev> yeah, I'm not worried about it, I'll provide an editor and code
[06:04:13] <SWPadnos> ok - look into editors that can validate against a DTD
[06:04:19] <petev> if people don't like it, they don't have to use it
[06:04:28] <petev> yes, DTD is important
[06:04:36] <SWPadnos> well - if the config files are XML, then they have to use *something*
[06:04:53] <SWPadnos> and a simple editor isn't really viable with xml
[06:04:55] <petev> right, and a good editor is better than what we have now
[06:05:01] <SWPadnos> true
[06:05:07] <petev> try kxmledit, it's not bad
[06:05:11] <petev> just to error checking
[06:05:12] <SWPadnos> I will
[06:05:41] <fenn> you are talking about this?: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?EmcConfig
[06:06:07] <petev> yes, that's xml
[06:06:16] <fenn> notice the last two lines
[06:06:22] <fenn> (my comments)
[06:06:50] <SWPadnos> (it's only one line here ;) )
[06:06:55] <petev> fenn: I don't follow
[06:07:02] <petev> u just use an XML editor
[06:07:06] <SWPadnos> the two editors / viewers
[06:07:09] <petev> even the raw XML is readable
[06:07:17] <SWPadnos> not by humans ;)
[06:07:20] <fenn> yeah but its not fun to edit
[06:07:31] <petev> that's why u use the GUI editor
[06:07:36] <fenn> look at slip or yaml configs.. it's practically what you would write anyway
[06:07:38] <petev> it gives u a tree view
[06:07:44] <petev> ok
[06:07:44] <fenn> but some people will always want to edit the config files
[06:07:54] <petev> with a text editor?
[06:07:57] <fenn> it is "the debian way" or some such
[06:08:00] <fenn> petev: yes
[06:08:04] <petev> why can't they use an xml editor?
[06:08:06] <SWPadnos> the fact that it's encoded as ASCII doesn't really matter - it's viewable, but not really understandable
[06:08:10] <fenn> because they are on a terminal
[06:08:33] <petev> ok, I don't get it
[06:08:40] <petev> who still has a terminal?
[06:08:48] <petev> this is all PC based with GUIs
[06:09:02] <fenn> i still use a terminal for like 90% of what i do
[06:09:10] <petev> what?
[06:09:11] <fenn> xterm
[06:09:26] <petev> ok, so type kxmledit &
[06:09:29] <SWPadnos> you can still run emc on a machine without X
[06:09:40] <fenn> yeah i need to get keystick into emc2
[06:09:46] <SWPadnos> that's what keystick is for
[06:11:33] <fenn> plus diagnosing .ini files over mailing lists wouldn't be fun it they're in raw xml
[06:12:08] <petev> fenn: what's your top choice?
[06:12:35] <fenn> honestly i havent looked into it that much
[06:12:54] <petev> well I need to code something ASAP
[06:13:00] <petev> I need to make a decision soon
[06:13:10] <petev> I was going to code tonight, but...
[06:13:17] <fenn> if you are already familiar with xml you should use SLiP
[06:13:38] <fenn> since it is just a different way of representing xml, really
[06:13:44] <petev> u got a link for SLiP?
[06:13:53] <fenn> http://www.scottsweeney.com/projects/slip/
[06:14:28] <petev> are there deb packages for editors and parser libs?
[06:15:43] <SWPadnos_> well - I've gotta get some sleep as well - night guys
[06:15:47] <SWPadnos_> SWPadnos_ is now known as SWP_Away
[06:15:48] <petev> gnight
[06:16:35] <petev> fenn: looks like the main diff is no closing tags and the tags are simpler
[06:17:49] <fenn> what are you writing anyway?
[06:17:53] <petev> I don't see any deb packages for SLiP
[06:18:09] <petev> Im' making new versions of task, interp, and canon
[06:18:38] <fenn> I really doubt there are deb packages for slip
[06:18:48] <petev> there are a few debs for YAML, but mostly perl based and no editors
[06:19:12] <fenn> i thought slip would provide a filter executable that took slip in and outputs XML
[06:19:16] <petev> that will be a problem as it should be easy for people to get the sw on their system
[06:19:17] <fenn> but not so sure anymore
[06:19:36] <fenn> you can just copy the code into emc
[06:20:01] <petev> on of my goals in this re-write is to use externally maintained packages wherever possible
[06:20:13] <petev> I want to reduce the EMC code base to machine related stuff
[06:20:17] <petev> not NML swill
[06:20:32] <fenn> ok
[06:20:34] <petev> so far I used ANTR
[06:20:38] <fenn> i feel that sentiment
[06:20:50] <petev> was thinking XML and RPC next
[06:21:18] <petev> yeah, I looked at what I thought was worht keeping from RCSLIB
[06:21:23] <petev> the pose stuff
[06:21:36] <petev> then I find it's used in like one place of user code in EMC2
[06:21:45] <petev> I look more and the lib is a mess
[06:22:00] <fenn> i was thinking about using orocos code for complex kinematics stuff
[06:22:06] <petev> I wanted to use it in the interp and canon, but I don't want to clean it up first
[06:22:20] <petev> isn't orocos another control package?
[06:22:25] <petev> do they have libs?
[06:22:28] <fenn> it's a robot control package
[06:22:33] <petev> right
[06:22:33] <fenn> unfinished, as usual
[06:22:41] <petev> hmm
[06:22:52] <fenn> but the api's are well written
[06:23:06] <petev> but are there libs?
[06:23:13] <fenn> uh, not sure what you mean
[06:23:19] <petev> if not, then we are just taking their code and will need to maintain it
[06:23:29] <fenn> there is a kinematics and dynamics library
[06:23:41] <petev> lib packages that they maintain and we could just use as a package
[06:23:59] <fenn> http://orocos.org/kinematics.html
[06:24:01] <petev> I don't want to just take other code and put it in the EMC tree
[06:26:00] <petev> how far along is orocos?
[06:27:29] <fenn> i think all the robot arm stuff is done
[06:27:58] <petev> they have a bunch of motion code on their
[06:28:07] <petev> I wonder if we could learn anything from it
[06:33:29] <fenn> too many windows open..
[06:37:06] <fenn> petev: are you talking about using XML-RPC for networked gui's?
[06:37:28] <petev> I wanted to make the task interface RPC
[06:37:47] <petev> I hadn't given much thought to getting config data to remote GUIs
[06:38:02] <petev> I thought anything a GUI would want should come from task
[06:38:18] <fenn> i would like to be able to edit configs from a gui
[06:38:36] <petev> ahh
[06:39:06] <fenn> rpc is just straight function calls right?
[06:39:08] <petev> what would be wrong with just opening the remote xml file in an xml editor?
[06:39:19] <petev> rcp is just the mechanism, not an API
[06:39:31] <petev> also tools for automating the interface
[06:39:50] <fenn> i mean, what does an rpc call look like?
[06:40:24] <petev> it just looks like any other procedure call from C within limits
[06:40:47] <petev> for instance there are some arg limits if you want to be able to make the procedure call and RPC
[06:41:04] <petev> the rpcgen tool generates stub libs for client and server
[06:41:23] <petev> you can link client directly to server (no RPC) or to the stub libs
[06:41:43] <petev> the stub libs implement the RPC
[06:42:05] <petev> you give rpcgen a description of the RPC API you want
[06:42:15] <petev> it generates the rest including header files
[07:43:04] <fenn> alex you missed all the fun mind-bending spline-based tp talks
[07:43:29] <alex_joni> fenn: can I say I'm not interested?
[07:43:36] <fenn> pooh pooh
[07:44:29] <alex_joni> it just seems to me it's that time of the year
[07:46:04] <fenn> winter encourages mathematics
[07:46:50] <fenn> sometimes I feel like i'm an AI program
[07:47:24] <alex_joni> the other time of year is when NML is the target
[07:47:32] <alex_joni> I'm kinda sick of both subjects ;)
[07:47:39] <fenn> that was what followed the tp talks
[07:47:59] <alex_joni> don't get me wrong, I wouldn't mind if anyone did something
[07:48:04] <fenn> if they weren't busted they wouldnt need fixin
[07:48:13] <alex_joni> but only talks.. serve really no purpose
[07:48:41] <fenn> well actually we seem to have revealed some possible problems
[07:48:42] <alex_joni> I mean.. discussion is good, but it's the same story all over again
[07:49:07] <alex_joni> that helps little, till I see some code I'm done with the subject
[07:49:14] <fenn> ok
[07:49:36] <fenn> i always feel that writing down what you intend to do counts as code
[07:49:50] <alex_joni> if it ends up getting done, maybe
[07:50:01] <fenn> if the first thing you do is make a finished product, you lose all the benefits of an open source project
[07:50:19] <fenn> also undocumented code sucks
[07:50:25] <alex_joni> yeap
[07:50:29] <alex_joni> I agree on that
[07:50:30] <fenn> much easier to write the documentation, then write the code to fit
[07:50:51] <alex_joni> yeah, but a lot of code is there, and that needs documentation
[07:50:58] <alex_joni> also there a re a lot of open bugfixes on SF
[07:51:08] <alex_joni> s/bugs/bugfixes/
[07:51:18] <alex_joni> likewise feature requests
[07:51:24] <alex_joni> then there's a stg2 driver
[07:51:27] <fenn> oh gawd
[07:51:30] <alex_joni> the release of emc1
[07:51:36] <fenn> i'm blowin it out my ass
[07:51:45] <alex_joni> that involves some cleaning out HEAD on emc1
[07:51:47] <fenn> the whole point of emc2 was to get away from emc1's crap
[07:52:03] <alex_joni> yeah, I know.. but we want to wrok towards releasing emc2
[07:52:14] <alex_joni> at least some initial version
[07:52:31] <alex_joni> the board is following a certain path on that
[07:56:39] <alex_joni> still there fenn?
[07:56:42] <fenn> yeah
[07:57:18] <fenn> dunno what to say that's all
[07:57:33] <alex_joni> ;)
[07:58:56] <fenn> did you know petev wrote a new interp?
[07:59:27] <alex_joni> I heard some stuff about that
[08:00:31] <fenn> does anyone but till have a stg2 card?
[08:00:46] <alex_joni> it's the one you can get now
[08:00:52] <alex_joni> not very different than stg1 though
[08:00:58] <alex_joni> just some port defines
[08:04:23] <fenn> http://fenn.dyndns.org/pub/emc/chips2.png
[08:04:36] <alex_joni> seen it in the logs
[08:04:45] <alex_joni> looks ok ;)
[08:04:46] <fenn> my contribution for today
[08:04:47] <alex_joni> nice
[08:05:11] <alex_joni> it doesn't look very friendly to me :(
[08:05:22] <fenn> i have "penguinitis" from looking at too many pictures of penguins
[08:05:32] <alex_joni> guess it's related to his mouth
[08:06:01] <fenn> well, he's a very discerning penguin
[08:06:12] <alex_joni> discerning?
[08:06:49] <fenn> yeah has to act professional and keep parts to certain tolerances and such
[08:09:04] <alex_joni> heh
[08:09:20] <fenn> i always thought chips was kinda beaky
[08:09:46] <fenn> http://emc.sourceforge.net/Handbook/index.html
[08:11:02] <alex_joni> that's ugly ;)
[08:18:56] <fenn> i think its past my bedtime
[08:19:23] <fenn> * fenn goes to bed
[08:19:24] <alex_joni> night
[10:56:46] <anonimasu> hello
[10:57:13] <alex_joni> hello
[11:06:05] <anonimasu> whats up?
[11:06:44] <alex_joni> work
[11:07:18] <anonimasu> :(
[11:16:27] <alex_joni> yeah ;)
[11:19:31] <anonimasu> I am working on some network problems
[11:25:17] <alex_joni> sent some mail to till
[11:51:13] <anonimasu> hm ok
[11:51:20] <anonimasu> I am tracking down latency troubles at the work network
[11:51:54] <alex_joni> bleah..
[11:52:04] <alex_joni> wire? FO? or wireless?
[11:56:44] <anonimasu> wire..
[11:56:57] <anonimasu> the trouble is mostly upstream..
[11:57:09] <anonimasu> but I just set up mrtg for monitoring it
[12:20:33] <alex_joni> heh.. got some AtMega16
[12:20:43] <alex_joni> how expensive are they over there?
[12:20:55] <alex_joni> I got mine for 0,54 EUR / piece ;)
[12:22:02] <anonimasu> like 7 eur
[12:27:23] <alex_joni> heh.. 0,54 seems a bit better
[12:29:13] <anonimasu> yeah
[12:29:26] <anonimasu> * anonimasu goes insane at ntpdate
[12:29:43] <alex_joni> lol.. getting wierd mrtg error messages?
[12:29:52] <alex_joni> like : "let's not do the timewarp again"
[12:29:52] <alex_joni> :D
[12:30:46] <anonimasu> nope
[12:30:56] <anonimasu> Tue Jul 5 13:26:42 CEST 2022
[12:31:00] <anonimasu> ^_^
[12:31:16] <anonimasu> sucker's back in the 2010's.
[12:31:19] <anonimasu> ^_^
[12:31:25] <anonimasu> I am way ahead of you
[12:31:33] <alex_joni> hmm.. maybe some wierd timezone?
[12:31:36] <alex_joni> like Pluto?
[12:31:41] <alex_joni> ROFL
[12:33:49] <anonimasu> neat
[12:37:11] <anonimasu> ah better now
[12:37:15] <anonimasu> Thu Dec 8 13:37:13 CET 2005
[12:39:28] <anonimasu> 2005-12-08 13:39:23 -- ERROR: Creating templock /etc/mrtg.cfg_l_30756: Permission denied at /usr/local/bin/mrtg line 1271.
[12:40:47] <alex_joni> huh.. /etc/ ?? , not good
[12:41:00] <alex_joni> you need to put your mrtg.cfg somewhere else
[12:41:07] <alex_joni> I have it all under /usr/local/mrtg
[12:41:10] <anonimasu> yeah
[12:41:12] <anonimasu> I know :)
[12:41:24] <anonimasu> that were what the mrtg docs recomended..
[12:41:26] <anonimasu> err /etc..
[12:41:31] <anonimasu> ls
[12:41:37] <alex_joni> .
[12:41:38] <alex_joni> ..
[12:41:45] <anonimasu> mrtg.log
[12:41:51] <anonimasu> emc.log
[12:41:58] <anonimasu> %
[12:42:22] <anonimasu> ^_^
[12:44:19] <anonimasu> mrtg wont stay online
[13:02:40] <anonimasu> brb..
[13:11:58] <anonimasu> *yawns*
[13:22:39] <skunkworks> 7� here - heat wave
[13:45:55] <skunkworks> I have a question again
[13:46:56] <skunkworks> Is there anyway to have a different accelleration for each axis?
[13:47:10] <skunkworks> emc2
[13:51:03] <les_w> hi. per axis accel has been around for a while on emc1 and I presume emc2 aswell
[13:51:10] <les_w> I don't use it...
[13:53:16] <les_w> I guess templates are in the generic.ini file
[13:54:02] <les_w> let me check
[13:56:10] <les_w> yeah MAX_ACCELERATION in the axes sections
[13:56:28] <les_w> put whatever number youwant there!
[13:57:14] <alex_joni> 5.3 should work :D
[13:57:49] <skunkworks> right - here is the deal. If I set the max_acceleration x,y to 5 and z to 2 - the default_acceleration in the traj section is the only one that seems to work.
[13:58:12] <alex_joni> how much is def. accel in traj?
[13:58:35] <skunkworks> If I set the sefault-accelertaion to 1 - all the axises accelerate 1
[13:58:42] <skunkworks> If I set the sefault-accelertaion to 2 - all the axises accelerate 2
[13:58:46] <alex_joni> and if you put 5?
[13:59:03] <skunkworks> If I set the sefault-accelertaion to 4 - all the axises try accelerate 4 and z gets a following error
[13:59:24] <skunkworks> ok sorry alex - how much is def. accel in traj? what do you mean
[13:59:26] <alex_joni> bummer.. than it's the same bug cradek talked about
[13:59:53] <skunkworks> ah - ok I thought you had mentioned that yesterday. I didn't know what you ment
[14:00:55] <alex_joni> it's not supposed to work that way..
[14:01:05] <skunkworks> I was hoping not ;)
[14:01:17] <alex_joni> it'll get fixed hopefully :P
[14:01:48] <skunkworks> I have 2 axises that can probably accelleratate at over 10 ips^2 but I have to run them at 1 or 2 because of my z
[14:02:27] <alex_joni> how much is max_accel in traj?
[14:02:56] <skunkworks> 20 I think
[14:03:01] <alex_joni> ok
[14:04:12] <les_w> well, it may not work right. Don't know since I don't use it.
[14:09:03] <skunkworks> just trying to make sure I am not doing something stupid
[14:09:27] <skunkworks> what if I took the default_acceleraton out of the [traj] secton
[14:09:42] <alex_joni> try it ;)
[14:09:53] <skunkworks> I knew you where going to say that
[14:09:55] <skunkworks> ;)
[14:21:04] <skunkworks_emc2> nope - can't find [TRAJ] DEFAULT_ACCELERATION, using default
[14:21:22] <alex_joni> bummer ;)
[14:21:26] <skunkworks> ?
[14:22:08] <alex_joni> then it won't work probably
[14:22:31] <skunkworks> did cradek
[14:22:43] <skunkworks> post a bug report?
[14:22:53] <skunkworks> I don't see it
[14:22:55] <cradek> ?
[14:23:11] <alex_joni> hi chris
[14:23:17] <cradek> last I looked, it was right on top
[14:23:19] <cradek> hi alex
[14:23:42] <skunkworks> the issue with the default_accelleration in the [traj] secion is trumping the axis max_accelleration
[14:23:49] <skunkworks> hold on - I will look again
[14:23:56] <cradek> oh, not that one
[14:24:04] <cradek> do you mean for feed override > 100%?
[14:24:19] <skunkworks> no - well have not played with that
[14:24:33] <cradek> ok
[14:24:36] <alex_joni> I think I mixed the two
[14:24:40] <cradek> no I didn't investigate the bug you're talking about
[14:24:41] <alex_joni> it's about different accels
[14:24:47] <skunkworks> I can't seem to make my axises accellerate at different rates
[14:24:58] <cradek> interesting
[14:25:08] <skunkworks> it seems to be what ever the default_acceleration is set at in the traj
[14:25:17] <cradek> that was supposedly added to make a rotary axis work right
[14:25:21] <cradek> about a year ago
[14:25:23] <skunkworks> I might be doing something wrong
[14:25:24] <skunkworks> also
[14:25:26] <cradek> (in emc1)
[14:25:32] <alex_joni> it's not about rotary
[14:25:36] <cradek> skunkworks: I remember it didn't seem to work either
[14:25:38] <alex_joni> plain linear axes, wmc2
[14:25:42] <alex_joni> emc2 even
[14:25:45] <cradek> alex_joni: I understand, but you REALLY need it with rotary
[14:26:03] <cradek> alex_joni: (and that's why it was added originally)
[14:26:39] <alex_joni> yeah... but I would REALLY expect it to work even without rotary
[14:26:45] <alex_joni> where it should be trivial
[14:29:54] <skunkworks> darn - I thought I had it licked with the extra variables in the ini and hal files. (it did fix the jogging problem and following errors at low accelleration). Now I need to be able to up the accelleration.
[14:36:21] <skunkworks> ok - something to do with if the default_accelleration is higer than the axises max_accelleration
[14:37:16] <skunkworks> If I keep the default accelleration the same or higer I don't get following errors - but the default_accelleration is that all the axises use as their acceleration.
[14:37:39] <alex_joni> how about default_accel on [AXIS] sections
[14:38:18] <skunkworks> So right now I am running z at 4 ips^2 so far (but all my axis must run at that speed)
[14:38:27] <skunkworks> I think I tried that - but will try it again
[14:39:00] <skunkworks> acceleration - not speed
[14:39:15] <alex_joni> yeah, accel
[14:39:28] <alex_joni> not sure there even is such a thing :)
[15:02:38] <les_w> Was just looking at tp.c and tc.c again. I have been trying to get in touch with Fred about the vel adaptation error, but he seems to be on sabatical in tibet or something
[15:03:08] <alex_joni> heh ;)
[15:03:22] <alex_joni> I wonder if anyone knows what a TC is
[15:03:30] <alex_joni> or what it stands for
[15:04:11] <les_w> actually..don't knw...trjectory calculations?
[15:05:03] <les_w> as far as I'm concerned it ought to be called impossibletofollow.c
[15:06:45] <alex_joni> all I know is that it's called : Trajectory planner based on TC elements
[15:08:46] <les_w> It is only hypothesis that the calcs break down at the zero cruise phase threshold
[15:08:52] <les_w> need to test that
[15:14:50] <cradek> les_w: I know I get misblends on colinear segments with LONG cruises
[15:15:02] <cradek> I can hear it
[15:15:25] <alex_joni> hmm.. the planner is not that bright it seems to me
[15:15:45] <alex_joni> only when it sees that it's decel'ing it looks if it can blend the next one
[15:21:41] <les_w> well, trying to remember...the misblends dramatically improved with the last change but some effect was still there
[15:24:46] <alex_joni> * alex_joni goes home
[15:24:49] <alex_joni> later guy
[15:24:51] <alex_joni> later guys
[15:29:03] <les_w> And the stutter was unchanged. Separate problem I suspect.
[15:29:38] <cradek> do you think stutter is simple queue starvation?
[15:29:54] <les_w> perhaps whatever calls queue elements doesn't get the timing right in the no cruise phase...
[15:30:31] <cradek> these behaviors are very hard for me to reproduce and study
[15:31:49] <les_w> just a sec...
[15:32:09] <les_w> hunting for a function that returns current queue size
[15:32:12] <les_w> in tc.c
[15:32:55] <cradek> tpQueueDepth(tp)
[15:34:19] <les_w> I see tcqLen() in tc.c
[15:34:41] <les_w> rem by it says how many items are in the queue?
[15:35:36] <les_w> so that's length rather than depth...whatever that means
[15:36:39] <les_w> all it does is just return tcq->_len
[15:36:47] <cradek> they might be the same number
[15:36:55] <les_w> yeah
[15:38:35] <les_w> So any commanded velocity should be honored until the no cruise phase occurs
[15:39:06] <cradek> no, you may have accel constraints
[15:39:22] <les_w> beyond that with shorter segments velocity on the path should smoothly decrease
[15:39:25] <cradek> imagine a tight, very long helix
[15:39:39] <cradek> most of it is cruise phase
[15:39:48] <les_w> well, yeah accel determines the no cruise phase point
[15:40:29] <cradek> ok, I'm not sure about how that bookkeeping is done
[15:41:25] <les_w> well the avarage velocity in a segment is checked
[15:41:43] <cradek> I was assuming a long tight helix would be TC_IS_CONST for most of the helix
[15:42:01] <les_w> the peak velocity during cruise has to be more than commanded velocity
[15:42:23] <les_w> for the average velocity to equal commanded velocity
[15:43:20] <cradek> but velocity during cruise phase is constant
[15:43:26] <les_w> because it is going slower in ramp up and ramp down
[15:43:34] <les_w> right
[15:44:33] <les_w> and points in a straight line should result in all cruise phase motions
[15:45:07] <cradek> well yes and no
[15:45:19] <cradek> the accel throughout the blend should be 0
[15:45:37] <cradek> but in the queue, the adjacent segments are marked as accel/decel pairs and blended
[15:46:16] <cradek> each segment still goes through all three phases
[16:12:52] <les_w> sorry phone
[16:12:57] <les_w> Fred!
[16:14:06] <les_w> Fred says the simple TC/TP algo does not work unless there is a cruise pahase
[16:14:09] <les_w> phase.
[16:15:19] <les_w> It is not designed to velocity adapt.
[16:15:55] <les_w> so this stutter bit is not a bug...it's the algo....which fred describes as simplistic.
[16:16:16] <les_w> He says tc/tp should just be trashed.
[16:16:46] <les_w> He has requested papers or psudocode for better TP algos
[16:16:53] <les_w> so let's send him some
[16:25:45] <les_w> So...this makes sense....normally when physically unrealizable motions are requested a system slows down until they are realizable.
[16:26:04] <les_w> TC/TP does not do this!
[16:48:12] <les_w> wb alex
[16:48:17] <alex_joni> hi les
[16:49:52] <les_w> talked with fred p. just now
[16:49:57] <alex_joni> nice
[16:50:25] <les_w> heres the deal: tp/tc does not velocity adapt at all.
[16:50:26] <alex_joni> what's the verdict?
[16:50:54] <alex_joni> huh, nice to know that
[16:50:59] <les_w> Fred says tp/tc is a siplistic algo that should be scrapped.
[16:51:05] <les_w> simplistic
[16:51:44] <les_w> He asked if we could send him papers and or pseudo code of better planning techniques.
[16:51:48] <les_w> I said ok
[16:52:13] <alex_joni> does he have the time to work it out?
[16:52:22] <SWPadnos> if only he could have told us that at Fest ;)
[16:52:36] <alex_joni> did you ask stephen?
[16:52:38] <SWPadnos> (or maybe he did)
[16:52:42] <les_w> He said if he had a worked out algo that he could glue it in
[16:52:50] <SWPadnos> no - why would I ask myself?
[16:53:04] <alex_joni> not yourself.. "did you ask, stephen?"
[16:53:11] <SWPadnos> I think that's what we were trying for last night
[16:53:11] <les_w> heh
[16:53:16] <SWPadnos> heh
[16:53:31] <SWPadnos> we did discuss the TP some, but I don't remember the details
[16:53:53] <alex_joni> further fests need someone taking care of minutes ,)
[16:54:03] <les_w> in the mean time I must recognize that tp/tc cannot deal with unrealizable motion requests...at all.
[16:54:07] <SWPadnos> we almost had that, kinda
[16:54:31] <SWPadnos> I thikn that's what the "disc" calculation is for, but it probably isn't implemented properly
[16:54:32] <les_w> choices when unrealizable motion is requested:
[16:54:49] <les_w> 1) slow down until it is realizable
[16:54:59] <les_w> 2) just stop
[16:55:08] <les_w> 3) go nuts
[16:55:25] <SWPadnos> well - I'd vote for 1 or 2
[16:55:36] <les_w> Fred says tc/tp does #3.
[16:55:37] <SWPadnos> or possibly 4) warn the operator before cutting the part
[16:55:53] <les_w> yeah
[16:56:05] <SWPadnos> you should be able to predict the problems (at FO=1) during validation
[16:56:09] <les_w> well short term filters come to mind
[16:56:15] <SWPadnos> I agree
[16:57:37] <SWPadnos> even a 5th order traj calculation is short - 9 or 10 multiplies, some loads and stores, and 5 additions, per axis
[17:00:52] <les_w> yeah
[17:01:35] <SWPadnos> about 0.01 microsecond, these days
[17:01:43] <les_w> Fred also said segments all must have a cruise phase, and that cruise is always set to the F rate
[17:02:13] <les_w> so if the requested motion is slower, deccels will be thrown in
[17:02:33] <SWPadnos> do you know if that's linear segments, or "G-code" segments (ie, is a 6" circle a single segment?)
[17:02:38] <les_w> He said that is simplistic and should basically be tossed.
[17:02:45] <cradek> les_w: so can you crank up your accel?
[17:02:51] <cradek> SWPadnos: a circle is one segment
[17:02:59] <SWPadnos> ok
[17:03:10] <les_w> yeah, well I run as high as I can
[17:03:19] <alex_joni> hi chris
[17:03:25] <cradek> hi
[17:03:43] <les_w> segment being defined as the line between tow destinations
[17:03:52] <les_w> so yea an arc is one segment
[17:05:13] <SWPadnos> that actually compolicates things a little, since a segment may (even at constant feedrate) require accels
[17:05:27] <SWPadnos> but just a little
[17:05:45] <les_w> yeah, centripedal
[17:07:11] <SWPadnos> ok - is this a correct statment: given a starting vector and an ending vector, there is exactly one arc segment that is tangent to both vectors
[17:07:29] <les_w> hmm
[17:07:41] <cradek> SWPadnos: do you mean going through the endpoints and also tangent? yes
[17:07:41] <les_w> yes
[17:07:43] <alex_joni> one shortest arc
[17:07:47] <SWPadnos> circular arc, not parabolic or some higher order func
[17:08:08] <alex_joni> ok, then only one
[17:08:08] <SWPadnos> yes, through the vector, both position and direction
[17:08:48] <SWPadnos> ok - that's what I was getting at last night - unless you mess with the vectors (starting and ending conditions), you have one solution for the path
[17:09:41] <SWPadnos> if you can rotate one or the other vector, then you can fit a larger or smaller arc between them
[17:09:54] <SWPadnos> (larger or smaller radius)
[17:12:54] <les_w> yes
[17:13:03] <alex_joni> depending on the center of rotation
[17:13:24] <SWPadnos> ?
[17:13:40] <alex_joni> if you keep the 2 points then yes, larger or smaller radius
[17:14:18] <SWPadnos> right - if you can change either the direction or the position of a vector, then you can get a curve of a desired radius
[17:16:09] <les_w> looking for a function that gives me cruisetime...
[17:16:25] <SWPadnos> in tp.c / tc.c ?
[17:18:36] <les_w> yeah. Oh Fred said he thought time scaling was the best way to incorporate feed override.
[17:18:45] <les_w> So it does not have to be RT.
[17:18:54] <SWPadnos> could be, but you end up with accel issues, I think
[17:19:14] <les_w> Accel gats scaled.
[17:19:40] <SWPadnos> inversely to time (ie, the FO code provides a scale factor for accel valuse, which the RT code uses)
[17:20:23] <alex_joni> why would you want to scale accel?
[17:20:42] <alex_joni> even a 50% slower move, should accel just as much as a 100% move
[17:20:45] <SWPadnos> I'm assuming that time scaling means changing the rate that the RT code runs
[17:20:54] <alex_joni> ahh.. I see
[17:21:06] <SWPadnos> the accel per period needs to change
[17:21:11] <alex_joni> then yes
[17:21:15] <les_w> What would happen is this: let's say you need a certain corner radius. Normally that is V^2/a, but if both v and a get time scaled, the radius would not improve if you slowed down.
[17:21:23] <alex_joni> but it needs to increase on FO < 1
[17:21:47] <SWPadnos> les: I'm talking about maxaccel limits - they're dependent on the RT rate in some way
[17:21:59] <les_w> hmm
[17:22:02] <alex_joni> les is talking about the same thing
[17:22:33] <SWPadnos> I'm not sure - you would want to increase accel if you increase feed, but the limits are constant, regardless of RT rate
[17:22:48] <alex_joni> the other way around imho
[17:22:57] <alex_joni> if you slow down (say you have 0,5 FO)
[17:23:06] <alex_joni> then velocity will be 0.5 of the normal one
[17:23:11] <alex_joni> but accell needs to say the same
[17:23:25] <alex_joni> so you'll have to artificially increase it by a factor of 2
[17:23:34] <les_w> that would make tighter corners
[17:23:35] <alex_joni> a=2*a
[17:23:51] <alex_joni> then after the 0.5 timescaling (applied to all RT) it will get back to 1a
[17:23:52] <les_w> and also require that the TP is RT.
[17:24:04] <les_w> which is fine if that's what you want
[17:24:06] <alex_joni> yup
[17:24:59] <SWPadnos> in my view, you should expect more rounding of corners if you increase the feedrate, though I can also see the merit of following the same path regardless of operator input ;)
[17:25:12] <SWPadnos> I'm talking about machine accel limits
[17:25:51] <les_w> Fred's comment about time scaling only applies to FO...If you command a lower F in the program corner radius would still get tighter.
[17:26:16] <SWPadnos> those are in IPS^2, and the RT code (deciding to change direction) needs to know how much accel it can ask for in a single RT "interpolation" period
[17:27:03] <SWPadnos> so it would need to recaclulate max accel in terms of the RT execution rate (not a big deal, I guess -even a divide is only 39 cycles)
[17:27:06] <alex_joni> right.. it can ask of max_accel/FO_factor
[17:27:49] <les_w> I think Sampling issues would pale compared to machine dynamics
[17:27:56] <SWPadnos> one would hope ;)
[17:28:35] <les_w> Since we can go from - max velocity to +max velocity in one traj calc
[17:29:03] <les_w> which might be under a millisecond
[17:29:14] <SWPadnos> how would that occur?
[17:29:27] <SWPadnos> (assuming that the userspace code does some blending)
[17:29:37] <les_w> just command it I guess
[17:29:50] <SWPadnos> OK - G0X1 / G0X0
[17:29:50] <les_w> it would prob be unrealizable
[17:30:14] <SWPadnos> that would result in accel / cruise / decel, then -accel, -cruise, -decel
[17:31:30] <les_w> And if it is not possible....Fred says algo breaks down.
[17:31:58] <les_w> In such a way that the queue tends to get starved.
[17:32:13] <SWPadnos> actually - the fact that it won't blend until it's in decel is just silly - what if the next move is nearly collinear, and at a higher feedrate?
[17:32:38] <SWPadnos> (or the same feedrate)
[17:32:52] <les_w> right. Fred said it was simplistic...and he ain't kiddin
[17:32:56] <SWPadnos> heh
[17:34:08] <les_w> Again he asked for papers, and even some code or pseudo code if there is any.
[17:34:59] <les_w> He of course has the segmentqueue stuff...but does not follow it.
[17:36:44] <les_w> I'll try to put some together. The better ones cost money, and I don't have a problem with buying it if no one else like etla can get them.
[17:37:08] <SWPadnos> and the Sonja paper, I assume
[17:37:14] <les_w> for sure
[17:37:19] <SWPadnos> )or was that segmentqueue)
[17:37:21] <les_w> that is pretty readable
[17:37:31] <SWPadnos> there's another site I found - I'm looking for it now
[17:37:36] <les_w> good
[17:43:04] <SWPadnos> damn - I'll have to talk to my mother again to get the name of the guy who wrote the other papers
[17:43:19] <les_w> Seemingly from what Fred said the smoothest results will be obtained when the F command is always == Max_ Velocity
[17:44:27] <les_w> If you fooled it into making that always happen....
[17:44:37] <les_w> not sure though.
[17:48:13] <les_w> HMM I may vanish for a while due to ice storm....but got a generator....have not even tried it yet though.
[17:48:27] <les_w> Gasoline powered computer.
[17:49:51] <SWPadnos> heh
[17:49:57] <SWPadnos> get a fuel cell PSU, and you're all set ;)
[17:50:04] <les_w> yeah
[17:50:12] <SWPadnos> hey - wait - patents ...
[17:50:35] <les_w> yeah that might be a good source
[17:50:53] <les_w> 'specially public domain stuff
[17:51:18] <les_w> the TP maths we have talked about have been around for a while
[17:51:31] <SWPadnos> no - I mean me, and a computer with a fuel intake ;)
[17:51:41] <les_w> oh
[17:51:43] <les_w> haha
[17:52:01] <SWPadnos> the papers I'm looking for are from a book by a math professor on blending
[17:52:13] <SWPadnos> or - a book on blending by a math professor
[17:52:36] <SWPadnos> the textbook was used in a class my mother took, and she remembered the autthor's name
[17:52:37] <les_w> The stuff on my site was just from my old robotics book....changed a little
[17:53:02] <les_w> it was 1984 I think
[17:53:27] <SWPadnos> I can't find any of the emails, or any of the papers I downloaded
[17:53:30] <SWPadnos> it's annoying
[17:54:04] <les_w> I'll have to hunt some too
[17:54:18] <les_w> have 3 or 4 somewhere
[17:54:50] <les_w> The Sonja one is about the best because it has a lot of historical context
[17:55:59] <skunkworks> swp - I want to meet your mother. :)
[17:56:10] <les_w> Fred and I talked about higher order planners and consequences
[17:56:19] <les_w> not allways good
[17:56:35] <SWPadnos> heh
[17:56:49] <les_w> Like the s made from two tangent arcs...
[17:57:02] <SWPadnos> or the bulges at corners
[17:57:05] <les_w> a jerk limited planner cannot make that shape
[17:57:20] <SWPadnos> why not?
[17:57:56] <les_w> the arcs are tangent but centripedal accel instantly reverses at the joint
[17:58:01] <les_w> infinite jerk
[17:58:19] <SWPadnos> well - I look at any move as an entry vector and an exit vector
[17:58:21] <les_w> a 5th order planner will put a kind of flat in there
[17:58:49] <SWPadnos> the vector has position, which is known to be the same (for the exit of one move and the entry of the next)
[17:58:59] <SWPadnos> also velocity
[17:59:14] <SWPadnos> if the twio velocities are different, then some blending needs to happen
[17:59:39] <les_w> yes
[17:59:42] <SWPadnos> that blending needs to be limited by the accel limits, and on the jerk limits
[18:00:01] <alex_joni> if you limit jerk, then accel should be limited already
[18:00:03] <SWPadnos> this can be as simple as matching two vectors
[18:00:21] <alex_joni> right les?
[18:00:21] <SWPadnos> not necessarily
[18:00:46] <SWPadnos> it's like limiting position by limiting accel - it doesn't quite get you there
[18:01:07] <les_w> clamping jerk clamps accel to the integral...a ramp of some max slope.
[18:01:23] <SWPadnos> sorry - limiting velocity by limiting accel - if you accel for long enough, you can still exceed the max vel
[18:01:39] <les_w> yes
[18:02:34] <SWPadnos> same with jerk - if you jerk long enough, the accel can exceed limits (don't go there ;) )
[18:02:46] <alex_joni> you jerk
[18:02:53] <les_w> hahaha
[18:02:55] <SWPadnos> a$$hole
[18:03:13] <SWPadnos> don't jerk too long - we need to get some work done ;)
[18:03:15] <alex_joni> * alex_joni goes back to BRDTST
[18:03:45] <les_w> Anyway, I think unbounded jerk should be allowed...sometimes
[18:03:47] <les_w> heh
[18:03:54] <SWPadnos> heh
[18:04:15] <SWPadnos> I think it's only a problem if you look at it from a higher order perspective
[18:04:35] <SWPadnos> each segment has an exit vector, which must be matched with the entry vector of the next segment
[18:04:58] <SWPadnos> it shouldn't matter if that vector is part of an arc, a line, an ellipse, or whatever
[18:05:12] <SWPadnos> it's just a line, at the cutover point
[18:06:10] <alex_joni> a vector actually
[18:06:17] <alex_joni> line is not a great term
[18:06:17] <SWPadnos> a line is a vector
[18:06:23] <SWPadnos> ok - vector
[18:06:48] <SWPadnos> position (known to be identical), velocity - not necessarily identical
[18:06:49] <alex_joni> it's a single point as the path is concearned
[18:07:08] <alex_joni> point=position
[18:07:14] <les_w> customer on the way....gotta go work (collect money)
[18:07:19] <alex_joni> ok..
[18:07:20] <les_w> bbiab
[18:07:22] <SWPadnos> ok - see ya
[18:07:34] <alex_joni> SWPadnos: so, how do you match them?
[18:07:47] <SWPadnos> it's a point, but with velocity information, so it's a directed vector
[18:07:52] <alex_joni> if they are the same value&orientation, it's trivial.. do nothing
[18:08:08] <alex_joni> we only care for orientation and magnitude for now
[18:08:12] <SWPadnos> (well - there's a good question, huh)
[18:08:26] <alex_joni> if they are different you need to:
[18:08:39] <SWPadnos> I'm thinking of each single axis right now
[18:08:46] <alex_joni> 1. get back from that point to the point where you need to decel
[18:08:54] <SWPadnos> an orientation change means that there's a velocity change on a different axis
[18:08:55] <alex_joni> depending on max_accell
[18:09:12] <alex_joni> let's assume only one joint for now
[18:09:16] <SWPadnos> yes
[18:09:22] <alex_joni> orientation is always the same
[18:09:28] <alex_joni> only magnitude can differ
[18:09:40] <alex_joni> within (-max,max)
[18:09:48] <SWPadnos> yes, magnitude and direction
[18:10:06] <alex_joni> ok.. 2 distinct cases
[18:10:20] <alex_joni> 1. different direction (no blending possible)
[18:10:31] <alex_joni> you need to slow down to a halt, then start the other way
[18:10:50] <SWPadnos> that's a blend, actually - you just end up with a zero point in there
[18:10:55] <alex_joni> 2. same direction, only speed adaptation needs to get done
[18:11:11] <alex_joni> I find it easier to treat them differently
[18:11:21] <SWPadnos> how about this:
[18:11:44] <SWPadnos> ok - trerating a stop differently does help, but only a little
[18:11:48] <SWPadnos> treating
[18:12:15] <SWPadnos> for a non-reversing blend, get the average velocity
[18:12:27] <SWPadnos> possibly the geometric mean, but that's debatable
[18:12:53] <SWPadnos> each segment is "responsible" for accel / decel to the calculated mean
[18:13:02] <SWPadnos> in the case of a reversal, the mean is set to 0
[18:13:59] <alex_joni> that's another vector I think
[18:14:03] <SWPadnos> so, in segment 1, you accel / decel from the seg1 velocity to the average velocity, and in segment 2, you accel/decel from the average to the seg2 vel
[18:14:14] <alex_joni> yup
[18:14:25] <alex_joni> so we have 3 vectors
[18:14:36] <SWPadnos> the trick is in setting the mid-vel to 0 for a reversal
[18:14:38] <alex_joni> if v1=v3, then v2=v1
[18:15:07] <alex_joni> if sgn(v1)!=sgn(v3) then v2=0
[18:15:23] <alex_joni> else v2=mediate(v1,v3)
[18:15:59] <alex_joni> how does that sound?
[18:16:17] <SWPadnos> how about just get rid of 1 - no need to check ((a+b)/2 isn't that CPU intensive)
[18:16:40] <alex_joni> ok.. sounds right
[18:16:49] <SWPadnos> not even sqrt(a^2 + b^2) is that bad
[18:17:04] <alex_joni> this is 6-axes, bear that in mind
[18:17:09] <SWPadnos> yes
[18:17:27] <SWPadnos> make that sqrt((a^2 + b^2)/2)
[18:17:29] <alex_joni> so probably a bit more complicated than a+b/2
[18:17:45] <SWPadnos> no - each axis is just (a+b)/2
[18:17:56] <alex_joni> except rotationals
[18:18:03] <SWPadnos> no - still the same
[18:18:14] <alex_joni> might be.. can't think straight right now ;)
[18:18:26] <SWPadnos> this would be after all the higher level tool rate calcs are done
[18:18:44] <SWPadnos> it's in units of "axis velocity / time"
[18:19:29] <SWPadnos> there are extra calcs for getting total tool speed, and limiting that, but I see the blending as happening after those calc
[18:19:34] <SWPadnos> calcs
[18:21:58] <les_w> back
[18:22:09] <les_w> it's easy to accept money!
[18:24:39] <les_w> hi etla
[18:24:43] <SWPadnos> hey -send those customers my way!
[18:24:52] <SWPadnos> I like the ones that bring money
[18:24:56] <les_w> yeah
[18:25:06] <les_w> the economy seems good.
[18:32:25] <les_w> Have another gig pending...have to decontent a line of consumer gas ranges.
[18:32:41] <SWPadnos> decontent?
[18:33:05] <les_w> well, cut costs by eliminating some wiring
[18:33:13] <SWPadnos> ah
[18:33:23] <SWPadnos> "take out content"
[18:34:33] <les_w> Don't know how. I'll think about it when I get some $$.
[18:34:44] <alex_joni> hint hint
[18:34:48] <les_w> Put a quarter in the slot!
[18:34:59] <alex_joni> to all those investers reading the logs :D
[18:35:15] <les_w> uh...heh...yeah
[18:47:15] <les_w> air temp +2, dewpoint -5, and it's raining. What th....
[18:47:23] <SWPadnos> heh
[18:47:44] <SWPadnos> and it's sunny / 23 F here
[18:47:57] <skunkworks> Sorry to interupt - Here is something to think about. I would get following errors on z with anything over 2ips^2 on my z axis with around a 10% higher acceleration sent to the .hal file. Right now I am getting no following errors with accelleratin set to 4 ips^2 with a 200% buffer to the .hal file (8ips^2) does that make sense?
[18:48:35] <SWPadnos> yes
[18:49:00] <alex_joni> you don't get software ferrors, but motors will struggle
[18:49:12] <skunkworks> this is steppers
[18:49:25] <SWPadnos> it tells me that you need a setting somewhere 10% and 100% over the emc settings for the HAP
[18:49:36] <SWPadnos> between 10% and 100%
[18:50:12] <SWPadnos> for very high accels, and / or very low ferror limits, you would need to increase the headroom percentage
[18:51:20] <skunkworks> crap - I have to run for a bit. be back. (keep talking among your selves) ;) I still need to be able to run higher acceleration on some axises - not all the same
[18:51:40] <SWPadnos> talk talk talk
[18:54:55] <CIA-12> 03alex_joni * 10emc2/src/hal/drivers/ (hal_stg.c hal_stg.h): added support for STG2
[18:56:15] <SWPadnos> HA! the author is deBoor - woohoo
[18:56:43] <alex_joni> ?
[18:56:58] <SWPadnos> the paper(s) I was looking for on spline blending and the like
[18:57:09] <alex_joni> and?
[18:57:20] <SWPadnos> well - http://www.cs.wisc.edu/~deboor/
[18:58:43] <SWPadnos> and http://www.cs.wisc.edu/~deboor/ftpreadme.html - for a list of relevant pubs
[19:07:55] <les_w> great. looking
[19:08:15] <SWPadnos> hopefully you'll understand what he's saying ;)
[19:10:02] <SWPadnos> He wrote a textbook with a guy named Davis - I haven't searched for the book online (though my mother bought a copy)
[19:11:20] <SWPadnos> I think the discussion at the time (around Fest) was about getting / setting the velocity along the path, and making sure that it was possible in RT or pseudo-RT code
[19:14:38] <les_w> not sure which paper to look at...
[19:14:45] <SWPadnos> heh - there are a lot of them
[19:15:30] <les_w> have you seen any TP code out there? like another open source project?
[19:15:38] <SWPadnos> fenn mentioned orocos
[19:16:03] <SWPadnos> but their TP stuff is at rev 0.2 or something (not sure how good it is)
[19:17:54] <les_w> oh yeah. let me check that again.
[19:54:30] <alex_joni> * alex_joni got back
[19:54:34] <alex_joni> TP done?
[19:54:48] <alex_joni> SWPadnos: you had half an hour...
[20:01:52] <les_w> I am doing a fresh search of papers/books
[20:02:11] <alex_joni> * alex_joni finished the stg driver
[20:02:15] <alex_joni> it supports stg2 now
[20:02:37] <alex_joni> probably some minor bugs in there, but those appear only on running machines :(
[20:02:44] <alex_joni> don't have one here :/
[20:05:55] <SWPadnos> what - me?
[20:06:01] <SWPadnos> I'm doing real work now ;)
[20:06:31] <alex_joni> that's nice for a change ;)
[20:07:19] <SWPadnos> I'm doing real work now ;)-272.75
[20:07:29] <SWPadnos> ooops
[20:07:44] <alex_joni> well... didn't turn out very readable
[20:07:49] <les_w> www-cvr.ai.uiuc.edu/~lab/ece470/2005/first-chapters.pdf
[20:07:58] <les_w> robotics text on line?
[20:09:06] <les_w> nope
[20:13:21] <Jacky^_> uh Jacky^ [n=Jacky^@d83-176-4-109.cust.tele2.it] has quit ?
[20:13:23] <Jacky^_> :P
[20:13:49] <Jacky^> :)
[20:24:25] <k4ts> hello
[20:24:44] <k4ts> hi les_w
[20:26:32] <Jacky^> ciao k4ts :)
[20:27:10] <les_w> hi k4ts and jacky
[20:27:50] <k4ts> come stai les_w?
[20:28:37] <k4ts> how are you?
[20:29:18] <les_w> I got that...I'm ok. Have a little break from working while patent lawyers argue.
[20:30:07] <k4ts> ok
[20:30:27] <Jacky^> k4ts: understood ? :)
[20:30:34] <k4ts> yes Jacky^
[20:30:41] <Jacky^> :D
[20:30:43] <k4ts> ha detto bene
[20:31:05] <k4ts> e ha detto che stava facendo piccolo
[20:31:13] <k4ts> spuntino penso
[20:31:15] <Jacky^> breve pausa
[20:31:18] <Jacky^> yes
[20:31:49] <Jacky^> le ultime parole non le ho capito nemmeno io sigh :(
[20:32:08] <Jacky^> hanno a che vedere con legge law= legge
[20:32:13] <Jacky^> credo ..
[20:32:14] <les_w> reminds me...I am supposed to call them. I'd rather not. Can I be sick today?
[20:34:03] <k4ts> uhm?
[20:34:14] <k4ts> andiamo sul difficle
[20:34:18] <Jacky^> hehe
[20:34:36] <les_w> ? haha
[20:35:09] <Jacky^> she have some difficult to understand all
[20:35:48] <k4ts> lei ha difficolt� a capire tutto!
[20:35:50] <k4ts> yes
[20:35:54] <les_w> Tell her I don't want to talk to lawyers today, so I will be sick.
[20:36:05] <les_w> sick day
[20:36:08] <les_w> no work
[20:36:23] <k4ts> sick= ?
[20:36:28] <Jacky^> les_w: since I sayd I want to become a worker like you she want to understand why
[20:36:31] <k4ts> day giorno
[20:36:38] <Jacky^> meant worker man
[20:36:43] <les_w> heh
[20:36:51] <Jacky^> sick.. credo seccante noioso
[20:37:34] <les_w> sick = don't go to work but have fun instead
[20:37:55] <Jacky^> k4ts: giorno libero, niente lavoro
[20:38:03] <Jacky^> les_w: we too
[20:38:08] <les_w> ha
[20:38:11] <Jacky^> right today
[20:38:20] <k4ts> les_w io molto malata
[20:38:30] <Jacky^> malata ?
[20:38:38] <Jacky^> lol
[20:38:43] <k4ts> ah ah si piede = foot
[20:39:01] <k4ts> spe prendo vocabolario
[20:39:14] <Jacky^> oh.. yes, foot accident
[20:41:11] <k4ts> to fall to the ground
[20:41:46] <Jacky^> k4ts: try systransbox too
[20:42:03] <Jacky^> I use it every day, its nice
[20:44:03] <les_w> ah...I now have english italian translation page up
[20:44:09] <les_w> well, a dictionary
[20:44:41] <Jacky^> k4ts: ha avuto un incidente al piede
[20:44:48] <Jacky^> sta a riposo
[20:44:53] <Jacky^> :)
[20:47:29] <les_w> had foot accident so you shoud rest. Right?
[20:47:38] <Jacky^> yeah
[20:47:41] <les_w> haha
[20:48:12] <Jacky^> :)
[20:51:18] <alex_joni> SWampy: still tehre?
[20:51:21] <alex_joni> there even..
[20:51:36] <Jacky^> hello alex_joni
[20:51:43] <alex_joni> hi Jacky
[20:52:59] <k4ts> hi alex_joni
[20:53:46] <Jacky^> k4ts: some question ?
[20:53:49] <Jacky^> :)
[20:54:44] <k4ts> les to came at italy for natale?
[20:54:53] <k4ts> hi hi!
[20:55:05] <Jacky^> k4ts: crhistmas
[20:55:18] <k4ts> vabbe natale no capisce
[20:55:24] <Jacky^> I dont know.. les_w religion
[20:55:38] <les_w> I would like to. I have never been. Closest was when I stayed in Nice for a while
[20:55:41] <Jacky^> he maybe is not cristian
[20:55:47] <Jacky^> oh :)
[20:56:20] <les_w> yes raised christian
[20:56:23] <les_w> heh
[20:56:57] <Jacky^> I think she want to say some other question
[20:56:57] <les_w> so yes we do christmas
[20:56:57] <Jacky^> for example..
[20:57:14] <Jacky^> why peoples here around spent a lot of time developing and using PC
[20:57:19] <SWPadnos> alex_joni, sort of
[20:57:39] <alex_joni> found my favourite comment in emc ;)
[20:57:39] <Jacky^> then why we are always here ! :D
[20:57:53] <Jacky^> right k4ts ?
[20:57:55] <SWPadnos> which is ...?
[20:58:18] <alex_joni> (Just because I'm paranoid doesn't mean they
[20:58:19] <alex_joni> are not out to get me!)
[20:58:23] <alex_joni> :P
[20:58:25] <SWPadnos> heh
[20:58:34] <Jacky^> haha
[20:59:07] <les_w> oh you found that bit alex
[20:59:17] <alex_joni> once again
[20:59:26] <alex_joni> I looked over it a while ago (a year or so)
[20:59:36] <alex_joni> but now I'm looking again .. following a bug
[21:02:27] <Jacky^> alex_joni: im too ..
[21:02:35] <Jacky^> tryng to debug k4ts :(
[21:02:58] <k4ts> spe tro traducendo � na fatica!
[21:03:00] <k4ts> sudo
[21:03:02] <Jacky^> well, she say we are a bit egoist on aour works
[21:03:05] <Jacky^> hahahah
[21:03:23] <Jacky^> clever but egoist :/
[21:03:37] <k4ts> lstai dicendo che state sempre al lavoro al pc?
[21:03:39] <Jacky^> is it true ?
[21:03:47] <Jacky^> k4ts: yes
[21:03:54] <k4ts> ho intuito
[21:04:07] <k4ts> altrimenti sfolgio tutto il vocabolario
[21:04:08] <Jacky^> per la parola egoist ?
[21:04:09] <Jacky^> LOL
[21:04:16] <k4ts> works
[21:04:19] <Jacky^> ah ok
[21:05:12] <les_w> yes she is right I think
[21:05:20] <Jacky^> ok, than the question want to be, how much are happy the womans are near to you whan you working soo much ?
[21:05:49] <Jacky^> les_w: she's right ? :(��
[21:05:57] <les_w> They don't like it at all. That's why I have been married twice! ;)
[21:06:08] <alex_joni> there are 2 rules with women
[21:06:16] <les_w> ?
[21:06:18] <alex_joni> #1. the women is always right
[21:06:24] <Jacky^> thats ok, but how can we get it otherwise ?
[21:06:29] <alex_joni> #2. if the women is not right, rule #1 gets applied
[21:06:44] <Jacky^> hahaha
[21:06:53] <Jacky^> alex_joni: loos like a loop
[21:07:00] <Jacky^> I like it enough :P
[21:07:06] <alex_joni> one you'll never escape from
[21:08:02] <k4ts> les_w what to reconcile work with your family?
[21:08:34] <les_w> I worked all the time. Never home with family.
[21:08:39] <les_w> I was bad!
[21:08:46] <k4ts> ugh!
[21:08:55] <Jacky^> :)
[21:09:03] <les_w> yeah
[21:09:04] <k4ts> very bad
[21:09:39] <les_w> We make lots of money, but never home
[21:10:03] <Jacky^> I think the 2 things could nicely meet
[21:10:21] <Jacky^> but its hard
[21:11:16] <k4ts> right = destra?
[21:11:23] <Jacky^> no, giusto
[21:11:24] <alex_joni> right
[21:11:32] <Jacky^> it depend
[21:11:42] <Jacky^> right = destra, giusto
[21:11:44] <alex_joni> right = destra, giusto, ok
[21:12:00] <k4ts> alex_joni ha scritto the women in not right
[21:12:12] <Jacky^> no ..
[21:12:25] <k4ts> is always right
[21:12:25] <k4ts> ?
[21:12:28] <k4ts> sorry
[21:12:33] <Jacky^> alex_joni: ha scritto: la donna � sempre giusta
[21:12:36] <k4ts> cosa significa
[21:12:42] <k4ts> � sempre destra?
[21:12:47] <Jacky^> noo
[21:12:48] <Jacky^> LOL
[21:12:52] <Jacky^> listen ..
[21:12:58] <k4ts> ah quindi ha piu significati
[21:13:01] <k4ts> ok
[21:13:04] <Jacky^> yes
[21:13:13] <Jacky^> ha scritto ci sono 2 regole
[21:13:18] <k4ts> si si
[21:13:23] <Jacky^> regola 1: la donna � sempre giusta
[21:13:24] <k4ts> capito
[21:13:41] <k4ts> alex_joni thanks
[21:13:44] <Jacky^> regola 2: se la donna non � giusta, allora si applica immediatamente la regola 1
[21:13:46] <k4ts> ih ih
[21:13:47] <Jacky^> haha
[21:13:49] <les_w> woah too fast for my italian dictionary
[21:13:52] <les_w> haha
[21:14:00] <alex_joni> les_w: italian is not that hard
[21:14:15] <alex_joni> actually my language has the same ancestor (latin)
[21:14:24] <k4ts> alex_joni inglese +
[21:14:29] <les_w> it is when you don't know much!
[21:15:10] <les_w> hey k4ts when will you sing on paltalk again?
[21:15:16] <k4ts> les_w repeat sppaghetti e pixxa
[21:15:17] <k4ts> ah ah
[21:15:27] <k4ts> pizza
[21:15:35] <k4ts> slurp
[21:15:44] <Jacky^> hehe k4ts want to sing Image ?
[21:15:47] <Jacky^> :)
[21:15:49] <k4ts> yessssssss
[21:15:59] <Jacky^> woo :)
[21:16:14] <k4ts> mah les_w non vieneeeee
[21:16:15] <k4ts> sigh
[21:16:23] <Jacky^> no ha chiesto proprio lui
[21:16:31] <Jacky^> quindi.. penso che venga
[21:16:40] <les_w> gulp. huh?
[21:17:05] <Jacky^> les_w: are you able to join to paltalk now to listen k4ts singing ?
[21:17:06] <alex_joni> les_w: you're deep in now
[21:17:07] <alex_joni> :)
[21:17:18] <les_w> haha
[21:17:20] <les_w> yes
[21:17:26] <les_w> which room?
[21:17:36] <Jacky^> k4ts: he can (lui puo)
[21:17:49] <k4ts> ah ok
[21:17:50] <Jacky^> k4ts: you could open your room right ?
[21:17:56] <k4ts> ma poi ride'
[21:18:00] <k4ts> che figura?
[21:18:07] <k4ts> yes
[21:18:13] <Jacky^> let me start winsoz in wmware :D
[21:18:16] <k4ts> les_w no smile!
[21:18:21] <Jacky^> k4ts: why ?
[21:18:32] <les_w> ;)
[21:18:38] <k4ts> del mio pessimo english
[21:18:48] <Jacky^> les_w: k4ts is not sure to sing well at all
[21:18:49] <k4ts> bud english
[21:18:52] <Jacky^> hehehe
[21:18:55] <Jacky^> bad
[21:18:59] <Jacky^> not bud
[21:19:01] <Jacky^> :)
[21:19:03] <k4ts> les_w conosce qualche canzone italiana?
[21:19:05] <k4ts> chiedilo
[21:19:19] <Jacky^> les_w: do you know some italian song ?
[21:19:49] <les_w> haha no....but last time she was singing bossa nova or something
[21:20:02] <Jacky^> uhm.. ok
[21:20:11] <les_w> I don't remember
[21:20:19] <Jacky^> k4ts: non ne conosce :(
[21:20:48] <Jacky^> k4ts: id try some english song in italian version
[21:21:09] <Jacky^> k4ts: una canzone inglese in IT
[21:21:23] <k4ts> ah
[21:21:36] <k4ts> mumble mumble
[21:21:38] <Jacky^> try to search
[21:21:55] <Jacky^> New Yor New Yor maybe ? :P
[21:22:13] <Jacky^> hehe not simple to sing :D
[21:22:17] <Jacky^> hahaha
[21:22:35] <Jacky^> brb in 3 min
[21:22:44] <les_w> I used to play guitar in a rock band. long ago.
[21:22:46] <les_w> k
[21:22:47] <k4ts> santana
[21:22:50] <k4ts> posso fargli
[21:22:53] <les_w> yes!
[21:22:55] <k4ts> lo conosce
[21:23:28] <k4ts> santana corazon espinado
[21:23:54] <k4ts> o sole mioooo
[21:23:58] <Jacky^> hehe
[21:24:04] <Jacky^> santana i think yes
[21:24:10] <les_w> yeah.
[21:24:13] <k4ts> ok
[21:24:15] <Jacky^> les_w: you know santana
[21:24:20] <Jacky^> well
[21:24:25] <les_w> of course
[21:25:47] <Jacky^> k4ts: ready ?
[21:25:53] <k4ts> si
[21:25:53] <alex_joni> * alex_joni loves jovanotti
[21:25:57] <alex_joni> you know jovanotti?
[21:25:58] <k4ts> ahah
[21:26:00] <Jacky^> hehe rap
[21:26:00] <k4ts> alex_joni
[21:26:02] <Jacky^> :)
[21:26:05] <alex_joni> serenata rap ;)
[21:26:07] <alex_joni> it's great
[21:26:15] <Jacky^> alex_joni: are you able to join the room in pal ?
[21:26:38] <les_w> alex let's go to to pal and listen
[21:26:45] <Jacky^> alex_joni: nice, but i dont think k4ts is able to sing rap :(
[21:26:46] <les_w> k4ts is a good singer
[21:27:00] <alex_joni> * alex_joni doesn't have pal
[21:27:20] <alex_joni> I also like: ombelico del mondo
[21:27:25] <alex_joni> not sure if it's spelled ok ;)
[21:27:28] <les_w> aw...get it sometime
[21:27:37] <k4ts> ho aperto room
[21:28:01] <Jacky^> ok
[21:28:07] <Jacky^> can invite me k4ts '
[21:28:09] <Jacky^> ?
[21:28:20] <k4ts> ok
[21:28:49] <Jacky^> may you can also add les to your pal list
[21:28:57] <Jacky^> its simple to find it
[21:29:02] <Jacky^> him
[21:29:36] <Jacky^> les_w: waht your nick ?
[21:29:56] <Jacky^> or
[21:30:04] <Jacky^> join Musica e allegria
[21:30:42] <les_w> les_watts
[21:31:08] <Jacky^> ok k4ts aggiungilo alla pl list e invita
[21:31:43] <k4ts> caduto
[21:33:12] <Jacky^> k4ts: aggiungilo per il nick
[21:33:21] <Jacky^> il nick les_watts
[21:33:25] <Jacky^> roger ?
[21:33:36] <alex_joni> qui e roger?
[21:33:38] <alex_joni> :P
[21:33:41] <Jacky^> hehe
[21:33:43] <Jacky^> K
[21:33:47] <k4ts> invitalo
[21:34:32] <Jacky^> tryng to add him to my pal list
[21:34:49] <Jacky^> damn , ice the window loched
[21:35:02] <Jacky^> locked by code verification account
[21:35:13] <Jacky^> cant act on menu LOL
[21:35:22] <les_w> searched musica e allegria but got Europhonic
[21:35:41] <Jacky^> ops sorry
[21:35:46] <Jacky^> Musica in allegria
[21:35:53] <les_w> k
[21:36:05] <Jacky^> try to search by language european too
[21:43:11] <Jacky^> hehe :)
[21:43:21] <les_w> alex k4ts is singing to us...sorry you are missing it!
[21:43:45] <alex_joni> yeah.. I'm fixing tp a bit in the meantime (with cradek)
[21:43:53] <les_w> ha ok
[21:43:56] <Jacky^> :)
[21:46:14] <Jacky^> k4ts: congrats :)
[21:46:17] <Jacky^> hehe
[21:46:21] <les_w> very nice.
[21:46:27] <Jacky^> :)
[21:56:11] <k4ts> thanks
[22:13:55] <Jacky^> les_w: lol
[22:14:18] <Jacky^> k4ts: is singing without know the pronunce
[22:14:32] <Jacky^> and works too
[22:14:36] <Jacky^> great
[22:14:39] <Jacky^> :)
[22:29:00] <Jacky^> k4ts: good :-)
[22:29:03] <les_w> well, that was very nice.
[22:29:09] <Jacky^> funny hehe
[22:29:10] <les_w> great voice
[22:29:20] <Jacky^> yeah, nice voice
[22:29:34] <les_w> I like music a lot you know
[22:29:37] <k4ts> eccomi
[22:29:44] <les_w> that is why I have a music room.
[22:29:49] <Jacky^> hard to get it right in language other then english ..
[22:29:57] <Jacky^> italian*
[22:30:27] <Jacky^> she sing with no mic effect too
[22:30:35] <Jacky^> absolute natural voice
[22:30:40] <les_w> k4ts sang imagine in english very well
[22:30:46] <k4ts> insomma
[22:30:50] <les_w> haha
[22:30:50] <Jacky^> but she could use some nice effect
[22:30:59] <Jacky^> because she have a great sound card
[22:31:12] <Jacky^> some effect could be nice
[22:31:26] <Jacky^> k4ts: les is an audiophile too
[22:31:35] <Jacky^> un intenditore di suono e speakers
[22:31:43] <k4ts> ah bene
[22:31:44] <Jacky^> ;-)
[22:31:49] <les_w> I used to design audio equipment
[22:31:52] <k4ts> come vorrei che capisse la mia scheda
[22:32:04] <les_w> for stage and home
[22:32:11] <Jacky^> cool
[22:32:26] <k4ts> traduci un po
[22:32:30] <k4ts> Jacky^
[22:32:33] <k4ts> per favore
[22:32:55] <k4ts> anche in pvt se qualcuno non vuole qui
[22:33:23] <Jacky^> lui progetta (o ha progettato impianti audio) per concerti e casa pure
[22:33:33] <k4ts> ah bello
[22:33:40] <Jacky^> yes
[22:34:09] <Jacky^> have a good eard ;)
[22:34:37] <Jacky^> I' happy with a mostef power amplifier I biuld from myself years ago
[22:34:47] <les_w> you did?
[22:34:49] <les_w> great
[22:34:52] <Jacky^> yeah
[22:35:08] <k4ts> eard non c'� sul vocabolario
[22:35:08] <Jacky^> but I sell my loudspeakers in a bad moment ..
[22:35:31] <Jacky^> and now I cant use it, since Ive no speakers :)
[22:35:35] <les_w> I designed loudspeakers
[22:35:49] <Jacky^> planning to build them .. in the future
[22:36:04] <k4ts> les_w dove vive?
[22:36:07] <k4ts> che stato?
[22:36:09] <les_w> when you do...I will help
[22:36:15] <Jacky^> les_w: I know, also Yuga seem to work around it
[22:36:29] <Jacky^> k4ts: you can find les_w location in our map
[22:36:32] <les_w> Yes I have been helping him some
[22:36:40] <Jacky^> http://www.frappr.com/emctheenhancedmachinecontroller
[22:36:49] <les_w> georgia, USA
[22:36:54] <Jacky^> les_w: yeah, I read something in chat
[22:36:56] <les_w> yes I am on there
[22:37:45] <les_w> Yuga wants to market a line of loudspeakers for disco use. I am trying to help him.
[22:37:58] <Jacky^> yeah, cool
[22:38:06] <les_w> A very good speaker can be made for not a lot of money
[22:38:33] <les_w> Helps if you have cnc to cut the parts!
[22:38:52] <Jacky^> right! :-)
[22:39:11] <Jacky^> many nice things could be done with cnc
[22:39:18] <les_w> But I design the speaker drivers also.
[22:39:28] <les_w> much like servos.
[22:39:55] <Jacky^> great .. Ive seen some link Yuga posted here
[22:39:56] <k4ts> digli che gli mando un dolce natalizio
[22:40:01] <Jacky^> very nice system
[22:40:01] <k4ts> ma chissa se arrvia?
[22:40:04] <les_w> some speakers use servo motors to drive the cone!
[22:40:10] <k4ts> uno confezionato
[22:40:19] <k4ts> mandiamo
[22:40:25] <k4ts> dolci napoletani
[22:40:36] <Jacky^> k4ts: I aggred :)
[22:42:15] <Jacky^> les_w: k4ts want to send to you some cookies from naples
[22:42:25] <Jacky^> we*
[22:42:37] <Jacky^> also for the help you gave me :)
[22:42:42] <k4ts> les_w geedy?
[22:42:47] <k4ts> greedy
[22:42:56] <Jacky^> I was thinking to do that later
[22:43:07] <les_w> cookies from naples? wow
[22:43:17] <Jacky^> to be honest, I should thanks a lot of peoples too here around
[22:43:17] <k4ts> slurp
[22:43:22] <Jacky^> :)
[22:43:56] <Jacky^> les_w: yeah, some artiginal local products
[22:44:02] <Jacky^> very good ;)
[22:44:24] <k4ts> in 3 4 giorni dovrebbero arrivare
[22:44:32] <Jacky^> uhm
[22:44:36] <Jacky^> 3-4 days ?
[22:44:38] <k4ts> ti fai dare address
[22:44:41] <Jacky^> not sure ..
[22:44:53] <k4ts> per natale c'� la faremo
[22:44:57] <les_w> it is on the site:
[22:45:06] <Jacky^> in this time (christmas) ..
[22:45:23] <Jacky^> bumaybe some week
[22:45:26] <Jacky^> but
[22:45:31] <k4ts> in pvt
[22:45:37] <k4ts> cosi non lo leggono!
[22:45:39] <k4ts> tutti
[22:45:41] <k4ts> ah ah
[22:45:43] <Jacky^> k4ts: non c� bisogno
[22:45:50] <Jacky^> lo sanno gi� tutti LOL
[22:45:51] <les_w> address is on
[22:45:58] <les_w> www.lmwatts.com
[22:45:59] <k4ts> spe penna
[22:46:04] <Jacky^> les_w: adrees is on the website
[22:46:20] <les_w> for us mail
[22:46:29] <k4ts> e come c'� li mando
[22:46:32] <k4ts> via email?
[22:46:36] <Jacky^> hahaha
[22:46:38] <k4ts> ihhhhhhhhh
[22:46:39] <Jacky^> noo
[22:46:40] <k4ts> ih
[22:46:41] <les_w> for ups it is 101 watts street
[22:46:53] <les_w> yes, I have my own street.
[22:47:01] <les_w> email me cookies?
[22:47:04] <Jacky^> k4ts: les_w ha detto che il suo indirizzo � sul suo sito !
[22:47:05] <les_w> haha
[22:47:19] <Jacky^> she have not understand..
[22:47:27] <k4ts> uhm O_O
[22:47:31] <Jacky^> wait ..
[22:47:32] <les_w> ha
[22:47:33] <anonimasu> 1hello
[22:47:37] <Jacky^> hi anonimasu
[22:47:41] <les_w> hi anon
[22:47:57] <Jacky^> k4ts: http://www.lmwatts.com/contact.html
[22:47:58] <k4ts> vabbe l importante � che hai capito tu
[22:48:21] <Jacky^> yes
[22:48:23] <Jacky^> :)
[22:48:50] <k4ts> digli visto dove abita prefersico portarli io direttamnete
[22:48:53] <k4ts> ih ih
[22:49:18] <anonimasu> what's up?
[22:49:23] <anonimasu> les_w: done any progress?
[22:49:52] <les_w> I had a long talk with Fred P.
[22:50:29] <anonimasu> hm ok?
[22:50:38] <anonimasu> tell me about it
[22:51:21] <les_w> well, he asked for some TP papers so he can change it. He says that tc/tp is simplistic and no good and should be trashed.
[22:51:35] <anonimasu> so we got a new tp comming ?
[22:51:36] <anonimasu> YAY!
[22:51:52] <les_w> tc/tp cannot do velocity adaptation!
[22:51:52] <anonimasu> maybe
[22:51:57] <les_w> yeah.
[22:52:30] <anonimasu> les_w: What kind of papers did he want?
[22:52:59] <les_w> any kind with modern TP algos. Like the Sonja paper.
[22:53:10] <anonimasu> neat
[22:53:16] <Jacky^> are you talking about a printer ?
[22:53:18] <les_w> i'll send them
[22:53:32] <anonimasu> do you have access to any even better ones?
[22:53:46] <anonimasu> something that will handle ultra high speed machining ;)
[22:54:14] <les_w> No, the author of emc had a talk with me today. He might help us improve it for HSM like routers
[22:54:25] <anonimasu> hm ok?
[22:54:34] <anonimasu> so hsm is still way off :/
[22:54:46] <les_w> depends
[22:55:08] <anonimasu> how so?
[22:55:10] <les_w> if we help him with information he will do it I think
[22:55:27] <anonimasu> hm ok
[22:55:39] <anonimasu> isnt there algos that will work well at very high speed?
[22:55:46] <anonimasu> with jerk limiting and stuff
[22:55:49] <les_w> yes
[22:55:51] <les_w> many
[22:56:09] <les_w> we have to get examples to him.
[22:56:25] <les_w> Help do the work.
[22:56:37] <Jacky^> guys want you see a very nice jobs maded with a 'special' printer here around ?
[22:56:53] <Jacky^> go to this link http://www.veroececcarelli.com/
[22:56:57] <les_w> Um, what kind of cookies does K4TS bake?
[22:57:03] <les_w> I am hungry.
[22:57:04] <Jacky^> click on : Servizi
[22:57:14] <Jacky^> then click Stampa termofissante
[22:57:28] <Jacky^> and look at the jobs
[22:57:45] <Jacky^> on glass, steel, wood, etc
[22:59:21] <Jacky^> les_w: the best of local sweet things from naples should be eat in few days :(
[22:59:40] <les_w> haha
[22:59:46] <Jacky^> but I think k4ts will find the appropriate for more days ;)
[23:01:16] <Jacky^> les_w: seen the jobs in the website I pasted ?
[23:01:25] <Jacky^> how it seem to you ?
[23:01:42] <les_w> I cook too...but always use cherry wood for the fire. I have so many scraps from the turkey call cnc work
[23:01:53] <les_w> yes...very nice
[23:02:09] <k4ts> http://cgi.ebay.it/DOLCI-NAPOLETANI-DI-NATALE-A-NAPOLI-SI-MANGIA-COSI_W0QQitemZ4417931607QQcategoryZ14309QQcmdZViewItem
[23:02:09] <anonimasu> *yawns*
[23:02:51] <k4ts> look les_w
[23:03:53] <k4ts> http://www.cookaround.com/cucina/speciali/napoli-4.php
[23:04:20] <k4ts> clicca su struffoli
[23:04:27] <les_w> looking
[23:05:06] <les_w> you make me hungry
[23:05:08] <Jacky^> k4ts: yes, the url its already on 'struffoli' page
[23:05:08] <les_w> mmm
[23:05:13] <Jacky^> :)
[23:05:20] <k4ts> si
[23:05:27] <k4ts> visto
[23:05:29] <k4ts> poi
[23:05:30] <Jacky^> les_w: is not sure you like that
[23:05:42] <Jacky^> but i think yes, at 70 %
[23:05:48] <les_w> heh
[23:05:50] <Jacky^> :)
[23:06:09] <les_w> When I was in Nice the food was good.
[23:06:14] <Jacky^> its hard to like food from other countries
[23:06:30] <Jacky^> but naples got a lot of americans tourist
[23:06:36] <les_w> I helped on the beach unloading the fish catch from Sardinia
[23:06:53] <Jacky^> then they know waht they like ;P
[23:07:01] <les_w> Your food is better than ours
[23:07:20] <Jacky^> ive been in 2002 in L.A. for 20 days
[23:07:33] <les_w> ours has preservatives and hormones and chemicals in it
[23:07:43] <k4ts> http://www.cookaround.com/cucina/speciali/napoli-1.php
[23:07:44] <Jacky^> im afraid to say that, really.. food is very different
[23:07:46] <les_w> our food tastes like plastic.
[23:08:01] <Jacky^> but there are a lot of good things :)
[23:08:18] <Jacky^> les_w: ive not tried your best food
[23:08:23] <Jacky^> im sure..
[23:08:43] <les_w> Spaghetti alle vongole veraci
[23:08:48] <les_w> looks good
[23:08:49] <Jacky^> hahaha good
[23:08:56] <Jacky^> we love that plate
[23:09:34] <k4ts> pacco internazionale 23 /4 giorni escluso quello di spedizione
[23:09:40] <k4ts> 3
[23:09:45] <k4ts> 4
[23:09:49] <anonimasu> * anonimasu yawn
[23:09:50] <anonimasu> s
[23:09:58] <les_w> haha
[23:10:10] <Jacky^> k4ts: could be ok
[23:10:21] <Jacky^> I want to check other ways too
[23:10:27] <Jacky^> ups for example
[23:10:40] <Jacky^> anonimasu: how the things are going there ?
[23:11:11] <anonimasu> going good
[23:11:26] <Jacky^> already tried the AC motors you bought time ago ?
[23:11:46] <anonimasu> the fsckers didnt ship them
[23:11:55] <les_w> k4ts made me hungry. I am going to go cook dinner. later!
[23:12:04] <anonimasu> later
[23:12:09] <Jacky^> les_w: heh later ( a dopo)
[23:12:28] <Jacky^> anonimasu: ugh :(
[23:12:53] <Jacky^> so, you dont get them ?
[23:13:01] <anonimasu> nope
[23:14:01] <Jacky^> sigh
[23:14:08] <Jacky^> was a nice price
[23:14:46] <anonimasu> yeah
[23:14:56] <anonimasu> * anonimasu dosent understand girls
[23:15:10] <Jacky^> :)
[23:15:19] <k4ts> bha
[23:15:23] <k4ts> non si capisce
[23:15:27] <k4ts> le poste volgiono
[23:15:30] <k4ts> localit�
[23:15:32] <Jacky^> what ?
[23:15:56] <Jacky^> k4ts: no problem, we'll solve togheter ok ?
[23:16:41] <Jacky^> depend on what we want send
[23:18:34] <Jacky^> anonimasu: laready seen this website ? http://www.veroececcarelli.com/
[23:18:43] <Jacky^> have some nice job
[23:18:54] <Jacky^> they use a big printer for all
[23:19:15] <Jacky^> I know a 'wall printer'
[23:19:48] <Jacky^> are able to print on a lot of materials too
[23:22:18] <lerman> Is anyone around from last night's discussion?
[23:22:30] <lerman> About TP.
[23:22:36] <petev> yeah
[23:23:25] <lerman> A couple of thoughts-- (1) all the talk was about precomputing an optimal path. But why does it have to be optimal? It just needs to be good enough.
[23:23:44] <petev> u have to define optimal
[23:23:52] <petev> jmks idea was multi pass
[23:24:02] <petev> the first pass was position only
[23:24:13] <petev> it would calc the "racing line" within the error band
[23:24:28] <lerman> (2) I thought the discussion was considering B-splines parameterized in time. But I think the Sonja paper discussed parameterization in curve length.
[23:24:36] <petev> then machine accel, etc. would be applied to determine the speed limits
[23:24:51] <petev> I'm still muddling through sonja
[23:25:12] <petev> the idea from last night was to apply a tolerance or error band to the path
[23:25:25] <petev> then calc the smoothest path that fit inside
[23:25:33] <petev> maybe using splines to represent it
[23:25:45] <petev> then apply the machine constraints
[23:26:01] <petev> the parameter would have to be time
[23:26:17] <lerman> Yes, I saw jmks idea. But, again, if we limited look ahead, the compute time would be bounded and lots of problems would go away. So, draw the road, but only look a few segments ahead.
[23:26:19] <petev> could be some function of spindle speed or whatever
[23:26:47] <petev> if u only look a few segments ahead, u could have a problem
[23:27:12] <petev> use the road metaphor, it's like have headlights that only let u see so far, then a hair pin turn
[23:27:39] <lerman> Also, can anyone tell me how many b-spline segments I would need to match a circle within a given tolerance?
[23:28:00] <petev> don't know about that
[23:28:11] <petev> a circle is second order
[23:28:16] <anonimasu> no
[23:28:21] <anonimasu> I cant access it..
[23:28:21] <lerman> But we could plan the trajectory with our limited headlights and then adjust be speed so that we don't exceed the limits.
[23:28:37] <petev> how do u do that?
[23:28:57] <petev> if u are going to fast and u don't have enough brakes, u are screwed
[23:30:05] <petev> none of use could come up with a way to bound the look ahead required
[23:30:28] <petev> maybe something statistical, but not 100% deterministic
[23:30:33] <lerman> But as we did each segment, we could limit things so that we could stop within the distance our headlinghts can see. (After all, that's the way we drive a car.)
[23:31:23] <petev> yes, so take the case where the segments are ultra tiny, you still don't know how many segments u have to look ahead
[23:31:25] <anonimasu> hm, the lookahead needs to be as long as the time it takes to slow the machine down sufficiently to handle the requested motion
[23:31:27] <lerman> The downside is that we would be overly conservative. The key question, though, is what is the cost of that?
[23:31:47] <petev> anonimaso: exactly and we don't know how to bound that
[23:31:56] <lerman> anon: yes. Precisely.
[23:32:08] <anonimasu> couldnt you go through the path first, and determinate how far you need to look ?
[23:32:38] <petev> lerman: so how many segments of look ahead? It's not known or bounded, it depends on the path
[23:32:57] <lerman> But, we drive that way all the time. We look ahead, and then slow our prsent speed so that we don't go off the road.
[23:32:58] <anonimasu> max velocity/accel vs segments at t
[23:33:50] <petev> lerman: when u drive, the road is analog, not sampled, you effectively combine as many segments as required
[23:34:14] <lerman> If we had no look ahead, we would stop at the end of every segment. If we set a one segment look ahead, we would set our present velocity so that we could stop at the end of hte one segment ahead of us.
[23:34:17] <petev> the best we could do is say we can process X segments in Y time
[23:34:44] <lerman> No, we sometimes slow down because of fog, or because we can't see far enough ahead.
[23:34:50] <anonimasu> what about preprocessing the path?
[23:34:56] <petev> lerman: ok, if you want to limit things that way, u will never get close to what the machine is capable of
[23:34:58] <anonimasu> to determinate how far to look?
[23:35:11] <petev> that's what we talked about
[23:35:29] <petev> the pre-processing has problems when u need to do cutter comp cause a cutter broke or something
[23:35:57] <lerman> How do you know how close we can get? (I guess that's what my issue really is -- are we optimizing out the last 1% of performance, or are we trying to get the last 50%/)
[23:36:02] <anonimasu> petev: hm I didnt mean preprocess the whole path..
[23:36:21] <anonimasu> petev: just where to look further..
[23:36:27] <petev> lerman: I think that really depends on the stats of the path
[23:36:43] <lerman> anon-- what petev is saying, I think, is that the only way to be sure you are optimal is to preprocess the whole path.
[23:36:54] <petev> we have to look far enough ahead to be able to stop from the current velocity
[23:37:02] <anonimasu> yeah
[23:37:02] <anonimasu> agreed
[23:37:09] <lerman> But even then, we might find that the problem is intractable.
[23:37:12] <petev> right, we can't bound it
[23:37:37] <petev> we might find that we have to go slower on the whole path
[23:37:50] <petev> an can never reach the desired velocity
[23:38:03] <anonimasu> trye
[23:38:28] <petev> feed override was another can of worms
[23:38:51] <lerman> One of the big issues last night was that you might have too long a delay between changing the feedrate and having it take effect. But, if we know that the machine can stop in two seconds from maximum velocity, then we know that we only have to look two seconds ahead.
[23:38:55] <fenn_> fenn_ is now known as fenn
[23:39:03] <petev> I'm beginning to like the idea of a FIR filter and let the op adjust feed to control tolerance
[23:39:41] <fenn> lerman: how many line segments is two seconds?
[23:39:45] <lerman> The problem with that is there is no way to tell the operator the consequences of his actions in advance.
[23:39:56] <petev> lerman: yes, the queue only needs to be kept full enough to have enough look ahead to be able to stop
[23:40:16] <petev> lerman: true, but that's how controls work today, no?
[23:40:35] <lerman> I took a seminar with Kleinrock (of queueing systems fame) once, and he said that the answer to any question is "it depends".
[23:40:38] <fenn> look at this page, most of the way down, in "controls" http://www.moldmakingtechnology.com/articles/030303.html
[23:41:11] <lerman> The above was addressed to fenns question of how many line segments is two seconds.
[23:41:31] <fenn> yep, "it depends" is not time-bounded and thus unsuitable for a rt process
[23:42:19] <anonimasu> hm, you could calculate it off the distance the machine can go..
[23:42:37] <petev> fenn: what are we supposed to get from that, that we need different planner modes?
[23:42:54] <lerman> But, when there a lots of small segments, we could just slow down. That would limit the number of segments to look ahead and thus set a bound.
[23:42:59] <fenn> petev: just showing that even commercial controls can't do everything at once
[23:43:05] <petev> ahh
[23:43:08] <fenn> they put the choice right up into your face
[23:43:20] <fenn> instead of hiding it in some obscure parameter to g64
[23:43:58] <lerman> Moldmakers are mostly concerned with precision and finish and less concerned with speed.
[23:44:17] <fenn> oh i'm sure they care about speed too
[23:44:22] <fenn> time == money
[23:44:36] <petev> lerman: we could always look ahead X segments and limit our speed to whatever distance that covers
[23:44:41] <petev> that's like driving
[23:44:53] <petev> but far from optimal
[23:44:59] <petev> take your fog case
[23:45:04] <anonimasu> yep
[23:45:07] <lerman> petev: exactly! I think that's what I'm saying.
[23:45:19] <petev> u could driver the same road faster without the fog than with
[23:45:29] <anonimasu> hm, just because you are looking ahead dosnt mean you have to slow down..
[23:46:00] <petev> anonimasu: what if the next segment is a sharp corner?
[23:46:04] <lerman> Ahhh. How far from optimal? (you need to get out there and count how many angels can dance on the head of that pin).
[23:46:14] <petev> u have to be able to stop within look ahead distance
[23:46:28] <anonimasu> petev: that's what I've been saying like 8 times..
[23:46:29] <petev> lerman: yes, path dependant
[23:46:40] <lerman> Well, if the next segment is a sharp corner, you will have to slow down in any case.
[23:46:58] <lerman> So, that doesn't change the optimality of the path.
[23:47:16] <anonimasu> you need to have enough lookahead to stop the machine in all cases..
[23:47:19] <fenn> but if it's not a sharp corner, you will have slowed down for no reason
[23:47:43] <petev> lerman: so do u have paths we can get stats from and see how far from optimal some value of X for look ahead would be?
[23:47:51] <anonimasu> you can calate that by the speed the machine is moving in..
[23:49:06] <lerman> Hell, I don't have any paths at all. But we could make some examples, I suppose -- well, probably not me, but someone could.
[23:49:23] <fenn> what's the problem with the speed-limit idea? 99% of the time you will be machining at well below the limits
[23:49:40] <anonimasu> petev: why wouldnt that approach work?
[23:49:46] <petev> fenn: we are trying to get out of having to pre-process the whole path
[23:49:47] <lerman> We probably should look at some automatically generated code to cut something like a saddle shape.
[23:49:52] <fenn> petev: why?
[23:49:56] <petev> anonimasu: which approach?
[23:50:26] <petev> fenn: so when a cutter breaks and we need to do comp, the op doesn't have to wait
[23:50:33] <fenn> oh gimme a break
[23:50:44] <petev> fenn: that is real
[23:50:57] <anonimasu> petev: calculating how long distance it takes to stop the machine and keeping that as lookahead..
[23:51:02] <petev> or when the cutter has been sharpened and is slightly smaller
[23:51:11] <fenn> you are going to limit the performance of the maching *always* so you dont have to wait if the operator re-sharpens a cutter??
[23:51:16] <petev> anonimaso: that is not bounded
[23:51:53] <petev> fenn: no, the path was done for 1/2" cutter, but op has 0.48" cuttern because it was sharpened
[23:51:57] <petev> what does he do?
[23:52:05] <fenn> he waits for the damn computer to calculate the path
[23:52:10] <anonimasu> petev: yes that's right..
[23:52:16] <fenn> people wait on computers all the time
[23:52:40] <fenn> we dont even know how long it will take to process a path
[23:52:42] <petev> fenn: I don't think the shop owner would be happy with that solution
[23:52:58] <fenn> i dont think he will be happy with his machines always going at 2 ipm
[23:53:05] <petev> true
[23:53:14] <fenn> or slowing down on complicated sections
[23:53:19] <fenn> for no particular reason
[23:53:20] <petev> but we should be able to do most of both I hope
[23:53:47] <anonimasu> petev: I can see the case where the bounding is nescessary...
[23:53:56] <petev> yes
[23:54:18] <anonimasu> petev: but, if you cant have enough lookahead maybe you shouldnt machine at that speed..
[23:54:28] <anonimasu> petev: it's like driving without headlights..
[23:54:41] <petev> maybe lermans sub-optimal approach will be good enough for 99% of the paths with some look ahead of X, I don't know
[23:55:00] <petev> anonimasu: exactly
[23:55:09] <anonimasu> there's no way around that really
[23:55:27] <anonimasu> could you estimate it?
[23:55:31] <petev> anonimasu: right, u have to process the whole file in batch mode
[23:55:41] <lerman> Let's see: the distance we go at max accel , s = a*t^2/2. And v^2 = 2 * a * s. If someone can plug in some real numbers for the maximum velocity and acceleratoin of some real machines, we can figure out how far ahead we have to look and how much time ahead we have to look to guarantee a stop in the look ahead distance.
[23:56:08] <petev> lerman: I already have a spread sheet on this
[23:56:13] <petev> what's your email?
[23:56:32] <lerman> lerman-emc at se-ltd.com
[23:56:43] <anonimasu> petev: if you preprocess the path and flag how long lookahead you need for pos x of the path you can always keep enough lookahead.. but it might be a bit hard to accomplish
[23:57:39] <fenn> yes you could do both
[23:57:41] <anonimasu> you can bound the lookahead if you do it like that and also flag some segments before to get the machine to start slowing down..
[23:57:54] <anonimasu> that'd generate a optimal path at the fastest possible speed..
[23:58:02] <anonimasu> I dont know about practical..
[23:58:20] <anonimasu> but, that wouldnt have troubles with boundries..
[23:59:03] <fenn> "warning sharp curve ahead 25km/h"
[23:59:07] <anonimasu> yeah
[23:59:14] <petev> lerman: sent email
[23:59:31] <anonimasu> fenn: that's a excelent quote :)