On Jun 10 2014 10:15 AM, Daniel Rogge wrote: >>I don't think that is quite fair. >>There is some resistance to the iocontrol hack that hard-codes the >> behaviour. (And there are reasons not to like the Fanuc way, too, >> it is incompatible with the tooldatabase schema that we hacked >> out last year) > >> Chris recently proposed a new variant of G43 that would allow >> one to configure a Fanuc-like toolchange by remapping the >> T-word, which I feel might be a better solution. > > > Andy, > > It wasn't hard coded - it was something only enabled in an ini file, > and was off by default. I know that you and Chris like a variant of > G43 better. Others prefer the way Fanuc does it (myself included). > There are valid arguments to be made for both syntaxes. I understand > that allowing everyone to have their own way of doing things makes > code much harder to maintain, and I don't fault anyone for rejecting > these patches. It is quite hard to determine where to draw the line > between each developer being allowed to add whatever they want, and a > stable, easy to read/configure/use codebase. I think that the folks > involved with Linuxcnc do a better job of this than I would if I were > in their shoes. I was only trying to convey to Rick that it's > unlikely that he will be getting the feature he wants anytime soon, > as > he is in the minority of individuals in favor of the Fanuc syntax.
About a decade ago I wrote an experimental parser that was polymorphic in runitime - meaning that you could overload this functionality without having to recompile the entire system. It was motivated by issues like this -- specifically where you have very old code that had a particular interpretation of the G/M-codes, but was different that yet another variant. That parser would also allow you to implement new g-codes on the fly. In cases like the above -- the division line between the implementation is the object dispatch mechanism, and the user's operator overloads. You can still have the debate as to what will be released in the standard package, but since it is runtime polymorphic you can mix and match. Looking forward to LCNC-2.7, 2.8 or even 3.0, more advanced interpreters/compilers may be fruitful. EBo -- ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
