On 09/28/2013 07:33 PM, Robert Ellenberg wrote: > That sounds like a good simplification. I like the idea of limiting the > horizon to the stopping distance, though unfortunately it's not a > straightforward calculation as of now. The big complication is that the > blends are constant speed, so only a portion of each move can have > acceleration / deceleration along the path. That makes it hard to know a > priori how many segments we need to queue up, since some short segments may > spend most of their distance in a blend. In principle, we could allow > tangential acceleration during a blend, but it complicates the > optimization. I'll look into it more and see if there's a good way to > reliably do this. > > For reversing a given motion, how far back would you need to go? A few > segments or the whole path? > > Best, > Rob > > > On Sat, Sep 28, 2013 at 8:15 PM, andy pugh <bodge...@gmail.com> wrote: > >> On 29 September 2013 01:07, Chris Radek <ch...@timeguy.com> wrote: >> >>> Robert, thanks for your interest; I am working on digesting your >>> paper. >> >> The idea of basically building the current trajectory then iteratively >> improving it seems interesting. >> It may be worth considering working only on a "patch" of moves that >> encompasses the distance required to stop in. >> >> Something else that would be useful would be to be able to run the >> motion backwards (EDM) , so keeping the already-completed moves in >> memory might be useful too. >> >> -- >> atp >> If you can't fix it, you don't own it. >> http://www.ifixit.com/Manifesto >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > Rob, thank you for looking into this.
I will try to explain the requirements of a 'gap control'. From an Wire EDM standpoint, the tool is a wire passing thru a slot in a metal plate. It is neccesary that the tool never touches the workpiece. The cutting action depends on sparks that melt tiny bits of stock in the path direction. Sparks cannot occur if the tool touches the workpeice. As a visual reference, imagine a .010" dia wire passing thru a 1" steel plate. This tool is .004" from the walls of the slot and is slowly advancing along a path. Imagine the path is the outline of a small gear. Sometimes the path is full of swarf and the tool must retract, that motion will be very small, In magnitude it would be near the 'kerf' size of the slot ( <= .010 in this example ), Sometimes the stock moves due to temperature or release of internal stress. In these cases the tool must retract an unknown distance, until the tool no longer touches the stock. In some implementaions, this is allowed to go all the way to the starting point. In other it is a finite distance or number of gcode blocks. I this limit of startpoint or distance or number-of-blocks is arrived at, and the tool is not yet free, the control will abort and notify the user. Now to answer your question: Retracting to the beginning may be unrealistic, and some small distance, say 0.5" of retract might indicate a 'give it up' condition. If you use a limit of N gcode blocks, the number of blocks has little to do with the needed result. I'll leave the how far to back up arguments to those who want Wire EDM ( need to retact along path ). thanks very much for working on these features. TomP ( tjtr33) (For myself. I specialize in a process called Sinking EDM, and the retract has little to do with a path, merely a safe position to retreat to ) ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
