On 16 September 2013 17:49, Jon Elson <[email protected]> wrote:
> The problem with the "larger read-ahead" is that there is no best > choice for how much read-ahead you need, and doing it in real > time gets pretty complicated. It is conceivable that you could need > 1000 blocks of read ahead in some contouring programs, and I > don't think you can have the TP do this for every line and arc > segment. My naive scheme was to have a big buffer of the > trajectory moves, and when you hit a part that required slowing > down, you could then work backwards to figure out when you > needed to begin the slowing down. There would be a velocity > for each move, and this working backwards scheme would edit > those velocities down to accommodate the need for acceleration > in the future. Not sure if this makes sense, but that was what > seemed to be the mechanism that made the problem tractable > to me. I don't think that is especially naïve, and I think is the basis of the PVT trajectory scheme. I think that your look-ahead only has to run as far ahead as the current stopping distance, and then it propagates a modified speed back up the chain. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
