For me this is an issue I have to deal with quite often, - so I'm very humbly going to put my 2 cents in.
I realize that probably everyone has their own idea of what the ideal solution is, and wholeheartedly respect that what may seem to be a "minor" change from a user perspective can often be massive work from a developer perspective but ideas never hurt so here are mine. On 08/19/2010 10:59 AM, Chris Radek wrote: > On Thu, Aug 19, 2010 at 09:31:42AM -0500, Viesturs L??cis wrote: > > >> Ok, thank You for the explanation, I kind of realised that it is the >> case that there is corner that cannot be completely reached, because >> tool is too big. >> >> The way I see the ideal solution - display the error message so that I >> am warned about the situation, and continue with the code. Using Your >> screenshot - the displayed tool position would be the point, where >> tool should do the corner - stop and start moving downwards. That is >> the desired behavior in current situation. >> > Yes I agree the ideal solution is to know what the *desired* behavior > is and then do it - however there are two problems with that - knowing > what the desired behavior is - and then doing it. > > I don't mean to be flippant, but both are very hard. Like Stuart S > implied with his question, you don't actually program a part profile > in gcode. EMC doesn't know anything about the shape of your desired > part. It simply has a series of lines and arcs. It moves the tool > along this path, or along the right or left of it. > > It seems to me that just having a configuration option somewhere, or a register, or a parameter, or a menu choice somewhere - such as whether to treat the condition as an error, warning, or silent, and knowing the result - would help to solve the "desired" unknown. For myself, in most situations it would be very convenient to just follow the path and leave what it cannot reach, - for other machinery or users or applications it might be unacceptable and an error condition could be a life-saver. I believe flexibility, where possible is always desirable. As for implementing the behavior, I guess that could be very easy and well worth it, or very hard and not. But I would imagine that there must already be some behavior that leaves material in shallow angles up to a certain point without generating an error? - since a circle can never cross a vertex from inside an angle without crossing a line. Or maybe it handles it another way - I have no idea. > One thing you might consider is having the CAM compensate the path for > your nominal tool diameter but leave in the G41/G42. Then run with a > tool diameter of zero in your tool table, or if you want tweak the > path, run with a very small positive or negative tool diameter that's > the difference between your CAM's idea of the nominal tool and the > actual tool. > > I think possibly for many EMC users, CAM is not an easy thing. Many plasma applications are using artistically oriented patterns and programs, such as clipart or truetype font cutouts and without a decent CAM, offset functionality can be a huge advantage. One could argue that offset functionality is a CAM issue altogether, but fortunately, there is a G-code for it :) ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
