Axis File Open

[John Thornton]

Is there a way to change the file open dialog in Axis to "see" .ngc
files without regard to case?

My post processor outputs all file names in all caps... :-(

How do you single step through your code? All I've been able
to do so far is to start then hit pause. Then hit step... This seems
clunky to me so I must be missing something...

I'm really starting to like the Axis interface...

Thanks
John

[Jeff Epler]

Post by John Thornton
Is there a way to change the file open dialog in Axis to "see" .ngc
files without regard to case?

In the inifile section [FILTER], add a line that reads
PROGRAM_EXTENSION = .[nN][gG][cC] rs274ngc gcode file
you can add any other extensions you like in this area.

[John Thornton]

Thanks Jeff

I did not find a section [FILTER] so I added to my stepper_inch.ini
file and it worked. I did find a reference in the user manual to [FILTER]

Now it shows the following filters:

All machinable files (*.[nN][gG][cC],*ngc)
rs274ngc files (*.ngc)
rs274ngc (*.[nN][gG][cC])
All files (*)

Where do the other filters come from?

Thanks
John

Date: Sun, 19 Aug 2007 14:46:09 -0500
Subject: Re: [Emc-users] Axis File Open
To: "Enhanced Machine Controller (EMC)"
Content-Type: text/plain; charset=us-ascii

Post by John Thornton
Is there a way to change the file open dialog in Axis to "see" .ngc
files without regard to case?

In the inifile section [FILTER], add a line that reads
PROGRAM_EXTENSION = .[nN][gG][cC] rs274ngc gcode file
you can add any other extensions you like in this area.

[Jeff Epler]

In one of the other sample configurations (sim/axis), the [FILTER]
section looks like this:
[FILTER]
PROGRAM_EXTENSION = .png,.gif,.jpg Grayscale Depth Image
PROGRAM_EXTENSION = .py Python Script

png = image-to-gcode
gif = image-to-gcode
jpg = image-to-gcode
py = python

When you select a .png, .gif, or .jpg file it's sent to "image-to-gcode"
http://linuxcnc.org/docs/2.1/html/gui/image-to-gcode/index.html
and the gcode produced by image-to-gcode is then loaded into emc.

When you load a .py file it is executed, and the lines it prints are
treated as gcode.

Jeff

[Ron Ginger]

In emc, there are lots of ways to interact with the running system
besides using gcode.
.................
The problem is not that emc is not customizable and extensible in a wide
variety of ways -- the problem is a lack of documentation and examples
that are accessible to the typical user.
Jeff

Thanks for the info. I stopped at Borders yesterday and bought a Python
book, and I have saved your message. I'm going to dig around in this for
a while, it would be a very interesting project.

ron ginger

[Ron Ginger]

I am not for a second suggesting Interactive machining should replace
conventional CAD-CAM, Gcode generation. As Stuart describes there are
large complex machines for which Gcode is the appropriate tool, and EMC
works very well.

However, I see application for the much simpler Interactive work. My
example would be a 3 axis mill, om which I want to do a simple set of
tasks like face off some stock, drill a bolt circle, then maybe mill a
couple circular pockets around it. Yes, one could go to the CAD system,
draw it all, then process it to Gcode, then load and run that.

But with a simple Interactive screen I can simply fill in a couple
fields, like length and width and depth of cut, then press a 'DoIt'
button and the machine does the job. Using the wizards in Mach I have
often demonstrated such a sequence in a matter of a minute or two-
faster that I can walk from my shop to my CAD computer and back again.

The Gcode with parameters and subroutine that lead into this thread is
an example of trying to make a universal gcode program for some
repetitive task. But editing that parameter list and getting it to run
correctly would be much slower that a screen that let you simply enter
the appropriate parameters, in a nice graphical view that looked like
the part, then just run it.

Interactive machining is NOT to replace Gcode, its for a different class
of work, and there are a lot of shops that could use it very
productively. Jon, Ray, some others may recall Ive been beating this
drum for years, starting back at NAMES several years ago with my Win 3.1
VB code to mimic the Acurite control.

ron ginger

[Ray Henry]

Yea he has!

Post by Ron Ginger
Jon, Ray, some others may recall Ive been beating this
drum for years, starting back at NAMES several years ago with my Win 3.1
VB code to mimic the Acurite control.

One of the things that often happens in these parts is that some folk
are much more comfortable with software programming with it's loops and
jumps and fancy maths and find g-code to be awkward. I don't have a
problem with that and supported the O word as an extension to the
interpreter even though there was no precedent/equivalent in the world
of g-code.

Someone mentioned that "conversational" front ends tend to produce
g-code programs to run. This is not true of Mazatrol. There are
abilities in Mazatrol that are not available in g-code. This leads me
to think that Mazak uses two different interpreters. I don't see this
as at all bad. We also have two interpreters.

What I do find disturbing is the attempt to bypass the interpreter
entirely. My thoughts here will be old hat to many readers. I'm really
bothered by some scripting language telling to machine to go to x3000m
without testing that command to the limits of the device as recorded in
a configuration file somewhere. At the same time there is no regular
error feedback to tell the operator to f*6k off.

When we get around to writing this "graphical" interpreter and making it
a part of the code we release, let's make certain it conforms to the
same sort of error checking our existing interpreters use -- or better
yet just make it use canterp.

Ray

[Andre' Blanchard]

Post by Ray Henry
One of the things that often happens in these parts is that some folk
are much more comfortable with software programming with it's loops and
jumps and fancy maths and find g-code to be awkward. I don't have a
problem with that and supported the O word as an extension to the
interpreter even though there was no precedent/equivalent in the world
of g-code.

But there is precedent and equivalent in the world of g-code, it's called
MACRO-B and is and option available on most any control.
And it makes possible things EMC has not even come close to yet.

http://www.gefanuc.com/literature/pdf/gft-321.pdf

__________
Andre' B. Clear Lake, Wi.

[Alex Joni]

I beg to differ.

[Andre' Blanchard]

Post by Alex Joni
I beg to differ.

[John Prentice]

Greetings

<head_above_parapet>

Post by Alex Joni
I beg to differ.

<snip>

The work offset numbers are available in EMC but, how to access the tool
table values in EMC?
These move around a lot on different machines but are usually around
#2000 or #10000 depends on if you have type I or type II offsets.

<snip>

Machine position information.
Preceding block endpoint, #5001,#5002, etc..
Current machine coordinate, #5021,#5022, etc..
Work coordinate, #5021,#5022, etc..

<snip>

And while EMC can do some of this the syntax is often very different
making
running a program written for a Fanuc on an EMC machine a challenge. Also
gives part programmers one more reason not to like EMC based machines,
which makes them less likely to get purchased in the first place.

If one could make a control that would run code unaltered from "a Fanuc"
then it might be useful. I suspect the truth is the best that is possible is
to run code for a "Fanuc xxE Rev d.q Option 3" and that is hard and has
little general applicability.

As soon as one conteplates modifying legacy programs full of # parameters
one is doomed. Is anyone left of this list who literaly programmed a "real"
program in binary/octal/hex machine code without the benefit of a symbolic
assembler? The nearest I came was keying the standard PDP8 boot loader.

I submit one should not contemplate extension of the # parameter mechanism.

So what is needed? Probably many things are useful but I suggest two that
are different in kind.

(a) Interactive CAM. The distinguishing feature is that the result of using
such a system is a "G-code" program or program fragment. There are plenty of
exemplars both in commercial machines and PC controllers. In essence one
defines the desired cut(s) by choosing from standard operations like
pockets, facing, PCD circles, standard panel apertures etc. and/or teaching
by recording jogs. Such a system have very little interaction with the
control beyond being easy to initiate, have a neat way of loading the
generated code and perhaps picking up DROs for teaching.
The author of this type of program needs access to tools to implement a GUI
for his/her users and the ability to write to a part program "file".

(b) Interactive machining. Here the distinguishing feature is that the
thread of code run by the user actually controls the machine. This allows
two things. Firstly the control flow of the user program depends not only on
user input but on the machine state (e.g. the tripping of a probe, the input
power to the spindle). Secondly it can take place whilst a "G-code" program
is loaded - so is useful for tasks like semi-automatic stock preparation.
The author of an Interactive program needs access to tools to present the
GUI at the user side, the ability to issue commands to the machine (say in
the form of G-code strings) and to read the current state of hardware and
software (offset systems, modes, speeds etc). This is a tougher call.

<head_even_higher>

These interfaces feel to me to be much like interactive web page designs.
Flash (and its support tools) seems to be a strong contender (very powerful
graphics - static and dynamic, a form of object orientated programming,
surprisingly efficient) although the Linux world seems currently rather
deprived on implementation.

</head_even_higher></head_above...>

John Prentice

[Stephen Wille Padnos]

Excellent post, John.

Post by John Prentice
Greetings
<head_above_parapet>

Post by Alex Joni
I beg to differ.

<snip>

The work offset numbers are available in EMC but, how to access the tool
table values in EMC?
These move around a lot on different machines but are usually around
#2000 or #10000 depends on if you have type I or type II offsets.

<snip>

Machine position information.
Preceding block endpoint, #5001,#5002, etc..
Current machine coordinate, #5021,#5022, etc..
Work coordinate, #5021,#5022, etc..

<snip>

And while EMC can do some of this the syntax is often very different
making
running a program written for a Fanuc on an EMC machine a challenge. Also
gives part programmers one more reason not to like EMC based machines,
which makes them less likely to get purchased in the first place.

If one could make a control that would run code unaltered from "a Fanuc"
then it might be useful. I suspect the truth is the best that is possible is
to run code for a "Fanuc xxE Rev d.q Option 3" and that is hard and has
little general applicability.

Additionally, it's impossible to make something that's compatible with
*both* Fanuc *and* Haas, for example. So although users of a specific
machine we might emulate will be happy, the users of the other 200
models/brands won't.

Post by John Prentice
As soon as one conteplates modifying legacy programs full of # parameters
one is doomed. Is anyone left of this list who literaly programmed a "real"
program in binary/octal/hex machine code without the benefit of a symbolic
assembler? The nearest I came was keying the standard PDP8 boot loader.
I submit one should not contemplate extension of the # parameter mechanism.

I agree wholeheartedly. Unfortunately, it's often easier to make small
changes to what's there than it is to design something new.

Post by John Prentice
So what is needed? Probably many things are useful but I suggest two that
are different in kind.
(a) Interactive CAM. The distinguishing feature is that the result of using
such a system is a "G-code" program or program fragment. There are plenty of
exemplars both in commercial machines and PC controllers. In essence one
defines the desired cut(s) by choosing from standard operations like
pockets, facing, PCD circles, standard panel apertures etc. and/or teaching
by recording jogs. Such a system have very little interaction with the
control beyond being easy to initiate, have a neat way of loading the
generated code and perhaps picking up DROs for teaching.
The author of this type of program needs access to tools to implement a GUI
for his/her users and the ability to write to a part program "file".
(b) Interactive machining. Here the distinguishing feature is that the
thread of code run by the user actually controls the machine. This allows
two things. Firstly the control flow of the user program depends not only on
user input but on the machine state (e.g. the tripping of a probe, the input
power to the spindle). Secondly it can take place whilst a "G-code" program
is loaded - so is useful for tasks like semi-automatic stock preparation.
The author of an Interactive program needs access to tools to present the
GUI at the user side, the ability to issue commands to the machine (say in
the form of G-code strings) and to read the current state of hardware and
software (offset systems, modes, speeds etc). This is a tougher call.

There's a (c) as well: non-machining applications. EMC2 has at its
core a very nice motion controller, and an excellent I/O interface
layer. There are a number of ways of using motion and I/O that aren't
related to machining: robotics, packaging, cell-to-cell part moving,
etc. There are a number of generic motion controllers out there, some
even have pluggable kinematics like EMC (so you can use a serial robot
but specify waypoints in cartesian coordinates instead of joint
positions). Most start at the $2000 range, and don't have a lot of
I/O. They're programmed in various ways, but there's usually some
scripting language (see Yaskawa's SMC4040 for an example of a script
language I don't much like :) ) I can see EMC2 with a similar scripting
language as a front end instead of the G-code interpreter. Ideally, I'd
like to be able to have the motion controller capable of servicing
multiple clients simultaneously, but that's a very radical design
change. Note: I mean multiple clients, like a G-code interpreter that
outputs commands for 4 axes, plus a robot controller that outputs
commands for a separate two or 3 axes, each being able to do its thing
without the other necessarily knowing about it. This is distinct from
several user interfaces all controlling the same "motion client": the
G-code interpreter and its associated stack of protocols and processes.

Post by John Prentice
<head_even_higher>
These interfaces feel to me to be much like interactive web page designs.
Flash (and its support tools) seems to be a strong contender (very powerful
graphics - static and dynamic, a form of object orientated programming,
surprisingly efficient) although the Linux world seems currently rather
deprived on implementation.
</head_even_higher></head_above...>

<head out of a$$>

I'd say that flash, although it's more or less fine for media, has no
place in the requirements list for EMC2 :) There are any number of fine
programming languages and environments to use for the UI. I'm not sure
what you'd use to make a flash presentation on Linux anyway, and I
wouldn't want to be beholden to Adobe to make updated versions for my OS
(which they don't - I use a 64-bit version of Linux, and they don't seem
to like supporting 64-bit OSes on anything but PowerPC macs AFAICS). On
a technical level, I'm not sure what facilities Flash has for actually
doing things that aren't "media" or web-related anyway.

</head back in a ... oh, wait a minute>

Post by John Prentice
John Prentice

- Steve

[John Prentice]

Greetings Steve et al

Congrats. on election result (to you and others of course)

Post by Stephen Wille Padnos
I'd say that flash, although it's more or less fine for media, has no
place in the requirements list for EMC2 :) There are any number of fine
programming languages and environments to use for the UI. I'm not sure
what you'd use to make a flash presentation on Linux anyway, and I
wouldn't want to be beholden to Adobe to make updated versions for my OS
(which they don't - I use a 64-bit version of Linux, and they don't seem
to like supporting 64-bit OSes on anything but PowerPC macs AFAICS).

No, I accept the current problem in a Linux environment but things do change
surprisingly quickly sometimes. Flash player penetration is very high in the
"parallel universe". Reliance on Adobe or any one vendor is unhappy but
Sothink and SWiSHMax both offer very capable development environments.

Post by Stephen Wille Padnos
On
a technical level, I'm not sure what facilities Flash has for actually
doing things that aren't "media" or web-related anyway.

It is not the time/place to be dogmatic as I cannot show a demonstration,
but there *are* two aspects I think Flash offers (a) A framework for design
of very interactive graphic interfaces (e.g. the label for an Axis DRO that
opens up to show scaling, offsets applied etc. when it is clicked)
integrated with (b) A powerful and well structured script programming
language.

The difficulty in applying Flash is that the documentation/tutorial material
is highly orientated to the web design aspects and the terminology is thus
"foreign". The ability to instantiate graphics objects, which can be
"movies", as buttons, text, DROs, etc. with overideable inherited
properties is, however, a very powerful tool.

On a more general point, we have come to accept heirarchical dialog systems
as the norm. So many application program dialogs are "modal" and we while
away our lives clicking OK/Done etc. When I started using Solidworks and
Pro/ENGINEER I was blown away by the benefits of the implied OK in
Solidworks. As an example, you place a dimension and a panel comes up for
entering its properties. This panel has an OK and a Cancel button but if you
just click on the sketch then OK is assumed and you can place another
dimension. This works wherever there is a reasonable assumption. Where the
implication is "risky" you need a positive confirmation of OK. Pro/E on the
other had pendantically wants confirmation at every step (and in Wildfire 2
at least different modules ask for it in different ways and on different
parts of the screen).

The available computing power seems to offer scope for increased safety and
ease of use in HMIs provided the development tools are available.
</mini-rant>

John Prentice

[Dale]

John,

Post by John Prentice
Greetings Steve et al
Congrats. on election result (to you and others of course)

Post by Stephen Wille Padnos
I'd say that flash, although it's more or less fine for media, has no
place in the requirements list for EMC2 :) There are any number of fine
programming languages and environments to use for the UI. I'm not sure
what you'd use to make a flash presentation on Linux anyway, and I
wouldn't want to be beholden to Adobe to make updated versions for my OS
(which they don't - I use a 64-bit version of Linux, and they don't seem
to like supporting 64-bit OSes on anything but PowerPC macs AFAICS).

No, I accept the current problem in a Linux environment but things do change
surprisingly quickly sometimes. Flash player penetration is very high in the
"parallel universe". Reliance on Adobe or any one vendor is unhappy but
Sothink and SWiSHMax both offer very capable development environments.

I don't even have Flash installed and see no need for it to control a
machine.

Post by John Prentice

Post by Stephen Wille Padnos
On
a technical level, I'm not sure what facilities Flash has for actually
doing things that aren't "media" or web-related anyway.

It is not the time/place to be dogmatic as I cannot show a demonstration,
but there *are* two aspects I think Flash offers (a) A framework for design
of very interactive graphic interfaces (e.g. the label for an Axis DRO that
opens up to show scaling, offsets applied etc. when it is clicked)
integrated with (b) A powerful and well structured script programming
language.
The difficulty in applying Flash is that the documentation/tutorial material
is highly orientated to the web design aspects and the terminology is thus
"foreign". The ability to instantiate graphics objects, which can be
"movies", as buttons, text, DROs, etc. with overideable inherited
properties is, however, a very powerful tool.
On a more general point, we have come to accept heirarchical dialog systems
as the norm. So many application program dialogs are "modal" and we while
away our lives clicking OK/Done etc. When I started using Solidworks and
Pro/ENGINEER I was blown away by the benefits of the implied OK in
Solidworks. As an example, you place a dimension and a panel comes up for
entering its properties. This panel has an OK and a Cancel button but if you
just click on the sketch then OK is assumed and you can place another
dimension. This works wherever there is a reasonable assumption. Where the
implication is "risky" you need a positive confirmation of OK. Pro/E on the
other had pendantically wants confirmation at every step (and in Wildfire 2
at least different modules ask for it in different ways and on different
parts of the screen).

I would get very upset if I had to keep confirming what I just told the
application what I wanted, I think once is enough. To place a dimension
should be pick the feature and pick whhere to place the dimensiion for
that feature. No confirmation is needed, if it doesn't get applied the
way I wanted it there's always a way to undo it and try again.

Post by John Prentice
The available computing power seems to offer scope for increased safety and
ease of use in HMIs provided the development tools are available.
</mini-rant>
John Prentice

Saftey? I do not need or want any protection from myself, I command the
computer and i expect it to do as I request without continually being
asked if it is OK!

KISS,
Dale

Post by John Prentice
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Dale]

