From: David A. <da...@ou...> - 2013-08-23 10:43:06
|
support for G71 As per posting on the forum , can this patch be assessed and included into master http://www.bpuk.org/linuxcnc/g71-patch-2-initial-feedback-mod2.diff |
From: Michael H. <ma...@ma...> - 2013-08-23 10:50:56
|
Am 23.08.2013 um 12:43 schrieb David Armstrong <da...@ou...>: > support for G71 > > As per posting on the forum , can this patch be assessed and included > into master which forum post? > > http://www.bpuk.org/linuxcnc/g71-patch-2-initial-feedback-mod2.diff all of this can be achieved without any C++ changes, by just using documented methods as outlined here: http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_creating_new_g_code_cycles_a_id_remap_g_code_cycles_a - Michael > > ------------------------------------------------------------------------------ > 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 > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers |
From: David A. <da...@ou...> - 2013-08-23 11:06:17
|
On 23/08/13 11:50, Michael Haberler wrote: > Am 23.08.2013 um 12:43 schrieb David Armstrong <da...@ou...>: > >> support for G71 >> >> As per posting on the forum , can this patch be assessed and included >> into master > > which forum post? > >> http://www.bpuk.org/linuxcnc/g71-patch-2-initial-feedback-mod2.diff > all of this can be achieved without any C++ changes, by just using documented methods as outlined here: > > http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_creating_new_g_code_cycles_a_id_remap_g_code_cycles_a > > - Michael > > >> ------------------------------------------------------------------------------ >> 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 >> Emc...@li... >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > ------------------------------------------------------------------------------ > 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 > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers > > http://linuxcnc.org/index.php/english/forum/9-installing-linuxcnc/26833-using-g71-on-sherline-lathe#37888 |
From: andy p. <bod...@gm...> - 2013-08-23 12:14:25
|
On 23 August 2013 11:50, Michael Haberler <ma...@ma...> wrote: > all of this can be achieved without any C++ changes, by just using documented methods as outlined here: Are you sure? One feature of G71 is that it interprets a block of G-code as defining a profile, but then doesn't actually follow the moves in that profile. I can see that that might be possible in Python, but not as a G-code based G-code remap. Also, as is clear in that forum thread, not everyone wants to have to install chunks of code or patch the source to have access to what is a moderately standard G-code. What little thought I have given to G71 (and friends) begins with adding an extra O-word "O100 BLOCK / ENDBLOCK" to define a chunk of code (and provide an ID number for it) that is skipped by the normal G-code parser, but that can be interpreted by a special routing (the same idea would work for a mill-pocketing routine) I am not clear how the G71 in that patch works, is there any documentation for it? What prevents the G-code interpreter from executing the N-numbered lines? -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto |
From: Michael H. <ma...@ma...> - 2013-08-23 12:38:15
|
Am 23.08.2013 um 14:13 schrieb andy pugh <bod...@gm...>: > On 23 August 2013 11:50, Michael Haberler <ma...@ma...> wrote: > >> all of this can be achieved without any C++ changes, by just using documented methods as outlined here: > > Are you sure? One feature of G71 is that it interprets a block of > G-code as defining a profile, but then doesn't actually follow the > moves in that profile. We had a similar profile discussion about a year ago, the proposed solution I suggested was: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/list-recorder-by-remap This was about a patch with severe breakage potential on label semantics and then some. The suggestion wasnt taken up because of a personal preference for C++ over Python, after which I rested my case. > I can see that that might be possible in Python, but not as a G-code > based G-code remap. why? all fields in a block are exposed in Python and open for alternative interpretation during a remapped code. > Also, as is clear in that forum thread, not everyone wants to have to > install chunks of code or patch the source to have access to what is a > moderately standard G-code. sure, that was the reason why extensability of the interpreter was on the desired feature list, and why I put considerable effort into making it work - I have no idea why folks refuse to look at whats there and go straight to fiddling C++ code. Thats what plugins are all about, I would think. > What little thought I have given to G71 (and friends) begins with > adding an extra O-word "O100 BLOCK / ENDBLOCK" to define a chunk of > code (and provide an ID number for it) that is skipped by the normal > G-code parser, but that can be interpreted by a special routing (the > same idea would work for a mill-pocketing routine) Have a look at the list-recorder-by-remap code. The basic idea is to mirror the codes used in the profile definition: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=configs/sim/remap/list-recorder/list-recorder.ini;h=379e96eb0d041ec22efb09fc0c186dcfdecb55d4;hb=65e9a3087223a196147d74625f715700cbe5d683#l99 so the 'recording version' of G0 becomes G0.1, G1 becomes G.1 etc. line 20 onwards shows the recording method: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=configs/sim/remap/list-recorder/nc_files/list.ngc;h=9609fccc7924566dbe4739fe2a5443684f01baf4;hb=65e9a3087223a196147d74625f715700cbe5d683 line 30 and 35 show the 'dump profile' and 'replay profile' operations. The is no need whatsoever to invent new block semantics, or fudge label semantics as proposed at the time and here. It is all linear execution. No breakage potential with new ad-hack control structures, all documented, doable now, examples available. -- Flatly I dont get it why folks just go straight to patching around in C++ code, and inventing bizarre new control "features" instead of reading a manual and trying examples, maybe ask a question on the list before going about it. - Michael > > I am not clear how the G71 in that patch works, is there any > documentation for it? What prevents the G-code interpreter from > executing the N-numbered lines? > > -- > atp > If you can't fix it, you don't own it. > http://www.ifixit.com/Manifesto > > ------------------------------------------------------------------------------ > 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 > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers |
From: andy p. <bod...@gm...> - 2013-08-23 13:07:16
|
On 23 August 2013 13:38, Michael Haberler <ma...@ma...> wrote: > Flatly I dont get it why folks just go straight to patching around in C++ code, and inventing bizarre new control "features" instead of reading a manual and trying examples Maybe because they see G71 as an addition to the LinuxCNC G-code language support, not an additional, optional, plug-in that requires users to configure Python files and create a unique system all of their own? I don't even know if this is an accurate description of the situation, but a G-code that only works for some people does seem like it might cause problems. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto |
From: David A. <da...@ou...> - 2013-08-23 13:58:10
|
On 23/08/13 14:06, andy pugh wrote: > On 23 August 2013 13:38, Michael Haberler <ma...@ma...> wrote: >> Flatly I dont get it why folks just go straight to patching around in C++ code, and inventing bizarre new control "features" instead of reading a manual and trying examples > Maybe because they see G71 as an addition to the LinuxCNC G-code > language support, not an additional, optional, plug-in that requires > users to configure Python files and create a unique system all of > their own? > > I don't even know if this is an accurate description of the situation, > but a G-code that only works for some people does seem like it might > cause problems. > I respectfully place this view . My point is that not all people are programmers or capable of scripting or re-compiling , and what is now a resonable standard G Code , should be supported as such and part of the mainstream build i have come across many people thinking to use Linuxcnc , and because it does not conform to their resonable standards out the box , in comparison to x product they wont use it , due to machine down time and perhaps the learning curve are other matters , but every controller on the planet just about has canned cycles G71 as standard , so no learning curve ! . which is perhaps one point why it keeps popping up on the lists and forums .. the easier we make it to do the majority out the box the better . we should support standards and leave scripting for the newer wizards .. With all the changes Micheal and others are doing are for the best , yes i agree , but missing out the basics .. should not be taken lightly , everyone is thinking as a programmer .. or coder ... not as a user or poor apprentice been given the task to program a machine . what can be easy for us to use , can be a nightmare of major proportions for others . or are we displaying it to wider user the wrong way . |
From: Michael H. <ma...@ma...> - 2013-08-23 15:55:56
|
Am 23.08.2013 um 15:58 schrieb David Armstrong <da...@ou...>: > On 23/08/13 14:06, andy pugh wrote: >> On 23 August 2013 13:38, Michael Haberler <ma...@ma...> wrote: >>> Flatly I dont get it why folks just go straight to patching around in C++ code, and inventing bizarre new control "features" instead of reading a manual and trying examples >> Maybe because they see G71 as an addition to the LinuxCNC G-code >> language support, not an additional, optional, plug-in that requires >> users to configure Python files and create a unique system all of >> their own? >> >> I don't even know if this is an accurate description of the situation, >> but a G-code that only works for some people does seem like it might >> cause problems. >> > > I respectfully place this view . > > My point is that not all people are programmers or capable of scripting > or re-compiling , and what is now a resonable standard G Code , should > be supported as such and part of the mainstream build > i have come across many people thinking to use Linuxcnc , and because it > does not conform to their resonable standards out the box , in > comparison to x product they wont use it , due to machine down time and > perhaps the learning curve are other matters , but every controller on > the planet just about has canned cycles G71 as standard , so no learning > curve ! . > > which is perhaps one point why it keeps popping up on the lists and > forums .. > > the easier we make it to do the majority out the box the better . > we should support standards and leave scripting for the newer wizards .. that's all fine, the problem is you ask 10 people and get 15+ different views of what is 'standard' now if you go down the 'lets do it in C++' route everybody rams down his view everybody else's throat, including any aberration - see the murky control flow changes which are inacceptable as proposed IMV if you do a remapping config, that does not happen because its optional; the C++ patches are not made to be optional. -- Let's take an analogy, for instance Firefox and say Autocad. These are generic frameworks with a plugin capability, and it is very easy to adapt behavior by installing 'extensions', ad blockers, lisp files, what have you. Much of the functionality comes from plugins, and nobody would think of asking Autocad or Mozilla Foundation to recode their favorite plugin in the core code just because they love C++ so much. I dont see the interpreter as anywhere different. You dont like what you have, you provide an extension. In fact I would see a future interpreter as a minimal C/C++ framework wich generates an abstract syntax tree, and exposes this to an embedded Language, which provides 'the meat' (semantics). Then the difference between core and extension code goes away completely. That said, I concede that building such an extension isnt exactly the most straighforward thing on earth, it requires reading the manual and working through the examples. But people definitely use it. 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? A remapped code is a .ini fragment, maybe a bit of Python, maybe an NGC file or several. Those could well be collected in a per-extension directory, and I could even imagine making these installable with say 'apt-get install rs274-g71-suchandsuch-flavor', and on startup that extension would be pulled in automatically because the interpreter scans a directory of installed extensions, which are one per subdirectory therein. That is for instance exactly what apache does, and gazillion of other demons which have some /etc/<commandname>.d/ directory where config fragments are assembled. - Michael > With all the changes Micheal and others are doing are for the best , yes > i agree , but missing out the basics .. should not be taken lightly , > everyone is thinking as a programmer .. or coder ... not as a user or > poor apprentice been given the task to program a machine . > > what can be easy for us to use , can be a nightmare of major proportions > for others . > > or are we displaying it to wider user the wrong way . > > > ------------------------------------------------------------------------------ > 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 > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers |
From: David A. <da...@ou...> - 2013-08-23 16:20:27
|
On 23/08/13 16:55, Michael Haberler wrote: > Am 23.08.2013 um 15:58 schrieb David Armstrong <da...@ou...>: > >> On 23/08/13 14:06, andy pugh wrote: >>> On 23 August 2013 13:38, Michael Haberler <ma...@ma...> wrote: >>>> Flatly I dont get it why folks just go straight to patching around in C++ code, and inventing bizarre new control "features" instead of reading a manual and trying examples >>> Maybe because they see G71 as an addition to the LinuxCNC G-code >>> language support, not an additional, optional, plug-in that requires >>> users to configure Python files and create a unique system all of >>> their own? >>> >>> I don't even know if this is an accurate description of the situation, >>> but a G-code that only works for some people does seem like it might >>> cause problems. >>> >> I respectfully place this view . >> >> My point is that not all people are programmers or capable of scripting >> or re-compiling , and what is now a resonable standard G Code , should >> be supported as such and part of the mainstream build >> i have come across many people thinking to use Linuxcnc , and because it >> does not conform to their resonable standards out the box , in >> comparison to x product they wont use it , due to machine down time and >> perhaps the learning curve are other matters , but every controller on >> the planet just about has canned cycles G71 as standard , so no learning >> curve ! . >> >> which is perhaps one point why it keeps popping up on the lists and >> forums .. >> >> the easier we make it to do the majority out the box the better . >> we should support standards and leave scripting for the newer wizards .. > that's all fine, the problem is you ask 10 people and get 15+ different views of what is 'standard' > > now if you go down the 'lets do it in C++' route everybody rams down his view everybody else's throat, including any aberration - see the murky control flow changes which are inacceptable as proposed IMV > > if you do a remapping config, that does not happen because its optional; the C++ patches are not made to be optional. I think it's more a question of ease of use , for the non programmers , and for it to be included by default in an extension directory , rather than an addition by whatever means so why not a directory structure where these ' plugins can reside ' , but to the user they are transparent and need no manipulation to work i.e installed by default , so yes i agree it's more of a packaging and 'Yes it works out the box ' rather than ' oh you need to do this for x to work ! ' so yea i think thoughts on it's structure may be the best way , and by far i'm not the one to suggest how to implement it , i am by far not criticising how it is now , just how the hell to make it better from the user point of view , that knows enough to be dangerous with linux .. and a machine attached > -- > > Let's take an analogy, for instance Firefox and say Autocad. These are generic frameworks with a plugin capability, and it is very easy to adapt behavior by installing 'extensions', ad blockers, lisp files, what have you. Much of the functionality comes from plugins, and nobody would think of asking Autocad or Mozilla Foundation to recode their favorite plugin in the core code just because they love C++ so much. > > I dont see the interpreter as anywhere different. You dont like what you have, you provide an extension. In fact I would see a future interpreter as a minimal C/C++ framework wich generates an abstract syntax tree, and exposes this to an embedded Language, which provides 'the meat' (semantics). Then the difference between core and extension code goes away completely. > > That said, I concede that building such an extension isnt exactly the most straighforward thing on earth, it requires reading the manual and working through the examples. But people definitely use it. > > 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? > > A remapped code is a .ini fragment, maybe a bit of Python, maybe an NGC file or several. Those could well be collected in a per-extension directory, and I could even imagine making these installable with say 'apt-get install rs274-g71-suchandsuch-flavor', and on startup that extension would be pulled in automatically because the interpreter scans a directory of installed extensions, which are one per subdirectory therein. That is for instance exactly what apache does, and gazillion of other demons which have some /etc/<commandname>.d/ directory where config fragments are assembled. > > > - Michael > > > > >> With all the changes Micheal and others are doing are for the best , yes >> i agree , but missing out the basics .. should not be taken lightly , >> everyone is thinking as a programmer .. or coder ... not as a user or >> poor apprentice been given the task to program a machine . >> >> what can be easy for us to use , can be a nightmare of major proportions >> for others . > > > >> or are we displaying it to wider user the wrong way . >> >> >> ------------------------------------------------------------------------------ >> 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 >> Emc...@li... >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > ------------------------------------------------------------------------------ > 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 > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers > > |
From: andy p. <bod...@gm...> - 2013-08-23 16:11:09
|
On 23 August 2013 16:55, Michael Haberler <ma...@ma...> 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. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto |
From: David A. <da...@ou...> - 2013-08-23 16:35:14
|
On 23/08/13 17:10, andy pugh wrote: > On 23 August 2013 16:55, Michael Haberler <ma...@ma...> 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 . |
From: Michael H. <ma...@ma...> - 2013-08-23 16:50:52
|
Am 23.08.2013 um 18:35 schrieb David Armstrong <da...@ou...>: > On 23/08/13 17:10, andy pugh wrote: >> On 23 August 2013 16:55, Michael Haberler <ma...@ma...> 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 . right, you want G71 to be always present, then you ship the interpreter with that extensions and any other you deem essential - that's like stock plugins nothing keeps us from defining extension sets like 'packaged', say 'recommended for lathe', 'recommended for mill', 'experimental', or whatever categories -- If there is any lesson to be learned from what is happening with user interfaces right now: if it is possible in Python, it will be picked up eventually - not everybody, but quite a few nevertheless; if it is C++, it will not happen time to sketch a spec for that feature -m > > > > ------------------------------------------------------------------------------ > 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 > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers |