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
