Sorry I missed this email. I am probably not the one to ask this - maybe one of the developers can say. ja3 I think is being worked on right now to be put into master but is going to take time. Maybe master?
sam On 10/3/2013 10:59 AM, Robert Ellenberg wrote: > Hi Sam, > What's the status of the ja3 branch? I'd like to start from a stable branch > to make debugging easier. If ja3 is under active development, I'd need to > discuss the plans with the developers. > > Thanks, > Rob > On Sep 29, 2013 9:58 AM, "sam sokolik" <sa...@empirescreen.com> wrote: > >> very neat - (I can't be much help ither than testing) >> >> I think though that if you do any developing - it should be in the JA3 >> branch. >> >> Also - the worry with larger look ahead - things like feedrate over or >> feed hold still need to be instantanious. >> >> (I also think this is a high priority) >> >> Thanks for your looking at this >> sam >> >> >> On 09/28/2013 09:09 PM, Robert Ellenberg wrote: >>> Thanks for the explanation! if we're lucky, such a feature wouldn't take >> a >>> separate optimization, since the forward and reverse trajectories have >> the >>> same speed and acceleration bounds. Once lookahead is implemented, It >>> sounds like a good feature to attack. >>> >>> -Rob >>> >>> >>> On Sat, Sep 28, 2013 at 9:24 PM, TJoseph Powderly <tjt...@gmail.com> >> wrote: >>>> 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 >>>> >> ------------------------------------------------------------------------------ >>> 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 >> > ------------------------------------------------------------------------------ > 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=60134791&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=60134071&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
