cradek, u there?
only a little
I have some TP questions
I have been looking at how to apply Macfarlane to arcs and I think I have a solution
but it raised some questions with the current TP
which macfarlane? the concatenated splines?
when you are traveling on an arc of a given radius at a given speed
the max tangential acceleration depends on the position on the arc and is not constant
how does the current TP deal with this?
I didn't see anyhing in the code that looked like it was taking this into account
it does the suboptimal but easy thing, look in emccanon.cc
not in the TP?
ok, guess that's why I couldn't find it
yes all motions have their vel and accel calculated outside TP
(based on machine constraints and programmed feed)
hmm, that won't work well with look ahead at all
how is overrid applied then if the segments are already queued?
the machine constraint (not considering requested feed) is also passed to TP with each segment
override can go up to that value
ok, I guess the changes for look ahead an jerk limitation will be more extensive than just the TP if we don't want to waste cycles elsewhere
cradek, u back?
can you take a look at cannon.cc with me?
I added a comment for you
sure as long as you don't blame me
I think I see code that is wrong
let's start with getStraightAcceleration()
246 in old file
let me cvs up
lerman_ is now known as lerman
why is a = d / t ?
should a = 2 * d / (t ^ 2) ?
the routine below uses the same calc for velocity unless I'm missing something
I'm pretty sure I had what you wrote, and it simplified ... somehow
I doubt that seems very convincing from where you're sitting
I'm digging in the history
I don't think the calcs for arc are correct either
the accel and vel routines look like cut / paste of each other with minor change
maybe someting got messed up
I'm pretty sure that was the intent
ok, let's look at the arc stuff
I'm looking around line 950
yeah I changed the getStraightAccel from what you said in rev 1.44
hmm, any comment why?
ok, I think it probably needs fixing
let's look at line 960
the arc calc seems to have the same problem
and I don't think the acc is right either
the acc seems to be the min of all axis involved
[01:54:16] <cradek> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/task/emccanon.cc.diff?r1=1.43;r2=1.44
yes that's the intent for the arc case - see my comment
but this doesn't take into account that both a normal and tangential component are needed
sure it does
oh, the normal is limited later
this is tangential only
by normal you mean the one based on radius?
but if all the acc is used on tangential, there may not be enough left to provide the normal acc
in that diff ^^ you can see the simplification I made
yes, normal to velocity heading
you're not considering that normal and tangential are perpendicular
if you do the worst case
what's the worst case? I'm not seeing it
it happens when the normal and tangetial add to create a force parallel to one of the axis
I think the worst case comes out cos(45) * min( accX, accY) or whatever plane is involved
if you make the tangetial acc higher than that, you will have a problem
hmm you might be right
I drew pics today ;-)
I gotta finish my books for taxes, but I wan to get back to this as soon as I get caught up
ok I see how getStraightAcceleration works. the times are t^2
I just removed the sqrts
did you see that diff?
[02:01:26] <cradek> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/task/emccanon.cc.diff?r1=1.43;r2=1.44
where's the factor of 2?
look at the diff
the second diff?
the one three lines up
you can see the way you want to write it, the way I changed it, and why they are equivalent
ok, t is not t at all
if it's still wrong say so - but this is well tested :-)
I'm much less sure about the arc case being well tested...
I think the arc needs the cos(45) for sure
the T part might work out
it would be nice to see a wrong halscope plot of an arc to be sure
when the normal and tangential are each stradling an axis at 45 degree
the resultant vector will be parallel to the axis
in order to limit that to the axis acc, you can see they each have to be cos(45) times the axis acc
but isn't the tangential zero?
not if you are accelerating
like an arc from 0 vel for instance
but if you're accelerating the normal isn't yet sqrt(a/r) or whatever it turns out to be either
true, as vel builds you have less acc left for tangetial as more is used by normal
but you need to set a safe limit
you start out with the A all tangential and it turns into all normal when you're up to tangential vel
the optimal solution is complex
I'm not yet sure it's wrong, but I think we should do the test cases
but you can't use the full acc as tangential to calc the max vel
at least not over the full path length
it changes as vel increases
and that makes things complex
but if you limit tangential and normal to cos(45) times axis acc, you can't got wrong
so if I do some semicircles you think I'll see an accel constraint violation?
the other thing is, what happens if you are at max vel and all acc is normal?
how do you slow down without going off path?
yes, I think you will if the max velocity is high enough
petev: instead of this speculation, propose a test case and then test it
I drew pics and force vectors today
I'm about 100% sure
you can easily write a g-code arc that starts at zero speed and goes off in a 45 degree direction
jmkasunich: this helps come up with the right test case! but I agree it would be nice to see
and I don't see any easy way to test
then use halscope and a couple ddt blocks to measure the accel demanded on each axis
in configs/sim I have a very nice check_constraints.hal
I think a g-code circle with the machine max velocity set high would show the issue
you can do a large radius arc (small radial accel, so limited by tangential) and then a very tight arc ( so it will be limited by radial accel)
a single test case showing a voilation is worth 10 hours of talking
the problem is when both accel add to be parallel to an axis
either case taken alone is not a violation
so write g-code that invokes that case, and run it
I'm still not sure they add - you trade one for the other as you start and stop
but yeah, I'm with jmk :-)
if you're right it sounds easy to fix, so that's nice
cradek, do you agree that while you are accellerating you have both force components in play?
sure if you're on the path
but neither one is at its max
right, so they do add and you have to take the vector sum into account
they can be at max with a trapezoidal velocity profile
the two components are orthogonal
acc is max until vel is reached
jmkasunich, I know
when you are at 45 degrees they add to be parallel to an axis
jmkasunich: I kept saying that too, but they're not necessarily along separate axes, which is what's important
the axis alignment isn't really the issue
petev is convincing me but I still want a test case because I'm stubborn that way
it is, if you use the axis acell as the limit
the it has to be the limit of the vector sum
not just one or the other
the vector sum of tangential and radial accels needs to be kept within spec, regardless of what direction that vector happens to point
but the limit is now set by the min axis acc
that is the worst case
and easy way to do it
in addition, I don't think you ever want to use all the acc as normal or you will have a problem slowing down at a decent rate and staying on path
"use all the accel as normal" translates into a velocity limit (for any given radius)
yes, but how do you slow down and stay on path?
you could calculate the speed limit to be that which requires 0.707 of the limit accel
leaving 0.707 of the limit accel available for tangent stuff
that's what I said cos(45)
that keeps the vector sum in spec
they can both be cos(45) * axis acc
and things will remain in spec
FO may screw this up
FO screws everything up
no maybe not, I dunno
this is the speed limit and accel, FO needs to remain within these bounds
I think it should work out ok
use the acc number for the trapzoidal vel profile and limit the vel to the max or FO, whichever is less
the normal accel going up has me worried
I wish I could draw a pic
if you limit to cos(45) for both normal and tangential
yeah talking geometry is really hard without pics
the vector sum will remain within limits
component oneshot is
clk : in std_logic;
delay : in std_logic_vector(10 downto 0);
input : in std_logic;
output : out std_logic
end component oneshot;
[02:29:55] <jmkasunich> http://www.drawblog.com/
man I can't even straight
no suitable plugins were found.
it uses some kind of flash
I haven't crapped up this machine with nonfree software yet...
it needs an eraser ;-)
turn the pen white
(I know,that sucks as an eraser)
petev: I hope you fix this - then I can say `you touched it last'!
petev: I'd be tickled if you'd write a test, show it's broken, fix it, and then verify the fix
jmkasunich, what are you supposed to do with the HTML afterwards?
it generated some html
wait, I think there is a link in there
[02:36:38] <petev> http://www.drawblog.com/images/20070405073411637.jpg
yeah, just copy the jpg url
ok, don't laugh, I can't draw worth a shit with my mouse
* cradek squints
the vector sum of the axis acc is limited to the rectangle
it's a cyclops?
the large circle is the path
we are in the lower left quadrant
the normal and tangential acc are transposed to the origin for the vector sum
where they add up to be parallel to Y axis
you can see if they are both limited to cos(45) then they will add and stay within limits
so your test case should be an arc that, in order to stop, starts to decel at 45 degrees to the axes
the small circle has radius of min acc of X and Y
yes, that should show it if you are running at max velocity
this is totally hidden if you do only quadrant arcs, right?
well almost totally hidden
you mean if an arc stays within a quadrant?
no if it starts and stops on quadrants of the circle
because your two accels are on separate axes
no, you should still see it if you reach max arc velocity
* cradek grumbles 'and people want splines'
max arc velocity would have the normal force out to the small circle
any addition of tangential force would exceed the limits
in the case I drew, X has more acc then Y
if they were the same, it would be a box around the circle
and it would be easier to get outside the box
the non optimal solution, limits the vector sum to the small circle
while limiting it to the box/rectangle is what's really required
I'm as convinced as I can be without a test case, thanks for finding it
ok, I'll work on it as soon as I get this tax stuff dealt with
crap, it's late already
lerneaen_hydra_ is now known as lerneaen_hydra
Im michal form emc user list
Guten Abend Jeff
besides being laid out wrong, some of the kezs on this kezboard are unreliable
I'm thinking the same about my new US layout :P
* cradek snickers
see you all later
lerman_ is now known as lerman
lerman_ is now known as lerman