On Thu, Aug 19, 2010 at 12:29:39PM -0400, Thomas D. wrote: > > 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.
So very true. > 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. Let me try to explain an example. I really think the disconnect between how I as a programmer think about it and how a user thinks about it is our different understanding of what a "corner" is. I tried to explain this in my last message. Say you are cutting inside a bunch of square pockets. If you use a reasonable tool size for it the offset path is some smaller squares. If you use a larger tool diameter, the offset path gets smaller. At some point, as you keep enlarging the tool, when the diameter of the tool is larger than the side of the square, the offset path disappears (it becomes a square with NEGATIVE side length). At this point EMC will give you an error because it can't make the tool follow inside that path anymore. Note EMC doesn't know these pockets are squares. But when it calculates these endpoints generated by finding where the tool fits inside the corner, and sees that they are connected by degenerate lines, it errors. (EMC considers two corners at a time because you need to know two endpoints to make a compensated move. These corners are defined by the three nearby moves. This is the extent of its knowledge of your programmed motions as it moves along.) I understand you want it to keep going in some cases of degenerate paths, and I do too. But without knowing things it can't know (like conceptually what the part looks like) it can't keep going without guessing. In your program that cuts a hundred square pockets, what does it mean to keep going if the tool doesn't fit in them? Chris ------------------------------------------------------------------------------ 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