Ray,

Fanuc used the O word to be the program name or filename and one could
be called and used by another. I could possibly find an example of the
advanced capabilities of the Fanuc I used to run if you wish.

Dale

Post by Ray Henry
Yea he has!

Post by Ron Ginger
Jon, Ray, some others may recall Ive been beating this
drum for years, starting back at NAMES several years ago with my Win 3.1
VB code to mimic the Acurite control.

One of the things that often happens in these parts is that some folk
are much more comfortable with software programming with it's loops and
jumps and fancy maths and find g-code to be awkward. I don't have a
problem with that and supported the O word as an extension to the
interpreter even though there was no precedent/equivalent in the world
of g-code.
Someone mentioned that "conversational" front ends tend to produce
g-code programs to run. This is not true of Mazatrol. There are
abilities in Mazatrol that are not available in g-code. This leads me
to think that Mazak uses two different interpreters. I don't see this
as at all bad. We also have two interpreters.
What I do find disturbing is the attempt to bypass the interpreter
entirely. My thoughts here will be old hat to many readers. I'm really
bothered by some scripting language telling to machine to go to x3000m
without testing that command to the limits of the device as recorded in
a configuration file somewhere. At the same time there is no regular
error feedback to tell the operator to f*6k off.
When we get around to writing this "graphical" interpreter and making it
a part of the code we release, let's make certain it conforms to the
same sort of error checking our existing interpreters use -- or better
yet just make it use canterp.
Ray
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Dale]

Ray,

Fanuc used the O word to be the program name or filename and one could
be called and used by another. I could possibly find an example of the
advanced (advanced as per about 10~15 years ago) capabilities of the
Fanuc I used to run if you wish. The versions of the controls on two of
the machines were an 11m or something like that on a horizontal
machining center and a Secos II (same as a Fanuc) on a vertical mill.
both were Hitachi Seiki. Both worked very well.

Dale

Post by Ray Henry
Yea he has!

Post by Ron Ginger
Jon, Ray, some others may recall Ive been beating this
drum for years, starting back at NAMES several years ago with my Win 3.1
VB code to mimic the Acurite control.

One of the things that often happens in these parts is that some folk
are much more comfortable with software programming with it's loops and
jumps and fancy maths and find g-code to be awkward. I don't have a
problem with that and supported the O word as an extension to the
interpreter even though there was no precedent/equivalent in the world
of g-code.
Someone mentioned that "conversational" front ends tend to produce
g-code programs to run. This is not true of Mazatrol. There are
abilities in Mazatrol that are not available in g-code. This leads me
to think that Mazak uses two different interpreters. I don't see this
as at all bad. We also have two interpreters.
What I do find disturbing is the attempt to bypass the interpreter
entirely. My thoughts here will be old hat to many readers. I'm really
bothered by some scripting language telling to machine to go to x3000m
without testing that command to the limits of the device as recorded in
a configuration file somewhere. At the same time there is no regular
error feedback to tell the operator to f*6k off.
When we get around to writing this "graphical" interpreter and making it
a part of the code we release, let's make certain it conforms to the
same sort of error checking our existing interpreters use -- or better
yet just make it use canterp.
Ray
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Hugh Currin]

Ron:

I didn't fully understand the intent. You're aiming for tools to do relatively
simple tasks while at the machine. This would be handy during "manual"
machining, i.e. additional functionality along with jog and MDI.

What you would like is a simple menu driven CAM package. In this you select,
for example, make countersink. The package brings up a menu asking, 1) center
(default current x-y), 2) diameter, 3) depth, 4) tool diameter. A "more" menu
might set parameters normally defaulted, feed, speed, tool offset, finish
cut, etc. A GUI might show the tool path. The CAM package then generates
G-code for this countersink. The G-code is loaded into EMC for execution. The
scripting language would be the basis of extending the CAM package, what new
menu items are written in. Would this work? Is it more in line with what you
were thinking?

For functionality this CAM package could be linked tightly with EMC. The CAM
package could draw on EMC defaults and automatically load generated G-code
into EMC.

I'd still suggest thinking of this as a separate CAM package that generates
G-code. It is very handy to see what the machine will do next and single
step "unproven" code. This requires viewing a known language as it's run. I,
along with Dale, don't want to learn a new G-code like language, Learning
G-code is a skill I can apply at any CNC, a new language would be specific to
EMC. I have enough trouble reading G-code without reference material at hand
(bad memory).

Such a CAM package may be useful in general, to other controllers, if not too
tightly linked to EMC. This would require a post-processor scheme though.

