On 23/08/13 17:10, andy pugh wrote: > On 23 August 2013 16:55, Michael Haberler <[email protected]> wrote: >> Now if it turns out to be more of a packaging problem what we are talking >> about here, then why dont we think a little bit about packaging extensions >> and make them easier installable? > That might be a solution. > > The G-code remapping capability we have is great, but it is very much > at the "Integrator" not the "User" level. > As the forum thread linked to show, some people really don't want to > be anywhere near what they think of as "programming", even those who > write and work with G-code. > > > i totaly agree Andy , although my other concern is that , for example everyone expects G71 to work out the box to resonable laid down standard or spec , as many commercial cam programs output for canned cycles out the box the last thing we need is an apprentice to go and change it fundamentaly , although say adding say G71.1 would be acceptable .
but having certian codes such as G71 in a plugin directory , we would then be able to say in the doc's that G71 is supported directly as installed , which is different for someone to see it missing , but that having to trawl or post to see , what he thinks for whatever reason is a work around ... as he sees it not incorporated in the main build . ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
