On Fri, Mar 21, 2014 at 12:32 PM, Bertho Stultiens ber...@vagrearg.orgwrote:
On 03/21/2014 05:05 PM, sam sokolik wrote:
heh - isn't that how we all dress?
That depends on how many lumps still hang together on my coat. It has
some signs of wear and tear.
You do realize a pocket protector
On Thu, Mar 20, 2014 at 1:43 PM, sam sokolik sa...@empirescreen.com wrote:
like...
http://electronicsam.com/images/KandT/oldkandt.JPG
well - it could do the velocity.. but the acceleration is set pretty
safe (not too many spare parts.) iirc 10in/sec^2 or something like that.
sam
Sam,
heh - isn't that how we all dress?
I had to post some scopes of the torodal gcode.
The new tp - strait G64
http://imagebin.org/300857
xyz - velocity gets to the programmed speed (aprox 1.96in/s - 3000mm/min)
x acc, y acc. nice sin/cos graphs. sexy! (yes - I think it is sexy...)
current tp -
On 03/21/2014 05:05 PM, sam sokolik wrote:
heh - isn't that how we all dress?
That depends on how many lumps still hang together on my coat. It has
some signs of wear and tear.
I had to post some scopes of the torodal gcode.
The new tp - strait G64
http://imagebin.org/300857
xyz - velocity
I was wondering how I could check that.. I don't know - but I can tell
you this..
At G64p.002q0
P is in mm and my config. 30in/s^2 and 500ipm per axis..
the velocity just starts to dip - just wiggles between 3000 and
2999mm/min. If I do p.001q0 it fluxuates around 2200mm/min. The
On 03/21/2014 07:06 PM, sam sokolik wrote:
I was wondering how I could check that.. I don't know - but I can tell
you this..
At G64p.002q0
P is in mm and my config. 30in/s^2 and 500ipm per axis..
the velocity just starts to dip - just wiggles between 3000 and
2999mm/min. If I do p.001q0
there is a limitation of 'too short' Rob explained it in a dev email
(discusing the Q part of G64)..
Unfortunately, the new TP still has the restriction that you have to touch
each segment at least once. A small NCD tolerance is still useful to
combine stupidly short segments, in
On 03/21/2014 07:43 PM, sam sokolik wrote:
there is a limitation of 'too short' Rob explained it in a dev email
(discusing the Q part of G64)..
Unfortunately, the new TP still has the restriction that you have to touch
each segment at least once. A small NCD tolerance is still
some more random paths running the circular arc blend rc3...
Playing around with
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Oword#Sample_3_loops_math_example_spirograph
P64Q.005
Current TP 6min 33s
http://imagebin.org/300518
Plot of velocity. (peaks at about 180ipm)
http://imagebin.org/300515
On 03/20/2014 01:28 PM, sam sokolik wrote:
some more random paths running the circular arc blend rc3...
I just tested trochoidal milling using the example I created for gcmc:
- image: http://www.vagrearg.org/gcmc/example-trochoidal-large.png
- source:
Could you post that gcode somewhere? (I don't have time right now to
play with your cool scripting language..) It could be the centripetal
accel limits of the spirals..
sam
On 3/20/2014 8:29 AM, Bertho Stultiens wrote:
On 03/20/2014 01:28 PM, sam sokolik wrote:
some more random paths
On 03/20/2014 02:38 PM, sam sokolik wrote:
Could you post that gcode somewhere? (I don't have time right now to
play with your cool scripting language..) It could be the
centripetal accel limits of the spirals..
Yes, I also suspect the centripetal accel limits may be a problem here.
You can
with my setup of 30in/s^2 - I get 3000mm/m (cool) the current TP peaks
at about 600-700mm/s
http://imagebin.org/300539
sam
On 3/20/2014 8:46 AM, Bertho Stultiens wrote:
On 03/20/2014 02:38 PM, sam sokolik wrote:
Could you post that gcode somewhere? (I don't have time right now to
play
On 03/20/2014 02:46 PM, Bertho Stultiens wrote:
On 03/20/2014 02:38 PM, sam sokolik wrote:
Could you post that gcode somewhere? (I don't have time right now to
play with your cool scripting language..) It could be the
centripetal accel limits of the spirals..
Yes, I also suspect the
On 03/20/2014 03:19 PM, sam sokolik wrote:
the limit of sim is 1800mm/m - so if you change all the axis velocities
to 58mm/s (3500mm/m) it peaks at 2900mm/min. Upping the acceleration to
1000mm/s^2 makes the program run at 3000mm/m steady.
Indeed, with that setup the trochoidal path will be
like...
http://electronicsam.com/images/KandT/oldkandt.JPG
well - it could do the velocity.. but the acceleration is set pretty
safe (not too many spare parts.) iirc 10in/sec^2 or something like that.
sam
On 3/20/2014 9:44 AM, Bertho Stultiens wrote:
On 03/20/2014 03:19 PM, sam sokolik wrote:
For anyone who wants to experiment with settings for trochoidal
milling, there is now an adapted version of Bertho's program for
git master for use with [py]ngcgui:
nc_files/gcmc_lib/trochoid-path.gcmc
The routine is included by default as a tab in several sim
configurations for gcmc usage.
Hey Sam;
How does it the improved look ahead compare on the chips 3d NGC sample file?
Greg
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how
running it as fast as it could go - feedrate set to way more than the
config would allow (config is 500ipm 30in/sec^2)
While the penguin - (metric so .1 is about .004)
parabolic blend (old)P.1=2:21 Strait G64=4:12
circular blend (new) P.1=1:41 Strait G64=2:27
this was from a
Here is a crappy video showing the difference (first run is current TP -
second run is Roberts hard work)
https://www.youtube.com/watch?v=oUajH5BCOUQfeature=youtu.be
spiral is made up of short line segments. The current tp has to be able
to stop by the end of the next segment so it peaks at
Looking forward to trying this out.
- Original Message -
From: sam sokolik sa...@empirescreen.com
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Sent: Tuesday, December 17, 2013 3:10:46 PM
Subject: Re: [Emc-users] Slow G code
Here is a crappy video showing
Rob;
On Fri, Dec 13, 2013 at 1:51 PM, Robert Ellenberg rwe...@gmail.com wrote:
I spent some time going through the math behind it, and I think blending
between linear moves with ABCUVW motion is feasible, though it will take a
a bunch of new data structures to store a 9D vector.
There are
On 12/16/2013 01:02 PM, John Alexander Stewart wrote:
It's been a while since I wrote SLERPing code, but the project I wrote it
for used Quaternions, which I don't think LinuxCNC uses?? Quaternions
certainly made a lot of the internal maths easier. (code was in the
FreeWRL VRML/X3D browser)
On 12/16/2013 01:43 PM, Kent A. Reed wrote:
On 12/16/2013 01:02 PM, John Alexander Stewart wrote:
It's been a while since I wrote SLERPing code, but the project I wrote it
for used Quaternions, which I don't think LinuxCNC uses?? Quaternions
certainly made a lot of the internal maths easier.
I spent some time going through the math behind it, and I think blending
between linear moves with ABCUVW motion is feasible, though it will take a
a bunch of new data structures to store a 9D vector.
There are two big challenges to making this work. The first is implementing
a new way to
On 13 December 2013 18:51, Robert Ellenberg rwe...@gmail.com wrote:
I spent some time going through the math behind it, and I think blending
between linear moves with ABCUVW motion is feasible,
One big problem is that G-code has no way to define the location of
centres of rotation.
(I don't
That's a good point: the radius affects the tool path error in a way that
we can't predict from G-code alone. It would be straightforward to do G64
with no tolerance, though, but I don't know how useful a
half-implementation like that would be.
On Fri, Dec 13, 2013 at 2:59 PM, andy pugh
Rob:
a axis is along x, config is simple, just have to edit GEOMETRY =
-AXYBC in ini file.
i will send you a link sharing a folder in goog drive, theres config
files and some sample gcode, just let me know if you can se it!
theres no way i could run it smoothly, blending in rot axis is a must!
Hi Robert,
Im very interested in this too, are you trying to solve slow gcode or
smooth movement? or both?
one problems i find doing a filament winder, linear X and rot A, was
the lack of blending between them. Also the diferent interpretation of
feed between linear and angular (regular feed or
On Mon, Dec 9, 2013 at 1:04 PM, Ricardo Moscoloni rmoscol...@gmail.comwrote:
Hi Robert,
Im very interested in this too, are you trying to solve slow gcode or
smooth movement? or both?
I'm mostly trying to improve the speed of programs with small segments, but
part of that effort has improved
That is huge! Excellent work.
Dave
On 12/5/2013 11:10 PM, sam sokolik wrote:
Robert has been working very hard on the new TP.
Here is an example
This program I found on the internet. (small line segments)
http://electronicsam.com/images/KandT/testing/internet.ngc
533228 line program
Very nice to hear someone is working on that, I can provide you some complex 3
and 5-axis code generated from NX (siemens unigraphics), and I can also test it
on my machine to check for improvements...
If you want, I can send you a this code I used for this test mill of
On Dec 6, 2013 5:53 PM, Tomaz T. tomaz_...@hotmail.com wrote:
Very nice to hear someone is working on that, I can provide you some
complex 3 and 5-axis code generated from NX (siemens unigraphics), and I
can also test it on my machine to check for improvements...
If you want, I can send you a
On 12/06/2013 01:46 AM, Robert Ellenberg wrote:
As some of you know already, I'm working on an improvement to the linuxcnc
trajectory planner that will allow much faster movement for engraving-type
programs with lots of short segments. As part of this effort, I need test
cases, both to find
On Thu, Dec 5, 2013 at 8:20 PM, Bertho Stultiens ber...@vagrearg.orgwrote:
You could use the wheels.gcmc example from gcmc (contributed by Alan
Battersby). It creates a lot of small segments of 10..100um. You can
even increase the number of segments by decreasing the angle-interval of
the
On 12/06/2013 02:37 AM, Robert Ellenberg wrote:
You could use the wheels.gcmc example from gcmc (contributed by Alan
Battersby). It creates a lot of small segments of 10..100um. You can
even increase the number of segments by decreasing the angle-interval of
the calculation (currently at 0.01
On Dec 5, 2013 8:52 PM, Bertho Stultiens ber...@vagrearg.org wrote:
On 12/06/2013 02:37 AM, Robert Ellenberg wrote:
You could use the wheels.gcmc example from gcmc (contributed by Alan
Battersby). It creates a lot of small segments of 10..100um. You can
even increase the number of segments
Robert has been working very hard on the new TP.
Here is an example
This program I found on the internet. (small line segments)
http://electronicsam.com/images/KandT/testing/internet.ngc
533228 line program running G64P.005
Old TP 2:37:42
New TP 1:38:49
Quite an improvement!!
The
: Robert Ellenberg rwe...@gmail.com
To: Enhanced Machine Controller, (EMC) emc-users@lists.sourceforge.net
Sent: Thursday, December 5, 2013 9:06:47 PM
Subject: Re: [Emc-users] Slow G code
On Dec 5, 2013 8:52 PM, Bertho Stultiens ber...@vagrearg.org wrote:
On 12/06/2013 02:37 AM, Robert Ellenberg
On Thu, Dec 5, 2013 at 11:57 PM, Todd Zuercher zuerc...@embarqmail.comwrote:
Glad to hear your making progress. Might your modifications work with
more than XYZ axis. (I need to run it on 4 axis xyzw.)
It will be compatible with 4+ axes, but most of the improvement will be for
XYZ moves
40 matches
Mail list logo