My thinking is in line with what Mike described. However, if made part of the
EMC project and rules developed for how to program each "feature module" more
people could contribute additional "features".

Thanks.

Post by Ron Ginger
I am not for a second suggesting Interactive machining should replace
conventional CAD-CAM, Gcode generation. As Stuart describes there are
large complex machines for which Gcode is the appropriate tool, and EMC
works very well.
However, I see application for the much simpler Interactive work. My
example would be a 3 axis mill, om which I want to do a simple set of
tasks like face off some stock, drill a bolt circle, then maybe mill a
couple circular pockets around it. Yes, one could go to the CAD system,
draw it all, then process it to Gcode, then load and run that.
What I have been playing with is using Gambas (a VB like language for
linux) http://gambas.sourceforge.net/ to generate a .nc file.

[Dale]

What you're talking about here, I can do with a combination of manual
and mdi. Using gcode when appropriate and manual positioning (jog). It
is just as easy to manually operate a cnc as it is to operate a
bridgeport with DRO. Actually can be easier? no languages required. as
for bolt circles and arcs etc. a calculator is all that's needed and
input via mdi. I did just that for years.

A few simple cuts on one part that I'll most likely will never see
again doesn't warrent the time it takes to draw it or use any cam to
generate a program or even write program manually. Think of it as a
manual machine with fly-by-wire. In manual, jog down z to touch off the
top surface with a face mill the jog clear, and in incremental jog down
the depth of cut. Go back to continious jog and turn the speed override
down to an appropriat speed and jog the cutter across the piece till it
clears. cut is made, done, no programming required. If that's all that
was required then you didn't even have to indicate and align the part
just eyeballed and clamped down. Wouldn't even need to pickup x and y
zero in a case like that. Why on earth would you want to make it more
complicated than it needs to be?

Dale

Post by Ron Ginger
I am not for a second suggesting Interactive machining should replace
conventional CAD-CAM, Gcode generation. As Stuart describes there are
large complex machines for which Gcode is the appropriate tool, and EMC
works very well.
However, I see application for the much simpler Interactive work. My
example would be a 3 axis mill, om which I want to do a simple set of
tasks like face off some stock, drill a bolt circle, then maybe mill a
couple circular pockets around it. Yes, one could go to the CAD system,
draw it all, then process it to Gcode, then load and run that.
But with a simple Interactive screen I can simply fill in a couple
fields, like length and width and depth of cut, then press a 'DoIt'
button and the machine does the job. Using the wizards in Mach I have
often demonstrated such a sequence in a matter of a minute or two-
faster that I can walk from my shop to my CAD computer and back again.
The Gcode with parameters and subroutine that lead into this thread is
an example of trying to make a universal gcode program for some
repetitive task. But editing that parameter list and getting it to run
correctly would be much slower that a screen that let you simply enter
the appropriate parameters, in a nice graphical view that looked like
the part, then just run it.
Interactive machining is NOT to replace Gcode, its for a different class
of work, and there are a lot of shops that could use it very
productively. Jon, Ray, some others may recall Ive been beating this
drum for years, starting back at NAMES several years ago with my Win 3.1
VB code to mimic the Acurite control.
ron ginger
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Kenneth Lerman]

Do you mean something like:

http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?G-Wiz

The idea of this is that a GUI would let you generate calls to predefined
gcode subroutines.

Ken

***@se-ltd.com
Mark Kenny Products Company, LLC
55 Main Street Voice: (888)ISO-SEVO [phone]
Newtown, CT 06470 Fax: [phone]
http://www.MarkKenny.com


-----Original Message-----
From: emc-users-***@lists.sourceforge.net
[mailto:emc-users-***@lists.sourceforge.net]On Behalf Of Ron Ginger
Sent: Monday, August 20, 2007 9:37 AM
To: emc-***@lists.sourceforge.net
Subject: Re: [Emc-users] Interactive machining


I am not for a second suggesting Interactive machining should replace
conventional CAD-CAM, Gcode generation. As Stuart describes there are
large complex machines for which Gcode is the appropriate tool, and EMC
works very well.

However, I see application for the much simpler Interactive work. My
example would be a 3 axis mill, om which I want to do a simple set of
tasks like face off some stock, drill a bolt circle, then maybe mill a
couple circular pockets around it. Yes, one could go to the CAD system,
draw it all, then process it to Gcode, then load and run that.

But with a simple Interactive screen I can simply fill in a couple
fields, like length and width and depth of cut, then press a 'DoIt'
button and the machine does the job. Using the wizards in Mach I have
often demonstrated such a sequence in a matter of a minute or two-
faster that I can walk from my shop to my CAD computer and back again.

The Gcode with parameters and subroutine that lead into this thread is
an example of trying to make a universal gcode program for some
repetitive task. But editing that parameter list and getting it to run
correctly would be much slower that a screen that let you simply enter
the appropriate parameters, in a nice graphical view that looked like
the part, then just run it.

Interactive machining is NOT to replace Gcode, its for a different class
of work, and there are a lot of shops that could use it very
productively. Jon, Ray, some others may recall Ive been beating this
drum for years, starting back at NAMES several years ago with my Win 3.1
VB code to mimic the Acurite control.

ron ginger

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[Ron Ginger]

Post by Ray Henry
What I do find disturbing is the attempt to bypass the interpreter
entirely. My thoughts here will be old hat to many readers. I'm really
bothered by some scripting language telling to machine to go to x3000m
without testing that command to the limits of the device as recorded in
a configuration file somewhere. At the same time there is no regular
error feedback to tell the operator to f*6k off.

For my use I don't see bypassing the interpreter. I would be happy to
issue simple G code commands from the Script language. I don't mean to
keep pushing the Mach model, but all VB can do from Mach is issue g code
commands to the interpreter. With that dozens of 'wizard' screens have
been written to do a wide range of tasks, from simple facing, to text
engraving, pocketing, and hole arrays.

I'm going off to read my new Python book, and follow some of the
references Jeff offered. Maybe someday I will have an example of what
I'm talking about.

ron ginger

[Mike Cinquino]

Ron,

What I have been playing with is using Gambas (a VB like language for
linux) http://gambas.sourceforge.net/ to generate a .nc file. My
Gamabs code creates a "Conversational" application that can run right
with EMC running. I can then append or over write the .nc file depending
on what I want to do. When I have a completed .nc file I simply browse
for the file. This file could be the default file that gets loaded when
EMC starts. If I make changes to the file I can just refresh it from
AXIS. This method eliminates the need for direct hooks into EMC.

Gambas is much easier to create GUI's for me than Python because I have
a VB background. I only have a couple crude pocket routines written at
this point. I will share that code with anyone that is interested in
it.

Mike

Post by Ron Ginger

Post by Ray Henry
What I do find disturbing is the attempt to bypass the interpreter
entirely. My thoughts here will be old hat to many readers. I'm really
bothered by some scripting language telling to machine to go to x3000m
without testing that command to the limits of the device as recorded in
a configuration file somewhere. At the same time there is no regular
error feedback to tell the operator to f*6k off.

For my use I don't see bypassing the interpreter. I would be happy to
issue simple G code commands from the Script language. I don't mean to
keep pushing the Mach model, but all VB can do from Mach is issue g code
commands to the interpreter. With that dozens of 'wizard' screens have
been written to do a wide range of tasks, from simple facing, to text
engraving, pocketing, and hole arrays.
I'm going off to read my new Python book, and follow some of the
references Jeff offered. Maybe someday I will have an example of what
I'm talking about.
ron ginger
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Dale]

Ron,

IMHO I'd say that's the best appraoch. Whatever you choose to display or
whatever language you wish to program with can easily send the proper
commands to EMC. Then EMC can do what it does best, control the machine.

Dale

Post by Ron Ginger

Post by Ray Henry
What I do find disturbing is the attempt to bypass the interpreter
entirely. My thoughts here will be old hat to many readers. I'm really
bothered by some scripting language telling to machine to go to x3000m
without testing that command to the limits of the device as recorded in
a configuration file somewhere. At the same time there is no regular
error feedback to tell the operator to f*6k off.

For my use I don't see bypassing the interpreter. I would be happy to
issue simple G code commands from the Script language. I don't mean to
keep pushing the Mach model, but all VB can do from Mach is issue g code
commands to the interpreter. With that dozens of 'wizard' screens have
been written to do a wide range of tasks, from simple facing, to text
engraving, pocketing, and hole arrays.
I'm going off to read my new Python book, and follow some of the
references Jeff offered. Maybe someday I will have an example of what
I'm talking about.
ron ginger
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Kenneth Lerman]

EMC has most of the functionality shown on the link you provided.

Language Features
YES ? Local Variables for passing parameters and for
intermediate calculations within a macro
YES ? Common Variables shared by all macros
??? ? Permanent Common Variables that keep their
values even when power is turned off
??? ? System Variables to read and write a variety of
CNC data items and generate alarm messages
YES ? Standard operations (add, subtract, multiply and
divide)
YES ? Trig Functions (Sin, Cosine, Tangent and their
inverse)
YES ? Math Functions (SQRT, ABS, ROUND, FIX,
FUP, LN, EXP)
YES ? Logical Bitwise Operators (AND, OR, XOR)
NO ? Conversion Functions (BCD to BIN, BIN to
BCD)
YES (IF-THEN) ? Branching (IF-THEN and GOTO)
NO (GOTO)
YES ? Conditional Operators (equals, not equals, less
than, less than or equal to, greater than, greater
than or equal to)
YES ? Loops (WHILE-DO-END)
Planned ? Variety of calling formats with parameters
including defining custom G-codes and M-codes
To a log or error message ? Printing of values to a serial port

Ken

***@se-ltd.com
Mark Kenny Products Company, LLC
55 Main Street Voice: (888)ISO-SEVO [phone]
Newtown, CT 06470 Fax: [phone]
http://www.MarkKenny.com


-----Original Message-----
From: emc-users-***@lists.sourceforge.net
[mailto:emc-users-***@lists.sourceforge.net]On Behalf Of Andre'
Blanchard
Sent: Monday, August 20, 2007 11:20 AM
To: ***@up.net; Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Interactive machining

Post by Ray Henry
One of the things that often happens in these parts is that some folk
are much more comfortable with software programming with it's loops and
jumps and fancy maths and find g-code to be awkward. I don't have a
problem with that and supported the O word as an extension to the
interpreter even though there was no precedent/equivalent in the world
of g-code.

But there is precedent and equivalent in the world of g-code, it's called
MACRO-B and is and option available on most any control.
And it makes possible things EMC has not even come close to yet.

http://www.gefanuc.com/literature/pdf/gft-321.pdf

__________
Andre' B. Clear Lake, Wi.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[Alex Joni]

Post by Kenneth Lerman
??? ? Permanent Common Variables that keep their
values even when power is turned off

Actually emc2 does have that, as a somehow hidden feature.
If you put a parameter in your .var file, the interpreter will save the last
value on shutdown, and reload it the next time emc2 runs.
All the user has to do, is add the parameter he wants to the end of the var
file.

Regards,
Alex

[Ray Henry]

Hi Ken

I've not tried this with your modified interpreter but with the old one,
you could save a variable from run to run if you manually add it's
numeric name and value to the .var file. That done, it will take
whatever value it's holds at the end of a run.

Rayh

Post by Kenneth Lerman
??? ? Permanent Common Variables that keep their
values even when power is turned off

[Manfredi Leto]

Post by Ron Ginger
However, I see application for the much simpler Interactive work. My
example would be a 3 axis mill, om which I want to do a simple set of
tasks like face off some stock, drill a bolt circle, then maybe mill a
couple circular pockets around it. Yes, one could go to the CAD system,
draw it all, then process it to Gcode, then load and run that.

