To create custom panels you use pyVCP as described here:
http://www.linuxcnc.org/docs/devel/html/hal_pyvcp.html#r1_5_10
John
On 12 Jan 2009 at 2:02, Steve Blackmore wrote:
On Thu, 08 Jan 2009 06:55:51 -0500, you wrote:
The new algorithm handles concave corners
And here I am, halfway
Hi Steve,
What sort of time scale are you working on? I am working on a GUI where
you can lay out the controls like you can in Mach. The editor is also a
bit less frustrating to use than scream4! It includes scripting as well
(Lua, not VBScript). The GUI itself will run in Linux, Windows or
On Mon, Jan 12, 2009 at 05:29:21PM +, Leslie Newell wrote:
By the way, emc should shortly support radius programming if I can get
the patch accepted.
[diameter]
I was just thinking about this the other day. I actually thought it
was in CVS but it's not yet. What problems remained?
On Sunday 11 January 2009, Chris Radek wrote:
Please send a patch that makes it build without warnings
You can send it to emc-developers or to me personally.
Restore my CVS access, and you won't need to mess with patches.
, 2009 12:37 PM
Subject: Re: [Emc-users] New cutter compensation algorithm in TRUNK
On Sunday 11 January 2009, Chris Radek wrote:
Please send a patch that makes it build without warnings
You can send it to emc-developers or to me personally.
Restore my CVS access, and you won't need to mess
On Sun, Jan 11, 2009 at 10:37:12AM +, paul_c wrote:
On Sunday 11 January 2009, Chris Radek wrote:
?Please send a patch that makes it build without warnings
?You can send it to emc-developers or to me personally.
Restore my CVS access, and you won't need to mess with patches.
Paul,
On Thu, 08 Jan 2009 06:55:51 -0500, you wrote:
The new algorithm handles concave corners
And here I am, halfway through writing the next installment
of Adventures in Filleting, explaining how to lay an arc
into a concave corner to avoid gouging. I am crushed, I
tell you, -crushed- by this
On Thursday 08 January 2009, Chris Radek wrote:
Today I merged my cutter compensation work. The new algorithm
handles concave corners and is not picky about entry moves.
You need to include cstdlib cstring headers in interp_queue.cc and then it
will at least compile with gcc-4.3.
On Sat, Jan 10, 2009 at 11:58:05PM +, paul_c wrote:
You need to include cstdlib cstring headers in interp_queue.cc and then it
will at least compile with gcc-4.3.
Thanks for helping test, paul. I'm not surprised if I missed
something. Please send a patch that makes it build without
thought to keep the discussion going..
Regards,
Alex
- Original Message -
From: Leslie Newell les.new...@fastmail.co.uk
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Sent: Friday, January 09, 2009 12:49 AM
Subject: Re: [Emc-users] New cutter compensation algorithm
The new algorithm handles concave corners
And here I am, halfway through writing the next installment
of Adventures in Filleting, explaining how to lay an arc
into a concave corner to avoid gouging. I am crushed, I
tell you, -crushed- by this horrible news!
big grin
The timing is actually
On Thu, Jan 08, 2009 at 06:54:37AM +, Leslie Newell wrote:
Looks good. It would be nice if you could enable these:
reading/writing motion's digital/analog ins/outs
I don't think it is possible to enable reading inputs. Consider the
following:
( already in cutter comp mode )
N000 G0
How is that handled currently?
Actually I am more interested in writing outputs than reading inputs.
For instance on a plasma cutter you may want to turn off the THC on some
corners to prevent torch dive.
Les
Jeff Epler wrote:
I don't think it is possible to enable reading inputs. Consider
On Thu, Jan 08, 2009 at 09:01:54PM +, Leslie Newell wrote:
How is that handled currently?
( already in cutter comp mode )
N000 G0 X0 Y0
N100 G1 X1
N200 M66 P1 L0 (intended to say: immediately read digital input 1 to #5399)
N300 G1 Y[1-2*#5399] ( so this line either goes to Y1 or
Fair enough for exact stop but what about CV? It would potentially try
to look ahead past the read.
Les
Jeff Epler wrote:
In 2.2, I believe emc would move directly to X1 Y0 and read the input.
If the resulting move on N300 creates a concave corner, then an error
occurs.
With chris's new
On Thu, Jan 08, 2009 at 09:26:39PM +, Leslie Newell wrote:
Fair enough for exact stop but what about CV? It would potentially try
to look ahead past the read.
No, I believe you'll find it exact-stops at that point.
Jeff
I thought that would probably be what happens. Presumably it also exact
stops to set an output?
Les
Jeff Epler wrote:
No, I believe you'll find it exact-stops at that point.
Jeff
--
Check out the new
Today I merged my cutter compensation work. The new algorithm
handles concave corners and is not picky about entry moves. The
old entry methods are still supported, as is any entry line longer
than the tool radius (as is customary).
I have tested many old working programs to make sure they run
On Wed, Jan 7, 2009 at 8:07 PM, Chris Radek ch...@timeguy.com wrote:
Today I merged my cutter compensation work. The new algorithm
handles concave corners and is not picky about entry moves. The
old entry methods are still supported, as is any entry line longer
than the tool radius (as is
Looks good. It would be nice if you could enable these:
reading/writing motion's digital/analog ins/outs
enabling/disabling feed/speed override
enabling/disabling adaptive feed
running user-defined m-codes
Thanks,
Les
Chris Radek wrote:
Today I merged my cutter compensation
20 matches
Mail list logo
