Re: [Emc-developers] linuxcnc-features in linuxcnc?

[Kenneth Lerman]

Right now, you get an error together with a line number.

A good fix would be to do a stack backtrace. If it is in a subroutine, show
the line that it was called from including the values of all of the
arguments. Then, if that line is in a subroutine, show where it was called
from with its arguments. Recursively.

A second aid that would be handy is to have tracing. As each line is
interpreted, output the raw line (and file:linenumber) to a file. Also
output the expanded values of any arguments. (So: X[#21+#44] would be
output with as X[4.] if that's the sum.) When an error is detected, the
trace file would be flushed so that the user could look at it.

A third aid would be like gdb. It would have the ability to set a
breakpoint on a line. It would also cause a "break" when there was an
error. Within this tool, one could look at the current subroutine stack,
look at local and global named parameters, etc.

The first two tools would be pretty easy. The third would be somewhat
harder.

Ken


On Fri, Nov 6, 2015 at 11:11 PM, EBo  wrote:

> On Nov 6 2015 4:44 PM, Gene Heskett wrote:
> > On Friday 06 November 2015 09:09:26 EBo wrote:
> >
> >> On Nov 6 2015 6:39 AM, Gene Heskett wrote:
> >> > On Friday 06 November 2015 04:53:15 andy pugh wrote:
> >> >> On 6 November 2015 at 04:29, Fernand Veilleux
> >> >> 
> >> >
> >> > wrote:
> >> >> > gcode is terrible IMHO.
> >> >>
> >> >> It's a terrible programming language, but then it was never
> >> >> intended to be one.
> >> >
> >> > I wouldn't condem it quite that vociferously.  It has the basic
> >> trig
> >> > functions, all the basic control loop stuff, and several ways to
> >> do
> >> > a subroutine.  My biggest and loudest bitch is the inability to
> >> > troubleshoot an errant arc move in a subroutine that may have 10
> >> of
> >> > them
> >> > in it,  it gets blamed on the line that calls the sub.  I have had
> >> > to convert my blanket-chest code from 3 subroutines, to multiple
> >> > copies of
> >> > the subroutine but inline.  In the process, I probably have 300
> >> LOC
> >> > out
> >> > of 650 or so that are never executed.  Its a horrible mess, but it
> >> > works.
> >>
> >> So then the question is "how do we develop better debugging tools?"
> >> or at least analytic tools of the results?  For example, I can see
> >> generating a little more output to go from the motion planner to the
> >> tool path display.  If those lines and arcs had the program line
> >> number somehow associated with it, then you would be able to
> >> possible
> >> zoom in and ask a question about a specific line segment displayed.
> >> It would then tell you which line of code generated it.  There might
> >> also be other metadata you want to associate with it (like depth of
> >> recursion or stack depth, ... hmmm... I do not know off the top of
> >> my
> >> head).  If we did not provide analytics, then it would be good to be
> >> able to step into a subroutine to execute it as well as run a call.
> >> Last version of LCNC I used had *something* like this, but I do
> >> remember that it did not play well with subroutines.  Not sure about
> >> the latest and greatest.  What I am envisioning here is the GDB
> >> equivalent of motion control -- full variable querying and setting
> >> capabilities, and the ability to set break points and other useful
> >> functionality.
> >>
> >> Just a thought...  now back to my normal programming...
> >>
> >>EBo --
> >>
> > Well, such thoughts would find me encouraging the effort for sure.
>
> I will add this to the end of a 50 level project queue...  Seriously
> though, it might not be that bad to implement.  A bit noisy though (but
> that is what dubug switches are for).  Hmmm... maybe if Google Summer of
> Code sponsored it, this would be a useful idea and suitable for an
> intern project...
>
>EBo --
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>



-- 
Kenneth Lerman
55 Main Street
Newtown, CT 06470
--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[EBo]

Agreed on all accounts.  It is also possible that options 1 and/or 2 
could be structure in such a way to support option 3 (simula gdb).

I was serious about the intern thing.  If one was interested I would be 
glad to try to help with mentioning, but I have roughly a petabyte of 
data to process at work (seriously), and it will be months before I have 
enough time to pick anything else up, and the couple of side projects I 
have not already swept under the rug are not getting much love.  I 
cannot take this one on.

   EBo --

On Nov 9 2015 11:15 AM, Kenneth Lerman wrote:
> Right now, you get an error together with a line number.
>
> A good fix would be to do a stack backtrace. If it is in a 
> subroutine, show
> the line that it was called from including the values of all of the
> arguments. Then, if that line is in a subroutine, show where it was 
> called
> from with its arguments. Recursively.
>
> A second aid that would be handy is to have tracing. As each line is
> interpreted, output the raw line (and file:linenumber) to a file. 
> Also
> output the expanded values of any arguments. (So: X[#21+#44] would be
> output with as X[4.] if that's the sum.) When an error is 
> detected, the
> trace file would be flushed so that the user could look at it.
>
> A third aid would be like gdb. It would have the ability to set a
> breakpoint on a line. It would also cause a "break" when there was an
> error. Within this tool, one could look at the current subroutine 
> stack,
> look at local and global named parameters, etc.
>
> The first two tools would be pretty easy. The third would be somewhat
> harder.
>
> Ken
>
>
> On Fri, Nov 6, 2015 at 11:11 PM, EBo  wrote:
>
>> On Nov 6 2015 4:44 PM, Gene Heskett wrote:
>> > On Friday 06 November 2015 09:09:26 EBo wrote:
>> >
>> >> On Nov 6 2015 6:39 AM, Gene Heskett wrote:
>> >> > On Friday 06 November 2015 04:53:15 andy pugh wrote:
>> >> >> On 6 November 2015 at 04:29, Fernand Veilleux
>> >> >> 
>> >> >
>> >> > wrote:
>> >> >> > gcode is terrible IMHO.
>> >> >>
>> >> >> It's a terrible programming language, but then it was never
>> >> >> intended to be one.
>> >> >
>> >> > I wouldn't condem it quite that vociferously.  It has the basic
>> >> trig
>> >> > functions, all the basic control loop stuff, and several ways 
>> to
>> >> do
>> >> > a subroutine.  My biggest and loudest bitch is the inability to
>> >> > troubleshoot an errant arc move in a subroutine that may have 
>> 10
>> >> of
>> >> > them
>> >> > in it,  it gets blamed on the line that calls the sub.  I have 
>> had
>> >> > to convert my blanket-chest code from 3 subroutines, to 
>> multiple
>> >> > copies of
>> >> > the subroutine but inline.  In the process, I probably have 300
>> >> LOC
>> >> > out
>> >> > of 650 or so that are never executed.  Its a horrible mess, but 
>> it
>> >> > works.
>> >>
>> >> So then the question is "how do we develop better debugging 
>> tools?"
>> >> or at least analytic tools of the results?  For example, I can 
>> see
>> >> generating a little more output to go from the motion planner to 
>> the
>> >> tool path display.  If those lines and arcs had the program line
>> >> number somehow associated with it, then you would be able to
>> >> possible
>> >> zoom in and ask a question about a specific line segment 
>> displayed.
>> >> It would then tell you which line of code generated it.  There 
>> might
>> >> also be other metadata you want to associate with it (like depth 
>> of
>> >> recursion or stack depth, ... hmmm... I do not know off the top 
>> of
>> >> my
>> >> head).  If we did not provide analytics, then it would be good to 
>> be
>> >> able to step into a subroutine to execute it as well as run a 
>> call.
>> >> Last version of LCNC I used had *something* like this, but I do
>> >> remember that it did not play well with subroutines.  Not sure 
>> about
>> >> the latest and greatest.  What I am envisioning here is the GDB
>> >> equivalent of motion control -- full variable querying and 
>> setting
>> >> capabilities, and the ability to set break points and other 
>> useful
>> >> functionality.
>> >>
>> >> Just a thought...  now back to my normal programming...
>> >>
>> >>EBo --
>> >>
>> > Well, such thoughts would find me encouraging the effort for sure.
>>
>> I will add this to the end of a 50 level project queue...  Seriously
>> though, it might not be that bad to implement.  A bit noisy though 
>> (but
>> that is what dubug switches are for).  Hmmm... maybe if Google 
>> Summer of
>> Code sponsored it, this would be a useful idea and suitable for an
>> intern project...
>>
>>EBo --
>>
>>
>> 
>> --
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[Gene Heskett]

On Friday 06 November 2015 09:09:26 EBo wrote:

> On Nov 6 2015 6:39 AM, Gene Heskett wrote:
> > On Friday 06 November 2015 04:53:15 andy pugh wrote:
> >> On 6 November 2015 at 04:29, Fernand Veilleux
> >> 
> >
> > wrote:
> >> > gcode is terrible IMHO.
> >>
> >> It's a terrible programming language, but then it was never
> >> intended to be one.
> >
> > I wouldn't condem it quite that vociferously.  It has the basic trig
> > functions, all the basic control loop stuff, and several ways to do
> > a subroutine.  My biggest and loudest bitch is the inability to
> > troubleshoot an errant arc move in a subroutine that may have 10 of
> > them
> > in it,  it gets blamed on the line that calls the sub.  I have had
> > to convert my blanket-chest code from 3 subroutines, to multiple
> > copies of
> > the subroutine but inline.  In the process, I probably have 300 LOC
> > out
> > of 650 or so that are never executed.  Its a horrible mess, but it
> > works.
>
> So then the question is "how do we develop better debugging tools?" 
> or at least analytic tools of the results?  For example, I can see
> generating a little more output to go from the motion planner to the
> tool path display.  If those lines and arcs had the program line
> number somehow associated with it, then you would be able to possible
> zoom in and ask a question about a specific line segment displayed. 
> It would then tell you which line of code generated it.  There might
> also be other metadata you want to associate with it (like depth of
> recursion or stack depth, ... hmmm... I do not know off the top of my
> head).  If we did not provide analytics, then it would be good to be
> able to step into a subroutine to execute it as well as run a call. 
> Last version of LCNC I used had *something* like this, but I do
> remember that it did not play well with subroutines.  Not sure about
> the latest and greatest.  What I am envisioning here is the GDB
> equivalent of motion control -- full variable querying and setting
> capabilities, and the ability to set break points and other useful
> functionality.
>
> Just a thought...  now back to my normal programming...
>
>EBo --
>
Well, such thoughts would find me encouraging the effort for sure.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[EBo]

On Nov 6 2015 4:44 PM, Gene Heskett wrote:
> On Friday 06 November 2015 09:09:26 EBo wrote:
>
>> On Nov 6 2015 6:39 AM, Gene Heskett wrote:
>> > On Friday 06 November 2015 04:53:15 andy pugh wrote:
>> >> On 6 November 2015 at 04:29, Fernand Veilleux
>> >> 
>> >
>> > wrote:
>> >> > gcode is terrible IMHO.
>> >>
>> >> It's a terrible programming language, but then it was never
>> >> intended to be one.
>> >
>> > I wouldn't condem it quite that vociferously.  It has the basic 
>> trig
>> > functions, all the basic control loop stuff, and several ways to 
>> do
>> > a subroutine.  My biggest and loudest bitch is the inability to
>> > troubleshoot an errant arc move in a subroutine that may have 10 
>> of
>> > them
>> > in it,  it gets blamed on the line that calls the sub.  I have had
>> > to convert my blanket-chest code from 3 subroutines, to multiple
>> > copies of
>> > the subroutine but inline.  In the process, I probably have 300 
>> LOC
>> > out
>> > of 650 or so that are never executed.  Its a horrible mess, but it
>> > works.
>>
>> So then the question is "how do we develop better debugging tools?"
>> or at least analytic tools of the results?  For example, I can see
>> generating a little more output to go from the motion planner to the
>> tool path display.  If those lines and arcs had the program line
>> number somehow associated with it, then you would be able to 
>> possible
>> zoom in and ask a question about a specific line segment displayed.
>> It would then tell you which line of code generated it.  There might
>> also be other metadata you want to associate with it (like depth of
>> recursion or stack depth, ... hmmm... I do not know off the top of 
>> my
>> head).  If we did not provide analytics, then it would be good to be
>> able to step into a subroutine to execute it as well as run a call.
>> Last version of LCNC I used had *something* like this, but I do
>> remember that it did not play well with subroutines.  Not sure about
>> the latest and greatest.  What I am envisioning here is the GDB
>> equivalent of motion control -- full variable querying and setting
>> capabilities, and the ability to set break points and other useful
>> functionality.
>>
>> Just a thought...  now back to my normal programming...
>>
>>EBo --
>>
> Well, such thoughts would find me encouraging the effort for sure.

I will add this to the end of a 50 level project queue...  Seriously 
though, it might not be that bad to implement.  A bit noisy though (but 
that is what dubug switches are for).  Hmmm... maybe if Google Summer of 
Code sponsored it, this would be a useful idea and suitable for an 
intern project...

   EBo --

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[andy pugh]

On 6 November 2015 at 04:29, Fernand Veilleux  wrote:
> gcode is terrible IMHO.

It's a terrible programming language, but then it was never intended to be one.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[Gene Heskett]

On Friday 06 November 2015 04:53:15 andy pugh wrote:

> On 6 November 2015 at 04:29, Fernand Veilleux  
wrote:
> > gcode is terrible IMHO.
>
> It's a terrible programming language, but then it was never intended
> to be one.

I wouldn't condem it quite that vociferously.  It has the basic trig 
functions, all the basic control loop stuff, and several ways to do a 
subroutine.  My biggest and loudest bitch is the inability to 
troubleshoot an errant arc move in a subroutine that may have 10 of them 
in it,  it gets blamed on the line that calls the sub.  I have had to 
convert my blanket-chest code from 3 subroutines, to multiple copies of 
the subroutine but inline.  In the process, I probably have 300 LOC out 
of 650 or so that are never executed.  Its a horrible mess, but it 
works.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[EBo]

On Nov 6 2015 6:19 AM, andy pugh wrote:
> On 6 November 2015 at 12:57, EBo  wrote:
>>> It's a terrible programming language, but then it was never 
>>> intended
>>> to be one.
>>
>> fine, but what is better?  STEP-NC (ISO-10303/14649)?
>
> It is a machine control language, not a programming language.
> If you want a programming language then it probably makes sense to 
> use
> one, and to output G-code (or direct motion commands)

I'm not disagreeing, and in fact that is what I typically do.  I was 
curious what people thought was better for both machine control and 
something that straddles general programming and machine control?

Put another way, what is the state of the art with regards to machine 
control and motion primitive programming?

   EBo --

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[andy pugh]

On 6 November 2015 at 12:57, EBo  wrote:
>> It's a terrible programming language, but then it was never intended
>> to be one.
>
> fine, but what is better?  STEP-NC (ISO-10303/14649)?

It is a machine control language, not a programming language.
If you want a programming language then it probably makes sense to use
one, and to output G-code (or direct motion commands)

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[Dewey Garrett]

> ...
> It seems that you deleted bringing_features
> ...

The 'bringin_features' branch rebased on git master was deleted to
avoid confustion with a newer branch 'features_preview' based
on git 2.7 (the current release)

> ...
> But you should not work with version 2.0 it is outdated, having been 
> released about 4 months ago.
> Version 2.01 released last month is much better. They both have much 
> code and files to delete.
> ...

The 'features_preview' branch brings in files from
   https://github.com/FernV/linuxcnc-features.git
starting at commit dfd2btb marked (v2.01)

> ... 
> Features depend on a good directory structure and links to those 
> directories.
> 

Please see posts with 'features_preview' in the Subject for 
additional information on the implemented directory structure.
-- 
Dewey Garrett


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[EBo]

On Nov 6 2015 2:53 AM, andy pugh wrote:
> On 6 November 2015 at 04:29, Fernand Veilleux 
>  wrote:
>> gcode is terrible IMHO.
>
> It's a terrible programming language, but then it was never intended 
> to be one.

fine, but what is better?  STEP-NC (ISO-10303/14649)?

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[EBo]

On Nov 6 2015 6:39 AM, Gene Heskett wrote:
> On Friday 06 November 2015 04:53:15 andy pugh wrote:
>
>> On 6 November 2015 at 04:29, Fernand Veilleux 
>> 
> wrote:
>> > gcode is terrible IMHO.
>>
>> It's a terrible programming language, but then it was never intended
>> to be one.
>
> I wouldn't condem it quite that vociferously.  It has the basic trig
> functions, all the basic control loop stuff, and several ways to do a
> subroutine.  My biggest and loudest bitch is the inability to
> troubleshoot an errant arc move in a subroutine that may have 10 of 
> them
> in it,  it gets blamed on the line that calls the sub.  I have had to
> convert my blanket-chest code from 3 subroutines, to multiple copies 
> of
> the subroutine but inline.  In the process, I probably have 300 LOC 
> out
> of 650 or so that are never executed.  Its a horrible mess, but it
> works.

So then the question is "how do we develop better debugging tools?"  or 
at least analytic tools of the results?  For example, I can see 
generating a little more output to go from the motion planner to the 
tool path display.  If those lines and arcs had the program line number 
somehow associated with it, then you would be able to possible zoom in 
and ask a question about a specific line segment displayed.  It would 
then tell you which line of code generated it.  There might also be 
other metadata you want to associate with it (like depth of recursion or 
stack depth, ... hmmm... I do not know off the top of my head).  If we 
did not provide analytics, then it would be good to be able to step into 
a subroutine to execute it as well as run a call.  Last version of LCNC 
I used had *something* like this, but I do remember that it did not play 
well with subroutines.  Not sure about the latest and greatest.  What I 
am envisioning here is the GDB equivalent of motion control -- full 
variable querying and setting capabilities, and the ability to set break 
points and other useful functionality.

Just a thought...  now back to my normal programming...

   EBo --

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[Fernand Veilleux]

Le 2015-10-26 13:09, Sebastian Kuzminsky a écrit :
> Hello Nick and Fernand, I'm a developer on the LinuxCNC project and 
> we've been talking about getting linuxcnc-features into the next 
> stable release of linuxcnc.
>
> Is this something you'd be interested in, willing to help with?
>
> We noticed that there are two linuxcnc-features repos on github, what 
> is the relationship between them?
>
>

Hello Sebastian,

I must admit you took me by surprise when you wrote you wanted to 
include features in next stable release.
I knew it would be interesting but I though that it needed some more 
refinements before.

I have a tight schedule currently and cannot spend much time to rush the 
project.

It seems that you deleted bringing_features and I do not blame you. I 
hope you still think that it is a very good add-on
to linuxcnc, nothing else comes close. Since I wrote more than 90% of 
the code I am the one that knows it best and I will help you.

But you should not work with version 2.0 it is outdated, having been 
released about 4 months ago.
Version 2.01 released last month is much better. They both have much 
code and files to delete.
Those releases were the first I made and it was some kind of market test 
to find the interest.

I believe version 2.02 will be ready to include in stable linuxcnc and I 
am proposing you what I know will work.
Please correct me on what does not fit your view.


Features depend on a good directory structure and links to those 
directories.

APP_PATH : /usr/features
files in this dir : features.py
 features.glade
 features.ui
 CHANGES
 README.md
sub-dirs :  catalogs
 lathe
 mill
 examples
 graphics
 images
 ini
 lathe
 mill
 lib
 support

Working dir : $HOME/linuxcnc/features
 link to APP_PATH/features.ui
 links to APP_PATH/...
 catalogs
 examples
 graphics
 ini
 lib
 support

USER_DATA : $HOME/linuxcnc/features/user (not $USER, full access)
 (preferences file will be saved there, no need to create)
sub-dirs :  catalogs
 lathe   (files that will be saved here : default 
template and history)
 mill(user will save his modified menu.xml)
 graphics
 ini
 lib
 scripts (or the name you think is best, this is where 
resulting file 'features.ngc' will be saved)
 xml
No files need to be created. This is where the user puts his 
modified files.
Features will first search files in USER_DATA and use it if 
found, else it uses APP_PATH


Links needed :
 /usr/local/bin/features to APP_PATH/features.py (stand alone from 
anywhere, no need for args, everything from defaults or preferences file)

 /usr/share/pyshared/gladevcp/features.glade -> APP_PATH/features.glade
 /usr/lib/pymodules/python2.7/gladevcp/features.glade -> 
APP_PATH/features.glade
 /usr/share/pyshared/gladevcp/features.py -> APP_PATH/features.py
 /usr/lib/pymodules/python2.7/gladevcp/features.py -> 
APP_PATH/features.py

 optional :
 /usr/share/pyshared/gladevcp/features_user -> USER_DATA


Files to edit :
 /usr/share/pyshared/gladevcp/hal_pythonplugin.py
 /usr/share/glade3/catalogs/hal_python.xml


Linuxcnc ini files
 axis-features.ini, axis_mm-features.ini and axis_lathe-features.ini 
could be added in sim.axis
 without any other files
 OR
 sim.axis.features dir could be created with the needed files

 Similar option for gmoccapy


This is what I am preparing for release 2.02
I hope to have it ready in less than one month. Some new features I am 
adding are very difficult to implement, gcode is terrible IMHO.


Regards
Fernand



























--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] linuxcnc-features in linuxcnc?

[Sebastian Kuzminsky]

(Please CC the emc-developers list in any replies you send.)


On 10/28/2015 02:27 AM, Nick wrote:
> Hello Sebastian. 
> 
> You should consider Fern's
> repo http://fernv.github.io/linuxcnc-features/ as it is latest one.
> 
> We are interested in including Features into linuxcnc repo because it
> will male it's install much much easier. 

Hi Николай and Fernand, a LinuxCNC developer named Dewey Garrett has
copied the files from github.com/cnc-club/linuxcnc-features.git into a
branch in linuxcnc named "bringin_features":

http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/bringin_features

We may redo it based on this information that Fern's repo is the one to
use, or we may just copy Fern's files over the files we imported.

Once this gets finalized and Features is in LinuxCNC, will you use our
repo as the central place for future bugfixes and development?  That
would bring new Features features and bugfixes to users in the fastest
and most direct way.

We could give you push access to our repo, or you could send us pull
requests on Github if you prefer.

A bunch of us played around with it and were very impressed.  I'm
excited to get this into the hands of all LinuxCNC users in the next
release.


-- 
Sebastian Kuzminsky

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[Nick]

Major benefit of including Features into the LinuxCNC - is making it much
easier to install.
So if we already have needed changes in the GladeVCP files will simplify
the installation procedure a lot. All we'll have to do is put all the files
into the configuration directory and add features into ini file.  (or if we
are satisfied with the version that have came with the release just add
Features into ini file). By the way, we can also add example configuration
into the sim version.

Most of people had problems with installation. If we can provide Features
together with LinuxCNC it will solve this problem!


--

As of the naming. "Features" came from "Feature"  -  a small simple
machining (i.e. slot, hole, or ID, array), and Features - is a combination
of such machinings that should give us a great potential :)

Before any changes of the mane I have o consult with FernV (from the forum)
- because he have made significant work to make Features better.

To my mind Native CAM sounds better than Live CAM (and IMHO Live CAM should
be overspread into the google as Live Camera).

In "my Google" LinuxCNC Features gives at least 7 first links that leads to
Features even with hidden personal results. I'm not saying that it is good,
but this means that LinuxCNC Features can be easily found.


-

These two videos have "English" comments:
https://www.youtube.com/watch?v=giJUiZVTXas
https://www.youtube.com/watch?v=fkOJhT69WEc

--
Best regards,
  Nick Drobchenko
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[Gene Heskett]

On Tuesday 15 September 2015 02:55:35 Nick wrote:

> Major benefit of including Features into the LinuxCNC - is making it
> much easier to install.
> So if we already have needed changes in the GladeVCP files will
> simplify the installation procedure a lot. All we'll have to do is put
> all the files into the configuration directory and add features into
> ini file.  (or if we are satisfied with the version that have came
> with the release just add Features into ini file). By the way, we can
> also add example configuration into the sim version.
>
> Most of people had problems with installation. If we can provide
> Features together with LinuxCNC it will solve this problem!
>
Possily not silly question Nick.  I got rid of the existing gladevcp 
stuffs on that machine, copying over the pyvcp stuff from my small 
lathe, which moved the tach to the right hand panel (axis display), 
making it visible full time.

Will I stand a better chance of installing "features" now?

Thank you Nick.
> --
> Best regards,
>   Nick Drobchenko

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[Gene Heskett]

On Tuesday 15 September 2015 02:55:35 Nick wrote:

> Major benefit of including Features into the LinuxCNC - is making it
> much easier to install.
> So if we already have needed changes in the GladeVCP files will
> simplify the installation procedure a lot. All we'll have to do is put
> all the files into the configuration directory and add features into
> ini file.  (or if we are satisfied with the version that have came
> with the release just add Features into ini file). By the way, we can
> also add example configuration into the sim version.
>
> Most of people had problems with installation.

I sure did Nick, I think a clash with  a gladecp spindle tach on the 3rd 
tab of the preview window is the culprit, but thats handy too.

pncconf puts it there, but IMO that is not the right place for it, it 
really belongs in the left panel immediately above or below the manual 
spindle dir, stop and speed stepping buttons.  Or in the right panel, 
top item where its visible full time.

The standalone preview looked quite useful, so I followed the install 
instructions from the web site, and wound up having to undo all the 
edited stuffs in /usr/share before LinuxCNC version 2.8.0-pre would run 
again.

I have not followed the instructions in the README.md file, are they 
different?

> If we can provide 
> Features together with LinuxCNC it will solve this problem!

I agree, it looks to be quite handy when run as standalone.  But on a 
mill, it come up defaulted to lathe mode, so I did as shown in the 
README.md, then told it to save as default, but it did not, it reverted 
to lathe mode on the next start without the --catalog="argument".

I also intend to install the camview and the align packages, but 2 things 
of note:

1. The camera I originally bought to do this has a physically wide 
format, a logitech C920, which is a very high resolution (1920x1280 
IIRC) camera.  The physical width is because it also has a pair of 
electret condensor mics on each side of the camera that I haven't 
attempted to saw off yet... Unfortunately, camview does not have a 
rotation at 90 degree intervals feature, so I bought a $22 "colonoscopy" 
camera on ebay, a much lower resolution camera. But since it was round I 
could set its rotation in the mount.  It worked quite well except for 
about a 5 second lag thru all the image processing, which made it very 
slow to use as you had to move the table a thou, and wait till the image 
was updated when looking for the mark.  But a wandering holdown bolt 
knocked the mount off the side of the quill housing plus the camera came 
unglued in its tubular housing.  The jig that carried that bolt has now 
been moved to a newer GO704 mill, where I'd like to use this C920 camera 
if I can build an adjustable mount for it.  But without the 90 degree 
rotation it will be confusing to use at best.

It comes across that this post is 100% whine I guess and for tht I 
appologize as you have some nice and useful stuff if the installation 
details can be worked out.

I thank you very much for doing what you have already done with camview 
and align.
> --
>
> As of the naming. "Features" came from "Feature"  -  a small simple
> machining (i.e. slot, hole, or ID, array), and Features - is a
> combination of such machinings that should give us a great potential
> :)
>
> Before any changes of the mane I have o consult with FernV (from the
> forum) - because he have made significant work to make Features
> better.
>
> To my mind Native CAM sounds better than Live CAM (and IMHO Live CAM
> should be overspread into the google as Live Camera).
>
> In "my Google" LinuxCNC Features gives at least 7 first links that
> leads to Features even with hidden personal results. I'm not saying
> that it is good, but this means that LinuxCNC Features can be easily
> found.
>
> These two videos have "English" comments:
> https://www.youtube.com/watch?v=giJUiZVTXas
> https://www.youtube.com/watch?v=fkOJhT69WEc
>
> --
> Best regards,
>   Nick Drobchenko

Thanks Nick.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[TJoseph Powderly]

Hi Nick,
thanks for the message.
Your 'Features' is nice.
Thanks to FernV also.
The name change is just to avoid some confusion.

Большое спасибо
хорошая работа !

regards
TomP tjtr33

On 09/15/2015 01:55 AM, Nick wrote:
> Major benefit of including Features into the LinuxCNC - is making it much
> easier to install.
> So if we already have needed changes in the GladeVCP files will simplify
> the installation procedure a lot. All we'll have to do is put all the files
> into the configuration directory and add features into ini file.  (or if we
> are satisfied with the version that have came with the release just add
> Features into ini file). By the way, we can also add example configuration
> into the sim version.
>
> Most of people had problems with installation. If we can provide Features
> together with LinuxCNC it will solve this problem!
>


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] "LinuxCNC Features"

