On Fri, 29 Jul 2011 08:53:57 -0400, you wrote:
I loaded this into a 2.4 system that I use to test Gcode. It ran just
like my other programs run.This system is not hooked up to any
motors at the moment, but I don't see anything abnormal.
Does the velocity shown on the display drop off when
On Saturday, July 30, 2011 11:21:40 AM Steve Blackmore did opine:
On Fri, 29 Jul 2011 15:31:49 -0500, you wrote:
All,
I have a dual boot computer configured with both Windows/Mach and
Linux/EMC2.4.6. I ran Steve's code on both systems and the problem
that he describes is evident when
Steve Blackmore wrote:
Thanks for testing - Looks like you found it, it does appear to be some
trajectory planner bug on transition from lines to curves/curves to
lines.
I tested the code on some mdf, I'm glad it was only a test and not an
expensive piece of wood, the cutter left burn
On Sat, 30 Jul 2011 11:12:54 -0500, you wrote:
Steve Blackmore wrote:
Thanks for testing - Looks like you found it, it does appear to be some
trajectory planner bug on transition from lines to curves/curves to
lines.
I tested the code on some mdf, I'm glad it was only a test and not an
I remember that the developers at one point changed the way g64px.xxx worked so
that it actually converted arcs to short line segments so the combining of line
segments worked for the arcs also.
but that is just a vauge recolection.
sam
On Sat, 30 Jul 2011 19:12:52 +0100
Steve Blackmore
Steve Blackmore wrote:
Further testing would be helpful to see if it's only stepper systems or
that servo systems see the same slow downs.
The burning problem is because the spindle speed and feed are optimised
for cutting at 3200 mm/min as per cutter manufacturers spec. (It's an
8mm
On Sat, 30 Jul 2011 13:30:25 -0500, you wrote:
I remember that the developers at one point changed the way g64px.xxx worked
so that it actually converted arcs to short line segments so the combining of
line segments worked for the arcs also.
but that is just a vauge recolection.
An odd
Steve,
I loaded this into a 2.4 system that I use to test Gcode. It ran just
like my other programs run.This system is not hooked up to any
motors at the moment, but I don't see anything abnormal.
Does the velocity shown on the display drop off when it almost stops
at the end of each
All,
I have a dual boot computer configured with both Windows/Mach and
Linux/EMC2.4.6. I ran Steve's code on both systems and the problem that he
describes is evident when running the code on EMC, but not on Mach.
To answer Jon's question:
Does it start out running well, but then the
On Wed, 27 Jul 2011 10:05:48 -0500, you wrote:
maybe a short sample of gcode that you see causing problems?
Here you go Sam
Code only gets smooth when line
N190 G64 P0.5
half a mm is way too far off, especially when Mach seems to be able to
do easily it at 0.1mm deviation, which I can live
On Tue, 26 Jul 2011 20:50:59 -0500, you wrote:
I do not think anything had changed between 2.3 and 2.4...
I can try to explain how I understand it. Emc only takes into account
the next line segment when blending moves.
Strait g64 tries to go as fast as it can while still touching every line
Steve Blackmore wrote:
Hi Sam - it's set to 600, tried more but it didn't help. It was
accelerating and decelerating faster, but still almost coming to a stop
before next move.
Does it start out running well, but then the slowdown develops later in
the part program?
It could be queue
On Tue, 26 Jul 2011 03:02:35 +0100, you wrote:
See http://wiki.linuxcnc.org/emcinfo.pl?TrajectoryControl for explanation
As discussed on the page you can use the exact path mode
so it goes to the full extents.
but it probably means your acceleration times need looking at.
Hi Dave, I came across
I do not think anything had changed between 2.3 and 2.4...
I can try to explain how I understand it. Emc only takes into account
the next line segment when blending moves.
Strait g64 tries to go as fast as it can while still touching every line
segment.
G64Px. combines sections of line
On 7/26/2011 6:11 PM, Steve Blackmore wrote:
On Tue, 26 Jul 2011 03:02:35 +0100, you wrote:
See http://wiki.linuxcnc.org/emcinfo.pl?TrajectoryControl for explanation
As discussed on the page you can use the exact path mode
so it goes to the full extents.
but it probably means your
Hi all,
We were diagnosing a Z-axis missing-steps issue, and noticed something
interesting ... in the midst of this, we wrote some quick G-code to
cycle the Z-axis up and down 10 times, and noticed that as we
increased the speed, the Z-axis did not actually travel all the way to
the top
See http://wiki.linuxcnc.org/emcinfo.pl?TrajectoryControl for explanation
As discussed on the page you can use the exact path mode
so it goes to the full extents.
but it probably means your acceleration times need looking at.
Dave Caroline
On Tue, Jul 26, 2011 at 2:53 AM, Neil
17 matches
Mail list logo
