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