Back
[00:00:32] <cradek> is `offset' a reserved word in C++?
[00:01:04] <cradek> aha, forget it
[00:01:15] <jepler> cradek: not that I'm aware of
[00:01:16] <cradek> very misleading gcc error message
[00:01:23] <cradek> but I figured it out
[00:01:25] <jepler> oh good
[00:22:35] <jepler> it looks like the failure of stepgen.0 is harmless, but the failure of stepgen.1 is sinister
[00:22:46] <cradek> oh?
[00:22:52] <jepler> the pins stepgen.0.phase-A and stepgen.0.phase-B don't even exist
[00:23:13] <jepler> (it uses quadrature, not step+direction)
[00:24:33] <cradek> hmm that's not a trivial failure
[00:25:03] <jepler> in the tests stepgen.0 and stepgen.2 there's actually one fewer step taken than before
[00:30:22] <cradek> jepler: that breaks the encoder test too
[00:30:27] <jepler> cradek: oh is that why?
[00:30:45] <cradek> yes, it uses stepgen/quadrature too
[00:30:54] <jepler> I hadn't gotten that far
[00:36:00] <SWPadnos> export_pid initializes all the struct members
[00:53:22] <cradek> I think few people use radius compensation
[00:53:34] <SWPadnos> I suspect you're right
[00:53:49] <SWPadnos> and the speed of modern computers makes it less likely to be used in the future
[00:53:51] <cradek> I think I've never seen a bug report on it
[00:54:09] <SWPadnos> (since you can regenerate compensated toolpaths so quickly)
[00:54:13] <cradek> yeah, it's probably only useful/needed for people who hand-write gcode
[00:54:30] <SWPadnos> it's probably useful for others, but they don't care ...
[00:54:36] <cradek> it sure is needed more with lathe
[00:55:27] <SWPadnos> I also think that the machining industry is moving more toward sending "higher level" information to shops
[00:55:49] <SWPadnos> tool comp is much more valuable when you send a part program to several shops for manufacture
[00:56:05] <SWPadnos> less so when you email a SolidWorks model and the shop generates their own toolpaths
[00:56:14] <cradek> true
[00:56:26] <SWPadnos> but I don't mean to sound like a downer on that - I like it :)
[00:56:43] <cradek> well it'd be nice to have it fully working before it becomes totally obsolete
[00:56:47] <SWPadnos> heh
[00:56:57] <cradek> (I sure have found a lot of things wrong with it lately)
[00:57:03] <SWPadnos> indeed you have
[00:57:07] <cradek> this was the last one, of course
[00:57:20] <SWPadnos> of course
[00:57:30] <SWPadnos> (last one found or last one there? ;) )
[00:57:35] <cradek> last one there
[00:57:44] <SWPadnos> oh, good!
[00:57:51] <cradek> yeah, it's a real relief to know that
[00:58:38] <cradek> jepler: I really like the sai based tests
[00:58:44] <SWPadnos> hmmm. now where's my hotel reservation for tomorrow
[01:00:59] <SWPadnos> ok. Mesa card going into kiosk PC, and Ubuntu, too. woohoo!
[01:01:17] <cradek> cool
[01:01:41] <SWPadnos> and I even have breakouts now, so I can connect a scope or something
[01:02:45] <SWPadnos> I wish there was a header for the LEDs on the board
[01:03:01] <SWPadnos> it faces "down" with the PCI riser card in this machine
[01:03:10] <cradek> hm that's too bad
[01:19:20] <cradek> it's interesting that a test program (lathecomp) I have looked at on-screen 100 times was wrong and I never noticed
[01:19:29] <SWPadnos> heh
[01:57:36] <roltek> are you saying that programmers don't use tool comp
[01:58:08] <SWPadnos> no, I'm saying that people seem to be forgetting that it's useful, since they can "rerender" the toolpath in seconds
[01:58:36] <roltek> it takes more than seconds
[01:58:53] <roltek> seconds = .oo5 in to tool comp
[01:59:00] <petev> assume that at end of look ahead vel must = 0
[01:59:12] <petev> because there may be a hair pin or brick wall or whatever
[01:59:26] <petev> start processing look ahead segments in reverse order
[01:59:33] <petev> apply max decel to each segment
[01:59:50] <petev> work all the way back to the current segment to arrive at it's max velocity
[01:59:59] <petev> accel towards this velocity
[02:00:11] <petev> repeat for the next segment
[02:00:26] <petev> you could apply any type of blending with this algo
[02:00:37] <SWPadnos> ok - let's shoot holes in that idea :)
[02:00:39] <cradek> I agree that sounds like a good plan
[02:00:46] <cradek> well except for swp's holes
[02:00:49] <cradek> like feed override
[02:00:52] <petev> ok, go for it
[02:01:10] <petev> why would that be a problem?
[02:01:10] <SWPadnos> one issue is that you never know how many segments you'll need before you "overrrun the headlights"
[02:01:32] <SWPadnos> any preprocessing gets thrown out once FO is changed
[02:01:33] <petev> SWPadnos, you are always staying within the look ahead you have
[02:01:38] <petev> please read again
[02:02:06] <SWPadnos> sure - it's bounded by the lookahead length, so that'll control the top speed (in some cases) - that's fine
[02:02:10] <petev> you have to process the whole lookahead again any time you get more segments or FO is changed
[02:02:17] <SWPadnos> right
[02:02:33] <petev> so what is the problem?
[02:02:43] <petev> you think that's too CPU intensive?
[02:03:07] <SWPadnos> it's not much of a problem I guess - I just think of the pathological cases :)
[02:03:29] <cradek> if you are doing it in realtime, there can be no pathological cases
[02:03:41] <SWPadnos> right
[02:04:03] <petev> I'm pretty sure this is what most commercial controls do, but there may be some tricks to reduce processing time
[02:04:04] <SWPadnos> there are cases where this won't help, and there are cases where you're doing way more work than needed
[02:04:12] <SWPadnos> "can't help" cases can't be helped ;)
[02:04:26] <SWPadnos> but, you can do more or less the same thing in the forward direction
[02:04:44] <petev> explain how forward direction would work
[02:05:21] <SWPadnos> start at the current segment, and assume you can go full speed. go forward through the lookahead until you (a) outrun the headlights or (b) hit the end of the buffer
[02:05:37] <petev> how do you know when you outrun?
[02:05:52] <SWPadnos> it's just path length/accel, actually
[02:05:56] <petev> I think you can process the reverse direction and then do incremental work for each new seg
[02:06:16] <petev> I don't see how the forward direction works at all
[02:06:36] <petev> you need to be able to stop by the end of the look ahead
[02:06:45] <petev> because you don't know what comes next
[02:07:03] <SWPadnos> yes, if you hit the end of lokoahead, then you know the total path length in the buffer, and can scale the speed downward
[02:07:34] <SWPadnos> once you've looked at "worst case", anything else is easy
[02:07:49] <petev> listen, all you have to do for the reverse direction is calc the new seg, then apply the previous calcs for all the preceding segs
[02:07:59] <petev> you work backwards to determine the same vel
[02:08:21] <petev> same^safe
[02:09:11] <SWPadnos> but the planned vel at the end of the buffer is 0, so I think you have to do all the work over once a segment is added to the buffer
[02:09:33] <petev> no, you don't
[02:09:47] <petev> you are adding up the acels for each seg in reverse order
[02:10:04] <petev> so all you have to do is drop the seg you just moved and add in the new one
[02:10:39] <petev> changing FO is another story
[02:10:47] <petev> there you have to calc each seg again
[02:11:07] <petev> or at least apply limits
[02:11:23] <SWPadnos> ok, so you keep an accel value for each item in the queue
[02:11:28] <petev> yes
[02:11:30] <SWPadnos> and then it's a moving sum
[02:11:32] <SWPadnos> hmmm
[02:11:43] <petev> actually a decel, but lets assume its the same as accel
[02:11:51] <petev> right
[02:12:05] <SWPadnos> well, if I have a zig-zag in the queue, then it's both
[02:12:27] <petev> no, I'm saying lets assume max axis accel and decel are equal
[02:12:37] <petev> you would calc safe vel from decel
[02:12:42] <petev> then use accel to reach it
[02:12:51] <SWPadnos> sure - there is only accel, it's just sometimes opposite the current motion ;)
[02:13:13] <cradek> some moves "use up" accel on their own (centripetal on arcs)
[02:13:23] <petev> I can imagine wierd machines where the two values may not be equal, but that's another issue
[02:13:29] <cradek> so path length doesn't give you all the info you need
[02:13:43] <SWPadnos> sure - I'm not considering anything too weird here
[02:13:52] <petev> cradek, pathlen tells you safe vel at any time
[02:13:58] <petev> it doesn't mean you can reach it
[02:14:07] <SWPadnos> no, you have to take direction into account
[02:14:08] <petev> it just gives the max safe value
[02:14:18] <SWPadnos> ok - that's true
[02:14:23] <petev> sure, that's part of the calc for each seg
[02:14:27] <SWPadnos> hmmm - no it's not true
[02:14:39] <cradek> I don't understand what you mean by 'safe'
[02:15:01] <petev> safe means you can stop the machine, staying on path, by the end of the look ahead
[02:16:03] <cradek> I'm just saying that is NOT a factor of just length
[02:16:03] <petev> so anything less than safe is ok, like if FO is turned down
[02:16:18] <petev> length and type of motion
[02:16:35] <petev> when you calc the accel for each segment, you consider it's shape
[02:17:07] <cradek> ok, if you are saying it's a factor of length, shape and direction, I agree
[02:17:32] <petev> so a small circ would not result in the same vel delta as a large circ using same accel
[02:17:47] <cradek> right
[02:17:47] <SWPadnos> or a line with the same path length
[02:17:52] <petev> right
[02:18:13] <cradek> and a line in a diagonal doesn't give the same delta as an axis-aligned one
[02:18:14] <petev> so you calc the vel delta for each seg
[02:18:34] <petev> true
[02:18:36] <SWPadnos> ok, so "max accel" for each segment would be related to the type of segment and the relative angle of the next segment
[02:18:55] <petev> yes, the goal is to determing the vel delta for each seg
[02:19:30] <SWPadnos> and for each axis, I think
[02:19:32] <cradek> petev: if you jump in and start coding this, I might be able to help - but I don't have the momentum to write a new planner by myself
[02:19:38] <SWPadnos> I'm not sure they can be compressed into one number
[02:20:04] <petev> let me think more about how to structure the code to keep it nice
[02:20:04] <cradek> we already *have* the max vel and accel along each segment
[02:20:05] <SWPadnos> actually, you could use the one with the lowest factor (max_calculated/max_setting)
[02:20:19] <petev> somewhere in all this the blending has to be applied too
[02:20:38] <cradek> hi jmk
[02:20:48] <jmkasunich> hi
[02:20:58] <SWPadnos> yeah - also, there's the fact that there is probably a programmed feedrate, so max isn't necessarily only machine dependent ;)
[02:21:04] <petev> cradek, how many segments are considered in the planning now? I thought it only looked ahead one
[02:21:15] <petev> SWPadnos, true
[02:21:15] <jmkasunich> we must have had a power dip, or phone line probs (thunderstorm while we were out this evening)
[02:21:18] <petev> but that's easy
[02:21:29] <cradek> petev: right, it mostly considers two at a time (uses three for some calcs)
[02:21:41] <SWPadnos> jmkasunich, I noticed you left - wasn't sure why :)
[02:22:07] <petev> ok, so this may be an extension of what you have already done if you already can make calcs for each seg after blending
[02:22:26] <jmkasunich> PC stayed up, but the dls modem and/or the router needed a reboot
[02:22:39] <SWPadnos> that reminds me - time to get a new UPS or two
[02:23:29] <SWPadnos> I noticed that the one on the modem/router is bad when I popped a breaker testing my servo transformer :)
[02:24:56] <SWPadnos> petev, I think it doesn't matter which direction you calculate from, but you may be able to shortcut the calcs by going forward
[02:25:43] <SWPadnos> since each segment has a max accel/vel needed already, you can just start with MAX and subtract when going forward
[02:26:26] <SWPadnos> if you hit 0, then you can safely run at full speed/accel, since the buffer is long enough to safely stop
[02:26:38] <petev> how do you figure the MAX vel if you don't work backwards? it's not the max vel for that segment, it's the max safe vel you need
[02:26:53] <SWPadnos> MAX is in the machine setup
[02:26:55] <jmkasunich> jepler: I see you caught an oops in stepgen too - thanks
[02:27:03] <jepler> jmkasunich: no problem
[02:27:23] <SWPadnos> you'd have to limit the sum to the ini value anyway, when working backwards
[02:27:33] <petev> is the MAX you're talking about the value so you can stop at the end of each segment?
[02:27:48] <petev> that's not what we want here
[02:27:57] <cradek> you may as well start with min(machine limits, F word) and work forward to zero
[02:28:05] <cradek> you don't need to look any further ahead than that
[02:28:06] <SWPadnos> no, I guess I'm saying that as long as max accel is sufficient to stop at some point within the queue, then it's safe. it's only when you would overrun the queue that you need to reduce it
[02:28:23] <SWPadnos> right - that's what I'm describing
[02:28:30] <SWPadnos> or trying to describe
[02:28:52] <petev> right, but you have to determine that
[02:29:03] <SWPadnos> no - there are already two bounds for accel
[02:29:11] <SWPadnos> one is zero, the other is in the ini file
[02:29:26] <petev> its vel we need to bound
[02:29:33] <petev> accel is bound by machine and jerk
[02:29:37] <SWPadnos> those are also bounded by (0, max from ini)
[02:29:40] <SWPadnos> ok
[02:29:48] <SWPadnos> jerk is another story :)
[02:29:53] <cradek> hey I resent that
[02:30:04] <SWPadnos> I wasn't talking about you
[02:30:06] <SWPadnos> (this time)
[02:30:08] <jmkasunich> jerk
[02:30:56] <cradek> http://timeguy.com/cradek-files/emc/bounded-jerk.png
[02:31:06] <cradek> I wrote this based on one of the McFarlane papers
[02:31:29] <cradek> I never got it to work quite right, but this shows a bounded-jerk accel from stop
[02:31:36] <jmkasunich> from the top: pos, vel, accel, and jerk?
[02:31:41] <cradek> yes
[02:31:47] <petev> cool
[02:31:51] <jmkasunich> you went beyond bounded jerk
[02:32:09] <petev> yeah, it looks like smoothed
[02:32:11] <cradek> yeah, the jerk is smoothish and sineish
[02:32:17] <jmkasunich> even the next deriviatve would be bounded
[02:32:22] <SWPadnos> "snap"
[02:32:24] <cradek> no, it has discontinuities
[02:32:41] <jmkasunich> discontinuities yes
[02:33:00] <SWPadnos> it's bounded, but its next derivative isn't
[02:33:05] <petev> I read in one of the papers that this (bounded 5th order) is actually desireable for HSM
[02:33:14] <SWPadnos> yep. the Sonja paper, I think
[02:33:30] <jmkasunich> jerk is bounded and continuous in that pic - "snap" is bounded and discontinuous
[02:33:31] <SWPadnos> hmmm - that may have mentioned it for robotics
[02:33:44] <cradek> I have the paper around somewhere if you guys can't find it anymore
[02:33:57] <cradek> I think I saw it (printed) recently
[02:34:01] <petev> I think there is a wiki page with a bunch of links
[02:34:03] <SWPadnos> cradek, is that the full plot? (ie, with vel back to 0 at the end)
[02:34:07] <jmkasunich> I have it on disk I believe
[02:34:21] <jmkasunich> SWPadnos: the third one down is accel, not vel
[02:34:25] <cradek> no, this is just the acceleration
[02:34:30] <jmkasunich> the plots show only the start
[02:34:33] <jmkasunich> starting is the easy part
[02:34:37] <cradek> stopping would look the same
[02:34:41] <SWPadnos> ok
[02:34:51] <jmkasunich> it deciding when to begin slowing down to stop at the right place that gets tricky
[02:35:00] <cradek> yes
[02:35:03] <petev> jmk, read back
[02:35:09] <petev> this is what we were discussing
[02:35:17] <cradek> jmkasunich: you mean even in one segment right?
[02:35:17] <SWPadnos> he can't - he was disconnected :)
[02:35:20] <jmkasunich> how far back?
[02:35:20] <petev> I don't think it's too bad
[02:35:24] <jmkasunich> 15 mins is all I have
[02:35:33] <jepler> logger_dev: bookmark
[02:35:33] <jepler> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-03-15.txt
[02:35:41] <petev> you said that yesterday ;-)
[02:35:56] <cradek> I have to run
[02:36:00] <SWPadnos> should have started att roughly 2:00 UTC
[02:36:04] <SWPadnos> heh
[02:36:11] <cradek> petev: I can't wait to see some code, I'm glad you're interested in this
[02:36:20] <SWPadnos> maybe I should change that so it uses a random phrase each time :)
[02:36:30] <petev> let me think about code structure more
[02:36:44] <petev> need to dust off all that matrix math and what not
[02:36:52] <SWPadnos> heh
[02:37:01] <SWPadnos> let me know if you have any pure math problems
[02:37:02] <cradek> when I wrote this one, we didn't have simulator/debugger for the realtime part - it will be nicer working on it today
[02:37:08] <SWPadnos> my mother is interested in solving stuff like that
[02:37:16] <petev> ok
[02:37:21] <SWPadnos> (as long as the solution you want is another equation ;) )
[02:37:39] <petev> I see several steps
[02:37:49] <cradek> SWPadnos: I had big problems with boundary conditions in this mcfarlane algorithm - maybe she can help out if we try to tackle that
[02:37:55] <cradek> ok, goodnight all
[02:38:03] <petev> gn
[02:38:14] <SWPadnos> as long as I can tell her that it's purely theoretical and has no application to the real world, I'm sure she can help
[02:38:23] <SWPadnos> night
[02:38:48] <jmkasunich> I had an idea for lookahead, but things like o-words make it impossible
[02:39:03] <petev> why is that?
[02:39:11] <petev> lookahead should be what is already in RT
[02:39:13] <SWPadnos> if it's done at the motion level rather than the interpreter level, it should be OK
[02:39:20] <petev> the interp should deal with O words, no ?
[02:39:34] <jmkasunich> just run the entire program backwards, recording the max allowable velocity at each critical point (beginning of each segment basiclly)
[02:39:46] <petev> yes, exactly what we discussed
[02:39:47] <SWPadnos> heh - that's what pete suggested
[02:39:56] <petev> and the tricks to shorten the calcs
[02:39:57] <SWPadnos> except limited to the queue length
[02:40:04] <jmkasunich> from the very end, only once?
[02:40:07] <petev> right
[02:40:15] <SWPadnos> no, whenever the qqueue changes
[02:40:16] <petev> from the end of lookahead back
[02:40:26] <petev> assume vel=0 at end of lookahead
[02:40:33] <jmkasunich> right, which means you are constantly doing it over and over
[02:40:35] <SWPadnos> acc=vel=0
[02:40:35] <petev> then cal like moving sum
[02:40:41] <petev> jmk, no
[02:40:50] <petev> the moving sum trick helps the calcs
[02:40:57] <jmkasunich> every time you add another item to the queue I would think
[02:41:10] <petev> drop the current segment, and add in the new one
[02:41:15] <SWPadnos> nope - you add the new one and subtract them as they're retired
[02:41:20] <petev> you don't need to calc them all over again
[02:41:33] <jmkasunich> if the last 50 items were nearly linear, and you add a hard left turn, that reduces the limit for everything else in the queue
[02:41:46] <petev> no, it's like this
[02:41:52] <SWPadnos> no, because the assumption is that you have to come to a dead stop at the end of the queue
[02:41:53] <jmkasunich> at least the ones immediately prior to the turn
[02:42:01] <petev> each item in the queue stores the vel delta for that segment
[02:42:28] <petev> you add the vel deltas in reverse order from 0 back to current pos to determing max safe vel
[02:43:09] <petev> it's like driving
[02:43:22] <petev> as long as you can stop in the distance you can see, you are ol
[02:43:23] <petev> ok
[02:43:32] <jmkasunich> ok - but you also have to store a max vel for each segment, and if the sum exceeds that at any point, clamp it
[02:43:41] <petev> right
[02:43:51] <petev> it would also be clamped by FO
[02:44:00] <jmkasunich> not an issue for straight stuff, but for curves it matters
[02:44:19] <SWPadnos> curves have a different calculation for max vel/accel, but it can still be stored
[02:44:23] <petev> I don't follow, this works for curves too
[02:44:26] <jmkasunich> if you have 310 straights, a 20mph curve, and then 50 straights
[02:44:29] <jmkasunich> oops
[02:44:33] <jmkasunich> 30 straights
[02:44:39] <SWPadnos> you need to take into account the length, shape, and relative angle for each move
[02:44:47] <jmkasunich> you can't sum all the way back over the 81 segs
[02:45:05] <petev> I see what you're saying
[02:45:08] <jmkasunich> you gotta start at 25mph at the curve and only sum over the ones between you and the curve
[02:45:40] <petev> so there are some max limits along the path that need to be obeyed
[02:45:44] <jmkasunich> so you start at the end of the buffer like you said, with zero, sum your way back towards current pos
[02:45:46] <SWPadnos> it has to be limited by FO, feedrate, machine limits, and path length
[02:45:53] <SWPadnos> among other things
[02:45:55] <jmkasunich> but if at any point the sum > the segment limit, clamp the sum
[02:46:12] <petev> SWPadnos, JMK is saying each segment also has a speed limit
[02:46:19] <SWPadnos> sure
[02:46:24] <petev> you can't exceed the speed limit
[02:46:28] <jmkasunich> I think that breaks the moving average optimization, but not the basic concept
[02:46:30] <SWPadnos> that's programmed rate
[02:46:33] <a-l-p-h-a> hey SWPadnos I read Mariss' thing... so essentially, he's saying "test it" if it's hot, it's bad.
[02:47:04] <SWPadnos> that's why I'd go forward through the buffer. once you hit any of these conditions, you stop the calcs:
[02:47:12] <SWPadnos> 1) total vel is above programmed rate
[02:47:25] <petev> forward doens't help
[02:47:34] <SWPadnos> 2) the next segment can't be combined
[02:47:36] <petev> and you have to be able to stop by the end of the lookahead
[02:47:55] <SWPadnos> of course - in most cases, the lookahead length won't be the limit, I think
[02:48:04] <jmkasunich> SWP: sounds like you are describing a way to say "yep. we're going too fast"
[02:48:06] <SWPadnos> unles syou have a thousand tiny straight lines
[02:48:09] <petev> so you need another condition
[02:48:13] <petev> the max safe vel
[02:48:15] <SWPadnos> sure
[02:48:17] <jmkasunich> not "here's how fast we can go"
[02:48:20] <petev> and that's what you need to calc
[02:48:48] <jmkasunich> each segment needs a stored max val
[02:48:52] <SWPadnos> I'm saying that I think that in most cases, you'll have far more travel in the queue than the machine needs to safely decel to 0
[02:49:01] <petev> jmk, what would the desired behavior be if a segment with low speed limit is approaching?
[02:49:08] <petev> brake as late as possible?
[02:49:17] <jmkasunich> yes
[02:49:25] <jmkasunich> arrive at the beginning of that segment at the target speed
[02:49:43] <jmkasunich> its no different than arriving at the end of a series of blended moves at zero speed
[02:49:55] <jmkasunich> zero is just a special case target speed
[02:50:17] <jmkasunich> btw, deltaV over a segment is not a constant
[02:50:30] <SWPadnos> actually, you probably want to be at the average speed of the two segments when you hit the shared point
[02:50:30] <petev> jmk, what is the stored max vel? the speed limit for that seg alone, or taking into account look ahead?
[02:50:47] <jmkasunich> I was thinking that seg only
[02:51:04] <petev> ok, so you still need to take into account the path too
[02:51:09] <jmkasunich> it would depend on the F word in effect, as well as the radius if its an arc
[02:51:14] <petev> right
[02:51:23] <petev> so it's the local speed limit
[02:51:26] <jmkasunich> you still have to sum the deltas to do the actual lookahead
[02:51:28] <jmkasunich> right
[02:51:31] <petev> right
[02:51:38] <jmkasunich> the problem I see is that you can't precalc the deltas - they aren't constant
[02:51:45] <petev> why?
[02:51:50] <petev> that I don't see
[02:51:56] <SWPadnos> it probably makes sense to calculate those at machine limits (for accel,jerk)
[02:52:03] <jmkasunich> assume a 1 inch segment, and a machine accel of 1in/sec^2
[02:52:15] <SWPadnos> then use the lower of the two (speed limit , programmed spees)
[02:52:24] <SWPadnos> speed
[02:52:27] <jmkasunich> if the initial speed is 10in/sec, you will cover the segment in 0.1 seconds, and deltav is 0.1
[02:52:46] <jmkasunich> if the initial speed is 1in/sec, you will cover it in 1 sec, and the deltav is longer
[02:53:02] <petev> don't follow
[02:53:12] <petev> constant accel = same delta V
[02:53:19] <jmkasunich> per unit TIME
[02:53:22] <petev> are you saying this is due to accel ramp
[02:53:23] <jmkasunich> not per unit distance
[02:53:23] <SWPadnos> but not for a constant length
[02:53:36] <petev> all we care about is delta V for the path
[02:53:41] <petev> time doesn't matter
[02:53:52] <jmkasunich> I think we're talking past each other
[02:53:55] <SWPadnos> delta V is accel* time, so time sure does matter
[02:53:56] <petev> it's only used as the safe limit
[02:54:07] <jmkasunich> I thought you wanted to calculate deltaV on a per-segment basis, and store that
[02:54:10] <petev> we may not be able to reach it with jerk limit and all
[02:54:16] <petev> right
[02:54:22] <jmkasunich> then sum the deltav's for all the segs in the queue to get the limit
[02:54:37] <jmkasunich> forget about jerk limits and machine limtis and all that for now
[02:54:41] <petev> ok
[02:54:45] <jmkasunich> we're just talking about deltav
[02:54:54] <petev> ok
[02:55:17] <petev> so all we are saying is the moving sum optimization is no good, correct?
[02:55:27] <jmkasunich> the deltaV for a segment depends on 1) the length of the segment 2) the accel limit and 3) the initial velocity entering the segment
[02:55:43] <jmkasunich> since 3 is unknown during lookahead, you can't calc deltaV in advance
[02:55:43] <petev> yes
[02:55:53] <petev> 3 is known
[02:56:00] <petev> it's calc from 0 back
[02:56:21] <petev> I think just the optimization doesn't work
[02:56:27] <jmkasunich> only if you redo all the calcs from zero back each time you add a new segment
[02:56:29] <SWPadnos> any change in FO (adaptive feed, feedhold) requires a recalculation of the entire buffer
[02:56:31] <petev> right
[02:56:56] <jmkasunich> 10 mins ago: <jmkasunich> I think that breaks the moving average optimization, but not the basic concept
[02:57:04] <petev> right
[02:57:17] <petev> just wanted to make sure that's all we're saying
[02:57:19] <jmkasunich> we were talking around each other again
[02:57:23] <petev> yes
[02:57:36] <SWPadnos> can we revisit the forward/backward through the buffer thing again?
[02:57:55] <jmkasunich> suer
[02:57:57] <jmkasunich> sure
[02:58:00] <SWPadnos> ok
[02:58:17] <SWPadnos> there are several things that need to cause planning to stop:
[02:58:36] <SWPadnos> (these are aside from operator intervention like FO/AF ...)
[02:59:01] <SWPadnos> 1) if there's a cusp or direction reversal in any segment
[02:59:07] <jmkasunich> cause planning to stop?
[02:59:11] <petev> no
[02:59:13] <jmkasunich> you mean stop lookahead?
[02:59:13] <SWPadnos> no - lookahead
[02:59:22] <SWPadnos> yes - lookahead
[02:59:25] <petev> huh?
[02:59:28] <SWPadnos> heh
[02:59:38] <petev> none = special case of some
[02:59:43] <petev> just plan over 1 seg
[03:00:02] <jepler> 'night guys
[03:00:15] <jmkasunich> goodnight jeff
[03:00:18] <petev> gn
[03:00:19] <SWPadnos> if I program a move from (0,0) to (1,0), then to (1,1) then the max vel will be different than if I program (0,0) -> (1,1) -> (1.999,1.001)
[03:00:22] <SWPadnos> night jeff
[03:00:38] <SWPadnos> same overall length (more or less)
[03:00:53] <jmkasunich> I don't think so
[03:01:01] <jepler> jmkasunich: sometime soon I'd like to hear what you think about the recent comp additions I made
[03:01:03] <jmkasunich> first path is 2 units long, 2nd is 2.414
[03:01:05] <jepler> jmkasunich: but not tonight
[03:01:19] <jmkasunich> jepler: thats good, cause I haven't lookedat at them
[03:01:20] <SWPadnos> no it's not, that was 1.999, 1.001 - very close to 2,1
[03:01:22] <jmkasunich> yet
[03:01:30] <jmkasunich> saw the commit messages, not the actual code or docs
[03:01:41] <SWPadnos> the samples look way cool
[03:01:48] <jmkasunich> lets not sidetrack
[03:01:54] <SWPadnos> at least the pastebinned ones :)
[03:02:06] <SWPadnos> no - so the length is close to 2.0 in the second case as well
[03:02:13] <SWPadnos> total length
[03:02:17] <jmkasunich> SWPadnos: one of us is smoking something
[03:02:22] <jmkasunich> and I think its you
[03:02:37] <jmkasunich> first one was 0,0 - 1,0 - 1,1
[03:02:44] <SWPadnos> right - one of us (me) had a pair of typos ;)
[03:02:45] <petev> I'm with jmk
[03:02:48] <jmkasunich> two segments, both 1 unit long
[03:02:59] <jmkasunich> GIGO then
[03:03:03] <SWPadnos> I wanted 0,0 -> 1,0 -> 1,999, 0.001
[03:03:10] <SWPadnos> gah 1.999
[03:03:33] <jmkasunich> iow, both are two segs, each seg 1 unit ling
[03:03:33] <petev> forget the number, just describe what you are trying to say
[03:03:43] <jmkasunich> but one is a 90 deg turn, and the other is a 0.1 deg turn
[03:03:51] <SWPadnos> well, the max vel for the first segment is different for the two paths
[03:04:12] <petev> right
[03:04:13] <SWPadnos> since Vx must come to 0 on one, and not on the other
[03:04:13] <jmkasunich> cause it needs to slow down for the sharper turn
[03:04:17] <SWPadnos> sure
[03:04:29] <petev> and that would be determined when working back throught look ahead
[03:04:36] <petev> this the a local speed limit issue
[03:04:38] <SWPadnos> or forward
[03:04:57] <petev> but forward doesn't give you the max safe vel
[03:05:01] <jmkasunich> if the path consisted of line, arc (for the turn), line, then you can compute a speed limit for the arc
[03:05:02] <SWPadnos> sure it does
[03:05:10] <jmkasunich> if its line, blend, line, its harder
[03:05:45] <petev> jmk, maybe do the vel calc after blend and make blend a new queue entry
[03:06:01] <jmkasunich> working forward from where you are can only tell you "you are already too fast" or "you are below the limit"
[03:06:08] <jmkasunich> not what the limit actually is
[03:06:08] <petev> right
[03:06:26] <SWPadnos> I don't understand why
[03:06:53] <SWPadnos> there is a configured maximum vel / acc (in the ini)
[03:06:55] <jmkasunich> petev: that would mean re-doing blending from scratch, the existing blend concept does blends on the fly, not as additional segments
[03:07:09] <jmkasunich> but lets focus on the rev/fwd issue
[03:07:18] <petev> ok
[03:07:40] <jmkasunich> SWPadnos: ok, splain to me the math for figuring out the limit ;-)
[03:07:53] <SWPadnos> for any given segment (consdiered alone), there is a max vel atatainable, and a max acc required
[03:08:06] <SWPadnos> ok - I was thinking of asking you to do it for the reverse case ;)
[03:08:12] <jmkasunich> keep it simple, two segments, assume no actual segment limits, no turn limits, just a "zero speed at end" requirement
[03:08:27] <SWPadnos> ok
[03:08:45] <jmkasunich> SWPadnos: I'd be happy to, and thats the point - I think the math is much worse going forward
[03:08:48] <SWPadnos> given the machine limits, you can calculate the minimum path length needed to stop
[03:08:54] <jmkasunich> as in "no closed form solution"
[03:09:11] <SWPadnos> it may be, but I think in most cases, reverse will take more work than necessary
[03:09:17] <SWPadnos> (if it's actually possible to do it forwards ;) )
[03:09:33] <petev> I can't see how forward would work
[03:09:48] <petev> you have to assume v=0 and end of lookahead
[03:10:03] <petev> so why would you try and go forward?
[03:10:20] <jmkasunich> petev: if you can, it can save a lot of calcs
[03:10:34] <SWPadnos> my method is to assume max accel (in the decel direction), and figure out how many segments I run through before I can stop
[03:10:40] <petev> I'm all ears, but I don't see the solution
[03:10:42] <jmkasunich> if you have a 200 entry queue, but the segments are such that it takes 2 to stop in, running 200 calcs every time sucks
[03:10:46] <SWPadnos> if I run out of segments before I run out of V, then I need to slow down
[03:11:03] <petev> but it's too late
[03:11:07] <petev> you are already speeding
[03:11:16] <jmkasunich> SWPadnos: yah, you need to slow down because you are already going to crash
[03:11:18] <SWPadnos> no, I run out of segments in the calculation, not actually moving
[03:11:29] <petev> what's the diff?
[03:11:35] <jmkasunich> what was the speed you used for the start of the calc? your current speed?
[03:11:55] <SWPadnos> probably, but remember that the current speed would have been found by a previous iteration of this algorithm
[03:12:04] <jmkasunich> if so, then you just calc'ed what will happen if you slam on the brakes, and you just calc'ed that a crash is inevitable
[03:12:14] <petev> right
[03:12:21] <jmkasunich> unless some more road comes into the headlights before you get there
[03:12:26] <petev> yep
[03:12:45] <SWPadnos> yes, but I wouldn't be at an unsafe speed if this algorithm had been used to generate my current speed ...
[03:12:50] <petev> but maybe the fixture (brick wall) is there ;-)
[03:13:04] <jmkasunich> its not a closed form solution
[03:13:17] <SWPadnos> consider it from the start: there's a zero length queue, and one segment is added
[03:13:31] <jmkasunich> you guess a speed (your current speed, or something else), you run the algorithm, and it either says OK, or crash
[03:13:45] <jmkasunich> if it says OK, you have to pick another speed and run it again
[03:14:10] <petev> right, it's some iterative algo that I don't see what makes it converge
[03:14:20] <SWPadnos> it's *not* iterative
[03:14:34] <SWPadnos> you start at V=A=0
[03:14:42] <SWPadnos> then segments show up, and you change that
[03:14:42] <petev> you just keep guessing slower speeds until you end at v=0 at end of lookahead
[03:14:47] <SWPadnos> wrong
[03:14:57] <jmkasunich> petev: lets shut up and let him splain it
[03:15:01] <petev> ok
[03:15:11] <SWPadnos> when the first segment shows up, the safe speed is determined only by that segment
[03:15:23] <SWPadnos> adding segments can't make the safe speed any lower
[03:15:26] <petev> meaning v=0 at the end?
[03:15:29] <SWPadnos> they can only increase it
[03:15:30] <SWPadnos> yes
[03:16:01] <SWPadnos> so while the first segment is running, 10 more show up
[03:16:35] <SWPadnos> the planner takes the current speed (which is safe enough to stop after the current segment), and then starts going forward
[03:17:49] <jmkasunich> and?
[03:17:57] <SWPadnos> sorry - rweording a lot :)
[03:17:59] <SWPadnos> rewording
[03:18:42] <SWPadnos> argh
[03:19:12] <SWPadnos> each new segment gives more length to work with, and the total length can then be used to get the allowed max vel
[03:19:37] <jmkasunich> that assumes that the total length is all the "same"
[03:19:37] <SWPadnos> of course taking direction into account (which is target vels for each axis)
[03:19:56] <jmkasunich> I wasn't very clear
[03:20:33] <jmkasunich> are you thinking of axis-by-axis calcs?
[03:20:43] <SWPadnos> you stop walking the queue if you calculate that you can go faster than the programmed rate or the machine limits
[03:20:56] <SWPadnos> sorry - that was a detail that's not needed at this level
[03:21:08] <jmkasunich> but it is
[03:21:12] <SWPadnos> any calculations (forward or backward) have to take direction into account
[03:21:34] <SWPadnos> segment direction, not queue walking direction ;)
[03:21:40] <jmkasunich> I agree, that if the path is straight, you can just use the total distance to end of queue as your stopping distance, do a single calc, and get max speed
[03:21:51] <jmkasunich> but the path is probalby NOT straight
[03:21:58] <SWPadnos> sure
[03:22:32] <SWPadnos> but any velocity aggregating function needs to know that, it makes no difference which direction you're walking the queue
[03:22:38] <jmkasunich> if you have 1 inch of straight, then a hard left, then 2 inches of straight, odds are the 2 inches can't be used as part of the stopping distance
[03:22:50] <jmkasunich> it DOES!
[03:23:02] <SWPadnos> right, but that hard left is no different than the V=0 case
[03:23:14] <jmkasunich> hard left = bad example
[03:23:15] <SWPadnos> it just has some accel on another axis
[03:23:22] <SWPadnos> I think I get the point though
[03:23:24] <jmkasunich> tight left arc of known radius (and thus known max speed)
[03:24:09] <SWPadnos> we have 2 limits on velocity: programmed rate (with all overrides) and machine limits
[03:24:30] <jmkasunich> 3
[03:24:45] <SWPadnos> ?
[03:24:48] <jmkasunich> those two, and a back-propogated limit that depends on what is coming up
[03:24:53] <jmkasunich> which is what this is all about
[03:24:54] <petev> I think he's lumpin that in machine limits
[03:25:02] <SWPadnos> that's what machine limits are
[03:25:06] <jmkasunich> and the key is - you have to back propogate it
[03:25:09] <petev> right
[03:25:52] <SWPadnos> ok. I'm not having any luck trying to explain (partly because I don't have the whole thing thought out, or it's impossible) - can you explain the reverse propagation method?
[03:26:00] <jmkasunich> yeah
[03:26:45] <jmkasunich> for the last (newest) seg in the buffer, assume that you need to be at zero speed when you get to the end
[03:27:07] <jmkasunich> actually, theres a better way to explain
[03:27:27] <jmkasunich> start at the end of the last segment, with your speed at 0
[03:27:46] <jmkasunich> run the path in reverse, accelerating at the same rate your decel is limited to
[03:27:58] <jmkasunich> its straightforward to calc the speed at any point
[03:28:58] <petev> ok, so lets talk about the local speed limits, they throw in a wrinkle
[03:29:00] <jmkasunich> if you reach a speed that is illegal for other reasons (tight curves, programmed feedrate, etc) clamp at that level
[03:29:15] <jmkasunich> once you get past the curve (still going backwards) accel some more
[03:29:20] <petev> easier said than done on the tight curves
[03:29:29] <jmkasunich> why?
[03:29:39] <petev> it's almost like you have a look ahead issue in the other dir now
[03:29:46] <jmkasunich> rememeber, we're not actually running the course in reverse
[03:29:50] <jmkasunich> we're just calcing
[03:29:55] <petev> you may need to slow down on you reverse coarse to make the turn
[03:29:59] <petev> I know
[03:30:09] <jmkasunich> lemme do a "road" example
[03:30:13] <petev> but let's say the rev course is like this
[03:30:22] <petev> a bunch of straight lines, then an arc
[03:30:30] <jmkasunich> 100mph straight 1/4 mile long, then 30 mph curve, then another 100mph straight 1 mile long
[03:30:43] <petev> ok
[03:30:45] <jmkasunich> going backwards, you start at the end of the 1 mile straight, and accel at top speed
[03:31:01] <jmkasunich> you can reach 75 at the end of the curve (beginning in reverse)
[03:31:15] <jmkasunich> at that point, you run into the weeds, but we don't care
[03:31:27] <jmkasunich> you reset the speed to 30 - the curve limit
[03:31:31] <petev> ok, but what if there were two straights at the end?
[03:31:39] <petev> then you need reverse lookahead
[03:31:55] <jmkasunich> you'd have acceled thru both, and reached 100mph, and run off the road, and then reset the speed to 30 for the curve
[03:32:12] <jmkasunich> we don't care if you run off the road when you are pre-calcing
[03:32:21] <SWPadnos> actually, you only need to know that a certain move will be a limit - that may be calculable at addition of new segments
[03:32:31] <petev> so some how when you hit the curve, you have to adjust the speeds down on all preceding segments
[03:32:38] <petev> that's all I'm saying
[03:32:45] <jmkasunich> exactly - thats why you do it in reverse
[03:32:57] <SWPadnos> and then you can start your reverse calcs with the programmed rate for that segment, instead of starting at the end of the queue
[03:33:09] <jmkasunich> argh
[03:33:23] <jmkasunich> this badly needs face to face and pictures, not typing and words
[03:33:26] <petev> I think what I was missing is that you don't need an optimum speed for the other segs
[03:33:32] <SWPadnos> fest fest fest :)
[03:33:55] <SWPadnos> I see the algorithm now
[03:34:19] <SWPadnos> I was thinking that you could start at vel=full to begin, and apply max decel as you go forward
[03:34:22] <petev> jmk, so when you hit the curve, you just set the vel to 30 and contiune processing
[03:34:42] <petev> so the algo at an arc is MIN(currentVel, arcVel)
[03:34:45] <jmkasunich> if you have straight, curve, straight, straight, straight, straight, you might not HAVE to start at the far end, because the curve is the limiting factor
[03:34:51] <jmkasunich> but its hard to know that unless you start at the end
[03:34:59] <jmkasunich> petev: right
[03:35:00] <SWPadnos> if you hit the end of the queue, then you can't use full vel, so scale down by 1/(1-determined end vel)
[03:35:07] <jmkasunich> its not linear
[03:35:25] <SWPadnos> that's the algo at any segment
[03:35:34] <jmkasunich> if you cut your speed in half, it takes twice as long, which means you can kill twice as much speed
[03:35:34] <SWPadnos> MIN(atatainable, programmed)
[03:35:48] <petev> no
[03:36:02] <petev> forget progarmmed limits here
[03:36:07] <jmkasunich> stopping distance from 70mph is much more than twice stopping distance from 35mph
[03:36:09] <petev> they can be applied later
[03:36:35] <SWPadnos> ok - I get it
[03:37:00] <SWPadnos> an arc has a max vel due to its geometry, which must limit the exit vel
[03:37:09] <jmkasunich> yes
[03:37:14] <jmkasunich> exit and entry
[03:37:17] <petev> I don't think it's that hard to code if we can put the blends in the queue as an arc
[03:37:51] <SWPadnos> ok. I think a couple of optimizations can make the reverse calcs pretty quick
[03:38:08] <jmkasunich> well, if we are agreed that backwards is needed, then its an order N calc that you repeat each time you add an entry
[03:38:17] <petev> right
[03:38:20] <SWPadnos> I can make it order N/2 :)
[03:38:31] <jmkasunich> thats still order N
[03:38:38] <petev> but better ;-)
[03:38:41] <SWPadnos> it is order N, but you don't have to examine the entire queue
[03:38:59] <jmkasunich> you still talking about forward calc?
[03:39:08] <SWPadnos> nope, I'm converted ;)
[03:39:25] <jmkasunich> ok, then I don't see how to do a partial
[03:39:26] <SWPadnos> starting at V=max screws things up
[03:39:45] <SWPadnos> ok, when adding a segment to the queue, do the following:
[03:40:07] <SWPadnos> caclulate the max vel attaainable in the new segment (would be done anyway)
[03:40:20] <jmkasunich> ok, stop
[03:40:26] <SWPadnos> if the previous segment has a lower max vel, then mark the previo
[03:40:30] <SWPadnos> stopped
[03:40:34] <jmkasunich> we need to be very clear, or we're gonna just confuse each other
[03:40:47] <jmkasunich> please define "the max vel attainable in the new segment"
[03:41:06] <petev> jmk, there may be some optimizations when a local speed limit is hit
[03:41:13] <jmkasunich> yes, I can see that
[03:41:19] <petev> if it's the cap, then you don't need to redo all the old calcs
[03:41:36] <jmkasunich> if you have 1 straight, a tight curve, and 100 straights, you may only need to calc from the curve back to where you are
[03:41:42] <petev> right
[03:41:48] <SWPadnos> I'm saying you apply the calc you described (the 100 MPH segment thing)
[03:42:17] <SWPadnos> and mark the previous queue end as a limiter if that segment has a lower max
[03:42:23] <jmkasunich> IOW, max for a brand new straight seg is the speed at which you could enter the seg and still manage to stop by its end
[03:42:30] <SWPadnos> yes
[03:42:40] <SWPadnos> that's what you were describing, right>
[03:42:43] <SWPadnos> ?
[03:42:50] <jmkasunich> and max for a curve is the lesser of the speed at which you could enter it and still stop and the end, or the inherent limit based on the radius of the curve
[03:43:23] <SWPadnos> yes, but I'm not sure you need to go that far
[03:43:34] <jmkasunich> yes, thats pretty much what I was describing - but that limit only applies until you add another segment
[03:43:50] <SWPadnos> let's assume that it's possible to calculate the max entry vel for a given segment, such that the V at the end is 0
[03:43:57] <jmkasunich> "go that far" ? what is "that"
[03:44:27] <jmkasunich> it is - trivial d=1/2at^2, solve for t, v = at
[03:44:40] <SWPadnos> nevermind "that" - can we agree that it must be possible to calculate a max entry vel for all segment types for this to work?
[03:44:43] <SWPadnos> right
[03:44:43] <petev> the only optimization I see is when you add a new seg and calc back to a point where a local speed limit caps things
[03:44:54] <SWPadnos> that's the one
[03:45:13] <SWPadnos> keep a list of "choke points", and only calculate back from those
[03:45:22] <SWPadnos> from the closest one, that is
[03:45:24] <petev> then you can stop, because the rest of the path is unchanged
[03:45:37] <jmkasunich> or only calc back TO those (each time you add a new segment)
[03:45:40] <petev> you don't need a list, it's already in the queue
[03:45:54] <petev> you keep going if the new segment made the limit less
[03:46:03] <petev> but not if you're still above the limit
[03:46:04] <jmkasunich> when you add a new seg, the limits for all previous segs increase, until you get back to a choke point - things prior to the choke remain constant
[03:46:13] <petev> right
[03:46:24] <SWPadnos> but you want to *start* the reverse calcs at the choke points
[03:46:25] <SWPadnos> right
[03:46:53] <jmkasunich> since things prior to a choke remain constant, there is no need to recalc them
[03:46:58] <petev> right
[03:47:09] <SWPadnos> right
[03:47:21] <petev> and in fact, no need to calc the new path until your past the choke point
[03:47:26] <petev> as none of it will effect anything
[03:47:40] <SWPadnos> with that optimization, this shouldn't take any more queue walking than an ideal forward approach
[03:47:42] <jmkasunich> I'd be inclined to do the calcs when adding segments
[03:47:54] <SWPadnos> yep
[03:47:56] <jmkasunich> and update the limit on each prior seg back to the choke
[03:48:01] <petev> but why do them until you pass the choke point?
[03:48:12] <SWPadnos> true
[03:48:13] <petev> they will all be wasted and redone again anyhow
[03:48:53] <jmkasunich> assume there are no chokes for a moment
[03:48:54] <SWPadnos> so this is essentially a bunch of "mini-queues", split at choke points
[03:49:10] <petev> so there are optimizations, but it's still order N worse case
[03:49:13] <jmkasunich> at any point, the queue is a series of speed limit signs with decreasing values as you cruise down the road
[03:49:28] <jmkasunich> each time you add a segment, you can go backwards and raise all the limits
[03:49:48] <petev> jmk, but those limits are never used until you pass the choke point
[03:49:52] <jmkasunich> the code that is "driving" can be O(1) - it just reads the signs
[03:49:57] <petev> the next calc after that sets them again anyhow
[03:50:15] <SWPadnos> ok, but since you get the limits for each segment as you go backwards along the road, there's no point in doing those calculations if you haven't passed the last turn yet ...
[03:50:21] <jmkasunich> pete - at some point (when you put the first segment in after the choke) its not a choke
[03:50:44] <petev> jmk, when the machine executes the choke move, then it needs the new limits
[03:51:02] <petev> and since you calc the whole q each time, all the other calcs are a waste
[03:51:19] <jmkasunich> define "every time"
[03:51:25] <jmkasunich> I only calc when a new seg is added
[03:51:32] <petev> every time a new segment is added
[03:51:48] <petev> so you can skip the new cacls until you reach the choke
[03:51:57] <petev> then do a calc right then
[03:52:04] <jmkasunich> but how do you know its a choke if you haven't done the calcs?
[03:52:08] <SWPadnos> there's more work doing calcs at every segment add than there is doing them every time you pass a choke point
[03:52:22] <SWPadnos> the first segment added is always a choke point
[03:52:24] <petev> you did the calcs and determined it's a choke
[03:52:27] <petev> now new segs are added
[03:52:38] <petev> they can only increase previous limits
[03:52:45] <petev> so the choke is still there
[03:52:48] <jmkasunich> fsck
[03:52:48] <SWPadnos> as you add more, they may or may not be choke points, so you may be calculating based on the entire queue
[03:52:54] <petev> you flag it as a choke point
[03:53:01] <jmkasunich> this sucks - I NEEEEEED to be able to draw a picture and point at it
[03:53:04] <petev> and then wait until you execute it to run more calcs
[03:53:30] <petev> until you hit the first choke, you don't care about what's added
[03:53:52] <petev> then you calc the whole thing and identify the next choke
[03:54:10] <SWPadnos> all this optimization is is moving the assumption of vel=0 at end of queue to vel=(something else) at some other point in the wueue
[03:54:11] <jmkasunich> I need to do an example
[03:54:24] <petev> one sec
[03:54:42] <jmkasunich> petev: you are on doze at the moment aren't you?
[03:54:46] <petev> do we agree that adding new segments can only increase the limit of previous segments?
[03:54:51] <SWPadnos> yes
[03:54:51] <jmkasunich> actually, I bet you both are
[03:54:54] <SWPadnos> yes
[03:54:56] <jmkasunich> frown
[03:54:59] <SWPadnos> yes
[03:55:06] <jmkasunich> was gonna do a spreadsheet
[03:55:06] <petev> jmk, is that a no?
[03:55:13] <SWPadnos> I have OO here
[03:55:31] <jmkasunich> yes, I agree taht adding new segs can only increase the limit of previous segs
[03:55:40] <petev> ok, continue
[03:56:18] <jmkasunich> continue with my spreadsheet?
[03:56:24] <jmkasunich> ;-)
[03:56:30] <petev> with the example you wanted to give
[03:56:39] <jmkasunich> I can't give it in IRC
[03:56:44] <jmkasunich> too much math and typing
[03:56:48] <SWPadnos> actually, the only moves that intrinsically limit vel are arcs
[03:56:51] <jmkasunich> I want to do real calcs with real numbers
[03:56:59] <SWPadnos> or other higher order things we don't have yet
[03:57:05] <jmkasunich> SWPadnos: blends limit velocity
[03:57:06] <petev> the optimization is a bit of a mute point anyhow
[03:57:11] <SWPadnos> blends are arcs
[03:57:13] <petev> it doens't change the order of the problem
[03:57:20] <jmkasunich> today they are not
[03:57:24] <petev> so the worst case is the same
[03:57:37] <jmkasunich> petev: correct
[03:57:38] <SWPadnos> sure
[03:58:03] <SWPadnos> blends are second order, but they result from the combination of two moves, not a simgle one
[03:58:21] <jmkasunich> one reason I like the idea of doing the calcs when you put a seg _on_ the queue is that the actual traj planning part (read from queue) is always O(1)
[03:58:30] <SWPadnos> so it's the directions that limit blends, not the moves
[03:58:46] <jmkasunich> putting on could be O(N), but depending on the implmenetation that could be less critical
[03:58:54] <petev> it's still O(1), but I agree a first pass at the code should not try optimizations
[03:58:59] <jmkasunich> for example if putting on wasn't in the same thread
[03:59:59] <petev> so how hard is it to make blends be arcs in the queue?
[04:00:01] <jmkasunich> SWP: you can either think of blends as changing line-line to line-arc-line with a speed limit on the arc, or you can think of it as line-line, with a speed limit sign at the junction of the lines
[04:00:19] <jmkasunich> petev: FO makes it a bitch
[04:00:43] <jmkasunich> I believe the existing code automatically makes tighter blends if the speed is slower
[04:00:43] <SWPadnos> sure - I was thinking of how you'd use the precalculated vel limit to determine if a previous segment was a real choke point
[04:00:50] <SWPadnos> yes it does
[04:00:54] <petev> hmm, so you want FO to effect what's in the RT queue immediately?
[04:01:03] <SWPadnos> as soon as possible
[04:01:04] <jmkasunich> if you precalc'ed an arc for each blend, the radius is fixed, and FO messes things up
[04:01:18] <petev> yes, but it does simplify the code
[04:01:28] <jmkasunich> crap - midnight again
[04:01:38] <SWPadnos> I think it's improper operation, reagardless of code simplicity :)
[04:01:41] <petev> kids crying, BRB
[04:01:51] <SWPadnos> yes - I just noticed that as my log filename changed
[04:01:59] <jmkasunich> you guys always suck me into discussions that go round and round, and keep me from doing other work
[04:02:15] <SWPadnos> hey - this discussion is work ;)
[04:02:31] <SWPadnos> but not *other* work
[04:02:34] <jmkasunich> I need to go to bed - its too late to do anything real, and talking for another two hours will not accomplish any of my goals
[04:02:46] <SWPadnos> ok. good night. thanks for explaining
[04:02:57] <jmkasunich> goodnight
[04:03:00] <petev> gn
[04:05:18] <SWPadnos> it is a good point that at least some calcs should be done when adding segments after a choke point
[04:05:57] <SWPadnos> since there's no guarantee that the process adding segments will run again before the queue is exhausted
[04:06:11] <SWPadnos> (or the choke point is passed)
[04:07:09] <petev> yes, that's why in the optimization you run the calcs when you hit a choke
[04:07:41] <petev> I think in actual machining the optimization may be useful, but it doesn't help the worst case
[04:08:24] <SWPadnos> well, the process that consumes queue entries is hard RT, and shouldn't have to do too much work
[04:08:55] <SWPadnos> the process that supplies entries is userspace, and can have non O(1) functions without a problem
[04:10:07] <SWPadnos> it makes sense that any time the supplier runs, it sticks as much as it can in the queue, and that anything in the queue is ready to run
[04:10:29] <SWPadnos> if even if the new group of segments doesn't have a new choke point
[04:10:38] <SWPadnos> (and even if the group is only one segment)
[04:11:30] <petev> well then FO won't take effect for anyting already in RT
[04:11:34] <petev> this is what I was asking before
[04:11:42] <petev> I would be fine with this
[04:11:47] <petev> but maybe others aren't
[04:11:56] <SWPadnos> this whole thing shouldn't have anything to do with programmed feedrates
[04:12:03] <petev> of couse there should probably be a max queue depth if this is done
[04:12:06] <SWPadnos> which includes FO
[04:12:17] <petev> it does, because of the blends
[04:12:26] <petev> otherwise I agree
[04:12:51] <SWPadnos> this would give a max usable vel. that would then be limited further by programmed rate
[04:13:18] <SWPadnos> essentially, it gives a per-segment limit for feedrate
[04:14:02] <petev> changing FO or programmed speed basically changes the path, because the blends are different
[04:14:08] <petev> that's why it's dependent
[04:14:54] <petev> if the blends are calcd some other method that is not dependent on FO then this could be nice
[04:14:56] <SWPadnos> if blends aren't in the path (ie, you don't stick in arcs), then the queued path doesn't change but following of the path will depending on speed
[04:15:05] <SWPadnos> it's dependent on "current speed",
[04:15:25] <petev> no, even if not q entries, then the local limit and intersections would change
[04:15:48] <petev> if blends could be calcd purely on deviation from path, this would be great
[04:16:05] <SWPadnos> heh - planning within the constraints of what EMC is "supposed to do" is not trivial
[04:16:07] <petev> but if they are calcd on min vel or some other param that effects the path, it's an issue
[04:16:18] <SWPadnos> they can be - there's a mode for that now
[04:16:46] <petev> I know, so in error mode we can optimize, but in vel mode, we can't
[04:17:05] <SWPadnos> right - the path has to change
[04:17:08] <petev> right
[04:17:21] <petev> I personally think vel mode is a bit useless
[04:17:26] <SWPadnos> but that can be done on the fly as it is now
[04:17:31] <SWPadnos> no - it gives the best finish
[04:17:33] <petev> so I wouldn't object to the optimization
[04:17:34] <SWPadnos> afaik
[04:17:52] <petev> yes, but if the part is out of tolerance, who cares how good the finish is?
[04:18:22] <SWPadnos> that depends on how far out of tolerance and how bad the finish is
[04:18:22] <petev> so I think the best way is the best finish within tolerance, wich is path optimization, not velocity
[04:18:30] <SWPadnos> sure
[04:18:37] <SWPadnos> the planner needs to do all the above
[04:18:44] <SWPadnos> but not necessarily at the same time
[04:19:01] <petev> right, and could do it before RT ever sees it if it's all path based and not vel based
[04:19:35] <SWPadnos> it needs to deal with FO in a reasonable time period
[04:19:52] <SWPadnos> not seconds, but tenths of a second at most, I'd say
[04:20:03] <petev> does FO override even if at less than the programmed feed?
[04:20:10] <petev> or is it just a max limit?
[04:20:18] <SWPadnos> that's a lot of TP cycles, and plenty of time to recalc a path for several hundred segments
[04:20:28] <SWPadnos> yes, it goes up or down
[04:20:33] <petev> that wan't real clear
[04:20:40] <petev> FO scales programmed feeds
[04:20:51] <petev> but what if the machine isn't reaching them
[04:20:55] <SWPadnos> oh - usually it's used to slow things down, but it could be used to speed up as well
[04:21:05] <petev> does it scale actual speeds, or just programmed?
[04:21:17] <SWPadnos> the machine will be limited by the programmed feedrate (including overrides) or the machine limits
[04:21:21] <SWPadnos> programmed
[04:21:25] <petev> ok
[04:21:48] <SWPadnos> there are at least 3 different topics for path planning:
[04:21:50] <petev> so then it's pretty easy if we only do path optimization for blends
[04:21:58] <SWPadnos> 1) speed limits, as we've just discussed
[04:22:07] <SWPadnos> 2) segment aggregation
[04:22:13] <SWPadnos> 3) segment blending
[04:22:28] <petev> 1 is RT
[04:22:34] <petev> I think the others can be user
[04:23:10] <SWPadnos> exact path mode, exact stop mode (whatever the difference is), constant velocity mode, tolerance mode, etc. are all variations that affect how those 3 underlying things are done
[04:23:37] <SWPadnos> the current thinking is that since FO / AF is RT, blending must also be
[04:23:44] <petev> yes, but if we only do path based planning, then it's easier to do more in user space
[04:23:58] <petev> the vel based planning is a pain, and not very usefull IMHO
[04:24:02] <SWPadnos> which makes soem sense, since spindle sync modes are also a form of FO
[04:24:29] <SWPadnos> you can't do path only planning for threading cycles, for example
[04:24:43] <petev> what?
[04:24:46] <petev> sure you can
[04:25:02] <SWPadnos> no, because the velocity will change based on spindle feedback, like FO
[04:25:19] <petev> but the path won't change
[04:25:32] <petev> you're mixing how axis are slaved with the path
[04:25:33] <SWPadnos> it will if you're in a blending mode
[04:36:34] <SWPadnos> hmmm. I don't think so. axes are slaved to a programmed path by using the feedrate (possibly modified by FO and AF) as the controlling factor
[04:37:14] <SWPadnos> they're slaved to a spidle-sync'ed path by using feedrate modified by (spindle feedback/programmed spindle speed)
[04:37:24] <SWPadnos> that's just like FO
[04:37:57] <SWPadnos> and as far as I know, you can program any path, and use any blending mode while doing spindle synced motion
[13:32:22] <jepler> hm -- array-personality isn't going to be useful on pluto
[13:33:19] <jepler> I had hoped to let the user say "I won't use pwm3, give me the digital outputs instead", but arrays are always contiguous
[13:33:52] <jepler> so I can't turn on dout.18 and dout.19 while leaving off dout.10 through dout.17
[13:34:59] <cradek> hmm, that would be nice
[13:36:18] <jepler> I guess I could make arrays non-contiguous but it'll make the declaration more of an unreadable mess than it is now
[18:04:45] <SWPadnos> hmmm. I had a thought regarding emc2 (and 2.1) repositories, and updates for users
[18:05:05] <SWPadnos> I know this was discussed quite a bit before the 2.1 release, so I may have just forgotten the answers
[18:05:32] <SWPadnos> here's teh problem: updates in TRUNK are only being made in 2.1_branch right now, not 2.0_branch
[18:05:59] <SWPadnos> people with 2.0 don't know there are any updates unless they manually change their repositories to emc2.1
[18:06:38] <SWPadnos> so there are probably users who have 2.0.5, and don't have the bugfixes that have gone into 2.1 (or will be in 2.2)
[18:06:44] <SWPadnos> (such as cutter comp ...)
[18:07:05] <SWPadnos> I don't remember what the solution to that problem is, if there is one
[18:11:54] <cradek> it might still be appropriate to backport some fixes to 2.0, but they would have to be extremely safe
[18:12:08] <cradek> changing cutter comp is probably not in that class
[18:13:00] <cradek> ... I'm not sure what is
[18:13:05] <SWPadnos> yeah
[18:13:31] <SWPadnos> I guess I realized that there have been no commits to the 2.0 branch since 2.1 was released
[18:13:37] <SWPadnos> even for bugfizes
[18:13:40] <SWPadnos> x
[18:13:54] <cradek> I consider 2.0 pretty much "finished" - it is stable and I think we don't have any bug reports coming in for it
[18:14:25] <SWPadnos> sure, but there are still long standing bugs, like cutter comp, that should probably be fixed
[18:14:27] <cradek> actually there may be an outstanding thing or two unreleased on the branch - I don't remember for sure
[18:14:51] <SWPadnos> also, there's no way to notify users that there are later improved versions unless they already know and change their repos
[18:15:35] <cradek> we could make a last 2.0 release that is the same as 2.0.5 in every way except it includes an announcement
[18:16:37] <SWPadnos> yep, I considered something like that. actually, adding a dependency on some package like "emc-announcements", which would consist of one tet file, could also be done
[18:16:45] <cradek> but, if someone is using 2.0 and doesn't go searching for new features or report a bug, I'm not sure we should bother them
[18:16:46] <SWPadnos> text file ...
[18:17:21] <SWPadnos> true, though the update manager is supposed to tell them when there are updates, and it doesn't because the repos are changed for every point revision (so far)
[18:24:07] <cradek> point revision = second number changing?
[18:24:24] <SWPadnos> heh - yes, in this case :)
[18:24:30] <cradek> ok
[18:24:50] <SWPadnos> minor revision number, I guess I should have said
[18:25:17] <cradek> well you're right the UM won't show it - but that was on purpose so people wouldn't upgrade and break their configs without understanding what was going on
[18:26:18] <cradek> if you have a proposition let's talk about it (when more folks are around)
[18:26:53] <SWPadnos> that's a good plan. I don't have any specific suggestions at this point - it was one of those thoughts that pops up in the shower ...
[18:40:15] <alex_joni_away> alex_joni_away is now known as alex_joni
[18:49:18] <alex_joni> hmm.. I thought I did the announcement on 2.0
[18:51:04] <SWPadnos> an announcement that would be picked up by update manager, or one on linuxcnc.org/mailing lists?
[18:52:00] <alex_joni> update manager
[18:52:16] <alex_joni> * alex_joni wonders where the code disappeared
[18:52:41] <SWPadnos> oh. could be - I don't have any installed 2.0.x, so I wouldn't have seen it
[18:53:13] <SWPadnos> as I said - I didn't remember the solution, if there was one
[18:53:18] <alex_joni> hmm.. seems I only wanted that
[18:53:21] <SWPadnos> heh
[18:53:23] <SWPadnos> :)
[18:53:32] <alex_joni> I added the same mechanism for 2.1.x to warn people of config change
[18:54:04] <SWPadnos> ok. does it make sense to have something like an emc-announcements package, which is a dependency for emc2?
[18:54:16] <SWPadnos> (or is that what you're saying?)
[18:54:21] <alex_joni> nope, hang on
[18:54:28] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/debian/emc2.postinst?rev=1.1.2.2;content-type=text%2Fplain;hideattic=0;only_with_tag=v2_1_branch
[18:54:42] <alex_joni> that's what I figured out, and is probably needed for 2.0.x too
[18:55:18] <SWPadnos> ah - ok. that's one part of the solution
[18:55:37] <alex_joni> that simply pops up a notify window after upgrading
[18:55:49] <SWPadnos> the problem is that 2.0.x users don't even see that there are upgrades available
[18:56:26] <alex_joni> I plan to add this to 2.0.6
[18:56:51] <alex_joni> so it will tell them there is a new 2.1.x tree which has some new features and improvements, and point to a wiki for the rest
[18:57:05] <alex_joni> (it will also need to say that the configs need a bit of tweaking)
[18:57:31] <SWPadnos> oh, ok. (I didn't see any reference to 2.1 in there, so didn't realize it would do that)
[18:57:42] <alex_joni> that one I pasted is the 2.1.x one
[18:57:55] <alex_joni> (it only appears once when you upgrade from any 2.0.x version)
[18:58:00] <SWPadnos> it says 1:2..0.* in the case :)
[18:58:08] <alex_joni> a similar thing will need to be written for 2.0.x
[18:58:46] <SWPadnos> ok - I'm not sure that addresses the concern I have, but if you think it does, then I'm happy about it :)
[18:59:29] <alex_joni> your concearn is to notify 2.0.x users there's an alternative now ?
[18:59:43] <SWPadnos> yes
[18:59:55] <SWPadnos> and of course dontinuing on with that pattern
[18:59:57] <alex_joni> ok, then it's ok
[18:59:57] <SWPadnos> continuing
[19:00:49] <SWPadnos> do you expect to update the 2.0.x (and 2.1.x) notifiers whenever a new minor release is done?
[19:05:05] <alex_joni> SWPadnos: I only plan to make one update notifier for 2.0.x
[19:05:16] <SWPadnos> ok
[19:05:29] <SWPadnos> that's probably sufficient
[19:05:40] <alex_joni> the the 2.1.x update notifier will stay the same (only voice if the user upgrades from a 2.0.x version)
[19:05:56] <SWPadnos> I was thinking about a user who's waiting for some feature, but it's not in 2.1.x (like EDM support or something)
[19:06:12] <SWPadnos> they see the notice, look at the new features page, and see that the thing they want isn't there
[19:06:24] <SWPadnos> so they sit back and wait for the next upgrade notice
[19:40:40] <alex_joni> btw, I didn't make it to leave for germany :(
[19:57:10] <alex_joni> jepler or cradek: would it be too much to ask for you to update this page?
http://axis.unpy.net/translations
[19:58:30] <cradek> we have a lot more now, don't we
[19:59:16] <jepler> se, ru, fr
[19:59:28] <jepler> are those the new ones not on that page?
[20:00:00] <alex_joni> jepler: right
[20:00:09] <jepler> hm, the "se" one is far from complete
[20:00:28] <cradek> I noticed the .ru was based on an older version, so is missing a few things
[20:00:44] <alex_joni> cradek: the .ro one might be the same
[20:01:03] <alex_joni> not sure about .de.. I did update that just before 2.1 but then flo-h updated it again, and I didn't look
[20:01:26] <jepler> the .ru one is in a huge (wide) font on my system, too
[20:01:58] <alex_joni> jepler: thought you have a screenshot for .ru
[20:04:39] <jepler> the .ru translator attached one, yes
[20:04:48] <cradek> it's ugly here too, but I swear I looked at it somewhere else and it looked nice
[20:04:49] <jepler> the font spacing is all weird there too
[20:05:03] <cradek> oh, hmm
[20:06:10] <alex_joni> bet there are other things .ru people do to display those nicely, probably ubuntu does it too if you change the language systemwide
[20:15:38] <jepler> I bet the tk people are simply incompetent at font handling
[21:11:08] <SWPadnos> later guys
[22:54:10] <jepler> hm -- after using 'run from line' then 'run', when it reaches the end of the program, milltask goes to 100%CPU
[22:54:15] <jepler> I can't see why
[22:54:16] <jepler> this is on TRUNK
[22:57:31] <jepler> 2937 || (emcStatus->task.readLine < programStartLine)
[22:57:40] <jepler> (gdb) print emcStatus->task.readLine
[22:57:40] <jepler> $10 = 0
[22:57:40] <jepler> (gdb) print programStartLine
[22:57:40] <jepler> $11 = 409
[22:57:41] <jepler> aha
[22:57:53] <jepler> programStartLine isn't being reset
[22:58:27] <jepler> or maybe this condition is wrong?
[23:09:23] <cradek> jepler: you got me
[23:09:48] <jepler> if I can figure it out, it'll be another one for 2.1.x...
[23:09:52] <jepler> assuming it's not new on TRUNK
[23:09:53] <cradek> yes
[23:10:03] <cradek> I bet it's not new
[23:10:25] <cradek> the pause/step thing is in there somewhere too...
[23:11:51] <jepler> yuck
[23:13:23] <jepler> that was easy
[23:13:42] <jepler> the emcTaskEager condition covers the verify and run-from-line cases too
[23:13:48] <jepler> so they don't have to be tested specifically anymore