[andy pugh]

I have just suggested (on the forum) that "LinuxCNC Features" should
be brought under LinuxCNC version control, and become part of the
project.

http://www.linuxcnc.org/index.php/english/forum/40-subroutines-and-ngcgui/26578-linuxcnc-features-a-kind-of-ngcgui?start=240#62559

I can't decide if it should live in Wizards or in the main repository.
Wizards seems rather poorly advertised, to the extent that I have
never tried it and don't know what it does.


-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[andy pugh]

On 14 September 2015 at 16:03, Sebastian Kuzminsky  wrote:
> However, I don't like the name "LinuxCNC Features" for the name of a
> conversational front-end.

 Well, _I_ don't like the name "Axis" for a GUI, that
could cause all sorts of confusion :-)


-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[andy pugh]

On 14 September 2015 at 16:03, Sebastian Kuzminsky  wrote:

> However, I don't like the name "LinuxCNC Features" for the name of a
> conversational front-end.  To me that sounds like an enumeration of the
> things LinuxCNC can do.

Yes, and I suspect that this is part of the reason that it has been
lurking in the background rather than being enthusiastically picked
up.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[Sebastian Kuzminsky]

On 9/14/15 6:14 AM, andy pugh wrote:
> I have just suggested (on the forum) that "LinuxCNC Features" should
> be brought under LinuxCNC version control, and become part of the
> project.
>
> http://www.linuxcnc.org/index.php/english/forum/40-subroutines-and-ngcgui/26578-linuxcnc-features-a-kind-of-ngcgui?start=240#62559
>
> I can't decide if it should live in Wizards or in the main repository.
> Wizards seems rather poorly advertised, to the extent that I have
> never tried it and don't know what it does.

I like the idea of more experimentation and development in 
conversational front-ends or add-ons for LinuxCNC.  I'd welcome a pull 
request, as long as it came with the promise of continuing support by 
the original developer(s).

However, I don't like the name "LinuxCNC Features" for the name of a 
conversational front-end.  To me that sounds like an enumeration of the 
things LinuxCNC can do.


-- 
Sebastian Kuzminsky

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[andy pugh]

On 14 September 2015 at 16:21, TJoseph Powderly  wrote:
> The popularity might be the difficulty in installing Nick's Features.

This is partly why I would like to "bring it in from the cold" so to speak.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[TJoseph Powderly]

The popularity might be the difficulty in installing Nick's Features.

I havent followed the forum, and i have asked.
I will read the forum now.

And for the name..
Linuxcnc Features or Features is about as good as Axis
google linuxcnc axis to see why
didnt hurt the popularity of axis the front end
but makes it damn hard to find

ask Nick for a new name

& Thanks Nick, it always looked great, I just never got it to run
Not your fault

(wish I could read russian, been to the CNC_RU site a lot on this then 
gave up, some damn clever stuff there, like reversal, and edm, for a 
long time )

regards TomP tjtr33

On 09/14/2015 10:13 AM, andy pugh wrote:
> On 14 September 2015 at 16:03, Sebastian Kuzminsky  wrote:
>
>> However, I don't like the name "LinuxCNC Features" for the name of a
>> conversational front-end.  To me that sounds like an enumeration of the
>> things LinuxCNC can do.
>
> Yes, and I suspect that this is part of the reason that it has been
> lurking in the background rather than being enthusiastically picked
> up.
>


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[andy pugh]