Actually you can do it very well using python and the "filter"feature of
EMC...just write a GUI with tkinter to create what you need (like G-wiz) and
write some code in python to generate the g-code and sent it to the
output...it will be received from EMC2 and you will have your work ready to
be machined.
I've tried it and it's usefu (I've written a small GUI to create NURBS
curves and send them to EMC2 for experimental purpose)l. I'm not very good
at python yet...so my GUI surely sucks...but it does what I need for now, it
will be improved when I've the time to improve my python skills.
A very good example is the script holecircle.py by Jeff Epler, find about it
at the end of this page (Program filters section):

http://www.linuxcnc.org/docs/html/gui/axis/index.html

the script is inlcuded in the official version of EMC2 if I remember well.

Regards,

Manfredi

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

[Ryan Hulsker]

I completed building my 4 axis hotwire foam cutter this weekend and am
trying to get EMC2 to work with it.

I checked out emc2-head yesterday and managed to get it to compile (run
in place) and it seems to run ok with the default "stepper_mm"
configuration. So i decided to use this as a base to configure it for
foam cutting, but I am getting some errors.

Here is what I did.

made a copy of stepper_mm.ini (foam.ini)

changed foam.ini "core_stepper.hal" to "core_foam_stepper.hal"
changed foam.ini "standard_pinout.hal" to "foam_pinout.hal"

copied core_stepper.hal to core_foam_stepper.hal
copied standard_pinout.hal to foam_pinout.hal

in core_foam_stepper.hal
changed loadrt stepgen step_type=0,0,0 to 0,0,0,0

changed all Z references to U
added V axis as axis.3 and stepgen.3 etc

in foam_pinout.hal
changed all references to Z axis to U
added Vstep as pin 9 and Vdir as pin 8
changed spindle out to pin 1

in the Traj section of foam.ini
changed axes to 4

changed COORDINATES to X Y U V

created [AXIS_3] section as a copy of [AXIS_2]

When I run EMC get this error. But I am not sure what to do about it?

HAL: ERROR: pin 'axis.3.motor-pos-cmd' not found
HAL:31: link failed
HAL config file ../configs/stepper/core_foam_stepper.hal failed.

I assume i am supposed to be using a different kin/mot module or
something but I can't figure it out.

Any help would be appreciated.

Ryan

[Ryan Hulsker]

Ok, so i solved that first problem (i had actually forgotten to set
"axes" to 4.

Now I am getting this problem.

Seems Axis may not handle 4 axes? Is there another front end I should
be using?


EMC2 - pre-2.2 CVS HEAD
Machine configuration directory is
'/home/rhulsker/emcsource/emc2-trunk/scripts/../configs/stepper'
Machine configuration file is 'foam.ini'
Starting EMC2...
iocontrol: machine: 'EMC-HAL-STEP-MM' version '1.15'
task: machine: 'EMC-HAL-STEP-MM' version '1.15'
emcTrajSetAxes failing: axes=4 axismask=c3
bad return value from emcTrajSetAxes
emcTrajSetAxes failing: axes=4 axismask=c3
bad return value from emcTrajSetAxes
emcTrajSetAxes failing: axes=4 axismask=c3
bad return value from emcTrajSetAxes
emcTrajSetAxes failing: axes=4 axismask=c3
bad return value from emcTrajSetAxes
emcTrajSetAxes failing: axes=4 axismask=c3
bad return value from emcTrajSetAxes
emcTrajSetAxes failing: axes=4 axismask=c3
bad return value from emcTrajSetAxes
emcTrajSetAxes failing: axes=4 axismask=c3
bad return value from emcTrajSetAxes
emcTrajSetAxes failing: axes=4 axismask=c3
bad return value from emcTrajSetAxes
emcTrajSetAxes failing: axes=4 axismask=c3
bad return value from emcTrajSetAxes
emcTrajSetAxes failing: axes=4 axismask=c3
bad return value from emcTrajSetAxes
emc/task/emctaskmain.cc 2584: can't initialize motion

And then I get the splash screen, but Axis never comes up.

Ryan

Post by Ryan Hulsker
I completed building my 4 axis hotwire foam cutter this weekend and am
trying to get EMC2 to work with it.
I checked out emc2-head yesterday and managed to get it to compile (run
in place) and it seems to run ok with the default "stepper_mm"
configuration. So i decided to use this as a base to configure it for
foam cutting, but I am getting some errors.
Here is what I did.
made a copy of stepper_mm.ini (foam.ini)
changed foam.ini "core_stepper.hal" to "core_foam_stepper.hal"
changed foam.ini "standard_pinout.hal" to "foam_pinout.hal"
copied core_stepper.hal to core_foam_stepper.hal
copied standard_pinout.hal to foam_pinout.hal
in core_foam_stepper.hal
changed loadrt stepgen step_type=0,0,0 to 0,0,0,0
changed all Z references to U
added V axis as axis.3 and stepgen.3 etc
in foam_pinout.hal
changed all references to Z axis to U
added Vstep as pin 9 and Vdir as pin 8
changed spindle out to pin 1
in the Traj section of foam.ini
changed axes to 4
changed COORDINATES to X Y U V
created [AXIS_3] section as a copy of [AXIS_2]
When I run EMC get this error. But I am not sure what to do about it?
HAL: ERROR: pin 'axis.3.motor-pos-cmd' not found
HAL:31: link failed
HAL config file ../configs/stepper/core_foam_stepper.hal failed.
I assume i am supposed to be using a different kin/mot module or
something but I can't figure it out.
Any help would be appreciated.
Ryan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Jeff Epler]

[TRAJ]AXES should probably be set to 8. Here's the explanation from the
documentation:
One more than the number of the highest joint number in the system.
For an XYZ machine, the joints are numbered 0, 1 and 2; in this case
AXES should be 3. For an XYUV machine using ``trivial kinematics'',
the V joint is numbered 8 and therefore AXES should be 9. For a
machine with nontrivial kinematics (e.g., scarakins) this will
generally be the number of controlled joints.
http://linuxcnc.org/docs/devel/html/config/ini_config/index.html#hue432

In the .hal files, the number of "stepgen" should be 4:
loadrt stepgen step_type=0,0,0,0
and the correspondance between axis numbers, axis names, and stepgen
numbers will be:
Axis Name Axis # Stepgen #
X 0 0
Y 1 1
U 6 2
V 7 3

Thanks for jumping in and trying out this new & only sparsely documented
feature. I hope we can help you get it working.

Jeff

[Jeff Epler]

Post by Jeff Epler
[TRAJ]AXES should probably be set to 8. Here's the explanation from the
One more than the number of the highest joint number in the system.
For an XYZ machine, the joints are numbered 0, 1 and 2; in this case
AXES should be 3. For an XYUV machine using ``trivial kinematics'',
the V joint is numbered 8 and therefore AXES should be 9. For a
machine with nontrivial kinematics (e.g., scarakins) this will
generally be the number of controlled joints.
http://linuxcnc.org/docs/devel/html/config/ini_config/index.html#hue432

Just as I was posting this, another developer noticed that the
documentation was incorrect. The corrected text reads:
the V joint is numbered 7 and therefore AXES should be 8.

I think the rest of what I said in my message is correct.

Jeff

[Ryan Hulsker]

Ok, thanks for your help (Chris too), I seem to have it working now.

In the ini file I have
AXES = 8
COORDINATES = X Y U V
HOME = 0 0 0 0

And [AXIS_6] and [AXIS_7] sections instead of the 2 and 3 I had before.

And in my "core_foam_stepper.hal" I changed all refences to
"axis.[23]...." to "axis.[67]...." etc. And of course I updated the
references to the [AXIS_x] parts of the ini file to match the new
settings. and I left all the "stepgen.[23]" references as they where.

Axis now loads up and I can jog XYUV and they all work. (I am not at
the machine at the moment but the front end seems to be doing the right
thing).

A question about feed rates.

[Jeff Epler]

Post by Ryan Hulsker
Ok, thanks for your help (Chris too), I seem to have it working now.

Yay! I am excited to hear it. If you want to, create a page on our
wiki (wiki.linuxcnc.org, follow instructions on page "BasicSteps" to be
able to add & edit pages) with some information & photos when you have
them. Other people have done this with their new or unusual types of
machines:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Alex_Joni's_Toy
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Koppi's_Toy

Post by Ryan Hulsker
A question about feed rates.

[Chris Radek]

Post by Ryan Hulsker
A question about feed rates.

[Thomas J Powderly]

in wedm the u&v are not only parallel to x&y
they are carried by x&y
meaning they are incremental to x&y
i think that idea isnt being considered by the guys working in emc/wedm as it is fundemental to the kins and never was stated
the u&v often have near a cm of stroke
the x&y might have meters

'squaring' u&v (aka wire allignment) is the process of zeroing the u&v guide when it is directly above the current xy pose
now the uv is prepared to do relative motion from this normal
tomp

[Ryan Hulsker]

Please keep us updated about your progress with XYUV.
(As far as I know, your foam machine is another milestone for EMC2.)
Chris

Well, I got everything up and running last night, and after playing with
my g-code for a bit, and trying to figure out the right combination of
feed rate and wire temperature I managed to cut a reasonably respectable
airfoil core.

Some pictures of it are here.
http://i14alberta.ca/gallery2/main.php?g2_itemId=1014

The only real issue I had was that I was generating x,y positions for
the foil shape in relation to the chord of the wing. On the leading 20%
I was creating them at 1/1000 of the chord length intervals to get a
high resolution shape, and over the trailing 80% I was using 1/100 of
the chord length intervals.

The first couple of cuts I was using a chord length of about 100mm,
meaning that my g-code statements around the leading edge where about
0.1mm apart or less, which caused the feedrate to slow down for some
reason, which caused too much heat to build up in the leading edge.

I re-processed the g-code to scale the chord up to 200mm, and remove any
statements that where less than 1.0mm from the previous point and that
seemed to do the trick.

I am using 20ga nichrome-80 wire (about 2.5 Ohms/ft) and found so far
that using about 2.2 amps of current and a feedrate of about 150mm/min
gave pretty good results.

My guess is that using a slightly higher temperature and faster feed
rate would be better, but I need to lubricate the machine and fix some
wobbles/stickies in my lead screws.

I am using standard hardware store threaded rod, with the standard
coupler nuts. Any idea what the best way to lubricate them is? I
bought some lithium grease, but have not applied it yet.

Next thing to do is to charactarize the kerf width and try some tapered
sections.

I will take some pictures of the machine when I get a chance and post
them in the wiki.

Ryan

