Sven, I ran into trouble in the past on my stepper router where I needed to limit Z speed to prevent lost steps.
I ended up writing a c program that would process the g-code and insert appropriate feed rate where required. If I recall, I think I looked at the delta z between two moves and if it went over a threshold I then inserted a new (reduced) feed rate. Things have changed since that time and I no longer use the program. I'll see if I still have it. In any case it was a simple program to write and it may be an option you want to explore. ----- Original Message ----- From: "Sven Mueller" <[EMAIL PROTECTED]> To: "Enhanced Machine Controller (EMC)" <[email protected]> Sent: Wednesday, August 29, 2007 1:52 PM Subject: Re: [Emc-users] A way to limit Z axis speeds (perhaps depending on tool)? > Jon Elson wrote on 29/08/2007 18:59: >> Sven Mueller wrote: >>> A nice feature my previous cnc software (PC/NC from lewetz.de) had was >>> the option to limit the rate at which Z travelled down (on >>> non-G00/non-Homing moves only). This made sure that even if I accidently >>> programmed a too high feed rate, I still wouldn't break the tool just by >>> sinking it into the material too quickly. >> >> A cool idea, but I'm not sure it is a total solution.[...] >> Limiting the Z plunge rate would be good when below the clearance >> plane, but you'd want it to be fast above the clearance plane. But, >> where the tool tip is relative to the work or clearance depends >> on the right offset for the tool length. So, it is not a >> panacea for operator mistakes. [...] >> >> The best solution is thinking things through carefully and >> planning out the operations you will perform. > > True, but it is relatively hard to calculate the right combined feed > rate for an XYZ move if you have to bear in mind that your flat end mill > doesn't like going in faster than x millimeters/min. (This is of course > only partly right since they usually don't like entering at an angle > bigger than A or deeper than B into a flat area, but you get the idea.) > > But anyway, this isn't intended as a panacea, just as an additional > safeguard or additional function the operator could use. Imagine a tool > (like a ball end mill) which doesn't like to enter material at a too > fast speed in Z direction (i.e. along the rotational axis of the tool), > no matter wether it is entering in parallel to that axis or diagonal (as > a combined XYZ move). The operator knows that it can cope with a feed > rate of 300mm/min on pure X/Y moves but only with 20mm/min on the Z axis > (a bit faster on diagonal moves, but let's skip that). Now the operator > wants to dive into the material 20mm over a combined X/Y travel of > 300mm. All is fine in this case even with todays options. Now the > customer comes in and wants a steeper (say within 200mm) dive into the > material for some reason. With the new limits I propose, the operator > would still be safe if he only adjusted the X/Y coordinates but not the > feedrate, while he might be damaging the tool with current limits. > This "small" change by a customer is the sort of change in programs > which quickly introduce odd bugs. So it would be really nice if such a > check/limit could somehow be introduced to emc2. > Or if we would get the tool based limits here, these values could change > automatically when the tools are changed. Obviously, G00 moves shouldn't > be affected. > BTW: I routinely use G00 moves for any move where I am sure (well, 95% > sure, I do make mistakes there) I won't hit the workpiece. > > I honestly think operators would benefit from such automatic limit > checks. Wether emc should abort when these limits are exceeded or simply > adjust the feedrates the program uses (perhaps while displaying a > warning), I'm not sure, both options have their advantages, a > configuration option which allows both ways would of course be the most > interesting thing here. > > As said: I could work around that using my Perl lib, integrating checks > there to make sure such limits are considered, but this would be better > suited in emc IMVHO anyway. > > regards, > Sven > > PS: /me really should round up some free time and check out the NML > interface and see wether he could use that to implement a nice surface > scanning tool. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