On 14 September 2015 at 17:54, Jeff Epler  wrote:
> Being in linuxcnc.git might be the worst possible choice for a new and
> fast-moving project,

The fact that you think it is "New" seems to show something about it
needing more exposure. Nick first mentioned it in May 2013.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[Jeff Epler]

If the goal is to have better online collaboration for this
linuxcnc-related project, I think at least some conderation should be
given to using github rather than hosting on git.linuxcnc.org.

I feel like github would give better visibility (as you mention,
wizards.git is an almost-forgotten thing), and can pretty much be
administered self-service by whoever is the head of that project.
And for better or for worse, github has a lot of currency among software
developers these days.

(personally, I like github's issue tracker over SF's and their pull
request interface works OK even for those who like me prefer to complete
a pull request via the commandline with 'git merge'.  some projects will
also find the wiki feature useful)

Being in linuxcnc.git might be the worst possible choice for a new and
fast-moving project, because of the main project's slow release pace.
If this project went into master branch tomorrow, there's no way it
would be in a released version in less than a year.  There is probably
little reason to tie the release cycles of these two pieces of software
together.

Jeff

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[Sebastian Kuzminsky]

On 9/14/15 10:54 AM, Jeff Epler wrote:
> If the goal is to have better online collaboration for this
> linuxcnc-related project, I think at least some conderation should be
> given to using github rather than hosting on git.linuxcnc.org.

