From: Michael H. <ma...@ma...> - 2011-10-25 21:22:25
|
Andy, Am 25.10.2011 um 20:04 schrieb andy pugh: > On 25 October 2011 18:20, Michael Haberler <ma...@ma...> wrote: > >> this strikes me as a more natural way to deal with it and reuse builtin functionality, and in that case I would see a use case to make many, if not all existing codes >> remappable > > Well, I can see it both ways. > If you have remapped a code, then it seems logical that it is remapped > everywhere, and to do otherwise is inconsistent. (The same code means > different things in different parts of the code) Your are right that it is a change of interpretation which is context-dependent - you cannot tell by looking at the replacement procedure alone what the semantics of a given code would be, you need to consider the corresponding REMAP= statement and wether it is a recursion case. I dont like that aspect. On the other hand its a lot less namespace clutter. As things are now, you could: it would always be an error, because it would be a remapping recursion, for which I found no reasonable use case. It would be nice to retain the property that you could look at a block in isolation and still tell what it does (nonwithstanding the context-free grammar aspects of the EMC2 RS274NGC dialect, like the oword control structures, which cant be analyzed block-by-block either). One possible solution I see is a another code in the style of G53 which changes the interpretation of another G code in the same block to mean absolute rather than current system. That would make it unambiguously explicit that the builtin functionality is requested for other codes in this block. Assume 'M666' would mean to say: 'regardless if a code in the same block is remapped or not, always use the builtin functionality if any' In the case of the M6 replacement example that could be o<foo> sub .. my additions ... M666 M6 (execute builtin M6 functionality whatever M6 is defined to mean currently) ... more additions .. o<foo> endsub I guess I'll sleep over it. -m > > However, it is probably a lot more _useful_ the other way. Any time > you remap a code you are very likely to still want to do it, > especially in the example of a remapped G0 or M6. > > One interesting application would be to allow Viesteurs to do G2/G3 in > UV space, though in that case there would still be no way to use the > existing G2/G3 because they still do the wrong thing (however as far > as I can make out, the real G2 and G3 just break up arcs into 128 > straight lines per circle (or is that per radian?)) > > -- > atp > "Torque wrenches are for the obedience of fools and the guidance of wise men" > > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > Emc-developers mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers |