Re: [Emc-users] Slow G code (sam sokolik)
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 and slide rule are required items of haute couture with that getup. -- Greetings Bertho Cheers, Mark -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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, Yer lookin' mighty spiffy in that lab coat. Mark -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 - same config - G64 http://imagebin.org/300858 velocity peaks at almost .5in/sec - about 760mm/min current tp - same config G64Q.1 (combine segments that diviate less than .1mm) http://imagebin.org/300859 velocity averages around 1in/sec - about 1500mm/min Again and again - Rob - awesome work. (and as with anything linuxcnc - only gets better) sam On 03/21/2014 04:08 AM, Mark Wendt wrote: 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, Yer lookin' mighty spiffy in that lab coat. Mark -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 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...) Ah yes, for trochoidal curves the accelerations of X and Y should be exactly sinusoidal. The first derivative (velocity) should show a static offset on the sinusoidal curves, which represents the direction of motion. Do you have a measurement of what the magnitude of path-deviation is from the programmed path? The path deviations may also be slightly reduced when the trochoidal path is generated with higher resolution (smaller angular step interval in the calculation). -- Greetings Bertho (disclaimers are disclaimed) -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 accelleration graph looks a but harry at that thoug though.. (wipping around to try to keep up the path tolerance and velocity up..) this is p.002q0 http://imagebin.org/300880 this is with a sane-ish p.01q0 http://imagebin.org/300881 so with the path programmed - it can follow at cutting speed with tollerances below what is sane... (with that config) sam On 03/21/2014 11:32 AM, Bertho Stultiens wrote: 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 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...) Ah yes, for trochoidal curves the accelerations of X and Y should be exactly sinusoidal. The first derivative (velocity) should show a static offset on the sinusoidal curves, which represents the direction of motion. Do you have a measurement of what the magnitude of path-deviation is from the programmed path? The path deviations may also be slightly reduced when the trochoidal path is generated with higher resolution (smaller angular step interval in the calculation). -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 it fluxuates around 2200mm/min. The accelleration graph looks a but harry at that thoug though.. (wipping around to try to keep up the path tolerance and velocity up..) [snip] so with the path programmed - it can follow at cutting speed with tollerances below what is sane... (with that config) That looks pretty impressive to follow within 50 micrometer. I prepared a few versions of the same patters. Each with a different angular interval to generate the curve from 10deg...0.2deg steps. That results in linear segments with lengths from ~0.75mm to ~0.01mm. http://media.vagrearg.org/gcmc/trochoidal-steps.tar.gz I wonder if the smallest angular interval would improve the following and where the breakdown occurs. -- Greetings Bertho (disclaimers are disclaimed) -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 particular ones that would be skipped over in a single cycle of the trajectory planner. A quick theoretical example: If we want to follow a path at 60 IPM (1 IPS), with a servo rate of 1kHz, then a segment that is shorter than 0.001 could be skipped entirely during a single cycle update. Therefore, an NCD tolerance of roughly 0.001 would eliminate these very short segments, letting the TP maintain the desired speed. Given this benefit, I don't think we can totally eliminate it. However, since the tolerance can be much smaller than the blend tolerance and still work well, it seems to me like another argument to decouple them. -Rob sam On 03/21/2014 01:31 PM, Bertho Stultiens wrote: 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 it fluxuates around 2200mm/min. The accelleration graph looks a but harry at that thoug though.. (wipping around to try to keep up the path tolerance and velocity up..) [snip] so with the path programmed - it can follow at cutting speed with tollerances below what is sane... (with that config) That looks pretty impressive to follow within 50 micrometer. I prepared a few versions of the same patters. Each with a different angular interval to generate the curve from 10deg...0.2deg steps. That results in linear segments with lengths from ~0.75mm to ~0.01mm. http://media.vagrearg.org/gcmc/trochoidal-steps.tar.gz I wonder if the smallest angular interval would improve the following and where the breakdown occurs. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 useful to combine stupidly short segments, in particular ones that would be skipped over in a single cycle of the trajectory planner. [snip] That explains the limits nicely, thanks. -- Greetings Bertho (disclaimers are disclaimed) -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 New TP 2min 9s http://imagebin.org/300517 Plot of velocity... (hits machine limit for most of the motion) http://imagebin.org/300516 Still having fun.. :) sam On 12/18/2013 8:56 PM, sam sokolik wrote: 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 while ago... there may have been improvements.. from my playing - around twice as fast for this configs. (for programs with lots of line segments) sam On 12/18/2013 05:41 PM, Greg Bentzinger wrote: 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 application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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: https://gitorious.org/gcmc/gcmc/source/example/trochoidal.gcmc Target: axis_mm simulator The runtime on 2.5.3: - trochoidal milling: 386s - total time: 482s Runtime on 2.6.0~pre, branch circular-blend-arc-rc3: - trochoidal milling: 110s - total time: 205s LinuxCNC reports the runtime at 2.7min (162s). It is clear that the old LinuxCNC version cannot keep the speed high and wanders between 500..600mm/min. The code sets the speed for the trochoidal path at 3000mm/min. The effective speed is still not entirely up to the requested speed and seems to hover arround 1900mm/min. That may be due to the simulator setup (maybe acceleration limits?) or the arc-blending not looking ahead far enough. Still, a very impressive improvement. -- Greetings Bertho (disclaimers are disclaimed) -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 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: https://gitorious.org/gcmc/gcmc/source/example/trochoidal.gcmc Target: axis_mm simulator The runtime on 2.5.3: - trochoidal milling: 386s - total time: 482s Runtime on 2.6.0~pre, branch circular-blend-arc-rc3: - trochoidal milling: 110s - total time: 205s LinuxCNC reports the runtime at 2.7min (162s). It is clear that the old LinuxCNC version cannot keep the speed high and wanders between 500..600mm/min. The code sets the speed for the trochoidal path at 3000mm/min. The effective speed is still not entirely up to the requested speed and seems to hover arround 1900mm/min. That may be due to the simulator setup (maybe acceleration limits?) or the arc-blending not looking ahead far enough. Still, a very impressive improvement. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 get the gcode here: http://www.vagrearg.org/gcmc/trochoidal.ngc.gz -- Greetings Bertho (disclaimers are disclaimed) -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 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 get the gcode here: http://www.vagrearg.org/gcmc/trochoidal.ngc.gz -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 centripetal accel limits may be a problem here. You can get the gcode here: http://www.vagrearg.org/gcmc/trochoidal.ngc.gz I just set the axis accelerations in the INI file from 508 to 1000, but the result is the same. Actual result is 109s vs. 110s, which is within the tolerance of my eye-on-the-clock timing. This is where my expertise end ;-) -- Greetings Bertho (disclaimers are disclaimed) -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 finished in ~73s and the total time ~168s. Also, LinuxCNC's runtime calculation of 2.7min will finally be correct for all practical purposes and intents. with my setup of 30in/s^2 - I get 3000mm/m (cool) the current TP peaks at about 600-700mm/s It works :-) However, if you are going to do trochoidal milling at those speeds, then you better make sure that you have one of those machines that weighs too much and is bolted securely or it will start dancing in the room. Great work! keep it up. -- Greetings Bertho (disclaimers are disclaimed) -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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: 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 finished in ~73s and the total time ~168s. Also, LinuxCNC's runtime calculation of 2.7min will finally be correct for all practical purposes and intents. with my setup of 30in/s^2 - I get 3000mm/m (cool) the current TP peaks at about 600-700mm/s It works :-) However, if you are going to do trochoidal milling at those speeds, then you better make sure that you have one of those machines that weighs too much and is bolted securely or it will start dancing in the room. Great work! keep it up. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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. An independent install of gcmc (v=1.5.1) is required. Debs are (or will be soon) available from the buildbot. Thanks Bertho! -- Dewey Garrett -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code (sam sokolik)
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 while ago... there may have been improvements.. from my playing - around twice as fast for this configs. (for programs with lots of line segments) sam On 12/18/2013 05:41 PM, Greg Bentzinger wrote: 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 application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 about 110ipm. The new TP can look 40 segments ahead. (that will be a configurable in the future..) and peaks at about 410ipm. Current status as I understand it. Read ahead works if segment transitions are -Line-Line -Tangent line-arc, arc-line -Tangent arc-arc Darn impressive. Great work Robert! sam On 12/16/2013 12: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. (code was in the FreeWRL VRML/X3D browser) *Does* LinuxCNC use Quaternions? Well, that depends on your meaning of the word use. If you look at the libnml/posemath/ routines you'll see a lot of internal usage of quarternions for the reason you name but most calls to the routines from the rest of LinuxCNC consist of customary and usual representations. What representations? Well, consider this snippet from posemath.h - /* translation types */ struct PM_CARTESIAN;/* Cart */ struct PM_SPHERICAL;/* Sph */ struct PM_CYLINDRICAL;/* Cyl */ /* rotation types */ struct PM_ROTATION_VECTOR;/* Rot */ struct PM_ROTATION_MATRIX;/* Mat */ struct PM_QUATERNION;/* Quat */ struct PM_EULER_ZYZ;/* Zyz */ struct PM_EULER_ZYX;/* Zyx */ struct PM_RPY;/* Rpy */ /* pose types */ struct PM_POSE;/* Pose */ struct PM_HOMOGENEOUS;/* Hom */ - You can browse the source code itself but it's faster to read the nearly 15-year old document http://www.isd.mel.nist.gov/projects/rcslib/posemath_examples.html Regards, Kent -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 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 about 110ipm. The new TP can look 40 segments ahead. (that will be a configurable in the future..) and peaks at about 410ipm. Current status as I understand it. Read ahead works if segment transitions are -Line-Line -Tangent line-arc, arc-line -Tangent arc-arc Darn impressive. Great work Robert! sam On 12/16/2013 12: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. (code was in the FreeWRL VRML/X3D browser) *Does* LinuxCNC use Quaternions? Well, that depends on your meaning of the word use. If you look at the libnml/posemath/ routines you'll see a lot of internal usage of quarternions for the reason you name but most calls to the routines from the rest of LinuxCNC consist of customary and usual representations. What representations? Well, consider this snippet from posemath.h - /* translation types */ struct PM_CARTESIAN;/* Cart */ struct PM_SPHERICAL;/* Sph */ struct PM_CYLINDRICAL;/* Cyl */ /* rotation types */ struct PM_ROTATION_VECTOR;/* Rot */ struct PM_ROTATION_MATRIX;/* Mat */ struct PM_QUATERNION;/* Quat */ struct PM_EULER_ZYZ;/* Zyz */ struct PM_EULER_ZYX;/* Zyx */ struct PM_RPY;/* Rpy */ /* pose types */ struct PM_POSE;/* Pose */ struct PM_HOMOGENEOUS;/* Hom */ - You can browse the source code itself but it's faster to read the nearly 15-year old document http://www.isd.mel.nist.gov/projects/rcslib/posemath_examples.html Regards, Kent -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 two big challenges to making this work. The first is implementing a new way to interpolate along a spherical arc (SLERP), since we won't have a normal vector…. 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) *Does* LinuxCNC use Quaternions? John A. Stewart. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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) *Does* LinuxCNC use Quaternions? Well, that depends on your meaning of the word use. If you look at the libnml/posemath/ routines you'll see a lot of internal usage of quarternions for the reason you name but most calls to the routines from the rest of LinuxCNC consist of customary and usual representations. What representations? Well, consider this snippet from posemath.h - /* translation types */ struct PM_CARTESIAN;/* Cart */ struct PM_SPHERICAL;/* Sph */ struct PM_CYLINDRICAL;/* Cyl */ /* rotation types */ struct PM_ROTATION_VECTOR;/* Rot */ struct PM_ROTATION_MATRIX;/* Mat */ struct PM_QUATERNION;/* Quat */ struct PM_EULER_ZYZ;/* Zyz */ struct PM_EULER_ZYX;/* Zyx */ struct PM_RPY;/* Rpy */ /* pose types */ struct PM_POSE;/* Pose */ struct PM_HOMOGENEOUS;/* Hom */ - You can browse the source code itself but it's faster to read the nearly 15-year old document http://www.isd.mel.nist.gov/projects/rcslib/posemath_examples.html Regards, Kent -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code - addendum
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. (code was in the FreeWRL VRML/X3D browser) *Does* LinuxCNC use Quaternions? Well, that depends on your meaning of the word use. If you look at the libnml/posemath/ routines you'll see a lot of internal usage of quarternions for the reason you name but most calls to the routines from the rest of LinuxCNC consist of customary and usual representations. What representations? Well, consider this snippet from posemath.h By the way, some of the less ordinary posemath operations defined in the header file remained stubbed out in the actual code. Invoking them should solicit a PM_IMPL_ERR error not implemented. Occasionally a new user discovers this the hard way. I suppose one could think of these missing operations as a possible homework assignment. Regards, Kent -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 interpolate along a spherical arc (SLERP), since we won't have a normal vector. The second is that tolerances become very hard to enforce with rotary movement. A small displacement in an ABC axis can mean a large tool displacement, and there it would likely be tough to predict this if TP treats all joints as independent and linear. Of course, we can simply have the algorithm abort if we ask for a tolerance, so this isn't a total deal-breaker. -Rob On Wed, Dec 11, 2013 at 11:20 AM, Ricardo Moscoloni rmoscol...@gmail.comwrote: 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! there is a way to implement it? could you expand the need of non trivial kinematics in this case?, seems trivial to me. Regards rick 2013/12/9 Robert Ellenberg rwe...@gmail.com: On Mon, Dec 9, 2013 at 1:04 PM, Ricardo Moscoloni rmoscol...@gmail.com wrote: 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 the smoothness as well. The smoothness comes from a higher average speed, which means fewer dips in velocity due to short segments. I added an additional check that reduces velocity ripple in programs with short, similar-length segments. one problems i find doing a filament winder, linear X and rot A, was the lack of blending between them. Also the different interpretation of feed between linear and angular (regular feed or non inverse time feed rate) cause trouble, when a move changes from linear to angular. My work so far has just been cartesian motion in XYZ, so the current set of changes may not help with A axis blends. I'm interested in expanding this to cover additional axes, but it's not as straightforward due to the non-trivial kinematics. Can you tell me more about the setup and motions you're using? For example, what orientation is your A axis? Can you send me an example machine config and G-code? Axis backplot draw the gcode correctly, and keeps me thinking in a manner to ensure constant surface speed doing blending based in tip point absolute spatial speed calculations but my lack of programming skills drop me. Im willing to help in whetever i cancould you explain more about your particular branch, i like to test it. Here is the current branch if you're interested in running it: https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-alpha In particular, I could use feedback on how this code runs with axis motion other than XYZ. It should gracefully fall back to parabolic blends, so any issues you can find with this would be very helpful. Thanks! -Rob -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net
Re: [Emc-users] Slow G code
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 know if that matters for your maths). It would not be at all unusual for Z=0 to be the surface of a cylindrical workpiece, rather than the axis. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 bodge...@gmail.com wrote: 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 know if that matters for your maths). It would not be at all unusual for Z=0 to be the surface of a cylindrical workpiece, rather than the axis. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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! there is a way to implement it? could you expand the need of non trivial kinematics in this case?, seems trivial to me. Regards rick 2013/12/9 Robert Ellenberg rwe...@gmail.com: 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 the smoothness as well. The smoothness comes from a higher average speed, which means fewer dips in velocity due to short segments. I added an additional check that reduces velocity ripple in programs with short, similar-length segments. one problems i find doing a filament winder, linear X and rot A, was the lack of blending between them. Also the different interpretation of feed between linear and angular (regular feed or non inverse time feed rate) cause trouble, when a move changes from linear to angular. My work so far has just been cartesian motion in XYZ, so the current set of changes may not help with A axis blends. I'm interested in expanding this to cover additional axes, but it's not as straightforward due to the non-trivial kinematics. Can you tell me more about the setup and motions you're using? For example, what orientation is your A axis? Can you send me an example machine config and G-code? Axis backplot draw the gcode correctly, and keeps me thinking in a manner to ensure constant surface speed doing blending based in tip point absolute spatial speed calculations but my lack of programming skills drop me. Im willing to help in whetever i cancould you explain more about your particular branch, i like to test it. Here is the current branch if you're interested in running it: https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-alpha In particular, I could use feedback on how this code runs with axis motion other than XYZ. It should gracefully fall back to parabolic blends, so any issues you can find with this would be very helpful. Thanks! -Rob -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 non inverse time feed rate) cause trouble, when a move changes from linear to angular. Axis backplot draw the gcode correctly, and keeps me thinking in a manner to ensure constant surface speed doing blending based in tip point absolute spatial speed calculations but my lack of programming skills drop me. Im willing to help in whetever i cancould you explain more about your particular branch, i like to test it. Regards Rick 2013/12/6 Robert Ellenberg rwe...@gmail.com: 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 this code I used for this test mill of turbine:http://www.youtube.com/watch?v=iy1Mb6G_VJ0 I'm definitely interested, in particular in the 5 axis code. I need to make sure that it handles motions on other axes properly. If you'd like to test the code, it's available on my github repository here: https://github.com/robEllenberg/linuxcnc-mirror The branch is circular-blend-arc-alpha. Thanks! If you'd like to contribute to this effort, I'm looking for G-code that runs slower than the requested feed rate. In particular, I'm looking for programs that have lots of short segments that approximate smooth paths. If you have a program that you think should run faster and are willing to share it, please email it to me. While my fixes won't improve every issue, part of my goal here is to survey how common some problems are. If it turns out that a slowdown I consider rare is common in your programs, it will justify some additional work in that direction. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 the smoothness as well. The smoothness comes from a higher average speed, which means fewer dips in velocity due to short segments. I added an additional check that reduces velocity ripple in programs with short, similar-length segments. one problems i find doing a filament winder, linear X and rot A, was the lack of blending between them. Also the different interpretation of feed between linear and angular (regular feed or non inverse time feed rate) cause trouble, when a move changes from linear to angular. My work so far has just been cartesian motion in XYZ, so the current set of changes may not help with A axis blends. I'm interested in expanding this to cover additional axes, but it's not as straightforward due to the non-trivial kinematics. Can you tell me more about the setup and motions you're using? For example, what orientation is your A axis? Can you send me an example machine config and G-code? Axis backplot draw the gcode correctly, and keeps me thinking in a manner to ensure constant surface speed doing blending based in tip point absolute spatial speed calculations but my lack of programming skills drop me. Im willing to help in whetever i cancould you explain more about your particular branch, i like to test it. Here is the current branch if you're interested in running it: https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-alpha In particular, I could use feedback on how this code runs with axis motion other than XYZ. It should gracefully fall back to parabolic blends, so any issues you can find with this would be very helpful. Thanks! -Rob -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 running G64P.005 Old TP 2:37:42 New TP 1:38:49 Quite an improvement!! The spiral.ngc program now starts at almost 400 ipm vs 110 ipm currently. There are some issues to work out yet - but as little time it has taken Robert to get this far - I don't think it will take long to get to a beta.. Using this config for testing http://electronicsam.com/images/KandT/testing/circblendlatest/ (500ipm max and 30in/sec^2 acc) sam On 12/05/2013 06:46 PM, Robert Ellenberg wrote: Hi All, 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 rare errors, and to estimate performance improvements. If you'd like to contribute to this effort, I'm looking for G-code that runs slower than the requested feed rate. In particular, I'm looking for programs that have lots of short segments that approximate smooth paths. If you have a program that you think should run faster and are willing to share it, please email it to me. While my fixes won't improve every issue, part of my goal here is to survey how common some problems are. If it turns out that a slowdown I consider rare is common in your programs, it will justify some additional work in that direction. Thanks! Rob -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 turbine:http://www.youtube.com/watch?v=iy1Mb6G_VJ0 If you'd like to contribute to this effort, I'm looking for G-code that runs slower than the requested feed rate. In particular, I'm looking for programs that have lots of short segments that approximate smooth paths. If you have a program that you think should run faster and are willing to share it, please email it to me. While my fixes won't improve every issue, part of my goal here is to survey how common some problems are. If it turns out that a slowdown I consider rare is common in your programs, it will justify some additional work in that direction. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 this code I used for this test mill of turbine:http://www.youtube.com/watch?v=iy1Mb6G_VJ0 I'm definitely interested, in particular in the 5 axis code. I need to make sure that it handles motions on other axes properly. If you'd like to test the code, it's available on my github repository here: https://github.com/robEllenberg/linuxcnc-mirror The branch is circular-blend-arc-alpha. Thanks! If you'd like to contribute to this effort, I'm looking for G-code that runs slower than the requested feed rate. In particular, I'm looking for programs that have lots of short segments that approximate smooth paths. If you have a program that you think should run faster and are willing to share it, please email it to me. While my fixes won't improve every issue, part of my goal here is to survey how common some problems are. If it turns out that a slowdown I consider rare is common in your programs, it will justify some additional work in that direction. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 rare errors, and to estimate performance improvements. 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 degrees). I am a bit reluctant to attach the file due to the size (1.1MByte uncompressed, 450k gzip, 380k bz2 and ~200k with 7-zip). You should easily be able to generate the example yourself. Otherwise let me know. -- Greetings Bertho (disclaimers are disclaimed) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 calculation (currently at 0.01 degrees). Thanks, Bertho, I'll give this a shot. By the way, I launched gcmc accidentally with no input, and it seemed to hang. Running with --help listed the arguments nicely, so you might want to treat no arguments the same as --help. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 degrees). Thanks, Bertho, I'll give this a shot. Great. By the way, I launched gcmc accidentally with no input, and it seemed to hang. Running with --help listed the arguments nicely, so you might want to treat no arguments the same as --help. Running gcmc with no file as input will read input from stdin (the command-line) as in good unix tradition. If you do not specify an output file (-o option) then all output is written to stdout. This is done so you can form command-chains with pipes on the command-line. The behavior is described in the man-page (http://www.vagrearg.org/content/gcmc-man). You can terminate with ^C (break) or ^D, which is EOF on *nix systems (or, if using windows, ^Z to indicate EOF). -- Greetings Bertho (disclaimers are disclaimed) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
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 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 degrees). Thanks, Bertho, I'll give this a shot. Great. By the way, I launched gcmc accidentally with no input, and it seemed to hang. Running with --help listed the arguments nicely, so you might want to treat no arguments the same as --help. Running gcmc with no file as input will read input from stdin (the command-line) as in good unix tradition. If you do not specify an output file (-o option) then all output is written to stdout. This is done so you can form command-chains with pipes on the command-line. The behavior is described in the man-page (http://www.vagrearg.org/content/gcmc-man). You can terminate with ^C (break) or ^D, which is EOF on *nix systems (or, if using windows, ^Z to indicate EOF). Ahh, I see, that's a clever feature! -- Greetings Bertho (disclaimers are disclaimed) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 spiral.ngc program now starts at almost 400 ipm vs 110 ipm currently. There are some issues to work out yet - but as little time it has taken Robert to get this far - I don't think it will take long to get to a beta.. Using this config for testing http://electronicsam.com/images/KandT/testing/circblendlatest/ (500ipm max and 30in/sec^2 acc) sam On 12/05/2013 06:46 PM, Robert Ellenberg wrote: Hi All, 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 rare errors, and to estimate performance improvements. If you'd like to contribute to this effort, I'm looking for G-code that runs slower than the requested feed rate. In particular, I'm looking for programs that have lots of short segments that approximate smooth paths. If you have a program that you think should run faster and are willing to share it, please email it to me. While my fixes won't improve every issue, part of my goal here is to survey how common some problems are. If it turns out that a slowdown I consider rare is common in your programs, it will justify some additional work in that direction. Thanks! Rob -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
Glad to hear your making progress. Might your modifications work with more than XYZ axis. (I need to run it on 4 axis xyzw.) Would it be ok to send the sample g-code directly to your email? If so I'll try to dig up some extra slow stuff tomorrow at work. - Original Message - From: 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 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 degrees). Thanks, Bertho, I'll give this a shot. Great. By the way, I launched gcmc accidentally with no input, and it seemed to hang. Running with --help listed the arguments nicely, so you might want to treat no arguments the same as --help. Running gcmc with no file as input will read input from stdin (the command-line) as in good unix tradition. If you do not specify an output file (-o option) then all output is written to stdout. This is done so you can form command-chains with pipes on the command-line. The behavior is described in the man-page (http://www.vagrearg.org/content/gcmc-man). You can terminate with ^C (break) or ^D, which is EOF on *nix systems (or, if using windows, ^Z to indicate EOF). Ahh, I see, that's a clever feature! -- Greetings Bertho (disclaimers are disclaimed) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
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 only. It falls back to simple parabolic blending if there's movement in the other 6 axes. Would it be ok to send the sample g-code directly to your email? If so I'll try to dig up some extra slow stuff tomorrow at work. Absolutely, that's a good way to avoid the attachment size limit. That's also my dropbox email address, so if you have dropbox and want to share a folder, that works too. Thanks! Rob -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
