as well use it and fix the clients instead
of creating a new architecture and associated bugs that will come with it.
just my 2 cents worth...
Bruno
On 10/20/14 11:22 AM, bruno wrote:
> On 10/20/14 11:00 AM, emc-developers-requ...@lists.sourceforge.net wr
intersect ? I mean that if there are two nurbs in sequence, the
offseting might not give a continuous curve.
Bruno
On 6/3/14 1:40 PM, emc-developers-requ...@lists.sourceforge.net wrote:
> Date: Mon, 2 Jun 2014 13:34:56 -0500
> From: Chris Radek
> Subject: Re: [Emc-developers] bug with nur
of course I meant that point 2's weight is vastly different from 1 and 3...
anyway, I am most interested now in finding a solution to the tool path
compensation not working with nurbs.
Bruno
On 6/2/14 7:06 PM, emc-developers-requ...@lists.sourceforge.net wrote:
> Message: 8
> Date:
this is handled ? Maybe I could
take a stab at implementing that...
Cheers
Bruno
Hi Bruno,
Investigating this led me to find and fix several bugs in the NURBS
implementation, which will give you a MUCH smoother wrong path when
you run your test program.
But that aside, you are seeing a
good to know.
Did you try the simplified gcode I sent to the list ? would be good to
know if you see the same thing there.
Is there a way to test on a recent sim build including the new planner,
etc. ?
On 6/1/14 1:10 AM, emc-developers-requ...@lists.sourceforge.net wrote:
> Date: Fri, 30 May 201
. Previewed path looks good, actual path followed does not come
close
Any other suggestions ?
Can somebody tris this program on the sim or a real machine ?
Thanks,
Bruno
On 5/31/14 8:20 AM, bruno wrote:
> Here is a much simplified test program using the values output from my
> routines an
trajectory is still completely wrong and goes way off to the
side. Same as on the sim.
Bruno
;;;
;
# = 5
( some init )
G21 (Unit in mm)
G90 (Absolute distance mode)
;G64 P0.005 (Exact Path 0.001 tol.)
G61
G17
G40 (Cancel diameter comp.)
G49 (Cancel length comp.)
G54
G0 X0
that it is), but G61, G64 should affect it in
this case. Really at a loss on this one.
On 5/30/14 8:03 PM, emc-developers-requ...@lists.sourceforge.net wrote:
>> Thanks !
>> >Bruno
>> >
> At first glance it looks like the machine aceleration limits are not being
> fo
velopers
> Message-ID:<5388c3ea.8060...@empirescreen.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> could you pastebin the program? running through the list really hacked
> up the gcode...
>
> sam
> On 05/30/2014 10:29 AM, bruno wrote:
>> >
on their setup ? Is there an explanation for this ?
Thanks !
Bruno
Here is the test program
;;
;
# = 5
( some init )
G21 (Unit in mm)
G90 (Absolute distance mode)
G64 P0.01 (Exact Path 0.001 tol.)
G17
G40 (Cancel diameter comp.)
G49 (Cancel length comp.)
G54
G0 X0 Y0 Z0
Subject: Re: [Emc-developers] bug with pncconf
> To: emc-developers@lists.sourceforge.net
> Message-ID: <5342a802.20...@gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 4/7/2014 5:48 AM, bruno wrote:
> > Traceback (most recent cal
am not stuck. But I think this should be looked at by the pncconf developer.
Thanks !
Bruno
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test &am
ed for the project above...
Bruno
On 2/13/14 4:01 PM, emc-developers-requ...@lists.sourceforge.net wrote:
> Date: Wed, 12 Feb 2014 14:19:45 -0600
> From: Charles Steinkuehler
> Subject: Re: [Emc-developers] usage of get_rtapi_config on machinekit?
> To: EMC developers
>
procedure to follow to build
everything, that would be very appreciated, thanks
Bruno
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the
Glad you can reproduce the error !
Obviously it is important to fix linuxcnc, but do you think the gcode
generated by qpocket is also a little too close to an edge case
(programatically and also geometrically :-) )
I mean in the example I gave, if you disable path compensation, the
entry seems
I am using the 2.5.3 sim from
http://www.linuxcnc.org/lucid/dists/lucid/linuxcnc2.5-sim/binary-i386/
and the default axis mm setup from
config/sim/axis/axis_mm.ini
>
> --
>
> Message: 1
> Date: Sun, 26 Jan 2014 19:13:59 + (UT
I am using a mm setup and I was not able to get any combination of
delta, depth, mill size, or pocket size to work after many attempts.
Thus, I figured this was just broken and commented out.
here is an example, using a 10mm diameter mill
o call
[5][1000][2][300][5][2.5][0.2][0][-30][-30][-30]
it just looks like the generated path is wrong. If someone
could give an example of use of qpocket.ngc that works with path
compensation enabled, that will cetainly help me a lot...
On 1/26/14 5:45 PM, bruno wrote:
> On 1/26/14 5:28 PM, emc-developers-requ...@lists.sourceforge.net wrote:
>
On 1/26/14 5:28 PM, emc-developers-requ...@lists.sourceforge.net wrote:
> Send Emc-developers mailing list submissions to
>
> --
>
> Message: 5
> Date: Sun, 26 Jan 2014 13:24:21 + (UTC)
> From: Dewey Garrett
> Subject: Re: [Emc-developers] ngcgui cutter path compens
Hi all,
I started playing with ngcgui which seemed to fit very well for a
project I have, however I noticed that cutter path compensation (g42,
g41) is commented out, for example in qpocket.ngc. Even if one where to
use the code as-is and compensate the pocket size by the cutter radius,
the cu
20 matches
Mail list logo