Managing this and other LinuxCNC add-ons as separate projects makes 
partial sense.

On the plus side, it frees them from our somewhat plodding release schedule.

On the minus side, it forces them to duplicate our 
build/test/release/distribution infrastructure, and forces us (their 
project and our project) to invent a new mechanism for collaborating 
(for example, getting their packages onto our repos & ISOs).


-- 
Sebastian Kuzminsky

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[TJoseph Powderly]

yes Nick has several oyutube videos, google "youtube cnc ru features"

 > Has anyone made videos to showcase it running?
>


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[EBo]

On Sep 14 2015 1:37 PM, Andrew wrote:
> 2015-09-14 21:13 GMT+03:00 Peter C. Wallace :
>
>> On Mon, 14 Sep 2015, Sebastian Kuzminsky wrote:
>>
>> > However, I don't like the name "LinuxCNC Features" for the name of 
>> a
>> > conversational front-end.  To me that sounds like an enumeration 
>> of the
>> > things LinuxCNC can do.
>> >
>>
>>
>> LiveCAM?
>>
>>
> It's described as "LinuxCNC Features v2 - native realtime CAM for 
> LinuxCNC"
> here https://github.com/cnc-club/linuxcnc-features
>
> So... LiveCAM is a perfect name.

Thanks for the pointer.  I completely missed that one.  When I heard it 
mentioned before I thought it was a collection of proposed new features, 
not an integrated CAM.  I will look into this when life slows down a 
little.