[Andre' Blanchard]

In case you are looking for something to play around with here is a 4 axis
shape I was messing around with at one time.
It does an ellipse in the XY plane and kind of an H shape in the UV.


G00 X0.0000 Y4.0000 U0.0000 V4.0000

G01 X0.0000 Y3.0000 U0.0000 V1.0000
G01 X0.0793 Y2.9976 U0.2667 V1.0000
G01 X0.1583 Y2.9906 U0.5333 V1.0000
G01 X0.2367 Y2.9789 U0.8000 V1.0000
G01 X0.3144 Y2.9627 U0.8618 V1.0098
G01 X0.3910 Y2.9421 U0.9176 V1.0382
G01 X0.4663 Y2.9173 U0.9618 V1.0824
G01 X0.5402 Y2.8885 U0.9902 V1.1382
G01 X0.6125 Y2.8559 U1.0000 V1.2000
G01 X0.6831 Y2.8196 U1.0000 V1.3200
G01 X0.7518 Y2.7800 U1.0000 V1.4400
G01 X0.8186 Y2.7372 U1.0000 V1.5600
G01 X0.8834 Y2.6915 U1.0000 V1.6800
G01 X0.9462 Y2.6430 U1.0000 V1.8000
G01 X1.0069 Y2.5920 U1.0098 V1.8618
G01 X1.0656 Y2.5387 U1.0382 V1.9176
G01 X1.1223 Y2.4832 U1.0824 V1.9618
G01 X1.1769 Y2.4256 U1.1382 V1.9902
G01 X1.2295 Y2.3662 U1.2000 V2.0000
G01 X1.2800 Y2.3051 U1.3500 V2.0000
G01 X1.3286 Y2.2424 U1.5000 V2.0000
G01 X1.3752 Y2.1782 U1.6500 V2.0000
G01 X1.4199 Y2.1127 U1.8000 V2.0000
G01 X1.4628 Y2.0459 U1.8618 V1.9902
G01 X1.5037 Y1.9780 U1.9176 V1.9618
G01 X1.5428 Y1.9090 U1.9618 V1.9176
G01 X1.5802 Y1.8390 U1.9902 V1.8618
G01 X1.6157 Y1.7681 U2.0000 V1.8000
G01 X1.6496 Y1.6963 U2.0000 V1.7200
G01 X1.6817 Y1.6238 U2.0000 V1.6400
G01 X1.7121 Y1.5506 U2.0000 V1.5600
G01 X1.7409 Y1.4766 U2.0000 V1.4800
G01 X1.7681 Y1.4021 U2.0000 V1.4000
G01 X1.7937 Y1.3270 U2.0000 V1.3200
G01 X1.8177 Y1.2514 U2.0000 V1.2400
G01 X1.8401 Y1.1753 U2.0000 V1.1600
G01 X1.8610 Y1.0988 U2.0000 V1.0800
G01 X1.8804 Y1.0219 U2.0000 V1.0000
G01 X1.8983 Y0.9446 U2.0000 V0.9200
G01 X1.9147 Y0.8670 U2.0000 V0.8400
G01 X1.9296 Y0.7891 U2.0000 V0.7600
G01 X1.9430 Y0.7109 U2.0000 V0.6800
G01 X1.9550 Y0.6325 U2.0000 V0.6000
G01 X1.9656 Y0.5539 U2.0000 V0.5200
G01 X1.9748 Y0.4751 U2.0000 V0.4400
G01 X1.9825 Y0.3961 U2.0000 V0.3600
G01 X1.9888 Y0.3170 U2.0000 V0.2800
G01 X1.9937 Y0.2379 U2.0000 V0.2000
G01 X1.9972 Y0.1586 U2.0000 V0.1200
G01 X1.9993 Y0.0793 U2.0000 V0.0400
G01 X2.0000 Y0.0000 U2.0000 V0.0000
G01 X1.9993 Y-0.0793 U2.0000 V-0.0400
G01 X1.9972 Y-0.1586 U2.0000 V-0.1200
G01 X1.9937 Y-0.2379 U2.0000 V-0.2000
G01 X1.9888 Y-0.3170 U2.0000 V-0.2800
G01 X1.9825 Y-0.3961 U2.0000 V-0.3600
G01 X1.9748 Y-0.4751 U2.0000 V-0.4400
G01 X1.9656 Y-0.5539 U2.0000 V-0.5200
G01 X1.9550 Y-0.6325 U2.0000 V-0.6000
G01 X1.9430 Y-0.7109 U2.0000 V-0.6800
G01 X1.9296 Y-0.7891 U2.0000 V-0.7600
G01 X1.9147 Y-0.8670 U2.0000 V-0.8400
G01 X1.8983 Y-0.9446 U2.0000 V-0.9200
G01 X1.8804 Y-1.0219 U2.0000 V-1.0000
G01 X1.8610 Y-1.0988 U2.0000 V-1.0800
G01 X1.8401 Y-1.1753 U2.0000 V-1.1600
G01 X1.8177 Y-1.2514 U2.0000 V-1.2400
G01 X1.7937 Y-1.3270 U2.0000 V-1.3200
G01 X1.7681 Y-1.4021 U2.0000 V-1.4000
G01 X1.7409 Y-1.4766 U2.0000 V-1.4800
G01 X1.7121 Y-1.5506 U2.0000 V-1.5600
G01 X1.6817 Y-1.6238 U2.0000 V-1.6400
G01 X1.6496 Y-1.6963 U2.0000 V-1.7200
G01 X1.6157 Y-1.7681 U2.0000 V-1.8000
G01 X1.5802 Y-1.8390 U1.9902 V-1.8618
G01 X1.5428 Y-1.9090 U1.9618 V-1.9176
G01 X1.5037 Y-1.9780 U1.9176 V-1.9618
G01 X1.4628 Y-2.0459 U1.8618 V-1.9902
G01 X1.4199 Y-2.1127 U1.8000 V-2.0000
G01 X1.3752 Y-2.1782 U1.6500 V-2.0000
G01 X1.3286 Y-2.2424 U1.5000 V-2.0000
G01 X1.2800 Y-2.3051 U1.3500 V-2.0000
G01 X1.2295 Y-2.3662 U1.2000 V-2.0000
G01 X1.1769 Y-2.4256 U1.1382 V-1.9902
G01 X1.1223 Y-2.4832 U1.0824 V-1.9618
G01 X1.0656 Y-2.5387 U1.0382 V-1.9176
G01 X1.0069 Y-2.5920 U1.0098 V-1.8618
G01 X0.9462 Y-2.6430 U1.0000 V-1.8000
G01 X0.8834 Y-2.6915 U1.0000 V-1.6800
G01 X0.8186 Y-2.7372 U1.0000 V-1.5600
G01 X0.7518 Y-2.7800 U1.0000 V-1.4400
G01 X0.6831 Y-2.8196 U1.0000 V-1.3200
G01 X0.6125 Y-2.8559 U1.0000 V-1.2000
G01 X0.5402 Y-2.8885 U0.9902 V-1.1382
G01 X0.4663 Y-2.9173 U0.9618 V-1.0824
G01 X0.3910 Y-2.9421 U0.9176 V-1.0382
G01 X0.3144 Y-2.9627 U0.8618 V-1.0098
G01 X0.2367 Y-2.9789 U0.8000 V-1.0000
G01 X0.1583 Y-2.9906 U0.5333 V-1.0000
G01 X0.0793 Y-2.9976 U0.2667 V-1.0000
G01 X0.0000 Y-3.0000 U0.0000 V-1.0000
G01 X-0.0793 Y-2.9976 U-0.2667 V-1.0000
G01 X-0.1583 Y-2.9906 U-0.5333 V-1.0000
G01 X-0.2367 Y-2.9789 U-0.8000 V-1.0000
G01 X-0.3144 Y-2.9627 U-0.8618 V-1.0098
G01 X-0.3910 Y-2.9421 U-0.9176 V-1.0382
G01 X-0.4663 Y-2.9173 U-0.9618 V-1.0824
G01 X-0.5402 Y-2.8885 U-0.9902 V-1.1382
G01 X-0.6125 Y-2.8559 U-1.0000 V-1.2000
G01 X-0.6831 Y-2.8196 U-1.0000 V-1.3200
G01 X-0.7518 Y-2.7800 U-1.0000 V-1.4400
G01 X-0.8186 Y-2.7372 U-1.0000 V-1.5600
G01 X-0.8834 Y-2.6915 U-1.0000 V-1.6800
G01 X-0.9462 Y-2.6430 U-1.0000 V-1.8000
G01 X-1.0069 Y-2.5920 U-1.0098 V-1.8618
G01 X-1.0656 Y-2.5387 U-1.0382 V-1.9176
G01 X-1.1223 Y-2.4832 U-1.0824 V-1.9618
G01 X-1.1769 Y-2.4256 U-1.1382 V-1.9902
G01 X-1.2295 Y-2.3662 U-1.2000 V-2.0000
G01 X-1.2800 Y-2.3051 U-1.3500 V-2.0000
G01 X-1.3286 Y-2.2424 U-1.5000 V-2.0000
G01 X-1.3752 Y-2.1782 U-1.6500 V-2.0000
G01 X-1.4199 Y-2.1127 U-1.8000 V-2.0000
G01 X-1.4628 Y-2.0459 U-1.8618 V-1.9902
G01 X-1.5037 Y-1.9780 U-1.9176 V-1.9618
G01 X-1.5428 Y-1.9090 U-1.9618 V-1.9176
G01 X-1.5802 Y-1.8390 U-1.9902 V-1.8618
G01 X-1.6157 Y-1.7681 U-2.0000 V-1.8000
G01 X-1.6496 Y-1.6963 U-2.0000 V-1.7200
G01 X-1.6817 Y-1.6238 U-2.0000 V-1.6400
G01 X-1.7121 Y-1.5506 U-2.0000 V-1.5600
G01 X-1.7409 Y-1.4766 U-2.0000 V-1.4800
G01 X-1.7681 Y-1.4021 U-2.0000 V-1.4000
G01 X-1.7937 Y-1.3270 U-2.0000 V-1.3200
G01 X-1.8177 Y-1.2514 U-2.0000 V-1.2400
G01 X-1.8401 Y-1.1753 U-2.0000 V-1.1600
G01 X-1.8610 Y-1.0988 U-2.0000 V-1.0800
G01 X-1.8804 Y-1.0219 U-2.0000 V-1.0000
G01 X-1.8983 Y-0.9446 U-2.0000 V-0.9200
G01 X-1.9147 Y-0.8670 U-2.0000 V-0.8400
G01 X-1.9296 Y-0.7891 U-2.0000 V-0.7600
G01 X-1.9430 Y-0.7109 U-2.0000 V-0.6800
G01 X-1.9550 Y-0.6325 U-2.0000 V-0.6000
G01 X-1.9656 Y-0.5539 U-2.0000 V-0.5200
G01 X-1.9748 Y-0.4751 U-2.0000 V-0.4400
G01 X-1.9825 Y-0.3961 U-2.0000 V-0.3600
G01 X-1.9888 Y-0.3170 U-2.0000 V-0.2800
G01 X-1.9937 Y-0.2379 U-2.0000 V-0.2000
G01 X-1.9972 Y-0.1586 U-2.0000 V-0.1200
G01 X-1.9993 Y-0.0793 U-2.0000 V-0.0400
G01 X-2.0000 Y0.0000 U-2.0000 V0.0000
G01 X-1.9993 Y0.0793 U-2.0000 V0.0400
G01 X-1.9972 Y0.1586 U-2.0000 V0.1200
G01 X-1.9937 Y0.2379 U-2.0000 V0.2000
G01 X-1.9888 Y0.3170 U-2.0000 V0.2800
G01 X-1.9825 Y0.3961 U-2.0000 V0.3600
G01 X-1.9748 Y0.4751 U-2.0000 V0.4400
G01 X-1.9656 Y0.5539 U-2.0000 V0.5200
G01 X-1.9550 Y0.6325 U-2.0000 V0.6000
G01 X-1.9430 Y0.7109 U-2.0000 V0.6800
G01 X-1.9296 Y0.7891 U-2.0000 V0.7600
G01 X-1.9147 Y0.8670 U-2.0000 V0.8400
G01 X-1.8983 Y0.9446 U-2.0000 V0.9200
G01 X-1.8804 Y1.0219 U-2.0000 V1.0000
G01 X-1.8610 Y1.0988 U-2.0000 V1.0800
G01 X-1.8401 Y1.1753 U-2.0000 V1.1600
G01 X-1.8177 Y1.2514 U-2.0000 V1.2400
G01 X-1.7937 Y1.3270 U-2.0000 V1.3200
G01 X-1.7681 Y1.4021 U-2.0000 V1.4000
G01 X-1.7409 Y1.4766 U-2.0000 V1.4800
G01 X-1.7121 Y1.5506 U-2.0000 V1.5600
G01 X-1.6817 Y1.6238 U-2.0000 V1.6400
G01 X-1.6496 Y1.6963 U-2.0000 V1.7200
G01 X-1.6157 Y1.7681 U-2.0000 V1.8000
G01 X-1.5802 Y1.8390 U-1.9902 V1.8618
G01 X-1.5428 Y1.9090 U-1.9618 V1.9176
G01 X-1.5037 Y1.9780 U-1.9176 V1.9618
G01 X-1.4628 Y2.0459 U-1.8618 V1.9902
G01 X-1.4199 Y2.1127 U-1.8000 V2.0000
G01 X-1.3752 Y2.1782 U-1.6500 V2.0000
G01 X-1.3286 Y2.2424 U-1.5000 V2.0000
G01 X-1.2800 Y2.3051 U-1.3500 V2.0000
G01 X-1.2295 Y2.3662 U-1.2000 V2.0000
G01 X-1.1769 Y2.4256 U-1.1382 V1.9902
G01 X-1.1223 Y2.4832 U-1.0824 V1.9618
G01 X-1.0656 Y2.5387 U-1.0382 V1.9176
G01 X-1.0069 Y2.5920 U-1.0098 V1.8618
G01 X-0.9462 Y2.6430 U-1.0000 V1.8000
G01 X-0.8834 Y2.6915 U-1.0000 V1.6800
G01 X-0.8186 Y2.7372 U-1.0000 V1.5600
G01 X-0.7518 Y2.7800 U-1.0000 V1.4400
G01 X-0.6831 Y2.8196 U-1.0000 V1.3200
G01 X-0.6125 Y2.8559 U-1.0000 V1.2000
G01 X-0.5402 Y2.8885 U-0.9902 V1.1382
G01 X-0.4663 Y2.9173 U-0.9618 V1.0824
G01 X-0.3910 Y2.9421 U-0.9176 V1.0382
G01 X-0.3144 Y2.9627 U-0.8618 V1.0098
G01 X-0.2367 Y2.9789 U-0.8000 V1.0000
G01 X-0.1583 Y2.9906 U-0.5333 V1.0000
G01 X-0.0793 Y2.9976 U-0.2667 V1.0000
G01 X0.0000 Y3.0000 U0.0000 V1.0000
__________
Andre' B. Clear Lake, Wi.

[John Kasunich]

Post by Ryan Hulsker
I need to lubricate the machine and fix some
wobbles/stickies in my lead screws.
I am using standard hardware store threaded rod, with the standard
coupler nuts. Any idea what the best way to lubricate them is? I
bought some lithium grease, but have not applied it yet.

Sometimes the hardware store rod is quite rough. I've heard of people
lapping the rods using Clover lapping compound on a coupling nut. (The
long nuts that are used to couple threaded rods together, usually sold
next to the rods.) Chuck the rod in a reversible drill, apply some
clover, and run the nut from end to end a few dozen times to take down
the rough spots. Then clean off the clover with kerosene or such and
install in your machine.

Regards,

John Kasunich

[ben lipkowitz]

Post by Ryan Hulsker
The first couple of cuts I was using a chord length of about 100mm,
meaning that my g-code statements around the leading edge where about
0.1mm apart or less, which caused the feedrate to slow down for some
reason, which caused too much heat to build up in the leading edge.

If you use G64 P0.1 the trajectory planner *should* automatically blend
out the unnecessary segments and give you full speed over the entire shape.

Post by Ryan Hulsker
I am using 20ga nichrome-80 wire (about 2.5 Ohms/ft) and found so far
that using about 2.2 amps of current and a feedrate of about 150mm/min
gave pretty good results.

Thanks for the data. Stuff like this can save others lots of time.

Post by Ryan Hulsker
I am using standard hardware store threaded rod, with the standard
coupler nuts. Any idea what the best way to lubricate them is? I
bought some lithium grease, but have not applied it yet.

You might try running a die over the threads to knock off the high spots.
Also, you can make pretty serviceable plastic nuts with a tap and some
cutting boards. You can even make anti-backlash nuts with this method.
Brass works well too. High-moly EP "extreme pressure" grease (lithium
grease with molybdenum sulfide added) is the best for metal-metal contact.
Lithium should work well for plastic/metal but I think no grease would be
the best, since its kinda messy. Most binding problems are caused by
misalignment anyway.

Post by Ryan Hulsker
Next thing to do is to charactarize the kerf width and try some tapered
sections.

I've heard that the kerf can be higher on the top side of a tapered cut
since heat rises. This might confuse your measurements.

HTH
-fenn

[Jeff Epler]

Post by ben lipkowitz

Post by Ryan Hulsker
The first couple of cuts I was using a chord length of about 100mm,
meaning that my g-code statements around the leading edge where about
0.1mm apart or less, which caused the feedrate to slow down for some
reason, which caused too much heat to build up in the leading edge.

If you use G64 P0.1 the trajectory planner *should* automatically blend
out the unnecessary segments and give you full speed over the entire shape.

Unfortunately, G64 P- only simplifies nearly-colinear segments when they
are purely XYZ movement. If there is any movement on the other axes
(ABC or UVW) then the simplification doesn't take place.

Jeff

[Ryan Hulsker]

Post by Jeff Epler

Post by ben lipkowitz

Post by Ryan Hulsker
The first couple of cuts I was using a chord length of about 100mm,
meaning that my g-code statements around the leading edge where about
0.1mm apart or less, which caused the feedrate to slow down for some
reason, which caused too much heat to build up in the leading edge.

If you use G64 P0.1 the trajectory planner *should* automatically blend
out the unnecessary segments and give you full speed over the entire shape.

Unfortunately, G64 P- only simplifies nearly-colinear segments when they
are purely XYZ movement. If there is any movement on the other axes
(ABC or UVW) then the simplification doesn't take place.

Ahhh, ok. After reading the description of G64, I am realizing that the
reduction in feed rate is probably due to my acceleration limits. I
have not really tuned those parameters and they are probably still very
conservative.

Does that make sense?

A question about radius cuts. I would like to be able to command a
circular cut simultaneously in XY and UV (to cut a cylinder).

G01 x10 y10 u10 v10
G17 G2 x10 y10 u10 v10 i0 y2

I assume that this will cut a circle in the XY plane with a radius of 2
and start/end at x10 y10, but it seems from the description that uv will
remain stationary causing me to end up with a cone, is that correct? Or
is there a way to tell it to use both xy and uv for the circle?

Ryan

[Chris Radek]

Post by Ryan Hulsker
is there a way to tell it to use both xy and uv for the circle?

Nope, you'll have to split it up into lines in your gcode.

One of these days we need plug-in interpreters because gcode works so
differently for different machine configurations. (UV on a mill is
separate, UV on foam is relative to XY, UV on a lathe is a special
kind of incremental!?)

[Chris Radek]

Post by Ryan Hulsker
Ok, so i solved that first problem (i had actually forgotten to set
"axes" to 4.
Now I am getting this problem.

http://linuxcnc.org/docs/devel/html/config/ini_config/index.html#SECTION00136000000000000000

[mgouget]

Binding EMC2 to a *real* language seems an *excellent* idea to me.



RS274 is an antique language. Adding O words, named parameters and special
comments, although very useful when nothing else is available, is only a
kludge...



The only advantage of RS274 is that it is normalised, and that many CAD
systems generate code for it, so that is the way to go for complex parts.



But, for small jobs like surfacing, pocketing or making holes, I found that
creating gcode is longer that doing the job by hand.



Mach3 has wizards for common tasks; the same could be done with EMC. Being
able to create quick and dirty interactive programs for small jobs would be
a BIG bonus for me.



I am mostly fluent in C, but learning *yet another modern OO-oriented
language* plus NML and HAL commands is not a big deal.



An important point is that we must not shutdown (at least) axis, (and
possibly) tkemc or minimill (my preferred interface...) when running a
script; I think that NML and the modular structure of EMC allows for this.



Just my 2 cents...



Michel

[Gene Heskett]

Post by mgouget
Binding EMC2 to a *real* language seems an *excellent* idea to me.
RS274 is an antique language. Adding O words, named parameters and special
comments, although very useful when nothing else is available, is only a
kludge...

I highly disagree with that word, its not a 'kludge' but simply is giving
RS274 the same looping and branching abilities the basic cpu is capable of.

Post by mgouget
The only advantage of RS274 is that it is normalised, and that many CAD
systems generate code for it, so that is the way to go for complex parts.
But, for small jobs like surfacing, pocketing or making holes, I found that
creating gcode is longer that doing the job by hand.
Mach3 has wizards for common tasks; the same could be done with EMC. Being
able to create quick and dirty interactive programs for small jobs would be
a BIG bonus for me.

Mach3 also I assume, has a cash cow in the form of its sales to be used to pay
programmers to develop favorite functions.

To parrot the oft used phrase, code contributions are always welcome. Usefull
stuff should see the source code finding its way into the wiki at
wiki.linuxcnc.org, or the examples directory of the emc distribution. With
of course, suitable licensing such as the CCL or GPL.

Post by mgouget
I am mostly fluent in C, but learning *yet another modern OO-oriented
language* plus NML and HAL commands is not a big deal.
An important point is that we must not shutdown (at least) axis, (and
possibly) tkemc or minimill (my preferred interface...) when running a
script; I think that NML and the modular structure of EMC allows for this.

Agreed, a display of what it is doing seems like a usefull feature.

Post by mgouget
Just my 2 cents...

And mine. :)

Post by mgouget
Michel

[Andre' Blanchard]

Post by Gene Heskett

Post by mgouget
Binding EMC2 to a *real* language seems an *excellent* idea to me.
RS274 is an antique language. Adding O words, named parameters and special
comments, although very useful when nothing else is available, is only a
kludge...

I highly disagree with that word, its not a 'kludge' but simply is giving
RS274 the same looping and branching abilities the basic cpu is capable of.

While it works and is way better then not having it and for the price it is
great.
I guess the main thing I don't get is, why the strange syntax, what would
have been wrong with doing IF THEN and IF GOTO branches and WHILE
loops like other CNC controls?

IF[#105LE0.0]GOTO8998
IF[#110LE0]GOTO8998
(Do stuff)
N8998

IF[]THEN#101=0.0005

WHILE[]DO1
(Do stuff)
WHILE[]DO2
(Do stuff)
WHILE[]DO3
(Do stuff)
END3
END2
END1



I get the feeling that not much research is done into how this stuff has
been done in the past.
Why reinvent the wheel?



__________
Andre' B. Clear Lake, Wi.

[Alan Condit]

Michel,

Post by mgouget
But, for small jobs like surfacing, pocketing or making holes, I
found that
creating gcode is longer that doing the job by hand.
Michel

I created a starter file over time with a bunch of macros that I use
regularly. In order to machine a new simple part, I often only have
to write a few lines of code to call the appropriate macros with the
correct parameters. So to drill a hole requires one line of code, a
pocket requires one line of code, the outline of the part can be one
line of code if it is a rectangle. If I want a bearing pocket with a
through hole it requires two lines of code. I could write a macro
for surfacing a rectangular area that would only require one line of
code to call. I have a bunch of variables at the start of the
program that allow me to change the diameter of the bit that I am
using, and set the machine offset for the part's origin, and the
thickness of the material and the location of the zero point for the
z axis. I can also set the step down with the variables.

What does this all buy me? Well I know the routines work, so I don't
have to spend a lot of time debugging. I also know their limitations,
so if I need to do something new and unique I can decide whether it
should be generalized as a modification to my starter file or just a
quick and dirty routine for that job.

Alan

---

Alan Condit
1085 Tierra Ct.
Woodburn, OR 97071

Email -- ***@ipns.com
Home-Office [phone]

[Kenneth Lerman]

I disagree with the defenders who say it is not a kludge. It is a kludge. It
was when I wrote it and it is now.

The reason that these features must begin with an o-word is very simple. It
made it easier to change the parser. The code simply tests if the line
begins with an o-word. If it does, it calls a function that processes
o-words.

The change was simple and effective. I wrote that set of changes (call, if,
then, else, while, return, endsub, do -- plus the expression changes -- eq,
ne, le, lt, gt, ge) in about a week while I was on vacation.

It IS free. If you don't like that syntax, please feel free to not use it.
If you prefer a different syntax, please, please feel free to add it to the
interpreter. I won't take offense. Really, I won't.

It is a kludge. One of my better ones, I think.

Ken

***@se-ltd.com
Mark Kenny Products Company, LLC
55 Main Street Voice: (888)ISO-SEVO [phone]
Newtown, CT 06470 Fax: [phone]
http://www.MarkKenny.com


-----Original Message-----
From: emc-users-***@lists.sourceforge.net
[mailto:emc-users-***@lists.sourceforge.net]On Behalf Of Andre'
Blanchard
Sent: Tuesday, August 21, 2007 11:07 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Interactive machining

Post by Gene Heskett

Post by mgouget
Binding EMC2 to a *real* language seems an *excellent* idea to me.
RS274 is an antique language. Adding O words, named parameters and

special

Post by Gene Heskett

Post by mgouget
comments, although very useful when nothing else is available, is only a
kludge...

I highly disagree with that word, its not a 'kludge' but simply is giving
RS274 the same looping and branching abilities the basic cpu is capable of.

While it works and is way better then not having it and for the price it is
great.
I guess the main thing I don't get is, why the strange syntax, what would
have been wrong with doing IF THEN and IF GOTO branches and WHILE
loops like other CNC controls?

IF[#105LE0.0]GOTO8998
IF[#110LE0]GOTO8998
(Do stuff)
N8998

IF[]THEN#101=0.0005

WHILE[]DO1
(Do stuff)
WHILE[]DO2
(Do stuff)
WHILE[]DO3
(Do stuff)
END3
END2
END1



I get the feeling that not much research is done into how this stuff has
been done in the past.
Why reinvent the wheel?



__________
Andre' B. Clear Lake, Wi.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[Gene Heskett]

Post by Kenneth Lerman
I disagree with the defenders who say it is not a kludge. It is a kludge. It
was when I wrote it and it is now.
The reason that these features must begin with an o-word is very simple. It
made it easier to change the parser. The code simply tests if the line
begins with an o-word. If it does, it calls a function that processes
o-words.
The change was simple and effective. I wrote that set of changes (call, if,
then, else, while, return, endsub, do -- plus the expression changes -- eq,
ne, le, lt, gt, ge) in about a week while I was on vacation.
It IS free. If you don't like that syntax, please feel free to not use it.
If you prefer a different syntax, please, please feel free to add it to the
interpreter. I won't take offense. Really, I won't.
It is a kludge. One of my better ones, I think.

If you, the author call it a kludge, I'll take your word for it Ken. To me,
its handier than bottled beer and sliced bread in the same sack. Thanks a
lot for doing it.

[Kirk Wallace]

This thread brings to mind that it would be nice to have a "skins"
feature. Let's say, ACME Precision, Inc. is a Haas shop and would like
to use EMC to convert an old unused Fadal. The person doing the
conversion would most likely not be the person running the machine so
the operator would be best served by having a familiar (Haas) interface
and not have to deal with EMC at all.

(On a side note, EMC enthusiasts could collect and trade skins. E-stop
ring tones would be nice too. But seriously, skins would be cool.)

Kirk Wallace

[Michel Gouget]

Ken,

I strongly agree with you, you did a wonderful hack, adding a lot of
functionality with a minimal amount of work. It was "the right thing to do",
and the price sure is unbeatable :)

I learned programming back in 1976 in FORTRAN66 on an IBM 1130. At least,
it was a high level language. RS274 is more like an assembler on which
we add flow control and macros (this can be very efficient, as does
Alan)..., the next step could be to write a compiler (which translate, as
suggested by André, some kind of FORTRAN to RS274, then enter the road of
structured programming with PASCAL_EMC, then OO, with RS274++ :)

Or we can take lessons from the actual trends in computing, and just add
bindings and specific classes to an *existing* OO language such as ruby,
python, perl... python being a very good candidate.

In that case, this will be EMC specific, but that is not a problem as long
as RS274-NGC is still supported. It is NOT a replacement, it is an
augmentation.

Is it difficult, very difficult or extremely difficult to add an NML+HAL
library to python?

Michel

-----Original Message-----
From: emc-users-***@lists.sourceforge.net [mailto:
emc-users-***@lists.sourceforge.net] On Behalf Of Kenneth Lerman
Sent: mardi 21 août 2007 19:17
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Interactive machining


I disagree with the defenders who say it is not a kludge. It is a kludge. It
was when I wrote it and it is now.

The reason that these features must begin with an o-word is very simple. It
made it easier to change the parser. The code simply tests if the line
begins with an o-word. If it does, it calls a function that processes
o-words.

The change was simple and effective. I wrote that set of changes (call, if,
then, else, while, return, endsub, do -- plus the expression changes -- eq,
ne, le, lt, gt, ge) in about a week while I was on vacation.

It IS free. If you don't like that syntax, please feel free to not use it.
If you prefer a different syntax, please, please feel free to add it to the
interpreter. I won't take offense. Really, I won't.

It is a kludge. One of my better ones, I think.

Ken

***@se-ltd.com
Mark Kenny Products Company, LLC
55 Main Street Voice: (888)ISO-SEVO [phone]
Newtown, CT 06470 Fax: [phone]
http://www.MarkKenny.com


-----Original Message-----
From: emc-users-***@lists.sourceforge.net
[mailto:emc-users-***@lists.sourceforge.net]On Behalf Of Andre'
Blanchard
Sent: Tuesday, August 21, 2007 11:07 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Interactive machining

Post by Gene Heskett

Post by mgouget
Binding EMC2 to a *real* language seems an *excellent* idea to me.
RS274 is an antique language. Adding O words, named parameters and

special

Post by Gene Heskett

Post by mgouget
comments, although very useful when nothing else is available, is only a
kludge...

I highly disagree with that word, its not a 'kludge' but simply is giving
RS274 the same looping and branching abilities the basic cpu is capable of.

While it works and is way better then not having it and for the price it is
great.
I guess the main thing I don't get is, why the strange syntax, what would
have been wrong with doing IF THEN and IF GOTO branches and WHILE
loops like other CNC controls?

IF[#105LE0.0]GOTO8998
IF[#110LE0]GOTO8998
(Do stuff)
N8998

IF[]THEN#101=0.0005

WHILE[]DO1
(Do stuff)
WHILE[]DO2
(Do stuff)
WHILE[]DO3
(Do stuff)
END3
END2
END1



I get the feeling that not much research is done into how this stuff has
been done in the past.
Why reinvent the wheel?



__________
Andre' B. Clear Lake, Wi.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Emc-users mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[Jeff Epler]

Post by Michel Gouget
Is it difficult, very difficult or extremely difficult to add an NML+HAL
library to python?

It's already there -- it's the basis for such neat things as AXIS, the
hal_input userspace driver, and so on.


Help on module hal:

NAME
hal - Interface to emc2's hal

FILE
/usr/lib/python2.4/site-packages/hal.so

DESCRIPTION
This module allows the creation of userspace HAL components in Python.
This includes pins and parameters of the various HAL types.

Typical usage:

import hal, time
h = hal.component("component-name")
# create pins and parameters with calls to h.newpin and h.newparam
h.newpin("in", hal.HAL_FLOAT, hal.HAL_IN)
h.newpin("out", hal.HAL_FLOAT, hal.HAL_OUT)
h.ready() # mark the component as 'ready'

try:
while 1:
# act on changed input pins; update values on output pins
time.sleep(1)
h['out'] = h['in']
except KeyboardInterrupt: pass

When the component is requested to exit with 'halcmd unload', a
KeyboardInterrupt exception will be raised.

CLASSES
__builtin__.object
component
exceptions.Exception
error

class component(__builtin__.object)
| HAL Component
|
| Methods defined here:
|
| __delattr__(...)
| x.__delattr__('name') <==> del x.name
|
| __delitem__(...)
| x.__delitem__(y) <==> del x[y]
|
| __getattribute__(...)
| x.__getattribute__('name') <==> x.name
|
| __getitem__(...)
| x.__getitem__(y) <==> x[y]
|
| __init__(...)
| x.__init__(...) initializes x; see x.__class__.__doc__ for signature
|
| __len__(...)
| x.__len__() <==> len(x)
|
| __repr__(...)
| x.__repr__() <==> repr(x)
|
| __setattr__(...)
| x.__setattr__('name', value) <==> x.name = value
|
| __setitem__(...)
| x.__setitem__(i, y) <==> x[i]=y
|
| exit(...)
| Call hal_exit
|
| newparam(...)
| Create a new parameter
|
| newpin(...)
| Create a new pin
|
| ready(...)
| Call hal_ready
|
| setprefix(...)
| Set the prefix for newly created pins and parameters
|
| ----------------------------------------------------------------------
| Data and other attributes defined here:
|
| __new__ = <built-in method __new__ of type object>
| T.__new__(S, ...) -> a new object with type S, a subtype of T

class error(exceptions.Exception)
| Methods inherited from exceptions.Exception:
|
| __getitem__(...)
|
| __init__(...)
|
| __str__(...)

FUNCTIONS
pin_has_writer(...)
Return a FALSE value if a pin has no writers and TRUE if it does

DATA
HAL_BIT = 1
HAL_FLOAT = 2
HAL_IN = 16
HAL_IO = 48
HAL_OUT = 32
HAL_RO = 16
HAL_RW = 48
HAL_S32 = 3
HAL_U32 = 4


Help on module emc:

NAME
emc - Interface to EMC

FILE
/usr/lib/python2.4/site-packages/emc.so

CLASSES
__builtin__.object
command
error_channel
ini
positionlogger
stat
exceptions.RuntimeError(exceptions.StandardError)
error

class command(__builtin__.object)
| Methods defined here:
|
| __init__(...)
| x.__init__(...) initializes x; see x.__class__.__doc__ for signature
|
| abort(...)
|
| auto(...)
|
| brake(...)
|
| debug(...)
|
| feedrate(...)
|
| flood(...)
|
| home(...)
|
| jog(...)
|
| load_tool_table(...)
|
| mdi(...)
|
| mist(...)
|
| mode(...)
|
| override_limits(...)
|
| program_open(...)
|
| reset_interpreter(...)
|
| set_block_delete(...)
|
| set_optional_stop(...)
|
| spindle(...)
|
| spindleoverride(...)
|
| state(...)
|
| teleop_enable(...)
|
| teleop_vector(...)
|
| tool_offset(...)
|
| traj_mode(...)
|
| wait_complete(...)
|
| ----------------------------------------------------------------------
| Data and other attributes defined here:
|
| __new__ = <built-in method __new__ of type object>
| T.__new__(S, ...) -> a new object with type S, a subtype of T
|
| serial = <member 'serial' of 'emc.command' objects>

class error(exceptions.RuntimeError)
| Method resolution order:
| error
| exceptions.RuntimeError
| exceptions.StandardError
| exceptions.Exception
|
| Methods inherited from exceptions.Exception:
|
| __getitem__(...)
|
| __init__(...)
|
| __str__(...)

class error_channel(__builtin__.object)
| Methods defined here:
|
| __init__(...)
| x.__init__(...) initializes x; see x.__class__.__doc__ for signature
|
| poll(...)
| Poll for errors
|
| ----------------------------------------------------------------------
| Data and other attributes defined here:
|
| __new__ = <built-in method __new__ of type object>
| T.__new__(S, ...) -> a new object with type S, a subtype of T

class ini(__builtin__.object)
| Methods defined here:
|
| __init__(...)
| x.__init__(...) initializes x; see x.__class__.__doc__ for signature
|
| find(...)
| Find value in inifile as string. This uses the ConfigParser-style (section,option) order, not the emc order.
|
| findall(...)
| Find value in inifile as a list. This uses the ConfigParser-style (section,option) order, not the emc order.
|
| ----------------------------------------------------------------------
| Data and other attributes defined here:
|
| __new__ = <built-in method __new__ of type object>
| T.__new__(S, ...) -> a new object with type S, a subtype of T

class positionlogger(__builtin__.object)
| Methods defined here:
|
| __init__(...)
| x.__init__(...) initializes x; see x.__class__.__doc__ for signature
|
| call(...)
| Plot the backplot now
|
| clear(...)
| Clear the position logger
|
| last(...)
| Return the most recent point on the plot or None
|
| start(...)
| Start the position logger and run every ARG seconds
|
| stop(...)
| Stop the position logger
|
| ----------------------------------------------------------------------
| Data and other attributes defined here:
|
| __new__ = <built-in method __new__ of type object>
| T.__new__(S, ...) -> a new object with type S, a subtype of T
|
| average_speed = <member 'average_speed' of 'emc.positionlogger' object...
|
|
| npts = <member 'npts' of 'emc.positionlogger' objects>

class stat(__builtin__.object)
| Methods defined here:
|
| __init__(...)
| x.__init__(...) initializes x; see x.__class__.__doc__ for signature
|
| gettaskfile(...)
| Get current task file
|
| poll(...)
| Update current machine state
|
| ----------------------------------------------------------------------
| Data and other attributes defined here:
|
| __new__ = <built-in method __new__ of type object>
| T.__new__(S, ...) -> a new object with type S, a subtype of T
|
| acceleration = <member 'acceleration' of 'emc.stat' objects>
|
|
| actual_position = <attribute 'actual_position' of 'emc.stat' objects>
|
|
| ain = <attribute 'ain' of 'emc.stat' objects>
|
|
| angular_units = <member 'angular_units' of 'emc.stat' objects>
|
|
| aout = <attribute 'aout' of 'emc.stat' objects>
|
|
| axes = <member 'axes' of 'emc.stat' objects>
|
|
| axis = <attribute 'axis' of 'emc.stat' objects>
|
|
| block_delete = <member 'block_delete' of 'emc.stat' objects>
|
|
| command = <member 'command' of 'emc.stat' objects>
|
|
| current_line = <member 'current_line' of 'emc.stat' objects>
|
|
| cycle_time = <member 'cycle_time' of 'emc.stat' objects>
|
|
| debug = <member 'debug' of 'emc.stat' objects>
|
|
| din = <attribute 'din' of 'emc.stat' objects>
|
|
| distance_to_go = <member 'distance_to_go' of 'emc.stat' objects>
|
|
| dout = <attribute 'dout' of 'emc.stat' objects>
|
|
| echo_serial_number = <member 'echo_serial_number' of 'emc.stat' object...
|
|
| enabled = <member 'enabled' of 'emc.stat' objects>
|
|
| estop = <member 'estop' of 'emc.stat' objects>
|
|
| exec_state = <member 'exec_state' of 'emc.stat' objects>
|
|
| feedrate = <member 'feedrate' of 'emc.stat' objects>
|
|
| file = <member 'file' of 'emc.stat' objects>
|
|
| flood = <member 'flood' of 'emc.stat' objects>
|
|
| gcodes = <attribute 'gcodes' of 'emc.stat' objects>
|
|
| homed = <attribute 'homed' of 'emc.stat' objects>
|
|
| id = <member 'id' of 'emc.stat' objects>
|
|
| inpos = <member 'inpos' of 'emc.stat' objects>
|
|
| interp_state = <member 'interp_state' of 'emc.stat' objects>
|
|
| interpreter_errcode = <member 'interpreter_errcode' of 'emc.stat' obje...
|
|
| joint_actual_position = <attribute 'joint_actual_position' of 'emc.sta...
|
|
| joint_position = <attribute 'joint_position' of 'emc.stat' objects>
|
|
| kinematics_type = <member 'kinematics_type' of 'emc.stat' objects>
|
|
| limit = <attribute 'limit' of 'emc.stat' objects>
|
|
| line = <member 'line' of 'emc.stat' objects>
|
|
| linear_units = <member 'linear_units' of 'emc.stat' objects>
|
|
| lube = <member 'lube' of 'emc.stat' objects>
|
|
| lube_level = <member 'lube_level' of 'emc.stat' objects>
|
|
| max_acceleration = <member 'max_acceleration' of 'emc.stat' objects>
|
|
| max_velocity = <member 'max_velocity' of 'emc.stat' objects>
|
|
| mcodes = <attribute 'mcodes' of 'emc.stat' objects>
|
|
| mist = <member 'mist' of 'emc.stat' objects>
|
|
| motion_line = <member 'motion_line' of 'emc.stat' objects>
|
|
| motion_mode = <member 'motion_mode' of 'emc.stat' objects>
|
|
| motion_type = <member 'motion_type' of 'emc.stat' objects>
|
|
| optional_stop = <member 'optional_stop' of 'emc.stat' objects>
|
|
| origin = <attribute 'origin' of 'emc.stat' objects>
|
|
| paused = <member 'paused' of 'emc.stat' objects>
|
|
| position = <attribute 'position' of 'emc.stat' objects>
|
|
| probe_index = <member 'probe_index' of 'emc.stat' objects>
|
|
| probe_polarity = <member 'probe_polarity' of 'emc.stat' objects>
|
|
| probe_tripped = <member 'probe_tripped' of 'emc.stat' objects>
|
|
| probe_val = <member 'probe_val' of 'emc.stat' objects>
|
|
| probed_position = <attribute 'probed_position' of 'emc.stat' objects>
|
|
| probing = <member 'probing' of 'emc.stat' objects>
|
|
| program_units = <member 'program_units' of 'emc.stat' objects>
|
|
| queue = <member 'queue' of 'emc.stat' objects>
|
|
| read_line = <member 'read_line' of 'emc.stat' objects>
|
|
| settings = <attribute 'settings' of 'emc.stat' objects>
|
|
| source_file = <member 'source_file' of 'emc.stat' objects>
|
|
| source_line = <member 'source_line' of 'emc.stat' objects>
|
|
| spindle_brake = <member 'spindle_brake' of 'emc.stat' objects>
|
|
| spindle_direction = <member 'spindle_direction' of 'emc.stat' objects>
|
|
| spindle_enabled = <member 'spindle_enabled' of 'emc.stat' objects>
|
|
| spindle_increasing = <member 'spindle_increasing' of 'emc.stat' object...
|
|
| spindle_speed = <member 'spindle_speed' of 'emc.stat' objects>
|
|
| spindlerate = <member 'spindlerate' of 'emc.stat' objects>
|
|
| state = <member 'state' of 'emc.stat' objects>
|
|
| task_mode = <member 'task_mode' of 'emc.stat' objects>
|
|
| task_state = <member 'task_state' of 'emc.stat' objects>
|
|
| tool_in_spindle = <member 'tool_in_spindle' of 'emc.stat' objects>
|
|
| tool_offset = <attribute 'tool_offset' of 'emc.stat' objects>
|
|
| tool_prepped = <member 'tool_prepped' of 'emc.stat' objects>
|
|
| tool_table = <attribute 'tool_table' of 'emc.stat' objects>
|
|
| velocity = <member 'velocity' of 'emc.stat' objects>

DATA
AUTO_PAUSE = 1
AUTO_RESUME = 2
AUTO_RUN = 0
AUTO_STEP = 3
AXIS_ANGULAR = 2
AXIS_LINEAR = 1
BRAKE_ENGAGE = 1
BRAKE_RELEASE = 0
DEBUG_CONFIG = 2
DEBUG_DEFAULTS = 4
DEBUG_INTERP = 256
DEBUG_INTERP_LIST = 2048
DEBUG_INVALID = 1
DEBUG_IO_POINTS = 32
DEBUG_MOTION_TIME = 128
DEBUG_NML = 64
DEBUG_RCS = 512
DEBUG_TASK_ISSUE = 16
DEBUG_TRAJ = 1024
DEBUG_VERSIONS = 8
FLOOD_OFF = 0
FLOOD_ON = 1
INTERP_IDLE = 1
INTERP_PAUSED = 3
INTERP_READING = 2
INTERP_WAITING = 4
JOG_CONTINUOUS = 1
JOG_INCREMENT = 2
JOG_STOP = 0
KINEMATICS_BOTH = 4
KINEMATICS_FORWARD_ONLY = 2
KINEMATICS_IDENTITY = 1
KINEMATICS_INVERSE_ONLY = 3
MIST_OFF = 0
MIST_ON = 1
MODE_AUTO = 2
MODE_MANUAL = 1
MODE_MDI = 3
NML_DISPLAY = 3
NML_ERROR = 1
NML_TEXT = 2
OPERATOR_DISPLAY = 13
OPERATOR_ERROR = 11
OPERATOR_TEXT = 12
SPINDLE_CONSTANT = 12
SPINDLE_DECREASE = 11
SPINDLE_FORWARD = 1
SPINDLE_INCREASE = 10
SPINDLE_OFF = 0
SPINDLE_REVERSE = -1
STATE_ESTOP = 1
STATE_ESTOP_RESET = 2
STATE_OFF = 3
STATE_ON = 4
TRAJ_MODE_COORD = 2
TRAJ_MODE_FREE = 1
TRAJ_MODE_TELEOP = 3
nmlfile = '/usr/local/etc/emc2/configs/sim/emc.nml'

[Michel Gouget]

Thanks a lot, Jeff; this is exactly what I was looking for.

I will experiment and see what I can do

Michel

[a***@conceptmachinery.com]

Hi
Recently I found job as a CNC programmer with leader aerospace
manufacturers. We use Catia 5 .
Our parts are very complex (5 axis surface machining) and expensive
and it is difficult/impossible to just go into the program and adjust
something. That kind manual adjustment can cause machine to crash and
it is expensive mistakes!
If something need to be change ? somewhere undercut than need go back
to Catia and redo programming.
My conclusion is that need keep standard core G code clear out of any
?Script Innovations?.
EMC must be able smoothly use code generated by main CAD-CAM programs.
Today already and into the future all commercial machining will be
complex ? complex part to be made- that CAD-CAM becomes more and more
important.

New type of interactive programming is good but it must be as separate
software and never bundle with any EMC release.
Aram

[Stephen Wille Padnos]

[snip]
New type of interactive programming is good but it must be as separate
software and never bundle with any EMC release.
Aram

I think it's unreasonable to say that EMC should never incorporate some
feature. As long as backward compatibility is maintained (and nobody
has said anything about eliminating support for standard G-code), there
should be no issue with adding features.

If you don't like new features or programs, it's your choice to not use
them.

- Steve