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