Has anyone made videos to showcase it running?

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[TJoseph Powderly]

better yet google "Nick Drobchenko"
he's the wiz

tomp

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[andy pugh]

On 14 September 2015 at 22:11, EBo  wrote:
> Has anyone made videos to showcase it running?

https://www.youtube.com/watch?v=I6ZxQrjfAE0

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[Gene Heskett]

On Monday 14 September 2015 17:11:10 EBo wrote:

> On Sep 14 2015 1:37 PM, Andrew wrote:
> > 2015-09-14 21:13 GMT+03:00 Peter C. Wallace :
> >> On Mon, 14 Sep 2015, Sebastian Kuzminsky wrote:
> >> > However, I don't like the name "LinuxCNC Features" for the name
> >> > of
> >>
> >> a
> >>
> >> > conversational front-end.  To me that sounds like an enumeration
> >>
> >> of the
> >>
> >> > things LinuxCNC can do.
> >>
> >> LiveCAM?
> >
> > It's described as "LinuxCNC Features v2 - native realtime CAM for
> > LinuxCNC"
> > here https://github.com/cnc-club/linuxcnc-features
> >
> > So... LiveCAM is a perfect name.
>
> Thanks for the pointer.  I completely missed that one.  When I heard
> it mentioned before I thought it was a collection of proposed new
> features, not an integrated CAM.  I will look into this when life
> slows down a little.
>
> Has anyone made videos to showcase it running?

First, you have to make it run with LCNC.  I just followed the install 
instructions on the above link, and had to remove all the edits to all the 
files it calls for, before I could even get LCNC to run again.  I believe there 
is a clash between its use of gladevcp, and the fact that I have a 3rd tab in 
the preview window containing a spindle tachometer.  So that basket of gladevcp 
based rattlesnakes has yet to be sorted.

On another piece of potentially usefull goodies, I drug out a 2 yo+ Logitech 
C920 webcam, a super duper highdef model, and plugged it in.

Installed cheese just to see if it still worked.  Fresh install of cheese is 
busted, throwing up a screenfull of duplicate definitions in one class error.

So, I install all the v4l2 stuffs I can find, and run v4l2ucp. It recognizes 
the camera, but its apparently read-only and v4l2ucp, if you click on an 
option, it goes into a popup forever saying it cannot communicate with the 
camera.  But it just did query it for its features and the default values for 
those features.

So, putting 1 = 1 together and coming up with 3 or more, the thought comes to 
mind that udev has made it root only to write to it.

But I am not comfortable wading around in a udev file with an editor unless I 
know precisely what I should do.

Am I playing on the correct field here, and if so, how to fix it so a normal 
user can access it and configure it and use it.

I was going to put it on the toy mill with camview a couple years ago, but this 
one is simply physically too big for the toy mill, but could be glued or 
screwed to the side of the head on this GO704 and would not be any more in the 
way than the triple handles I have removed from the manual quill drive.

