On Sep 24 2013 1:02 AM, Chris Morley wrote: >> >> I also think we should have rapid override rather then use max >> >> velocity >> >> as max velocity affects feed moves, though I am not nearly as >> >> excited >> >> about that compared to the feed override behaviour. >> >> I would go one step further. I would expect that no feed will >> *ever* >> be faster than rapid, even if it is in override mode. >> >> EBo -- >> > > I think I have missed your point here. > No feed _can_ be faster then rapid - rapids moves at the maximum > allowable speed. > > I should also explain max velocity better. > > Max velocity controls the absolute maximum velocity limit of the > axis. > it is set by INI settings. > Turning max velocity down limits rapids first but if you turn it down > enough it limits feed rates all the way down to zero. > What it is doing is limiting the absolute axis speed, regardless of > Gcode command. > > Having a separate rapid override allows one to set feed to 100% > and the rapid to 10% while proving a program. > This allows you to sneak up to the part while still cutting at the > proper > rate. > You can do this with max velocity but if you really want to creep > in rapid, you must turn the max velocity back up to feed at a proper > rate. As I said IMHO this behaviour is not terrible, but separate is > better.
Sorry. It was 1 or 2 in the morning when I wrote that. I agree with you entirely. If you separate out the two then you can can do just as you say. I basically do the same with a single feed override, but I was just saying that 100% on the rapid feed is typically set to max, and overdriving that can cause problems. Sorry, I meant to say that I agree with you, but everything should be limited to MAX. EBo -- ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
