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?
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
Ma
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, ha
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 t
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".
I suppose you sent a ssh public key as described here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?DeveloperAccess
Regards,
Alex
- Original Message -
From: "paul_c"
To: "Enhanced Machine Controller (EMC)"
Sent: Sunday, January 11, 2009 12:37 PM
Subject: Re: [E
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".
---
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
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.
My vote would be for 2 as well. However blended moves by definition are
inaccurate so a slight timing inaccuracy is probably unimportant.
Assuming the machine has sensible acceleration, 1 and 3 should be close
enough together for it to make little difference. I suppose for my
plasma example the
n to enable
the output.
Just some thought to keep the discussion going..
Regards,
Alex
- Original Message -
From: "Leslie Newell"
To: "Enhanced Machine Controller (EMC)"
Sent: Friday, January 09, 2009 12:49 AM
Subject: Re: [Emc-users] New cutter compensation algo
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 SourceFor
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
---
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 ne
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
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 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 G
> 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!
The timing is actually great. I'
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 w
On Wed, Jan 7, 2009 at 8:07 PM, Chris Radek 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 customary).
>
>
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
e
21 matches
Mail list logo