What udev file do I check, and adjust if this lack of user perms is the problem?

Thanks all.
 
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[EBo]

it is not really a collection of CAM software is it?  What exactly do 
all the features do, or intended to do?

On Sep 14 2015 12:13 PM, Peter C. Wallace wrote:
> On Mon, 14 Sep 2015, Sebastian Kuzminsky wrote:
>
>> However, I don't like the name "LinuxCNC Features" for the name of a
>> conversational front-end.  To me that sounds like an enumeration of 
>> the
>> things LinuxCNC can do.
>>
>
>
> LiveCAM?
>
>
>>
>> --
>> Sebastian Kuzminsky
>>
>> 
>> --
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
> 
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[Peter C. Wallace]

On Mon, 14 Sep 2015, Sebastian Kuzminsky wrote:

> However, I don't like the name "LinuxCNC Features" for the name of a
> conversational front-end.  To me that sounds like an enumeration of the
> things LinuxCNC can do.
>


LiveCAM?


>
> -- 
> Sebastian Kuzminsky
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[W. Martinjak]

Just a suggestion:

Just fancy, linuxcnc is the distribution and "linuxcnc-feature" is a 
package of this distribution.
So they have to take care delivering a working package.

Would this be a approach?

g m


On 2015-09-14 19:43, Sebastian Kuzminsky wrote:
> On 9/14/15 10:54 AM, Jeff Epler wrote:
>> If the goal is to have better online collaboration for this
>> linuxcnc-related project, I think at least some conderation should be
>> given to using github rather than hosting on git.linuxcnc.org.
> Managing this and other LinuxCNC add-ons as separate projects makes 
> partial sense.
>
> On the plus side, it frees them from our somewhat plodding release schedule.
>
> On the minus side, it forces them to duplicate our 
> build/test/release/distribution infrastructure, and forces us (their 
> project and our project) to invent a new mechanism for collaborating 
> (for example, getting their packages onto our repos & ISOs).
>
>

-- 
"In der Wissenschaft siegt nie eine neue Theorie,
nur ihre Gegner sterben nach und nach"

Max Planck


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[Viesturs Lācis]

2015-09-14 21:32 GMT+03:00 EBo :
> it is not really a collection of CAM software is it?  What exactly do
> all the features do, or intended to do?

As the author describes it in russian forum, it is similar to ngcgui -
it allows to create subroutines and macros for mills and lathes.

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[andy pugh]

On 14 September 2015 at 20:11, Viesturs Lācis  wrote:

> As the author describes it in russian forum, it is similar to ngcgui -
> it allows to create subroutines and macros for mills and lathes.

But more than that, there is already quite a range of existing subroutines.

Also, given the enthusiasm that Pathpilot has been received with, the
fact that it looks quite pretty shouldn't be discounted.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] "LinuxCNC Features"

[Andrew]

2015-09-14 21:13 GMT+03:00 Peter C. Wallace :

> On Mon, 14 Sep 2015, Sebastian Kuzminsky wrote:
>
> > However, I don't like the name "LinuxCNC Features" for the name of a
> > conversational front-end.  To me that sounds like an enumeration of the
> > things LinuxCNC can do.
> >
>
>
> LiveCAM?
>
>
It's described as "LinuxCNC Features v2 - native realtime CAM for LinuxCNC"
here https://github.com/cnc-club/linuxcnc-features

So... LiveCAM is a perfect name.


-- 
Andrew
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers