Re: [Emc-developers] Distributing remaps
>I think remap might be a good way to prototype it, and it could be >distributed (like Sam says) as one of the remap examples. In this >format it would be useful to anyone who did the work of integrating that >remap code with their own machine config. >But i think the end goal should be inclusion into the C++ code inside >the interpreter itself, so that it's available to all users with no >setup required. How difficult would it be to modify linuxcnc to use remapped Gcode automatically if it is placed in a particular folder and that folder is distributed? I see a great service to integrators if gcode routines (particularly canned cycles) are written in python / O codes. Is there a real world difference (to users) if the interpreter uses c++ or python? I assume the interpreter would take a little longer if it uses python but it is usually miles ahead of the actual machine. Is there any developer reason not to use python coded cycles as 'standard & distributed'? Chris M -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Distributing remaps
On 11/14/2016 08:20 AM, dragon wrote: > That was exactly my plan as well. Use a sub to make it more in line with > the way that linuxCNC already does things. > > There have been a few attempts at g71 in the past, but they were all > half-baked from what I could find. None that I found implemented g70. > They were also very 'hacky' in the way that they tried to use line > numbers. I personally feel that the fix for that is to use an o-sub. > > The big question is, if it is done as a remap will it get distributed? I really like the g-code syntax you (Todd/Dragon and Andy) are talking about, using o-subs instead of line numbers for the profile. I think remap might be a good way to prototype it, and it could be distributed (like Sam says) as one of the remap examples. In this format it would be useful to anyone who did the work of integrating that remap code with their own machine config. But i think the end goal should be inclusion into the C++ code inside the interpreter itself, so that it's available to all users with no setup required. This is just one dude's opinion, take it with a grain of salt since it didn't come with an offer to help do the work! -- Sebastian Kuzminsky -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Distributing remaps
My thought would be to add a config to /sim/axis/remap then people can use it as they please. sam On 11/14/2016 9:20 AM, dragon wrote: > That was exactly my plan as well. Use a sub to make it more in line with > the way that linuxCNC already does things. > > There have been a few attempts at g71 in the past, but they were all > half-baked from what I could find. None that I found implemented g70. > They were also very 'hacky' in the way that they tried to use line > numbers. I personally feel that the fix for that is to use an o-sub. > > The big question is, if it is done as a remap will it get distributed? > > It would be great to work together with others on this. > > -Todd > > On 11/14/2016 09:01 AM, andy pugh wrote: >> On 14 November 2016 at 14:20, dragon wrote: >>> I am working towards implementing lathe roughing cycles g71/g72. There >>> was some discussion in Wichita as to using remap or integrating this >>> into interp. I am trying to get a feel for what the devs would prefer. >> Interesting, I was seriously considering doing this myself. >> >> What I was thinking of doing was doing it Python first to check the >> logic, then converting to C++ to move it to interp_cycles.cc >> >> What started me looking at it was that there is a moderately simple >> way to tell G71 where to find the code without considerably altering >> the way that LinuxCNC works with line numbers. >> >> All you need to do is define the profile in a numbered O-sub block. >> >> O100 SUB >> G0 >> G1 >> G2 >> G3 >> G1 >> O100 ENDSUB >> >> G71 P100 >> >> This way the profile will be automatically skipped by the interpreter. >> > > > -- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Distributing remaps
That was exactly my plan as well. Use a sub to make it more in line with the way that linuxCNC already does things. There have been a few attempts at g71 in the past, but they were all half-baked from what I could find. None that I found implemented g70. They were also very 'hacky' in the way that they tried to use line numbers. I personally feel that the fix for that is to use an o-sub. The big question is, if it is done as a remap will it get distributed? It would be great to work together with others on this. -Todd On 11/14/2016 09:01 AM, andy pugh wrote: > On 14 November 2016 at 14:20, dragon wrote: >> I am working towards implementing lathe roughing cycles g71/g72. There >> was some discussion in Wichita as to using remap or integrating this >> into interp. I am trying to get a feel for what the devs would prefer. > > Interesting, I was seriously considering doing this myself. > > What I was thinking of doing was doing it Python first to check the > logic, then converting to C++ to move it to interp_cycles.cc > > What started me looking at it was that there is a moderately simple > way to tell G71 where to find the code without considerably altering > the way that LinuxCNC works with line numbers. > > All you need to do is define the profile in a numbered O-sub block. > > O100 SUB > G0 > G1 > G2 > G3 > G1 > O100 ENDSUB > > G71 P100 > > This way the profile will be automatically skipped by the interpreter. > signature.asc Description: OpenPGP digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Distributing remaps
On 14 November 2016 at 14:20, dragon wrote: > I am working towards implementing lathe roughing cycles g71/g72. There > was some discussion in Wichita as to using remap or integrating this > into interp. I am trying to get a feel for what the devs would prefer. Interesting, I was seriously considering doing this myself. What I was thinking of doing was doing it Python first to check the logic, then converting to C++ to move it to interp_cycles.cc What started me looking at it was that there is a moderately simple way to tell G71 where to find the code without considerably altering the way that LinuxCNC works with line numbers. All you need to do is define the profile in a numbered O-sub block. O100 SUB G0 G1 G2 G3 G1 O100 ENDSUB G71 P100 This way the profile will be automatically skipped by the interpreter. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1916 -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Distributing remaps
I am working towards implementing lathe roughing cycles g71/g72. There was some discussion in Wichita as to using remap or integrating this into interp. I am trying to get a feel for what the devs would prefer. If a remap implementation is preferred, is there a proposal for shipping these remaps and having them available to users by default? Thanks, Todd signature.asc Description: OpenPGP digital signature -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
