Jon On Fri, Apr 20, 2012 at 12:33 PM, Jon Elson <el...@pico-systems.com> wrote: > Viesturs Lācis wrote: >> I also agree that separate filter would be better. Because the problem >> is solely in the g-code, so the filter to sort out the code is needed. >> With proper code the existing LinuxCNC can completely handle the job. >> > Not completely. Some very correct G-code cannot be fixed completely outside > LinuxCNC. You have a case where smooth curves cover a surface, but then > at the end > of a curve it has to turn around and go back the other way. The machine > can handle > the smooth curve at high speed because it is smooth. But, LinuxCNC > requires it > never exceed a velocity where it can stop on the next block. If you fix > all the > velocities so the motion hardware would never be maxed out, LinuxCNC > will still limit the velocity. So, there needs to be an option where > this limiting > could be turned off. Then you are at the mercy of assuring that the > filter never > asks for more accel than the motion hardware can deliver. > > Jon >
here's how one group worked with the fast turn around at edge of work the machine tool was like the emc2-bipod and the software built huge arcs into the endmotions to keep velocity up and dampen the bipod swing the effort was http://hektor.ch and the added arcs that kept the velocity up are seen on http://hektor.ch/About/Interface.gif/ the red lines are the programmed paths the blue lines are the addition motion added to allow a constant velocity. kinda fun a cam solution to the machine's capabilties (not a control solution) regards tomp ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
