Re: [Emc-developers] jepler/rtos-uspace: a new POSIX realtime branch
What is cool is I found the rt-preempt kernel from the synaptic package manager - installed it - built linuxcnc to use it. it just worked. (this was on wheezy) (I was testing the 7i80 ethernet device) http://electronicsam.com/images/KandT/testing/ethlatestbuild.png sam On 07/06/2014 08:58 AM, Jeff Epler wrote: Since it's been about a week, here are some incremental updates about uspace: There's now a wiki page, which covers how to obtain and build the branch: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Uspace The branch has been rebased several more times, squashing out bugs and adding a few new features. Some more important items: - the code taken from ubc3 for pci access actually had *two different* implementations. I removed the older one, leaving only the one needed for hostmot2. Other PCI drivers will have to adapt to the APIs used by hostmot2 if they are to run under uspace. While I was there, I believe I lifted the one board only limitation in that code, but I haven't been able to test it. - Realtime delays are detected and reported - new C and Python APIs report whether the RTOS runs in userspace or in kernel space - The parport detection/registration routines (hal_parport_get, now rtapi_parport_get) are implemented for uspace, so parport drivers can now be ported to uspace. Chris R. and Seb K. have both provided valuable code review. Peter W. and Sam K. have also done testing. And I've probably overlooked somebody--no slight is intended. The list of hardware that has been tested, at least briefly, has grown: mesa 5i20 (pci) mesa 5i25 (pci) mesa 7i43 (parallel port) parport serport .. and in fact, Chris and Seb each dared to run mills with the branch, at least briefly. Michał G.'s branch for mesa 7i80 (ethernet-attached hardware) works when rebased onto the uspace branch. However, it's not merge-ready, because it breaks all the traditional mesa cards. This is in the rtos-uspace-7i80 branch if you'd like to try it, but (see below) I won't be maintaining this branch at the moment. The delta compared to upstream is growing: 44 commits, 115 files changed, 4360 insertions(+), 3973 deletions(-) though, happily, the deletions grew much faster than the insertions, as I deleted an unnecessary copy of the hal_parport driver thta lived at src/hal/simdrivers. About 10% of insertions are in documentation. I've agreed informally with Seb that when the time comes to merge, I'll merge rtos-uspace-apis. As a result, I'm no longer going to separately maintain the rtos-uspace branch. Similarly, I'm not going to continue rebasing the rtos-uspace-7i80 branch. This streamlines my workflow and reduces the chance of mistakes. I'm not sure when this will be pushed to master branch, but not before Seb completes his code review and I address the issues he raises. I welcome code reviews, results of testing, and other comments from anyone on the list as well. There's a trivial merge conflict in src/Makefile, otherwise it merges cleanly. Jeff -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Comp
plus there is a hal component named comp... comp − Two input comparator with hysteresis sam On 6/24/2014 10:06 AM, Chris Radek wrote: On Tue, Jun 24, 2014 at 02:46:50PM +0100, andy pugh wrote: The program 'comp' can be found in the following packages mailutils-mh nmh in the obvious way. Maybe we should rename it? It's not a particularly good or descriptive name. halcompile? -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] TP issue with exact stop and slow machine acceleration
wow - The little bit of playing seems to fixed the bugs (g0 exact stop, skipping collinear segments).. Also - g61 and g61.1 are different. (exact path vs exact stop) very very cool. Nice work!! So - to explain further - G61 vs G61.1 from the manual.. The original planner ran G61 and g61.1 exactly the same. It would stop at every end point. now (this is from the manual) Snip... G61 - exact path mode. G61 visits the programmed point exactly, even though that means temporarily coming to a complete stop. G61.1 - exact stop mode. Same as G61 End snip... Now - in G61 if the points are collinear - exact path with combine them together. because - exact path doesn't have to stop at endpoints that don't make the path change direction. G61.1 is exact stop - it stops at every end point no matter what.. sam On 06/20/2014 11:52 AM, Robert Ellenberg wrote: Many thanks to Sam for finding this! Once again, his diligent testing has uncovered a subtle but important issue (posted here https://groups.google.com/forum/#!searchin/machinekit/discriminant/machinekit/u-Cni7u6jPQ/Da_qzl5AjAgJ). After some digging, it turns out that the final velocity for a segment was not accounting for the target velocity of the next segment. So, if you had a slow spot, the TP could enter the segment moving too fast, and cruise through it without slowing down enough. I've pushed a quick fix here that needs to get hammered on a bit: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/hotfix/g61-exactstop This also enables by-the-book exact stop behavior, so that a G61 actually does exact path, and doesn't stop if the segment is tangent with the next. I'm not sure how useful this is, but I figured I'd throw it out there if anyone wants it. It's also easy to make everything exact stop again if not. -Rob -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] New trajectory planner in master - found a new bug.
Actually - someone posted some gcode related to the discriminant error (which I cannot reproduce...) G61 G1 X -850 F6000 G0 X -325 ; bug appears here G1 X -275 F300 G0 X -52 G1 X -2 F300 M2 Now - it seems like the new TP combines all collinear segments into 1 regardless of the feed.. so - this program runs to -850 at F6000 then runs the rest of the program at G0 feeds - not stopping at points -325, -275, -52 or slowing down during the G1 moves.. G64Q0 acts the same... Pre circular arc blending works as expected.. sam -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Error compiling latest master
Try a 'make clean' first. sam On 06/16/2014 03:04 AM, Marius Liebenberg wrote: I just did a pull and got an error on compile cannot stat emc/kinematics/tc.h : no such file or directory Any suggestions please -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Threading issue with new TP
yay - will test thanks! sam On 06/11/2014 10:35 AM, Robert Ellenberg wrote: Hi sam, I'm honestly not surprised about the increased vibrations, since we're doing infinite-jerk planning here, but I'm glad to hear it's sped things up at least. I just pushed a small fix to the circular-blend-arc-rc4 branch. It seems to work in simulation for a G33 move (position sync). -Rob On Mon, Jun 9, 2014 at 9:41 AM, sam sokolik sa...@empirescreen.com wrote: Great! Running the current TP on the KT with its current acceleration settings was pretty 'tame' With the new TP - you could feel it in the floor.. Part of it was the Z axis has about .0003 backlash - so an audible 'thud' could be heard at stops/reversals.. Great work.. sam On 6/8/2014 11:10 PM, Robert Ellenberg wrote: Good find! I bet that bug was introduced during the overhaul of max speed and feed to get smoother performance with arcs. The good news is, if what I think is wrong actually is, it's a simple fix (just to make sure that if we're doing synced motion, to ignore the F-word). I'll poke around in the morning and see it I can fix it. -Rob On Sun, Jun 8, 2014 at 11:52 PM, sam sokolik sa...@empirescreen.com wrote: Here is a cell phone picture of the new TP cutting jmk's fusee program. (this is how the problem was found...) after setting the F word before the spindle synced motion to something very high (like F9) it cut correctly. (with F6 within the program - the motion would fall behind as it need to go faster for the pitch..) A good test though - I think there my need to be more to make sure nothing was missed... http://electronicsam.com/images/KandT/testing/IMG_20140608_174826_229.jpg sam On 06/08/2014 06:12 PM, sam sokolik wrote: Found a small bug with the new TP and threading... The threading move is capped by the current F word. (if you have the F word set to 6ipm - and the threading motion need to go faster - the feed is capped at 6ipm) Other than that... We ran the new TP on the KT this weekend.. It is quite impressive. The G-code programs ran 30+% faster than the current TP. Great work sam -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Threading issue with new TP
Great! Running the current TP on the KT with its current acceleration settings was pretty 'tame' With the new TP - you could feel it in the floor.. Part of it was the Z axis has about .0003 backlash - so an audible 'thud' could be heard at stops/reversals.. Great work.. sam On 6/8/2014 11:10 PM, Robert Ellenberg wrote: Good find! I bet that bug was introduced during the overhaul of max speed and feed to get smoother performance with arcs. The good news is, if what I think is wrong actually is, it's a simple fix (just to make sure that if we're doing synced motion, to ignore the F-word). I'll poke around in the morning and see it I can fix it. -Rob On Sun, Jun 8, 2014 at 11:52 PM, sam sokolik sa...@empirescreen.com wrote: Here is a cell phone picture of the new TP cutting jmk's fusee program. (this is how the problem was found...) after setting the F word before the spindle synced motion to something very high (like F9) it cut correctly. (with F6 within the program - the motion would fall behind as it need to go faster for the pitch..) A good test though - I think there my need to be more to make sure nothing was missed... http://electronicsam.com/images/KandT/testing/IMG_20140608_174826_229.jpg sam On 06/08/2014 06:12 PM, sam sokolik wrote: Found a small bug with the new TP and threading... The threading move is capped by the current F word. (if you have the F word set to 6ipm - and the threading motion need to go faster - the feed is capped at 6ipm) Other than that... We ran the new TP on the KT this weekend.. It is quite impressive. The G-code programs ran 30+% faster than the current TP. Great work sam -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Threading issue with new TP
Found a small bug with the new TP and threading... The threading move is capped by the current F word. (if you have the F word set to 6ipm - and the threading motion need to go faster - the feed is capped at 6ipm) Other than that... We ran the new TP on the KT this weekend.. It is quite impressive. The G-code programs ran 30+% faster than the current TP. Great work sam -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Threading issue with new TP
Here is a cell phone picture of the new TP cutting jmk's fusee program. (this is how the problem was found...) after setting the F word before the spindle synced motion to something very high (like F9) it cut correctly. (with F6 within the program - the motion would fall behind as it need to go faster for the pitch..) A good test though - I think there my need to be more to make sure nothing was missed... http://electronicsam.com/images/KandT/testing/IMG_20140608_174826_229.jpg sam On 06/08/2014 06:12 PM, sam sokolik wrote: Found a small bug with the new TP and threading... The threading move is capped by the current F word. (if you have the F word set to 6ipm - and the threading motion need to go faster - the feed is capped at 6ipm) Other than that... We ran the new TP on the KT this weekend.. It is quite impressive. The G-code programs ran 30+% faster than the current TP. Great work sam -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://www.hpccsystems.com ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] bug with nurbs ?
could you pastebin the program? running through the list really hacked up the gcode... sam On 05/30/2014 10:29 AM, bruno wrote: ;; ; #mill_number = 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 ( select endmill ) T[#mill_number ] M6 G43 ( enable tool length compensation ) G0 Z5 F300 ; G0 X20 Y20 G1 Y-20 G1 X-20 G1 Y20 G1 X20 G0 X40 Y40 G0 Y-40 G0 X-40 G0 Y40 G0 X40 G0 X0 Y0 ; ; parameters (coordinates of the corners are absolute) ( starting corner top right) #x1 = 40 #y1 = 40 #x2 = 40 #y2 = -40 #x3 = -40 #y3 = -40 #x4 = -40 #y4 = 40 #z_safe = 2 ( defines how the nurb weight vary) #initial_weight = 0.1 #weight_mult = 8 #weight_offset = 2 #hole_radius = 4 #pocket_depth = 15 ( z step for each turn when drilling down ) #z_step = 1 ( z step for each layer ) #z_stepover = 8 #xy_stepover = 5 ;;; onpocket4 call [#x1] [#y1] [#x2] [#y2] [#x3] [#y3] [#x4] [#y4] [#z_safe] [#initial_weight] [#weight_mult] [#weight_offset] [#hole_radius] [#pocket_depth] [#z_step] [#z_stepover] [#xy_stepover] M2 ; -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New Trajectory Planner
I am using these settings ARC_BLEND_ENABLE = 1 ARC_BLEND_FALLBACK_ENABLE = 0 ARC_BLEND_OPTIMIZATION_DEPTH = 50 ARC_BLEND_GAP_CYCLES = 4 ARC_BLEND_RAMP_FREQ = 20 So - do you want the good news or the bad news? The good news is that tort.ngc runs though without any velocity violations.. The bad news is - if you rotate tort.ngc 90 deg you get violations and it stops at line 258... G19 G2 F99260 (180 150) J3.00 K-0.00 X5.819503 Y19.442335 Z-0.367643 and just sits there.. (if we ever meet - you can hit me in the arm...) Again - closer and closer... sam On 04/17/2014 11:56 PM, Robert Ellenberg wrote: Hi Sam, I think I fixes the remaining errors now. tort.ngc doesn't violate the velocity constraints on my test config (with different Z axis max vel and max accel). I missed a few subtleties when refactoring ARC_FEED that broke the max velocity calculation, but only for helical arcs. There was also a small bug in blendmath.c that was calculating the max velocity for some blend arcs to be slightly too high. The latest commit on the rc3 branch in my github and the official repo has these fixes. Also, nice video! The motors sound very smooth and even. What ARC_BLEND_RAMP_FREQ are you using for it? -Rob On Thu, Apr 17, 2014 at 7:53 PM, sa...@empirescreen.com wrote: Well your initial fix for the velocity overages definitely fixed the terco losing position. Yay. I ran the program (31K line program takes about 20mins I think) quite a few times and it came right back to the same starting position. Sounds better to obviously.. Not bad for a machine that originally spec-ed at 20ipm max.. http://youtu.be/IkhlpdRWREE The only program so far that displays the velocity constraint violation that I have found so far is the tort.ngc I posted earlier. Great work!! sam On Tue, 15 Apr 2014 13:02:01 -0400 Robert Ellenberg rwe...@gmail.com wrote: That's a possibility, I just did a quick diff of 2.5 and master and don't see any changes to the ARC_FEED function (other than a few renames). On Tue, Apr 15, 2014 at 10:06 AM, Chris Radek ch...@timeguy.com wrote: On Tue, Apr 15, 2014 at 01:21:07AM -0400, Robert Ellenberg wrote: Well, I did a little more investigating, and it turns out the problem is deeper (and older) than I thought. The reason the velocity constraints were being violated here was that the axis_len calculation in emccanon.cc (ARC_FEED function) was wrong if the coordinate system is rotated. Rob, would this also be broken in 2.5 before any of your changes? Chris -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three
Re: [Emc-developers] New Trajectory Planner
Looks like you left logging enabled. This is what is in terminal. http://pastebin.ca/2698142 the last seciton is line number = 281 plane = 1 arc disp = -2.828427 -0.00 -2.50 axis_len = 2.50 axis1 = 0, axis2 = 1 theta1 = 2.356194, theta2 = -2.356195, angle = -4.712389, radius = 2.01 tmax = 0.295682 helical_length = 9.750718 Don't know if that helps. sam On 04/18/2014 05:14 AM, sam sokolik wrote: I am using these settings ARC_BLEND_ENABLE = 1 ARC_BLEND_FALLBACK_ENABLE = 0 ARC_BLEND_OPTIMIZATION_DEPTH = 50 ARC_BLEND_GAP_CYCLES = 4 ARC_BLEND_RAMP_FREQ = 20 So - do you want the good news or the bad news? The good news is that tort.ngc runs though without any velocity violations.. The bad news is - if you rotate tort.ngc 90 deg you get violations and it stops at line 258... G19 G2 F99260 (180 150) J3.00 K-0.00 X5.819503 Y19.442335 Z-0.367643 and just sits there.. (if we ever meet - you can hit me in the arm...) Again - closer and closer... sam On 04/17/2014 11:56 PM, Robert Ellenberg wrote: Hi Sam, I think I fixes the remaining errors now. tort.ngc doesn't violate the velocity constraints on my test config (with different Z axis max vel and max accel). I missed a few subtleties when refactoring ARC_FEED that broke the max velocity calculation, but only for helical arcs. There was also a small bug in blendmath.c that was calculating the max velocity for some blend arcs to be slightly too high. The latest commit on the rc3 branch in my github and the official repo has these fixes. Also, nice video! The motors sound very smooth and even. What ARC_BLEND_RAMP_FREQ are you using for it? -Rob On Thu, Apr 17, 2014 at 7:53 PM, sa...@empirescreen.com wrote: Well your initial fix for the velocity overages definitely fixed the terco losing position. Yay. I ran the program (31K line program takes about 20mins I think) quite a few times and it came right back to the same starting position. Sounds better to obviously.. Not bad for a machine that originally spec-ed at 20ipm max.. http://youtu.be/IkhlpdRWREE The only program so far that displays the velocity constraint violation that I have found so far is the tort.ngc I posted earlier. Great work!! sam On Tue, 15 Apr 2014 13:02:01 -0400 Robert Ellenberg rwe...@gmail.com wrote: That's a possibility, I just did a quick diff of 2.5 and master and don't see any changes to the ARC_FEED function (other than a few renames). On Tue, Apr 15, 2014 at 10:06 AM, Chris Radek ch...@timeguy.com wrote: On Tue, Apr 15, 2014 at 01:21:07AM -0400, Robert Ellenberg wrote: Well, I did a little more investigating, and it turns out the problem is deeper (and older) than I thought. The reason the velocity constraints were being violated here was that the axis_len calculation in emccanon.cc (ARC_FEED function) was wrong if the coordinate system is rotated. Rob, would this also be broken in 2.5 before any of your changes? Chris -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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
Re: [Emc-developers] New Trajectory Planner
wow. Nice catch. sam? Yes? Does it happen if the program isn't rotated? Well I don't know.. Sorry - basic troubleshooting 101.. I figured my test was running it also in master which doesn't show this problem. Again - awesome work! sam On 04/15/2014 12:21 AM, Robert Ellenberg wrote: Well, I did a little more investigating, and it turns out the problem is deeper (and older) than I thought. The reason the velocity constraints were being violated here was that the axis_len calculation in emccanon.cc (ARC_FEED function) was wrong if the coordinate system is rotated. You can see this by editing sim.var (set #5230 to 90 deg), then run this branch (based on master): https://github.com/robEllenberg/linuxcnc-mirror/tree/hotfix/axis_len If you run a program like the LHchips4.ngc, you'll see a bunch of debug output that looks like axis_len = 5.000. This is an incorrect result; there are no helical moves in this program, so this length should always be zero. Why is this a problem? Well, the maximum velocity for a helix can be higher than for a circle, because part of the move is in a 3rd axis. So, if the axis_len is artificially high, then canon calculates a max velocity that's too high, leading to constrain violations. I fixed this in the circular-blend-arc-rc3 branch by explicitly unrotating the displacement vector before calculating the axis length. Now we should be able to set an arbitrary XY rotation, and still satisfy velocity limits. I ran through LHchips4.ngc at 0 deg. and 45 deg. with no violations (in simulation), so I'm hopeful that's the fix. -Rob On Mon, Apr 14, 2014 at 11:20 PM, sam sokolik sa...@empirescreen.comwrote: the lone 'K[#scale*5.0]' should be on the previous line... sam On 04/14/2014 10:04 PM, sam sokolik wrote: ok - it is better. it seems though if one of the velocities is lower - there is a velocity constraint violation Here I am running my terco config (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) http://imagebin.org/305565 Z velocity peaks at 1.239 (74ipm). Here is a halscope showing it http://imagebin.org/305566 here is a short program that will make it do the above.. g21 g10l2p1r90 f10 #scale = .7 g19 G0X[#scale*74.845]Y[#scale*114.166] G1Y[#scale*76.188]Z[#scale*-18.048] X[#scale*48.561]Y[#scale*74.594] Z[#scale*-16.479] Y[#scale*74.86]Z[#scale*-16.946] Y[#scale*75.659]Z[#scale*-18.189] G3Y[#scale*80.659]Z[#scale*-13.189] J[#scale*0.0] K[#scale*5.0] G0Z[#scale*5.0] g10l2p1r90 m30 again - so close thanks for all your hard work! sam On 04/14/2014 02:19 PM, sam sokolik wrote: this is when it finished.. http://imagebin.org/305525 (z velocity is peaking at 74ipm - set for 60ipm) On 04/14/2014 02:09 PM, sam sokolik wrote: when I ran the config that had all the axis constraints the same (132ipm and 30in/s^2) it ran though just fine. When I ran the config that originally showed the constraint violation (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) I still get a few violations on Z http://imagebin.org/305521 Close!! sam On 04/14/2014 01:41 PM, Robert Ellenberg wrote: I just updated the circular-blend-arc-rc3 branch with a quick fix for the velocity constraint violation, so hopefully it should fix that little hiccup as well. -Rob On Mon, Apr 14, 2014 at 10:49 AM, sam sokolik sa...@empirescreen.com wrote: Cool - for grins I ran it with ARC_BLEND_ENABLE = 0 only a very very slight violation http://imagebin.org/305467 although it has a message 'already splitting on id 1481 with cycle time 0.001000' Notice 32.36 minutes the 'old' way vs 16m the new way... :) (the violation shouldn't have much effect at all on the run time as it is pretty sporadic) http://imagebin.org/305472 sam On 04/14/2014 09:27 AM, Robert Ellenberg wrote: Hi Sam, Thanks for tracking this down. Based on your data here, I did a little investigating and it looks like to root cause may be a divide by almost zero error. I added some additional calculations to get higher MA I'll velocities, and I think that was the source of this new issue, and possibly the RT hangups that Mark was seeing. I'll push a fix today as soon as I'm sure. Rob On Apr 14, 2014 9:58 AM, sam sokolik sa...@empirescreen.com wrote: I have played a bit more with this. My fast config (500ipm and 30in/s^2) doesn't violate the velocity constraint. (and they seem to me mainly on Z) 500ipm 30in/s^2 no violation 500ipm 20in/s^2 no violation 132ipm 30in/s^2 violation 153ipm peak Z 132ipm 20in/s^2 violation 159ipm peak Z 60ipm 30in/s^2 violation 78ipm peak Z it then is worse when the acc/vel are not equal. I have seen the z limit of 60ipm go as high as 121ipm (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) sam On 04/11/2014 08:27 AM, sam sokolik wrote: well - it seems to go a bit over when they are all equal also.. (vel and acc) here is with the velocities all
Re: [Emc-developers] New Trajectory Planner
and yay! (no constraint violations) http://imagebin.org/305747 sam On 04/15/2014 05:30 AM, sam sokolik wrote: wow. Nice catch. sam? Yes? Does it happen if the program isn't rotated? Well I don't know.. Sorry - basic troubleshooting 101.. I figured my test was running it also in master which doesn't show this problem. Again - awesome work! sam On 04/15/2014 12:21 AM, Robert Ellenberg wrote: Well, I did a little more investigating, and it turns out the problem is deeper (and older) than I thought. The reason the velocity constraints were being violated here was that the axis_len calculation in emccanon.cc (ARC_FEED function) was wrong if the coordinate system is rotated. You can see this by editing sim.var (set #5230 to 90 deg), then run this branch (based on master): https://github.com/robEllenberg/linuxcnc-mirror/tree/hotfix/axis_len If you run a program like the LHchips4.ngc, you'll see a bunch of debug output that looks like axis_len = 5.000. This is an incorrect result; there are no helical moves in this program, so this length should always be zero. Why is this a problem? Well, the maximum velocity for a helix can be higher than for a circle, because part of the move is in a 3rd axis. So, if the axis_len is artificially high, then canon calculates a max velocity that's too high, leading to constrain violations. I fixed this in the circular-blend-arc-rc3 branch by explicitly unrotating the displacement vector before calculating the axis length. Now we should be able to set an arbitrary XY rotation, and still satisfy velocity limits. I ran through LHchips4.ngc at 0 deg. and 45 deg. with no violations (in simulation), so I'm hopeful that's the fix. -Rob On Mon, Apr 14, 2014 at 11:20 PM, sam sokolik sa...@empirescreen.comwrote: the lone 'K[#scale*5.0]' should be on the previous line... sam On 04/14/2014 10:04 PM, sam sokolik wrote: ok - it is better. it seems though if one of the velocities is lower - there is a velocity constraint violation Here I am running my terco config (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) http://imagebin.org/305565 Z velocity peaks at 1.239 (74ipm). Here is a halscope showing it http://imagebin.org/305566 here is a short program that will make it do the above.. g21 g10l2p1r90 f10 #scale = .7 g19 G0X[#scale*74.845]Y[#scale*114.166] G1Y[#scale*76.188]Z[#scale*-18.048] X[#scale*48.561]Y[#scale*74.594] Z[#scale*-16.479] Y[#scale*74.86]Z[#scale*-16.946] Y[#scale*75.659]Z[#scale*-18.189] G3Y[#scale*80.659]Z[#scale*-13.189] J[#scale*0.0] K[#scale*5.0] G0Z[#scale*5.0] g10l2p1r90 m30 again - so close thanks for all your hard work! sam On 04/14/2014 02:19 PM, sam sokolik wrote: this is when it finished.. http://imagebin.org/305525 (z velocity is peaking at 74ipm - set for 60ipm) On 04/14/2014 02:09 PM, sam sokolik wrote: when I ran the config that had all the axis constraints the same (132ipm and 30in/s^2) it ran though just fine. When I ran the config that originally showed the constraint violation (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) I still get a few violations on Z http://imagebin.org/305521 Close!! sam On 04/14/2014 01:41 PM, Robert Ellenberg wrote: I just updated the circular-blend-arc-rc3 branch with a quick fix for the velocity constraint violation, so hopefully it should fix that little hiccup as well. -Rob On Mon, Apr 14, 2014 at 10:49 AM, sam sokolik sa...@empirescreen.com wrote: Cool - for grins I ran it with ARC_BLEND_ENABLE = 0 only a very very slight violation http://imagebin.org/305467 although it has a message 'already splitting on id 1481 with cycle time 0.001000' Notice 32.36 minutes the 'old' way vs 16m the new way... :) (the violation shouldn't have much effect at all on the run time as it is pretty sporadic) http://imagebin.org/305472 sam On 04/14/2014 09:27 AM, Robert Ellenberg wrote: Hi Sam, Thanks for tracking this down. Based on your data here, I did a little investigating and it looks like to root cause may be a divide by almost zero error. I added some additional calculations to get higher MA I'll velocities, and I think that was the source of this new issue, and possibly the RT hangups that Mark was seeing. I'll push a fix today as soon as I'm sure. Rob On Apr 14, 2014 9:58 AM, sam sokolik sa...@empirescreen.com wrote: I have played a bit more with this. My fast config (500ipm and 30in/s^2) doesn't violate the velocity constraint. (and they seem to me mainly on Z) 500ipm 30in/s^2 no violation 500ipm 20in/s^2 no violation 132ipm 30in/s^2 violation 153ipm peak Z 132ipm 20in/s^2 violation 159ipm peak Z 60ipm 30in/s^2 violation 78ipm peak Z it then is worse when the acc/vel are not equal. I have seen the z limit of 60ipm go as high as 121ipm (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) sam On 04/11/2014 08:27 AM, sam sokolik
Re: [Emc-developers] New Trajectory Planner
Well - going through my normal test programs - I ran the tort with the terco config (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) Z peaks at 78ipm (it goes above 60ipm quite often) rotated and not rotated http://imagebin.org/305767 that was around line 78 sick of me yet? :) sam On 04/15/2014 06:07 AM, sam sokolik wrote: and yay! (no constraint violations) http://imagebin.org/305747 sam On 04/15/2014 05:30 AM, sam sokolik wrote: wow. Nice catch. sam? Yes? Does it happen if the program isn't rotated? Well I don't know.. Sorry - basic troubleshooting 101.. I figured my test was running it also in master which doesn't show this problem. Again - awesome work! sam On 04/15/2014 12:21 AM, Robert Ellenberg wrote: Well, I did a little more investigating, and it turns out the problem is deeper (and older) than I thought. The reason the velocity constraints were being violated here was that the axis_len calculation in emccanon.cc (ARC_FEED function) was wrong if the coordinate system is rotated. You can see this by editing sim.var (set #5230 to 90 deg), then run this branch (based on master): https://github.com/robEllenberg/linuxcnc-mirror/tree/hotfix/axis_len If you run a program like the LHchips4.ngc, you'll see a bunch of debug output that looks like axis_len = 5.000. This is an incorrect result; there are no helical moves in this program, so this length should always be zero. Why is this a problem? Well, the maximum velocity for a helix can be higher than for a circle, because part of the move is in a 3rd axis. So, if the axis_len is artificially high, then canon calculates a max velocity that's too high, leading to constrain violations. I fixed this in the circular-blend-arc-rc3 branch by explicitly unrotating the displacement vector before calculating the axis length. Now we should be able to set an arbitrary XY rotation, and still satisfy velocity limits. I ran through LHchips4.ngc at 0 deg. and 45 deg. with no violations (in simulation), so I'm hopeful that's the fix. -Rob On Mon, Apr 14, 2014 at 11:20 PM, sam sokolik sa...@empirescreen.comwrote: the lone 'K[#scale*5.0]' should be on the previous line... sam On 04/14/2014 10:04 PM, sam sokolik wrote: ok - it is better. it seems though if one of the velocities is lower - there is a velocity constraint violation Here I am running my terco config (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) http://imagebin.org/305565 Z velocity peaks at 1.239 (74ipm). Here is a halscope showing it http://imagebin.org/305566 here is a short program that will make it do the above.. g21 g10l2p1r90 f10 #scale = .7 g19 G0X[#scale*74.845]Y[#scale*114.166] G1Y[#scale*76.188]Z[#scale*-18.048] X[#scale*48.561]Y[#scale*74.594] Z[#scale*-16.479] Y[#scale*74.86]Z[#scale*-16.946] Y[#scale*75.659]Z[#scale*-18.189] G3Y[#scale*80.659]Z[#scale*-13.189] J[#scale*0.0] K[#scale*5.0] G0Z[#scale*5.0] g10l2p1r90 m30 again - so close thanks for all your hard work! sam On 04/14/2014 02:19 PM, sam sokolik wrote: this is when it finished.. http://imagebin.org/305525 (z velocity is peaking at 74ipm - set for 60ipm) On 04/14/2014 02:09 PM, sam sokolik wrote: when I ran the config that had all the axis constraints the same (132ipm and 30in/s^2) it ran though just fine. When I ran the config that originally showed the constraint violation (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) I still get a few violations on Z http://imagebin.org/305521 Close!! sam On 04/14/2014 01:41 PM, Robert Ellenberg wrote: I just updated the circular-blend-arc-rc3 branch with a quick fix for the velocity constraint violation, so hopefully it should fix that little hiccup as well. -Rob On Mon, Apr 14, 2014 at 10:49 AM, sam sokolik sa...@empirescreen.com wrote: Cool - for grins I ran it with ARC_BLEND_ENABLE = 0 only a very very slight violation http://imagebin.org/305467 although it has a message 'already splitting on id 1481 with cycle time 0.001000' Notice 32.36 minutes the 'old' way vs 16m the new way... :) (the violation shouldn't have much effect at all on the run time as it is pretty sporadic) http://imagebin.org/305472 sam On 04/14/2014 09:27 AM, Robert Ellenberg wrote: Hi Sam, Thanks for tracking this down. Based on your data here, I did a little investigating and it looks like to root cause may be a divide by almost zero error. I added some additional calculations to get higher MA I'll velocities, and I think that was the source of this new issue, and possibly the RT hangups that Mark was seeing. I'll push a fix today as soon as I'm sure. Rob On Apr 14, 2014 9:58 AM, sam sokolik sa...@empirescreen.com wrote: I have played a bit more with this. My fast config (500ipm and 30in/s^2) doesn't violate the velocity constraint. (and they seem to me mainly on Z) 500ipm 30in/s^2 no violation 500ipm 20in/s^2
Re: [Emc-developers] New Trajectory Planner
this is what I am using http://electronicsam.com/images/KandT/testing/tort.ngc it is the normal tort with the feedrates set very high. Yes - getting closer and closer! Don't feel rushed - school comes first :) (we have gotten by this long :) ) sam On 04/15/2014 08:16 AM, Robert Ellenberg wrote: Oh well, I suppose I shouldn't be too surprised, I only had time to go through a few programs last night. Is this test program in the usual place? If so, I'll be able to run it again tonight or tomorrow morning and see what's up. At least we're making incremental progress! Rob -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New Trajectory Planner
running master as of a week or so ago - doesn't seem to show the same issue (it does have the known acc constraint issue) http://imagebin.org/305773 sam On 4/15/2014 12:02 PM, Robert Ellenberg wrote: That's a possibility, I just did a quick diff of 2.5 and master and don't see any changes to the ARC_FEED function (other than a few renames). On Tue, Apr 15, 2014 at 10:06 AM, Chris Radek ch...@timeguy.com wrote: On Tue, Apr 15, 2014 at 01:21:07AM -0400, Robert Ellenberg wrote: Well, I did a little more investigating, and it turns out the problem is deeper (and older) than I thought. The reason the velocity constraints were being violated here was that the axis_len calculation in emccanon.cc (ARC_FEED function) was wrong if the coordinate system is rotated. Rob, would this also be broken in 2.5 before any of your changes? Chris -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New Trajectory Planner
I have played a bit more with this. My fast config (500ipm and 30in/s^2) doesn't violate the velocity constraint. (and they seem to me mainly on Z) 500ipm 30in/s^2 no violation 500ipm 20in/s^2 no violation 132ipm 30in/s^2 violation 153ipm peak Z 132ipm 20in/s^2 violation 159ipm peak Z 60ipm 30in/s^2 violation 78ipm peak Z it then is worse when the acc/vel are not equal. I have seen the z limit of 60ipm go as high as 121ipm (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) sam On 04/11/2014 08:27 AM, sam sokolik wrote: well - it seems to go a bit over when they are all equal also.. (vel and acc) here is with the velocities all the same (2.2in/s^2) http://imagebin.org/305052 here is with velocities and acc all the same http://imagebin.org/305054 sam On 04/10/2014 10:21 PM, Robert Ellenberg wrote: Hmm, I'll take a closer look at this over the weekend. I suspect this issue is due to one of the recent fixes. Do you still see violations if the Z axis limit is the same as X and Y? On Thu, Apr 10, 2014 at 9:57 PM, sam sokolik sa...@empirescreen.com wrote: Ok - I found another issue. I have been playing with the little terco mill. Z kept losing steps. I figured noise or running too fast... well dad said - maybe linuxcnc is erroring.. I thought no way. I have tested the new tp extensively.. :) well I ran the config in sim with the peak readings and it looks like the z axis's velocity constraints are violated. Here is a screenshot of halscope. z axis has a max velocity of 1in/s (60in/min) You can see that it violates the velocity - peaks at 1.6in/sec. (positive and negative) http://imagebin.org/304984 here is a screenshot of the whole run - it peaks at 2in/sec at some point. (way faster than that axis can go) http://imagebin.org/304985 here is the ini http://pastebin.ca/2694160 here is a short snippet of gcode. (it violates velocity -1.6in/sec) http://pastebin.ca/2694169 dad always seems to be right sam On 03/28/2014 06:40 PM, Robert Ellenberg wrote: It turned out that the max feed override defaulted to zero if not set in the INI, which caused the velocity to be set to zero. I added a default value here that seems to fix that test. Also, I think the ripple issue is fixed (I moved the vLimit check to always be called in the function that calculates target velocity). On Fri, Mar 28, 2014 at 7:27 AM, sam sokolik sa...@empirescreen.com wrote: inital testing now the feed override acts as expected. (This is going from 100% to 90%) http://imagebin.org/302341 I still see the same ripples when the maximim velocity is turned down. (ie - 20ipm sees peaks of 27ipm) http://imagebin.org/302342 on thing - it seems to be failing a run test now. 'subroutine-return' Great work! sam -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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/NeoTech ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https
Re: [Emc-developers] New Trajectory Planner
Cool - for grins I ran it with ARC_BLEND_ENABLE = 0 only a very very slight violation http://imagebin.org/305467 although it has a message 'already splitting on id 1481 with cycle time 0.001000' Notice 32.36 minutes the 'old' way vs 16m the new way... :) (the violation shouldn't have much effect at all on the run time as it is pretty sporadic) http://imagebin.org/305472 sam On 04/14/2014 09:27 AM, Robert Ellenberg wrote: Hi Sam, Thanks for tracking this down. Based on your data here, I did a little investigating and it looks like to root cause may be a divide by almost zero error. I added some additional calculations to get higher MA I'll velocities, and I think that was the source of this new issue, and possibly the RT hangups that Mark was seeing. I'll push a fix today as soon as I'm sure. Rob On Apr 14, 2014 9:58 AM, sam sokolik sa...@empirescreen.com wrote: I have played a bit more with this. My fast config (500ipm and 30in/s^2) doesn't violate the velocity constraint. (and they seem to me mainly on Z) 500ipm 30in/s^2 no violation 500ipm 20in/s^2 no violation 132ipm 30in/s^2 violation 153ipm peak Z 132ipm 20in/s^2 violation 159ipm peak Z 60ipm 30in/s^2 violation 78ipm peak Z it then is worse when the acc/vel are not equal. I have seen the z limit of 60ipm go as high as 121ipm (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) sam On 04/11/2014 08:27 AM, sam sokolik wrote: well - it seems to go a bit over when they are all equal also.. (vel and acc) here is with the velocities all the same (2.2in/s^2) http://imagebin.org/305052 here is with velocities and acc all the same http://imagebin.org/305054 sam On 04/10/2014 10:21 PM, Robert Ellenberg wrote: Hmm, I'll take a closer look at this over the weekend. I suspect this issue is due to one of the recent fixes. Do you still see violations if the Z axis limit is the same as X and Y? On Thu, Apr 10, 2014 at 9:57 PM, sam sokolik sa...@empirescreen.com wrote: Ok - I found another issue. I have been playing with the little terco mill. Z kept losing steps. I figured noise or running too fast... well dad said - maybe linuxcnc is erroring.. I thought no way. I have tested the new tp extensively.. :) well I ran the config in sim with the peak readings and it looks like the z axis's velocity constraints are violated. Here is a screenshot of halscope. z axis has a max velocity of 1in/s (60in/min) You can see that it violates the velocity - peaks at 1.6in/sec. (positive and negative) http://imagebin.org/304984 here is a screenshot of the whole run - it peaks at 2in/sec at some point. (way faster than that axis can go) http://imagebin.org/304985 here is the ini http://pastebin.ca/2694160 here is a short snippet of gcode. (it violates velocity -1.6in/sec) http://pastebin.ca/2694169 dad always seems to be right sam On 03/28/2014 06:40 PM, Robert Ellenberg wrote: It turned out that the max feed override defaulted to zero if not set in the INI, which caused the velocity to be set to zero. I added a default value here that seems to fix that test. Also, I think the ripple issue is fixed (I moved the vLimit check to always be called in the function that calculates target velocity). On Fri, Mar 28, 2014 at 7:27 AM, sam sokolik sa...@empirescreen.com wrote: inital testing now the feed override acts as expected. (This is going from 100% to 90%) http://imagebin.org/302341 I still see the same ripples when the maximim velocity is turned down. (ie - 20ipm sees peaks of 27ipm) http://imagebin.org/302342 on thing - it seems to be failing a run test now. 'subroutine-return' Great work! sam -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New Trajectory Planner
when I ran the config that had all the axis constraints the same (132ipm and 30in/s^2) it ran though just fine. When I ran the config that originally showed the constraint violation (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) I still get a few violations on Z http://imagebin.org/305521 Close!! sam On 04/14/2014 01:41 PM, Robert Ellenberg wrote: I just updated the circular-blend-arc-rc3 branch with a quick fix for the velocity constraint violation, so hopefully it should fix that little hiccup as well. -Rob On Mon, Apr 14, 2014 at 10:49 AM, sam sokolik sa...@empirescreen.comwrote: Cool - for grins I ran it with ARC_BLEND_ENABLE = 0 only a very very slight violation http://imagebin.org/305467 although it has a message 'already splitting on id 1481 with cycle time 0.001000' Notice 32.36 minutes the 'old' way vs 16m the new way... :) (the violation shouldn't have much effect at all on the run time as it is pretty sporadic) http://imagebin.org/305472 sam On 04/14/2014 09:27 AM, Robert Ellenberg wrote: Hi Sam, Thanks for tracking this down. Based on your data here, I did a little investigating and it looks like to root cause may be a divide by almost zero error. I added some additional calculations to get higher MA I'll velocities, and I think that was the source of this new issue, and possibly the RT hangups that Mark was seeing. I'll push a fix today as soon as I'm sure. Rob On Apr 14, 2014 9:58 AM, sam sokolik sa...@empirescreen.com wrote: I have played a bit more with this. My fast config (500ipm and 30in/s^2) doesn't violate the velocity constraint. (and they seem to me mainly on Z) 500ipm 30in/s^2 no violation 500ipm 20in/s^2 no violation 132ipm 30in/s^2 violation 153ipm peak Z 132ipm 20in/s^2 violation 159ipm peak Z 60ipm 30in/s^2 violation 78ipm peak Z it then is worse when the acc/vel are not equal. I have seen the z limit of 60ipm go as high as 121ipm (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) sam On 04/11/2014 08:27 AM, sam sokolik wrote: well - it seems to go a bit over when they are all equal also.. (vel and acc) here is with the velocities all the same (2.2in/s^2) http://imagebin.org/305052 here is with velocities and acc all the same http://imagebin.org/305054 sam On 04/10/2014 10:21 PM, Robert Ellenberg wrote: Hmm, I'll take a closer look at this over the weekend. I suspect this issue is due to one of the recent fixes. Do you still see violations if the Z axis limit is the same as X and Y? On Thu, Apr 10, 2014 at 9:57 PM, sam sokolik sa...@empirescreen.com wrote: Ok - I found another issue. I have been playing with the little terco mill. Z kept losing steps. I figured noise or running too fast... well dad said - maybe linuxcnc is erroring.. I thought no way. I have tested the new tp extensively.. :) well I ran the config in sim with the peak readings and it looks like the z axis's velocity constraints are violated. Here is a screenshot of halscope. z axis has a max velocity of 1in/s (60in/min) You can see that it violates the velocity - peaks at 1.6in/sec. (positive and negative) http://imagebin.org/304984 here is a screenshot of the whole run - it peaks at 2in/sec at some point. (way faster than that axis can go) http://imagebin.org/304985 here is the ini http://pastebin.ca/2694160 here is a short snippet of gcode. (it violates velocity -1.6in/sec) http://pastebin.ca/2694169 dad always seems to be right sam On 03/28/2014 06:40 PM, Robert Ellenberg wrote: It turned out that the max feed override defaulted to zero if not set in the INI, which caused the velocity to be set to zero. I added a default value here that seems to fix that test. Also, I think the ripple issue is fixed (I moved the vLimit check to always be called in the function that calculates target velocity). On Fri, Mar 28, 2014 at 7:27 AM, sam sokolik sa...@empirescreen.com wrote: inital testing now the feed override acts as expected. (This is going from 100% to 90%) http://imagebin.org/302341 I still see the same ripples when the maximim velocity is turned down. (ie - 20ipm sees peaks of 27ipm) http://imagebin.org/302342 on thing - it seems to be failing a run test now. 'subroutine-return' Great work! sam -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Emc-developers mailing list Emc-developers
Re: [Emc-developers] New Trajectory Planner
this is when it finished.. http://imagebin.org/305525 (z velocity is peaking at 74ipm - set for 60ipm) On 04/14/2014 02:09 PM, sam sokolik wrote: when I ran the config that had all the axis constraints the same (132ipm and 30in/s^2) it ran though just fine. When I ran the config that originally showed the constraint violation (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) I still get a few violations on Z http://imagebin.org/305521 Close!! sam On 04/14/2014 01:41 PM, Robert Ellenberg wrote: I just updated the circular-blend-arc-rc3 branch with a quick fix for the velocity constraint violation, so hopefully it should fix that little hiccup as well. -Rob On Mon, Apr 14, 2014 at 10:49 AM, sam sokolik sa...@empirescreen.comwrote: Cool - for grins I ran it with ARC_BLEND_ENABLE = 0 only a very very slight violation http://imagebin.org/305467 although it has a message 'already splitting on id 1481 with cycle time 0.001000' Notice 32.36 minutes the 'old' way vs 16m the new way... :) (the violation shouldn't have much effect at all on the run time as it is pretty sporadic) http://imagebin.org/305472 sam On 04/14/2014 09:27 AM, Robert Ellenberg wrote: Hi Sam, Thanks for tracking this down. Based on your data here, I did a little investigating and it looks like to root cause may be a divide by almost zero error. I added some additional calculations to get higher MA I'll velocities, and I think that was the source of this new issue, and possibly the RT hangups that Mark was seeing. I'll push a fix today as soon as I'm sure. Rob On Apr 14, 2014 9:58 AM, sam sokolik sa...@empirescreen.com wrote: I have played a bit more with this. My fast config (500ipm and 30in/s^2) doesn't violate the velocity constraint. (and they seem to me mainly on Z) 500ipm 30in/s^2 no violation 500ipm 20in/s^2 no violation 132ipm 30in/s^2 violation 153ipm peak Z 132ipm 20in/s^2 violation 159ipm peak Z 60ipm 30in/s^2 violation 78ipm peak Z it then is worse when the acc/vel are not equal. I have seen the z limit of 60ipm go as high as 121ipm (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) sam On 04/11/2014 08:27 AM, sam sokolik wrote: well - it seems to go a bit over when they are all equal also.. (vel and acc) here is with the velocities all the same (2.2in/s^2) http://imagebin.org/305052 here is with velocities and acc all the same http://imagebin.org/305054 sam On 04/10/2014 10:21 PM, Robert Ellenberg wrote: Hmm, I'll take a closer look at this over the weekend. I suspect this issue is due to one of the recent fixes. Do you still see violations if the Z axis limit is the same as X and Y? On Thu, Apr 10, 2014 at 9:57 PM, sam sokolik sa...@empirescreen.com wrote: Ok - I found another issue. I have been playing with the little terco mill. Z kept losing steps. I figured noise or running too fast... well dad said - maybe linuxcnc is erroring.. I thought no way. I have tested the new tp extensively.. :) well I ran the config in sim with the peak readings and it looks like the z axis's velocity constraints are violated. Here is a screenshot of halscope. z axis has a max velocity of 1in/s (60in/min) You can see that it violates the velocity - peaks at 1.6in/sec. (positive and negative) http://imagebin.org/304984 here is a screenshot of the whole run - it peaks at 2in/sec at some point. (way faster than that axis can go) http://imagebin.org/304985 here is the ini http://pastebin.ca/2694160 here is a short snippet of gcode. (it violates velocity -1.6in/sec) http://pastebin.ca/2694169 dad always seems to be right sam On 03/28/2014 06:40 PM, Robert Ellenberg wrote: It turned out that the max feed override defaulted to zero if not set in the INI, which caused the velocity to be set to zero. I added a default value here that seems to fix that test. Also, I think the ripple issue is fixed (I moved the vLimit check to always be called in the function that calculates target velocity). On Fri, Mar 28, 2014 at 7:27 AM, sam sokolik sa...@empirescreen.com wrote: inital testing now the feed override acts as expected. (This is going from 100% to 90%) http://imagebin.org/302341 I still see the same ripples when the maximim velocity is turned down. (ie - 20ipm sees peaks of 27ipm) http://imagebin.org/302342 on thing - it seems to be failing a run test now. 'subroutine-return' Great work! sam -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try
Re: [Emc-developers] New Trajectory Planner
ok - it is better. it seems though if one of the velocities is lower - there is a velocity constraint violation Here I am running my terco config (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) http://imagebin.org/305565 Z velocity peaks at 1.239 (74ipm). Here is a halscope showing it http://imagebin.org/305566 here is a short program that will make it do the above.. g21 g10l2p1r90 f10 #scale = .7 g19 G0X[#scale*74.845]Y[#scale*114.166] G1Y[#scale*76.188]Z[#scale*-18.048] X[#scale*48.561]Y[#scale*74.594] Z[#scale*-16.479] Y[#scale*74.86]Z[#scale*-16.946] Y[#scale*75.659]Z[#scale*-18.189] G3Y[#scale*80.659]Z[#scale*-13.189] J[#scale*0.0] K[#scale*5.0] G0Z[#scale*5.0] g10l2p1r90 m30 again - so close thanks for all your hard work! sam On 04/14/2014 02:19 PM, sam sokolik wrote: this is when it finished.. http://imagebin.org/305525 (z velocity is peaking at 74ipm - set for 60ipm) On 04/14/2014 02:09 PM, sam sokolik wrote: when I ran the config that had all the axis constraints the same (132ipm and 30in/s^2) it ran though just fine. When I ran the config that originally showed the constraint violation (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) I still get a few violations on Z http://imagebin.org/305521 Close!! sam On 04/14/2014 01:41 PM, Robert Ellenberg wrote: I just updated the circular-blend-arc-rc3 branch with a quick fix for the velocity constraint violation, so hopefully it should fix that little hiccup as well. -Rob On Mon, Apr 14, 2014 at 10:49 AM, sam sokolik sa...@empirescreen.comwrote: Cool - for grins I ran it with ARC_BLEND_ENABLE = 0 only a very very slight violation http://imagebin.org/305467 although it has a message 'already splitting on id 1481 with cycle time 0.001000' Notice 32.36 minutes the 'old' way vs 16m the new way... :) (the violation shouldn't have much effect at all on the run time as it is pretty sporadic) http://imagebin.org/305472 sam On 04/14/2014 09:27 AM, Robert Ellenberg wrote: Hi Sam, Thanks for tracking this down. Based on your data here, I did a little investigating and it looks like to root cause may be a divide by almost zero error. I added some additional calculations to get higher MA I'll velocities, and I think that was the source of this new issue, and possibly the RT hangups that Mark was seeing. I'll push a fix today as soon as I'm sure. Rob On Apr 14, 2014 9:58 AM, sam sokolik sa...@empirescreen.com wrote: I have played a bit more with this. My fast config (500ipm and 30in/s^2) doesn't violate the velocity constraint. (and they seem to me mainly on Z) 500ipm 30in/s^2 no violation 500ipm 20in/s^2 no violation 132ipm 30in/s^2 violation 153ipm peak Z 132ipm 20in/s^2 violation 159ipm peak Z 60ipm 30in/s^2 violation 78ipm peak Z it then is worse when the acc/vel are not equal. I have seen the z limit of 60ipm go as high as 121ipm (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) sam On 04/11/2014 08:27 AM, sam sokolik wrote: well - it seems to go a bit over when they are all equal also.. (vel and acc) here is with the velocities all the same (2.2in/s^2) http://imagebin.org/305052 here is with velocities and acc all the same http://imagebin.org/305054 sam On 04/10/2014 10:21 PM, Robert Ellenberg wrote: Hmm, I'll take a closer look at this over the weekend. I suspect this issue is due to one of the recent fixes. Do you still see violations if the Z axis limit is the same as X and Y? On Thu, Apr 10, 2014 at 9:57 PM, sam sokolik sa...@empirescreen.com wrote: Ok - I found another issue. I have been playing with the little terco mill. Z kept losing steps. I figured noise or running too fast... well dad said - maybe linuxcnc is erroring.. I thought no way. I have tested the new tp extensively.. :) well I ran the config in sim with the peak readings and it looks like the z axis's velocity constraints are violated. Here is a screenshot of halscope. z axis has a max velocity of 1in/s (60in/min) You can see that it violates the velocity - peaks at 1.6in/sec. (positive and negative) http://imagebin.org/304984 here is a screenshot of the whole run - it peaks at 2in/sec at some point. (way faster than that axis can go) http://imagebin.org/304985 here is the ini http://pastebin.ca/2694160 here is a short snippet of gcode. (it violates velocity -1.6in/sec) http://pastebin.ca/2694169 dad always seems to be right sam On 03/28/2014 06:40 PM, Robert Ellenberg wrote: It turned out that the max feed override defaulted to zero if not set in the INI, which caused the velocity to be set to zero. I added a default value here that seems to fix that test. Also, I think the ripple issue is fixed (I moved the vLimit check to always be called in the function that calculates target velocity). On Fri, Mar 28, 2014 at 7:27 AM, sam sokolik sa...@empirescreen.com wrote
Re: [Emc-developers] New Trajectory Planner
the lone 'K[#scale*5.0]' should be on the previous line... sam On 04/14/2014 10:04 PM, sam sokolik wrote: ok - it is better. it seems though if one of the velocities is lower - there is a velocity constraint violation Here I am running my terco config (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) http://imagebin.org/305565 Z velocity peaks at 1.239 (74ipm). Here is a halscope showing it http://imagebin.org/305566 here is a short program that will make it do the above.. g21 g10l2p1r90 f10 #scale = .7 g19 G0X[#scale*74.845]Y[#scale*114.166] G1Y[#scale*76.188]Z[#scale*-18.048] X[#scale*48.561]Y[#scale*74.594] Z[#scale*-16.479] Y[#scale*74.86]Z[#scale*-16.946] Y[#scale*75.659]Z[#scale*-18.189] G3Y[#scale*80.659]Z[#scale*-13.189] J[#scale*0.0] K[#scale*5.0] G0Z[#scale*5.0] g10l2p1r90 m30 again - so close thanks for all your hard work! sam On 04/14/2014 02:19 PM, sam sokolik wrote: this is when it finished.. http://imagebin.org/305525 (z velocity is peaking at 74ipm - set for 60ipm) On 04/14/2014 02:09 PM, sam sokolik wrote: when I ran the config that had all the axis constraints the same (132ipm and 30in/s^2) it ran though just fine. When I ran the config that originally showed the constraint violation (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) I still get a few violations on Z http://imagebin.org/305521 Close!! sam On 04/14/2014 01:41 PM, Robert Ellenberg wrote: I just updated the circular-blend-arc-rc3 branch with a quick fix for the velocity constraint violation, so hopefully it should fix that little hiccup as well. -Rob On Mon, Apr 14, 2014 at 10:49 AM, sam sokolik sa...@empirescreen.comwrote: Cool - for grins I ran it with ARC_BLEND_ENABLE = 0 only a very very slight violation http://imagebin.org/305467 although it has a message 'already splitting on id 1481 with cycle time 0.001000' Notice 32.36 minutes the 'old' way vs 16m the new way... :) (the violation shouldn't have much effect at all on the run time as it is pretty sporadic) http://imagebin.org/305472 sam On 04/14/2014 09:27 AM, Robert Ellenberg wrote: Hi Sam, Thanks for tracking this down. Based on your data here, I did a little investigating and it looks like to root cause may be a divide by almost zero error. I added some additional calculations to get higher MA I'll velocities, and I think that was the source of this new issue, and possibly the RT hangups that Mark was seeing. I'll push a fix today as soon as I'm sure. Rob On Apr 14, 2014 9:58 AM, sam sokolik sa...@empirescreen.com wrote: I have played a bit more with this. My fast config (500ipm and 30in/s^2) doesn't violate the velocity constraint. (and they seem to me mainly on Z) 500ipm 30in/s^2 no violation 500ipm 20in/s^2 no violation 132ipm 30in/s^2 violation 153ipm peak Z 132ipm 20in/s^2 violation 159ipm peak Z 60ipm 30in/s^2 violation 78ipm peak Z it then is worse when the acc/vel are not equal. I have seen the z limit of 60ipm go as high as 121ipm (x and y 132ipm 20in/s^2, z 60ipm 15in/s^2) sam On 04/11/2014 08:27 AM, sam sokolik wrote: well - it seems to go a bit over when they are all equal also.. (vel and acc) here is with the velocities all the same (2.2in/s^2) http://imagebin.org/305052 here is with velocities and acc all the same http://imagebin.org/305054 sam On 04/10/2014 10:21 PM, Robert Ellenberg wrote: Hmm, I'll take a closer look at this over the weekend. I suspect this issue is due to one of the recent fixes. Do you still see violations if the Z axis limit is the same as X and Y? On Thu, Apr 10, 2014 at 9:57 PM, sam sokolik sa...@empirescreen.com wrote: Ok - I found another issue. I have been playing with the little terco mill. Z kept losing steps. I figured noise or running too fast... well dad said - maybe linuxcnc is erroring.. I thought no way. I have tested the new tp extensively.. :) well I ran the config in sim with the peak readings and it looks like the z axis's velocity constraints are violated. Here is a screenshot of halscope. z axis has a max velocity of 1in/s (60in/min) You can see that it violates the velocity - peaks at 1.6in/sec. (positive and negative) http://imagebin.org/304984 here is a screenshot of the whole run - it peaks at 2in/sec at some point. (way faster than that axis can go) http://imagebin.org/304985 here is the ini http://pastebin.ca/2694160 here is a short snippet of gcode. (it violates velocity -1.6in/sec) http://pastebin.ca/2694169 dad always seems to be right sam On 03/28/2014 06:40 PM, Robert Ellenberg wrote: It turned out that the max feed override defaulted to zero if not set in the INI, which caused the velocity to be set to zero. I added a default value here that seems to fix that test. Also, I think the ripple issue is fixed (I moved the vLimit check to always be called
Re: [Emc-developers] New Trajectory Planner
well - it seems to go a bit over when they are all equal also.. (vel and acc) here is with the velocities all the same (2.2in/s^2) http://imagebin.org/305052 here is with velocities and acc all the same http://imagebin.org/305054 sam On 04/10/2014 10:21 PM, Robert Ellenberg wrote: Hmm, I'll take a closer look at this over the weekend. I suspect this issue is due to one of the recent fixes. Do you still see violations if the Z axis limit is the same as X and Y? On Thu, Apr 10, 2014 at 9:57 PM, sam sokolik sa...@empirescreen.com wrote: Ok - I found another issue. I have been playing with the little terco mill. Z kept losing steps. I figured noise or running too fast... well dad said - maybe linuxcnc is erroring.. I thought no way. I have tested the new tp extensively.. :) well I ran the config in sim with the peak readings and it looks like the z axis's velocity constraints are violated. Here is a screenshot of halscope. z axis has a max velocity of 1in/s (60in/min) You can see that it violates the velocity - peaks at 1.6in/sec. (positive and negative) http://imagebin.org/304984 here is a screenshot of the whole run - it peaks at 2in/sec at some point. (way faster than that axis can go) http://imagebin.org/304985 here is the ini http://pastebin.ca/2694160 here is a short snippet of gcode. (it violates velocity -1.6in/sec) http://pastebin.ca/2694169 dad always seems to be right sam On 03/28/2014 06:40 PM, Robert Ellenberg wrote: It turned out that the max feed override defaulted to zero if not set in the INI, which caused the velocity to be set to zero. I added a default value here that seems to fix that test. Also, I think the ripple issue is fixed (I moved the vLimit check to always be called in the function that calculates target velocity). On Fri, Mar 28, 2014 at 7:27 AM, sam sokolik sa...@empirescreen.com wrote: inital testing now the feed override acts as expected. (This is going from 100% to 90%) http://imagebin.org/302341 I still see the same ripples when the maximim velocity is turned down. (ie - 20ipm sees peaks of 27ipm) http://imagebin.org/302342 on thing - it seems to be failing a run test now. 'subroutine-return' Great work! sam -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New Trajectory Planner
Ok - I found another issue. I have been playing with the little terco mill. Z kept losing steps. I figured noise or running too fast... well dad said - maybe linuxcnc is erroring.. I thought no way. I have tested the new tp extensively.. :) well I ran the config in sim with the peak readings and it looks like the z axis's velocity constraints are violated. Here is a screenshot of halscope. z axis has a max velocity of 1in/s (60in/min) You can see that it violates the velocity - peaks at 1.6in/sec. (positive and negative) http://imagebin.org/304984 here is a screenshot of the whole run - it peaks at 2in/sec at some point. (way faster than that axis can go) http://imagebin.org/304985 here is the ini http://pastebin.ca/2694160 here is a short snippet of gcode. (it violates velocity -1.6in/sec) http://pastebin.ca/2694169 dad always seems to be right sam On 03/28/2014 06:40 PM, Robert Ellenberg wrote: It turned out that the max feed override defaulted to zero if not set in the INI, which caused the velocity to be set to zero. I added a default value here that seems to fix that test. Also, I think the ripple issue is fixed (I moved the vLimit check to always be called in the function that calculates target velocity). On Fri, Mar 28, 2014 at 7:27 AM, sam sokolik sa...@empirescreen.com wrote: inital testing now the feed override acts as expected. (This is going from 100% to 90%) http://imagebin.org/302341 I still see the same ripples when the maximim velocity is turned down. (ie - 20ipm sees peaks of 27ipm) http://imagebin.org/302342 on thing - it seems to be failing a run test now. 'subroutine-return' Great work! sam -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] sim gotchas in sim/axis/lathe
you could do something as simple as G20 F15 G21 On 04/10/2014 08:03 PM, Eric Keller wrote: On Thu, Apr 10, 2014 at 8:36 PM, Gene Heskett ghesk...@wdtv.com wrote: I don't think it was quite all that encompassing before, Andy, and you are by pure common sense correct. So if I run in metric mode, I'll have to recall that F is in mm per min. That means a bunch of them. As in 15 ipm=384mm-min. I am pretty sure that I can recall a time when metric was broken. It absolutely must be the case that all numbers associated with units are in the current units. No automagic conversions. Not sure what the software should do if there is a units conversion and it has to use the last F word though, that is a conundrum. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New Trajectory Planner
Just to clarify.. This is all rob. I only try to test the crap out of it. :) sam On 04/01/2014 11:48 PM, Marius Liebenberg wrote: On 2014-04-01 22:45, Sebastian Kuzminsky wrote: On 4/1/14 14:27 , Marius Liebenberg wrote: What was the verdict then, is this work going to be incorporated somewhere in the near future or will we have to wait until Robert has done more to it? I'm not sure exactly what state it's in currently. After i make the 2.6 branch I hope to speak with Sam Sokolik and Robert Ellenberg and see where things stand. I'm hoping to merge it into master for the following (2.7) release cycle (which will hopefully be much shorter than 2.6 was/is). And that might give Robert and Sam some time to get more axis included maybe. -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Announcing the LinuxCNC 2.6 branch
Just because it didn't make it into 2.6 doesn't mean it isn't going to happen. This isn't the end of the world. Have you seen the todo list? There have been a few calls for help http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Todo-2.6 As far as rt_preempt - I have tested it using the unified build - michael debs. (playing with the 7i80) All the hardware I have tested it on - I have never seen anything better than 50us latency. Just fine for servo loop systems. (where as the same hardware runs rtai/xeomai 10us or there abouts..) I see things moving forward.. Anyone can test/use any of the linuxcnc advancements. (be it the ub, new trajectory planner, whatever) I wish I could do more than just test... (not enough hours in the day) sam On 04/02/2014 03:20 PM, Lars Segerlund wrote: Just give it up, I followed rt-preempt developement for 4 years or so, and even measurement doesn't affect these guys, a good system can do rt-preempt and less than 10 us , under load, infact less jitter under heavy load than RTAI or xenomai, ( perhaps not less jitter, but smaller worst cases ). I don't get it, there is a realtime kernel in debian, and ubuntu and so on now that we have a sane build with the realtime dependent parts in libraries which can be loaded at runtime this happens. Abandon all hope ! 2014-04-02 22:13 GMT+02:00 EBo e...@sandien.com: Oh good god... Is there any way this could be brought in some how? On Apr 2 2014 2:09 PM, Lars Segerlund wrote: Great, so no unified build ... this means rt-preemt is also not in emc 2.6 progress Please say I'm to pessimistic ? :-D / Lars Segerlund. 2014-04-02 8:50 GMT+02:00 Sebastian Kuzminsky s...@highlab.com: I am pleased to announce the creation of a branch for stabilizing and releasing LinuxCNC 2.6. This marks the beginning of the 2.6 release process. Look for a 2.6.0~pre1 pre-release in the near future. The 2.6 branch does not contain either of the two big, hotly anticipated merge candidates, joints-axes and unified-build-candidate. It is my (unpopular) opinion that both of these branches require additional work to be release-ready, and i don't want to hold up the 2.6 release any longer. It's been two years since 2.5.0 and that's way too long. There are good features that are ready to release today, so I want to get those out to users while we finish up the next round of features for the next release. Both branches are candidates for a future 2.7 release (as is Robert Ellenberg's new trajectory planner). I intend for the 2.7 release cycle to be much shorter than 2.6 was, and i intend to keep working with everyone's help to make ready the features in the pipeline for 2.7. But for now I ask for everyone's help in getting 2.6 out. Breaking with tradition, the 2.6 branch is called, simply, 2.6. Bug fixes are welcome in 2.6 (or in v2.5_branch if appropriate), as are new components and drivers, but commits that potentially destabilize existing functionality should be reviewed before being pushed to the release branch. The 2.6 release is targeting the following platforms: Realtime (RTAI): Ubuntu Lucid (32-bit, Linux 2.6.32) Ubuntu Precise (32-bit, Linux 3.4) Debian Wheezy (32-bit, Linux 3.4) Simulation: Ubuntu Lucid Ubuntu Precise Debian Wheezy Ubuntu Hardy (RTAI and simulation) is not currently supported because of a build dependency of the new xhc-hb04 driver. If there is user desire for 2.6 on Hardy we can disable that driver on Hardy (while still shipping that driver on the newer platforms). Work remaining/request for help: Testing - especially be on the lookout for any needed config changes Squashing of bugs (https://sf.net/p/emc/bugs/milestone/2.6/) Building of new Live CDs (for both Precise and Wheezy) Proof-reading the docs -- Sebastian Kuzminsky -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New Trajectory Planner
This is what I was expecting also... (big changes needs a lot of testing before release) (and this was started during the 2.6 work...) sam On 04/01/2014 03:45 PM, Sebastian Kuzminsky wrote: On 4/1/14 14:27 , Marius Liebenberg wrote: What was the verdict then, is this work going to be incorporated somewhere in the near future or will we have to wait until Robert has done more to it? I'm not sure exactly what state it's in currently. After i make the 2.6 branch I hope to speak with Sam Sokolik and Robert Ellenberg and see where things stand. I'm hoping to merge it into master for the following (2.7) release cycle (which will hopefully be much shorter than 2.6 was/is). -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New Trajectory Planner
inital testing now the feed override acts as expected. (This is going from 100% to 90%) http://imagebin.org/302341 I still see the same ripples when the maximim velocity is turned down. (ie - 20ipm sees peaks of 27ipm) http://imagebin.org/302342 on thing - it seems to be failing a run test now. 'subroutine-return' Great work! sam On 3/27/2014 10:56 PM, Robert Ellenberg wrote: I just added another vLimit check on the final velocity as well, which I think will clean up those ripples. Gotta love problems where copy+paste is the solution! Also, after a bit of digging, I think the dips issue was due to the way feed override was being applied. I changed it so that it would scale the requested feed rate instead of the actual feed rate, and now it behaves as you would expect. Doing so meant changing how the target velocity was calculated though, so let me know if you see any unexpected changes. On Thu, Mar 27, 2014 at 10:57 PM, sam sokolik sa...@empirescreen.comwrote: I did a quick test - Doesn't run full speed now. There are some spikes (if I have the MV slider set to 20ipm - I see spikes to 20.7) I don't know if it is an issue or not. (I don't think it would bother me..) http://imagebin.org/302238 sam On 03/27/2014 09:36 PM, Robert Ellenberg wrote: Good catch! It wasn't checking the slider max velocity (tp.vLimit) when doing ramped velocity, so those sections ran at full speed. The latest push to the RC3 branch should fix that. On Thu, Mar 27, 2014 at 9:59 PM, sam sokolik sa...@empirescreen.com wrote: here is a video showing the jumping of the velocity. (we cobbled together an old terco trainer to play with) http://www.youtube.com/watch?v=4Mz7tzVSsYkfeature=youtu.be here is the little machine running the penguin as fast as it can go.. (with the setting we had) it seems go gain z hight (about .030 each run) - but our wiring is so bad that I am surprised it works as good as it does. http://www.youtube.com/watch?v=Qp0ZpxsgxVs The new tp ran the penguin in 1:40 vs 2:20. (lots of strait lines that run the same with both planners) sam On 03/27/2014 05:48 PM, sa...@empirescreen.com wrote: one more thing - maximum velocity slider doesn't seem to be obeyed. some of the time it is - but take the 3dchips and have the feedrate set very high. now run the maximum velocity slider to say 10 ipm. when it gets to sections of short line segments - it take off and goes at a much higher feedrate.. sam On Wed, 26 Mar 2014 15:03:50 -0500 sam sokolik sa...@empirescreen.com wrote: here is 50% (1750mm/min) http://imagebin.org/301967 sam On 03/26/2014 02:49 PM, Robert Ellenberg wrote: One thing I noticed... Lets say we are running that profile at 3500mm/s and it is dipping like this http://imagebin.org/301375 if you slow the feedrate down - the dips get scaled also. I would think at 3200mm/min it would flatten out. :) (probably another nit-pick) That's a good point, it shouldn't scale proportionally at lower feeds. Does that keep happening at slower feeds like 3000 or 2500? If so, it might mean that something's being limited that doesn't need to be. -Rob sam On 3/26/2014 1:27 PM, Robert Ellenberg wrote: Hi Sam, This acceleration limitation is by design, so that the TP can deal with tangential and normal acceleration separately. On a circular arc segment, the acceleration along the path is limited to 0.5 * a_max. Using the pythagorean theorem, the maximum normal acceleration is: sqrt( a_max^2 - (1/2*a_max) ^2 ) = sqrt(3/2) * a_max ~= .866 * a_max So, if your maximum axis acceleration is 30 in/sec^2, then the TP only moves fast enough around the arc to create 25.98 in/sec^2 of normal acceleration. This way, if you have to speed up or slow down during an arc move, the total acceleration it won't exceed the machine maximum. A good analogy is high-speed cornering with a car on a twisty road. There's a maximum speed you can go around the corner before the tires slip. However, if you actually drive at that speed and have to hit the brakes, you're in trouble :). So, to be safe, you go a little slower so that you can slow down if need be. The good news is, this particular limit on tangential vs. cornering acceleration gets you pretty close to top speed. For example, on a 0.1 radius, a max normal acceleration of 26 in/sec^2 gives you a max speed of sqrt( 26 in/sec^2 * 0.1 in) ~= 1.61 in/sec. Compare that to 30 in/sec^2, which gives you sqrt( 30 in/sec^2 * 0.1 in) ~= 1.73 in/sec (about 7% difference). I just hard-coded this because it seemed to give me the best speed on my test runs. Maybe it could be an INI parameter? You could potentially get a little performance from a program with lots of circular arcs by reducing the tangential acceleration in favor of normal acceleration. Conversely, making tangential and normal acceleration both sqrt(2) * a_max might move more quickly
Re: [Emc-developers] New Trajectory Planner
adaptive-feed seems to work as expected.. This is setting it from 1 to .5 http://imagebin.org/302346 sam On 3/28/2014 5:42 AM, andy pugh wrote: On 28 March 2014 02:57, sam sokolik sa...@empirescreen.com wrote: I did a quick test - Doesn't run full speed now. There are some spikes (if I have the MV slider set to 20ipm Have you checked adaptive-feed? -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New Trajectory Planner
here is a video showing the jumping of the velocity. (we cobbled together an old terco trainer to play with) http://www.youtube.com/watch?v=4Mz7tzVSsYkfeature=youtu.be here is the little machine running the penguin as fast as it can go.. (with the setting we had) it seems go gain z hight (about .030 each run) - but our wiring is so bad that I am surprised it works as good as it does. http://www.youtube.com/watch?v=Qp0ZpxsgxVs The new tp ran the penguin in 1:40 vs 2:20. (lots of strait lines that run the same with both planners) sam On 03/27/2014 05:48 PM, sa...@empirescreen.com wrote: one more thing - maximum velocity slider doesn't seem to be obeyed. some of the time it is - but take the 3dchips and have the feedrate set very high. now run the maximum velocity slider to say 10 ipm. when it gets to sections of short line segments - it take off and goes at a much higher feedrate.. sam On Wed, 26 Mar 2014 15:03:50 -0500 sam sokolik sa...@empirescreen.com wrote: here is 50% (1750mm/min) http://imagebin.org/301967 sam On 03/26/2014 02:49 PM, Robert Ellenberg wrote: One thing I noticed... Lets say we are running that profile at 3500mm/s and it is dipping like this http://imagebin.org/301375 if you slow the feedrate down - the dips get scaled also. I would think at 3200mm/min it would flatten out. :) (probably another nit-pick) That's a good point, it shouldn't scale proportionally at lower feeds. Does that keep happening at slower feeds like 3000 or 2500? If so, it might mean that something's being limited that doesn't need to be. -Rob sam On 3/26/2014 1:27 PM, Robert Ellenberg wrote: Hi Sam, This acceleration limitation is by design, so that the TP can deal with tangential and normal acceleration separately. On a circular arc segment, the acceleration along the path is limited to 0.5 * a_max. Using the pythagorean theorem, the maximum normal acceleration is: sqrt( a_max^2 - (1/2*a_max) ^2 ) = sqrt(3/2) * a_max ~= .866 * a_max So, if your maximum axis acceleration is 30 in/sec^2, then the TP only moves fast enough around the arc to create 25.98 in/sec^2 of normal acceleration. This way, if you have to speed up or slow down during an arc move, the total acceleration it won't exceed the machine maximum. A good analogy is high-speed cornering with a car on a twisty road. There's a maximum speed you can go around the corner before the tires slip. However, if you actually drive at that speed and have to hit the brakes, you're in trouble :). So, to be safe, you go a little slower so that you can slow down if need be. The good news is, this particular limit on tangential vs. cornering acceleration gets you pretty close to top speed. For example, on a 0.1 radius, a max normal acceleration of 26 in/sec^2 gives you a max speed of sqrt( 26 in/sec^2 * 0.1 in) ~= 1.61 in/sec. Compare that to 30 in/sec^2, which gives you sqrt( 30 in/sec^2 * 0.1 in) ~= 1.73 in/sec (about 7% difference). I just hard-coded this because it seemed to give me the best speed on my test runs. Maybe it could be an INI parameter? You could potentially get a little performance from a program with lots of circular arcs by reducing the tangential acceleration in favor of normal acceleration. Conversely, making tangential and normal acceleration both sqrt(2) * a_max might move more quickly in programs with a lot of detail like stellabee1.ngc. -Rob On Mon, Mar 24, 2014 at 2:47 PM, sam sokolik sa...@empirescreen.com wrote: I have a question about the acceleration limits. (and I might be nit-picking here) But I have been goofing around with the trochoidal.ngc file from http://www.vagrearg.org/gcmc/trochoidal.ngc.gz I see when I push the velocity up to 3500mm/min - the peak velocity starts to dip (this is with 30in/s^2 acc) http://imagebin.org/301375 but you can see that the acc doesn't get to 30in/s^2 - it seems to peak at about 26 or so. I did play around with the gap freq in the ini file (setting it to my servo period of 1000) and it may have helped just a little bit. http://imagebin.org/301376 (acc peaks just a little higher) is this just a limitation of the whole system? It it still way way better than the current tp - but was wondering what was causing this. sam -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Learn Graph Databases - Download FREE
Re: [Emc-developers] New Trajectory Planner
hey! aren’t you supposed to be studying? ;) That was quick - thank you! sam On 03/27/2014 09:36 PM, Robert Ellenberg wrote: Good catch! It wasn't checking the slider max velocity (tp.vLimit) when doing ramped velocity, so those sections ran at full speed. The latest push to the RC3 branch should fix that. On Thu, Mar 27, 2014 at 9:59 PM, sam sokolik sa...@empirescreen.com wrote: here is a video showing the jumping of the velocity. (we cobbled together an old terco trainer to play with) http://www.youtube.com/watch?v=4Mz7tzVSsYkfeature=youtu.be here is the little machine running the penguin as fast as it can go.. (with the setting we had) it seems go gain z hight (about .030 each run) - but our wiring is so bad that I am surprised it works as good as it does. http://www.youtube.com/watch?v=Qp0ZpxsgxVs The new tp ran the penguin in 1:40 vs 2:20. (lots of strait lines that run the same with both planners) sam On 03/27/2014 05:48 PM, sa...@empirescreen.com wrote: one more thing - maximum velocity slider doesn't seem to be obeyed. some of the time it is - but take the 3dchips and have the feedrate set very high. now run the maximum velocity slider to say 10 ipm. when it gets to sections of short line segments - it take off and goes at a much higher feedrate.. sam On Wed, 26 Mar 2014 15:03:50 -0500 sam sokolik sa...@empirescreen.com wrote: here is 50% (1750mm/min) http://imagebin.org/301967 sam On 03/26/2014 02:49 PM, Robert Ellenberg wrote: One thing I noticed... Lets say we are running that profile at 3500mm/s and it is dipping like this http://imagebin.org/301375 if you slow the feedrate down - the dips get scaled also. I would think at 3200mm/min it would flatten out. :) (probably another nit-pick) That's a good point, it shouldn't scale proportionally at lower feeds. Does that keep happening at slower feeds like 3000 or 2500? If so, it might mean that something's being limited that doesn't need to be. -Rob sam On 3/26/2014 1:27 PM, Robert Ellenberg wrote: Hi Sam, This acceleration limitation is by design, so that the TP can deal with tangential and normal acceleration separately. On a circular arc segment, the acceleration along the path is limited to 0.5 * a_max. Using the pythagorean theorem, the maximum normal acceleration is: sqrt( a_max^2 - (1/2*a_max) ^2 ) = sqrt(3/2) * a_max ~= .866 * a_max So, if your maximum axis acceleration is 30 in/sec^2, then the TP only moves fast enough around the arc to create 25.98 in/sec^2 of normal acceleration. This way, if you have to speed up or slow down during an arc move, the total acceleration it won't exceed the machine maximum. A good analogy is high-speed cornering with a car on a twisty road. There's a maximum speed you can go around the corner before the tires slip. However, if you actually drive at that speed and have to hit the brakes, you're in trouble :). So, to be safe, you go a little slower so that you can slow down if need be. The good news is, this particular limit on tangential vs. cornering acceleration gets you pretty close to top speed. For example, on a 0.1 radius, a max normal acceleration of 26 in/sec^2 gives you a max speed of sqrt( 26 in/sec^2 * 0.1 in) ~= 1.61 in/sec. Compare that to 30 in/sec^2, which gives you sqrt( 30 in/sec^2 * 0.1 in) ~= 1.73 in/sec (about 7% difference). I just hard-coded this because it seemed to give me the best speed on my test runs. Maybe it could be an INI parameter? You could potentially get a little performance from a program with lots of circular arcs by reducing the tangential acceleration in favor of normal acceleration. Conversely, making tangential and normal acceleration both sqrt(2) * a_max might move more quickly in programs with a lot of detail like stellabee1.ngc. -Rob On Mon, Mar 24, 2014 at 2:47 PM, sam sokolik sa...@empirescreen.com wrote: I have a question about the acceleration limits. (and I might be nit-picking here) But I have been goofing around with the trochoidal.ngc file from http://www.vagrearg.org/gcmc/trochoidal.ngc.gz I see when I push the velocity up to 3500mm/min - the peak velocity starts to dip (this is with 30in/s^2 acc) http://imagebin.org/301375 but you can see that the acc doesn't get to 30in/s^2 - it seems to peak at about 26 or so. I did play around with the gap freq in the ini file (setting it to my servo period of 1000) and it may have helped just a little bit. http://imagebin.org/301376 (acc peaks just a little higher) is this just a limitation of the whole system? It it still way way better than the current tp - but was wondering what was causing this. sam -- 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
Re: [Emc-developers] New Trajectory Planner
I did a quick test - Doesn't run full speed now. There are some spikes (if I have the MV slider set to 20ipm - I see spikes to 20.7) I don't know if it is an issue or not. (I don't think it would bother me..) http://imagebin.org/302238 sam On 03/27/2014 09:36 PM, Robert Ellenberg wrote: Good catch! It wasn't checking the slider max velocity (tp.vLimit) when doing ramped velocity, so those sections ran at full speed. The latest push to the RC3 branch should fix that. On Thu, Mar 27, 2014 at 9:59 PM, sam sokolik sa...@empirescreen.com wrote: here is a video showing the jumping of the velocity. (we cobbled together an old terco trainer to play with) http://www.youtube.com/watch?v=4Mz7tzVSsYkfeature=youtu.be here is the little machine running the penguin as fast as it can go.. (with the setting we had) it seems go gain z hight (about .030 each run) - but our wiring is so bad that I am surprised it works as good as it does. http://www.youtube.com/watch?v=Qp0ZpxsgxVs The new tp ran the penguin in 1:40 vs 2:20. (lots of strait lines that run the same with both planners) sam On 03/27/2014 05:48 PM, sa...@empirescreen.com wrote: one more thing - maximum velocity slider doesn't seem to be obeyed. some of the time it is - but take the 3dchips and have the feedrate set very high. now run the maximum velocity slider to say 10 ipm. when it gets to sections of short line segments - it take off and goes at a much higher feedrate.. sam On Wed, 26 Mar 2014 15:03:50 -0500 sam sokolik sa...@empirescreen.com wrote: here is 50% (1750mm/min) http://imagebin.org/301967 sam On 03/26/2014 02:49 PM, Robert Ellenberg wrote: One thing I noticed... Lets say we are running that profile at 3500mm/s and it is dipping like this http://imagebin.org/301375 if you slow the feedrate down - the dips get scaled also. I would think at 3200mm/min it would flatten out. :) (probably another nit-pick) That's a good point, it shouldn't scale proportionally at lower feeds. Does that keep happening at slower feeds like 3000 or 2500? If so, it might mean that something's being limited that doesn't need to be. -Rob sam On 3/26/2014 1:27 PM, Robert Ellenberg wrote: Hi Sam, This acceleration limitation is by design, so that the TP can deal with tangential and normal acceleration separately. On a circular arc segment, the acceleration along the path is limited to 0.5 * a_max. Using the pythagorean theorem, the maximum normal acceleration is: sqrt( a_max^2 - (1/2*a_max) ^2 ) = sqrt(3/2) * a_max ~= .866 * a_max So, if your maximum axis acceleration is 30 in/sec^2, then the TP only moves fast enough around the arc to create 25.98 in/sec^2 of normal acceleration. This way, if you have to speed up or slow down during an arc move, the total acceleration it won't exceed the machine maximum. A good analogy is high-speed cornering with a car on a twisty road. There's a maximum speed you can go around the corner before the tires slip. However, if you actually drive at that speed and have to hit the brakes, you're in trouble :). So, to be safe, you go a little slower so that you can slow down if need be. The good news is, this particular limit on tangential vs. cornering acceleration gets you pretty close to top speed. For example, on a 0.1 radius, a max normal acceleration of 26 in/sec^2 gives you a max speed of sqrt( 26 in/sec^2 * 0.1 in) ~= 1.61 in/sec. Compare that to 30 in/sec^2, which gives you sqrt( 30 in/sec^2 * 0.1 in) ~= 1.73 in/sec (about 7% difference). I just hard-coded this because it seemed to give me the best speed on my test runs. Maybe it could be an INI parameter? You could potentially get a little performance from a program with lots of circular arcs by reducing the tangential acceleration in favor of normal acceleration. Conversely, making tangential and normal acceleration both sqrt(2) * a_max might move more quickly in programs with a lot of detail like stellabee1.ngc. -Rob On Mon, Mar 24, 2014 at 2:47 PM, sam sokolik sa...@empirescreen.com wrote: I have a question about the acceleration limits. (and I might be nit-picking here) But I have been goofing around with the trochoidal.ngc file from http://www.vagrearg.org/gcmc/trochoidal.ngc.gz I see when I push the velocity up to 3500mm/min - the peak velocity starts to dip (this is with 30in/s^2 acc) http://imagebin.org/301375 but you can see that the acc doesn't get to 30in/s^2 - it seems to peak at about 26 or so. I did play around with the gap freq in the ini file (setting it to my servo period of 1000) and it may have helped just a little bit. http://imagebin.org/301376 (acc peaks just a little higher) is this just a limitation of the whole system? It it still way way better than the current tp - but was wondering what was causing this. sam -- Learn
Re: [Emc-developers] New Trajectory Planner
Clear as mud :) I only sort of understand it. (that is ok though - and why I don't do any trajectory work) I was wondering because mach seems to run the profile full speed (no dips) at 3600mm/min vs the new TP starts to dip a bit above 3200mm/min. That is approaching the 12% I suppose. (assuming it is violating it..) Mach with feed set to 3600 (although looking at it - it seems to be actually going about 3400mm/min.. Huh.) so that is only around 7%... http://imagebin.org/301962 linuxcnc at 3200ipm.. closer to mach than I thought.. http://imagebin.org/301961 linuxcnc at 3600mm/min. (notice it peaks at 3600) http://imagebin.org/301960 so - not a problem I guess... :) One thing I noticed... Lets say we are running that profile at 3500mm/s and it is dipping like this http://imagebin.org/301375 if you slow the feedrate down - the dips get scaled also. I would think at 3200mm/min it would flatten out. :) (probably another nit-pick) sam On 3/26/2014 1:27 PM, Robert Ellenberg wrote: Hi Sam, This acceleration limitation is by design, so that the TP can deal with tangential and normal acceleration separately. On a circular arc segment, the acceleration along the path is limited to 0.5 * a_max. Using the pythagorean theorem, the maximum normal acceleration is: sqrt( a_max^2 - (1/2*a_max) ^2 ) = sqrt(3/2) * a_max ~= .866 * a_max So, if your maximum axis acceleration is 30 in/sec^2, then the TP only moves fast enough around the arc to create 25.98 in/sec^2 of normal acceleration. This way, if you have to speed up or slow down during an arc move, the total acceleration it won't exceed the machine maximum. A good analogy is high-speed cornering with a car on a twisty road. There's a maximum speed you can go around the corner before the tires slip. However, if you actually drive at that speed and have to hit the brakes, you're in trouble :). So, to be safe, you go a little slower so that you can slow down if need be. The good news is, this particular limit on tangential vs. cornering acceleration gets you pretty close to top speed. For example, on a 0.1 radius, a max normal acceleration of 26 in/sec^2 gives you a max speed of sqrt( 26 in/sec^2 * 0.1 in) ~= 1.61 in/sec. Compare that to 30 in/sec^2, which gives you sqrt( 30 in/sec^2 * 0.1 in) ~= 1.73 in/sec (about 7% difference). I just hard-coded this because it seemed to give me the best speed on my test runs. Maybe it could be an INI parameter? You could potentially get a little performance from a program with lots of circular arcs by reducing the tangential acceleration in favor of normal acceleration. Conversely, making tangential and normal acceleration both sqrt(2) * a_max might move more quickly in programs with a lot of detail like stellabee1.ngc. -Rob On Mon, Mar 24, 2014 at 2:47 PM, sam sokolik sa...@empirescreen.com wrote: I have a question about the acceleration limits. (and I might be nit-picking here) But I have been goofing around with the trochoidal.ngc file from http://www.vagrearg.org/gcmc/trochoidal.ngc.gz I see when I push the velocity up to 3500mm/min - the peak velocity starts to dip (this is with 30in/s^2 acc) http://imagebin.org/301375 but you can see that the acc doesn't get to 30in/s^2 - it seems to peak at about 26 or so. I did play around with the gap freq in the ini file (setting it to my servo period of 1000) and it may have helped just a little bit. http://imagebin.org/301376 (acc peaks just a little higher) is this just a limitation of the whole system? It it still way way better than the current tp - but was wondering what was causing this. sam -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New Trajectory Planner
here is 50% (1750mm/min) http://imagebin.org/301967 sam On 03/26/2014 02:49 PM, Robert Ellenberg wrote: One thing I noticed... Lets say we are running that profile at 3500mm/s and it is dipping like this http://imagebin.org/301375 if you slow the feedrate down - the dips get scaled also. I would think at 3200mm/min it would flatten out. :) (probably another nit-pick) That's a good point, it shouldn't scale proportionally at lower feeds. Does that keep happening at slower feeds like 3000 or 2500? If so, it might mean that something's being limited that doesn't need to be. -Rob sam On 3/26/2014 1:27 PM, Robert Ellenberg wrote: Hi Sam, This acceleration limitation is by design, so that the TP can deal with tangential and normal acceleration separately. On a circular arc segment, the acceleration along the path is limited to 0.5 * a_max. Using the pythagorean theorem, the maximum normal acceleration is: sqrt( a_max^2 - (1/2*a_max) ^2 ) = sqrt(3/2) * a_max ~= .866 * a_max So, if your maximum axis acceleration is 30 in/sec^2, then the TP only moves fast enough around the arc to create 25.98 in/sec^2 of normal acceleration. This way, if you have to speed up or slow down during an arc move, the total acceleration it won't exceed the machine maximum. A good analogy is high-speed cornering with a car on a twisty road. There's a maximum speed you can go around the corner before the tires slip. However, if you actually drive at that speed and have to hit the brakes, you're in trouble :). So, to be safe, you go a little slower so that you can slow down if need be. The good news is, this particular limit on tangential vs. cornering acceleration gets you pretty close to top speed. For example, on a 0.1 radius, a max normal acceleration of 26 in/sec^2 gives you a max speed of sqrt( 26 in/sec^2 * 0.1 in) ~= 1.61 in/sec. Compare that to 30 in/sec^2, which gives you sqrt( 30 in/sec^2 * 0.1 in) ~= 1.73 in/sec (about 7% difference). I just hard-coded this because it seemed to give me the best speed on my test runs. Maybe it could be an INI parameter? You could potentially get a little performance from a program with lots of circular arcs by reducing the tangential acceleration in favor of normal acceleration. Conversely, making tangential and normal acceleration both sqrt(2) * a_max might move more quickly in programs with a lot of detail like stellabee1.ngc. -Rob On Mon, Mar 24, 2014 at 2:47 PM, sam sokolik sa...@empirescreen.com wrote: I have a question about the acceleration limits. (and I might be nit-picking here) But I have been goofing around with the trochoidal.ngc file from http://www.vagrearg.org/gcmc/trochoidal.ngc.gz I see when I push the velocity up to 3500mm/min - the peak velocity starts to dip (this is with 30in/s^2 acc) http://imagebin.org/301375 but you can see that the acc doesn't get to 30in/s^2 - it seems to peak at about 26 or so. I did play around with the gap freq in the ini file (setting it to my servo period of 1000) and it may have helped just a little bit. http://imagebin.org/301376 (acc peaks just a little higher) is this just a limitation of the whole system? It it still way way better than the current tp - but was wondering what was causing this. sam -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New Trajectory Planner
I have a question about the acceleration limits. (and I might be nit-picking here) But I have been goofing around with the trochoidal.ngc file from http://www.vagrearg.org/gcmc/trochoidal.ngc.gz I see when I push the velocity up to 3500mm/min - the peak velocity starts to dip (this is with 30in/s^2 acc) http://imagebin.org/301375 but you can see that the acc doesn't get to 30in/s^2 - it seems to peak at about 26 or so. I did play around with the gap freq in the ini file (setting it to my servo period of 1000) and it may have helped just a little bit. http://imagebin.org/301376 (acc peaks just a little higher) is this just a limitation of the whole system? It it still way way better than the current tp - but was wondering what was causing this. sam On 3/21/2014 2:14 PM, Robert Ellenberg wrote: I haven't implemented arc blending with more than 3 axes yet. However, the last big refactor will make it easier to do that in the future. The big obstacle is that it requires changing how the trajectory planner treats velocity and arc length internally. Right now, the path progress and velocity only consider XYZ motion, and the other axes follow proportionally. To get arc blending to work with other axes, the planner needs to consider all 9 axes when calculating path progress and velocity. It's not as scary as it sounds, since most of the math is the same. However, it means a lot of small changes in the TP. Unfortunately, my schedule is filling fast as I wrap up grad school, so it will be at least two months before I can tackle big changes like this. Still, when I do get the time, it'll be nice to implement. Rob On Mar 21, 2014 2:56 PM, John Thornton bjt...@gmail.com wrote: I have a friend that is very interested in the new trajectory planner with an X, Z, A machine. Is there any development on the A axis? Thanks JT -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New Trajectory Planner
I hope you can get credit somehow for the work you have done on linuxcnc! Let us know if you need anything. sam On 03/21/2014 08:44 PM, Jon Elson wrote: On 3/21/2014 2:14 PM, Robert Ellenberg wrote: Unfortunately, my schedule is filling fast as I wrap up grad school, so it will be at least two months before I can tackle big changes like this. Still, when I do get the time, it'll be nice to implement. If you never do another thing on LinuxCNC, you will still line up in the pantheon of guys who have made MAJOR contributions to LinuxCNC! This has been a long-standing deficit that people who did high-speed machining and contouring always ran into. I don't in any way want to discourage any future extensions on your work, but getting the degree finished is always a long slog! Jon -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Circular blend arc RC1 pushed
well - I cannot get it to do it on a different reatime build.. So maybe it is something odd with that setup... I will keep playing with it., sam // On 3/17/2014 9:03 PM, sam sokolik wrote: rob - I am seeing something odd with the realtime builds. Could there be a difference? I cannot get the sim on the laptop to act the same. If x and y velocitys are set to 2.33ips - and z is set to .833 - there is a section of steve.ngc (about 1/3 of the way in) that runs slower - like 120ipm. (sorry - I did not have halscope setup) when I set Z to 2.33 - the slow down goes away. Sim runs the same config with no slow down.. thank sam On 03/17/2014 12:51 PM, Robert Ellenberg wrote: I think one can argue both ways John. Basically I just wanted to throw it out there and see if it sticks. :) You are of coarse correct because I can still set the F to what my machine can do, and running smoother is always going to be faster. Those little near stops of millisecond duration when turning a corner have been known to make the 24 steel kitchen base cabinet mine is sitting on dance a bit. Gene, to clarify a bit, the only reason we're seeing those velocity humps is because we're pushing the path as fast as it will go. Since the requested feed rate is far above what the machine config can actually do, the feed that the trajectory planner produces is limited by the maximum velocities of each segment. The trajectory planner will never exceed your requested feed rate (other than by feed override), so you won't see those humps at a reasonable feed rate. You might benefit from the ramp frequency setting in the new TP. I talked about this in the forum posthttp://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=130#44474, but basically, it reduces jerks by using constant acceleration during short segments. If you set the frequency lower, it will smooth more aggressively. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Circular blend arc RC1 pushed
Should have posted a screen shot.. http://imagebin.org/299652 quite a bit better - runs in 13 sec vs 24 before the fix... great work! sam On 03/15/2014 09:42 PM, Robert Ellenberg wrote: I think I found the problem. My refactor of the code that calculates arc feed in canon assumed that CANON_AXIS_# was zero-indexed. As a result, it was looking at the wrong pair of axes when finding limits. Does anyone know why the constants in canon.hh typically start at one instead of zero? It makes using these constants as indices of an array more difficult, particular with modular arithmetic. Similarly, there seem to be a bunch of enums that would do that already there, but commented out. On Mar 15, 2014 3:10 PM, sa...@empirescreen.com wrote: both master and 2.5.3 act the same to me. (I don't think the current tp has had any changes for a long time..) sam On Sat, 15 Mar 2014 15:06:38 -0400 Robert Ellenberg rwe...@gmail.com wrote: By current, do you mean 2.5.3, or master? I'd like to run that comparison myself to see what's going on. It shouldn't be limited by Z axis velocity at all with the new calculation, if the move is X and Y only. On Mar 15, 2014 3:01 PM, sa...@empirescreen.com wrote: I think there is still an issue on how it picks calculates the max velocity for a move when there are slower axis's. Looking at steve.ngc again - if I make both x and y at 140ipm - and z is at 50ipm - it runs the whole profile at 50ipm (with a few short spikes faster..) I could not log the whole run because of the speed.. http://imagebin.org/299492 Even if I have no z moves in the profile - it still runs mostly at 50ipm If I set the z axis so it is the same velocity - then it works as expected. (runs the profile at 140ipm) The current TP actually does better trying to get at the 140ipm - just a lot more jerky as it slows down for the blends.. it runs it quite a bit faster.. 18 vs 24sec http://imagebin.org/299491 thanks! sam On Wed, 12 Mar 2014 09:29:15 -0500 sam sokolik sa...@empirescreen.com wrote: Yay! Thanks rob! I found out from seb that scratch debs get deleted after 1 week. (but we can force a rebuild) He is thinking of making the time frame longer. sam On 3/11/2014 11:21 PM, Robert Ellenberg wrote: I just updated the RC3 branch with the latest experimental stuff. I'm not sure what happened to the debs, but since I pushed new commits, I think they're in the queue to be built. The name will be different, so I'll post a link to the 10.04 deb when it's done. All the scratch debs for 10.04 RT are here if you want to take a look: http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/ On Tue, Mar 11, 2014 at 10:50 PM, sam sokolik sa...@empirescreen.com wrote: Ok - I was just going to point someone to the Debs - but they don't seem to be there... (and I don't understand how to find out why ;) ) http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/binary-i386/linuxcnc_2.6.0~pre~circular.blend.arc.rc3~12a6c8b_i386.deb also - rob - are you going to push the experimental3 changes to rc3? sam On 03/05/2014 09:08 PM, Robert Ellenberg wrote: Thanks to Seb's help, circular-blend-arc-rc3 is now available as a debian package in the scratch/rt and scratch/sim folders. The suffix is RC3 instead of RC1 because I rebased a few times until we found a master commit that passed all the tests. Since I made a bit of a mess pushing these branches, I'd like to clean up a bit by deleting circular-blend-arc-rc1. It's been supersede by RC3, so leaving it in the repo will just cause confusion. My plan is to delete it by this Friday unless someone objects. In the meantime, for anyone who was holding out for the debian packages, you should be able to test the new TP. For safety, please run any programs in a simulation build before risking your expensive hardware :) Setting up is pretty straightforward: 1) Download and install the .deb file for your system. 10.04 32 bit RT: http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/binary-i386/linuxcnc_2.6.0~pre~circular.blend.arc.rc3~12a6c8b_i386.deb 10.04 32 bit sim: http://buildbot.linuxcnc.org/dists/lucid/scratch-sim/binary-i386/linuxcnc-sim_2.6.0~pre~circular.blend.arc.rc3~12a6c8b_i386.deb For other builds, go here and find your distribution / architecture: http://buildbot.linuxcnc.org/dists/ 2) Update your machine configuration (ini file) with the following settings under [TRAJ]: ARC_BLEND_ENABLE = 1 ARC_BLEND_FALLBACK_ENABLE = 0 ARC_BLEND_OPTIMIZATION_DEPTH = 50 ARC_BLEND_GAP_CYCLES = 4 ARC_BLEND_RAMP_FREQ = 20 For more detail on what these settings mean, look here: http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=120#44419 http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=130#44474 On Wed, Mar
Re: [Emc-developers] Circular blend arc RC1 pushed
I just did some quick checks and for sure steve.ngc runs as expected. again - great work! sam On 03/15/2014 09:42 PM, Robert Ellenberg wrote: I think I found the problem. My refactor of the code that calculates arc feed in canon assumed that CANON_AXIS_# was zero-indexed. As a result, it was looking at the wrong pair of axes when finding limits. Does anyone know why the constants in canon.hh typically start at one instead of zero? It makes using these constants as indices of an array more difficult, particular with modular arithmetic. Similarly, there seem to be a bunch of enums that would do that already there, but commented out. On Mar 15, 2014 3:10 PM, sa...@empirescreen.com wrote: both master and 2.5.3 act the same to me. (I don't think the current tp has had any changes for a long time..) sam On Sat, 15 Mar 2014 15:06:38 -0400 Robert Ellenberg rwe...@gmail.com wrote: By current, do you mean 2.5.3, or master? I'd like to run that comparison myself to see what's going on. It shouldn't be limited by Z axis velocity at all with the new calculation, if the move is X and Y only. On Mar 15, 2014 3:01 PM, sa...@empirescreen.com wrote: I think there is still an issue on how it picks calculates the max velocity for a move when there are slower axis's. Looking at steve.ngc again - if I make both x and y at 140ipm - and z is at 50ipm - it runs the whole profile at 50ipm (with a few short spikes faster..) I could not log the whole run because of the speed.. http://imagebin.org/299492 Even if I have no z moves in the profile - it still runs mostly at 50ipm If I set the z axis so it is the same velocity - then it works as expected. (runs the profile at 140ipm) The current TP actually does better trying to get at the 140ipm - just a lot more jerky as it slows down for the blends.. it runs it quite a bit faster.. 18 vs 24sec http://imagebin.org/299491 thanks! sam On Wed, 12 Mar 2014 09:29:15 -0500 sam sokolik sa...@empirescreen.com wrote: Yay! Thanks rob! I found out from seb that scratch debs get deleted after 1 week. (but we can force a rebuild) He is thinking of making the time frame longer. sam On 3/11/2014 11:21 PM, Robert Ellenberg wrote: I just updated the RC3 branch with the latest experimental stuff. I'm not sure what happened to the debs, but since I pushed new commits, I think they're in the queue to be built. The name will be different, so I'll post a link to the 10.04 deb when it's done. All the scratch debs for 10.04 RT are here if you want to take a look: http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/ On Tue, Mar 11, 2014 at 10:50 PM, sam sokolik sa...@empirescreen.com wrote: Ok - I was just going to point someone to the Debs - but they don't seem to be there... (and I don't understand how to find out why ;) ) http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/binary-i386/linuxcnc_2.6.0~pre~circular.blend.arc.rc3~12a6c8b_i386.deb also - rob - are you going to push the experimental3 changes to rc3? sam On 03/05/2014 09:08 PM, Robert Ellenberg wrote: Thanks to Seb's help, circular-blend-arc-rc3 is now available as a debian package in the scratch/rt and scratch/sim folders. The suffix is RC3 instead of RC1 because I rebased a few times until we found a master commit that passed all the tests. Since I made a bit of a mess pushing these branches, I'd like to clean up a bit by deleting circular-blend-arc-rc1. It's been supersede by RC3, so leaving it in the repo will just cause confusion. My plan is to delete it by this Friday unless someone objects. In the meantime, for anyone who was holding out for the debian packages, you should be able to test the new TP. For safety, please run any programs in a simulation build before risking your expensive hardware :) Setting up is pretty straightforward: 1) Download and install the .deb file for your system. 10.04 32 bit RT: http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/binary-i386/linuxcnc_2.6.0~pre~circular.blend.arc.rc3~12a6c8b_i386.deb 10.04 32 bit sim: http://buildbot.linuxcnc.org/dists/lucid/scratch-sim/binary-i386/linuxcnc-sim_2.6.0~pre~circular.blend.arc.rc3~12a6c8b_i386.deb For other builds, go here and find your distribution / architecture: http://buildbot.linuxcnc.org/dists/ 2) Update your machine configuration (ini file) with the following settings under [TRAJ]: ARC_BLEND_ENABLE = 1 ARC_BLEND_FALLBACK_ENABLE = 0 ARC_BLEND_OPTIMIZATION_DEPTH = 50 ARC_BLEND_GAP_CYCLES = 4 ARC_BLEND_RAMP_FREQ = 20 For more detail on what these settings mean, look here: http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=120#44419 http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=130#44474 On Wed, Mar 5, 2014 at 9:42 PM, sam sokolik sa
Re: [Emc-developers] Circular blend arc RC1 pushed
Yay! Thanks rob! I found out from seb that scratch debs get deleted after 1 week. (but we can force a rebuild) He is thinking of making the time frame longer. sam On 3/11/2014 11:21 PM, Robert Ellenberg wrote: I just updated the RC3 branch with the latest experimental stuff. I'm not sure what happened to the debs, but since I pushed new commits, I think they're in the queue to be built. The name will be different, so I'll post a link to the 10.04 deb when it's done. All the scratch debs for 10.04 RT are here if you want to take a look: http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/ On Tue, Mar 11, 2014 at 10:50 PM, sam sokolik sa...@empirescreen.comwrote: Ok - I was just going to point someone to the Debs - but they don't seem to be there... (and I don't understand how to find out why ;) ) http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/binary-i386/linuxcnc_2.6.0~pre~circular.blend.arc.rc3~12a6c8b_i386.deb also - rob - are you going to push the experimental3 changes to rc3? sam On 03/05/2014 09:08 PM, Robert Ellenberg wrote: Thanks to Seb's help, circular-blend-arc-rc3 is now available as a debian package in the scratch/rt and scratch/sim folders. The suffix is RC3 instead of RC1 because I rebased a few times until we found a master commit that passed all the tests. Since I made a bit of a mess pushing these branches, I'd like to clean up a bit by deleting circular-blend-arc-rc1. It's been supersede by RC3, so leaving it in the repo will just cause confusion. My plan is to delete it by this Friday unless someone objects. In the meantime, for anyone who was holding out for the debian packages, you should be able to test the new TP. For safety, please run any programs in a simulation build before risking your expensive hardware :) Setting up is pretty straightforward: 1) Download and install the .deb file for your system. 10.04 32 bit RT: http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/binary-i386/linuxcnc_2.6.0~pre~circular.blend.arc.rc3~12a6c8b_i386.deb 10.04 32 bit sim: http://buildbot.linuxcnc.org/dists/lucid/scratch-sim/binary-i386/linuxcnc-sim_2.6.0~pre~circular.blend.arc.rc3~12a6c8b_i386.deb For other builds, go here and find your distribution / architecture: http://buildbot.linuxcnc.org/dists/ 2) Update your machine configuration (ini file) with the following settings under [TRAJ]: ARC_BLEND_ENABLE = 1 ARC_BLEND_FALLBACK_ENABLE = 0 ARC_BLEND_OPTIMIZATION_DEPTH = 50 ARC_BLEND_GAP_CYCLES = 4 ARC_BLEND_RAMP_FREQ = 20 For more detail on what these settings mean, look here: http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=120#44419 http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=130#44474 On Wed, Mar 5, 2014 at 9:42 PM, sam sokolik sa...@empirescreen.com wrote: Ok - I finally got a chance to test some more real hardware. This is a bastard router that has 3 different steppers/drive (it was a converted step/repeat machine.) I built robs latest (RC3) from the linuxcnc git and ran some of the test programs. some good news one bad. Good news. The motion is very smooth. The program I was testing was the LHchips4.ngc. It sounds very nice. http://electronicsam.com/images/KandT/testing/LHchips4.ngc I found one issue. A cutting profile containing more than 1 axis will only go as fast as the slowest axis. This machine has 3 different axis velocities X 150ipm Y 78IPM Z 50IPM On the 'belly' of chips - there are long x-z profiles (mostly X moves). The profiles would peak at 50ipm. (they should peak at something between X and Z. The current TP actually runs that profile faster (closer to 100ipm) There are long XY profiles also - they peak at 78ipm but should peak pretty close to 150ipm in some areas.. I talked to Rob about this - he said I should post here in case others have seen this issue and didn't know what was happening. He has some Ideas on solutions and will keep us posted. sam On 03/03/2014 05:12 PM, Robert Ellenberg wrote: Hi All, I just created a release candidate branch for circular arc blending: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/circular-blend-arc-rc1 It's identical to my github branch that Sam and others have been testing. There was one small hiccup in pushing the new branch: remote: fatal: bad object However, it looks like the build failed here: http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-rtpreempt-amd64/builds/193 I'm not sure how to interpret this error, but I suspect that since I forked from master back in October, there have been fixes that my branch is missing. As a possible solution, I've been able to rebase the RC branch onto the lastest master with minimal changes
Re: [Emc-developers] Circular blend arc RC1 pushed
Running programs through it (experimental3) over the last few days - no issues I have found. Great work! sam On 3/9/2014 3:05 PM, Robert Ellenberg wrote: Ok, it turned out to be a stupid mistake, and the latest commit fixes it. On Mar 9, 2014 3:52 AM, Robert Ellenberg rwe...@gmail.com wrote: Just a head's up, I think the fix I pushed recently isn't quite perfect. I noticed a small acceleration overage on one of the blend tests, but it shouldn't be hard to bisect since all the tests passed so recently. I'll keep you posted when I find the issue. On Sat, Mar 8, 2014 at 10:15 PM, sa...@empirescreen.com wrote: Have to add... It still keeps the velocity up and steadier than the current tp. Again - awesome work! On Sat, 08 Mar 2014 20:28:13 -0600 sam sokolik sa...@empirescreen.com wrote: ran the experimental3 branch on real hardware tonight. The LHchips4 sounded real good. Now it peaks across the belly at close to the y axis velocity. Very nice! Now running steve.ngc you can really see the arc issue. X is MAX_VELOCITY = 2.33 MAX_ACCELERATION = 10 Y is MAX_VELOCITY = 1.33 MAX_ACCELERATION = 15 http://imagebin.org/298016 notice the whole profile runs mostly at 1.33in/sec - with a few peaks. Now this profile has a great portion of the motion in the x axis. sam On 03/08/2014 11:50 AM, Robert Ellenberg wrote: It would be really nice to have consistent behavior between lines and arcs that way, though I think the limitation is not in the blend arcs themselves. Currently, maximum speed and acceleration are calculated in canon with conservative assumptions. For short arc segments, it should be possible to squeeze a bit more speed / acceleration out. Unfortunately, there isn't a good way to do the same thing with a large arc (like 90 deg). Since the velocity changes direction so much, the overall maximum velocity is more likely to be constrained by axis limits. One way around this could be to have CAM break up segments into short (20 deg or less) arcs. Unfortunately, to prevent slowdowns, you'd have to keep the segments longer than the minimum length for your feed (approximately 2 * v_max / servo_period). It might be possible to do something like this in canon too, though I'm not sure how hard it would be. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Learn
Re: [Emc-developers] Circular blend arc RC1 pushed
Ok - I was just going to point someone to the Debs - but they don't seem to be there... (and I don't understand how to find out why ;) ) http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/binary-i386/linuxcnc_2.6.0~pre~circular.blend.arc.rc3~12a6c8b_i386.deb also - rob - are you going to push the experimental3 changes to rc3? sam On 03/05/2014 09:08 PM, Robert Ellenberg wrote: Thanks to Seb's help, circular-blend-arc-rc3 is now available as a debian package in the scratch/rt and scratch/sim folders. The suffix is RC3 instead of RC1 because I rebased a few times until we found a master commit that passed all the tests. Since I made a bit of a mess pushing these branches, I'd like to clean up a bit by deleting circular-blend-arc-rc1. It's been supersede by RC3, so leaving it in the repo will just cause confusion. My plan is to delete it by this Friday unless someone objects. In the meantime, for anyone who was holding out for the debian packages, you should be able to test the new TP. For safety, please run any programs in a simulation build before risking your expensive hardware :) Setting up is pretty straightforward: 1) Download and install the .deb file for your system. 10.04 32 bit RT: http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/binary-i386/linuxcnc_2.6.0~pre~circular.blend.arc.rc3~12a6c8b_i386.deb 10.04 32 bit sim: http://buildbot.linuxcnc.org/dists/lucid/scratch-sim/binary-i386/linuxcnc-sim_2.6.0~pre~circular.blend.arc.rc3~12a6c8b_i386.deb For other builds, go here and find your distribution / architecture: http://buildbot.linuxcnc.org/dists/ 2) Update your machine configuration (ini file) with the following settings under [TRAJ]: ARC_BLEND_ENABLE = 1 ARC_BLEND_FALLBACK_ENABLE = 0 ARC_BLEND_OPTIMIZATION_DEPTH = 50 ARC_BLEND_GAP_CYCLES = 4 ARC_BLEND_RAMP_FREQ = 20 For more detail on what these settings mean, look here: http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=120#44419 http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=130#44474 On Wed, Mar 5, 2014 at 9:42 PM, sam sokolik sa...@empirescreen.com wrote: Ok - I finally got a chance to test some more real hardware. This is a bastard router that has 3 different steppers/drive (it was a converted step/repeat machine.) I built robs latest (RC3) from the linuxcnc git and ran some of the test programs. some good news one bad. Good news. The motion is very smooth. The program I was testing was the LHchips4.ngc. It sounds very nice. http://electronicsam.com/images/KandT/testing/LHchips4.ngc I found one issue. A cutting profile containing more than 1 axis will only go as fast as the slowest axis. This machine has 3 different axis velocities X 150ipm Y 78IPM Z 50IPM On the 'belly' of chips - there are long x-z profiles (mostly X moves). The profiles would peak at 50ipm. (they should peak at something between X and Z. The current TP actually runs that profile faster (closer to 100ipm) There are long XY profiles also - they peak at 78ipm but should peak pretty close to 150ipm in some areas.. I talked to Rob about this - he said I should post here in case others have seen this issue and didn't know what was happening. He has some Ideas on solutions and will keep us posted. sam On 03/03/2014 05:12 PM, Robert Ellenberg wrote: Hi All, I just created a release candidate branch for circular arc blending: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/circular-blend-arc-rc1 It's identical to my github branch that Sam and others have been testing. There was one small hiccup in pushing the new branch: remote: fatal: bad object However, it looks like the build failed here: http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-rtpreempt-amd64/builds/193 I'm not sure how to interpret this error, but I suspect that since I forked from master back in October, there have been fixes that my branch is missing. As a possible solution, I've been able to rebase the RC branch onto the lastest master with minimal changes. If there is a recent build that we know is solid, I can rebase my branch onto that and push it. If I go down this route, should I increment the branch's name, or just overwrite the bad branch? -Rob -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc
Re: [Emc-developers] Circular blend arc RC1 pushed
makes sense. large arcs or full circles running the same speed probably isn't a big deal. arcspiral and spiral running the same would probably be better (speeding up short arc segment with different axis velocites) if possible. (short arc style gcode) I might be able to run the latest experimental3 on a real machine today thanks again sam On 03/08/2014 11:50 AM, Robert Ellenberg wrote: It would be really nice to have consistent behavior between lines and arcs that way, though I think the limitation is not in the blend arcs themselves. Currently, maximum speed and acceleration are calculated in canon with conservative assumptions. For short arc segments, it should be possible to squeeze a bit more speed / acceleration out. Unfortunately, there isn't a good way to do the same thing with a large arc (like 90 deg). Since the velocity changes direction so much, the overall maximum velocity is more likely to be constrained by axis limits. One way around this could be to have CAM break up segments into short (20 deg or less) arcs. Unfortunately, to prevent slowdowns, you'd have to keep the segments longer than the minimum length for your feed (approximately 2 * v_max / servo_period). It might be possible to do something like this in canon too, though I'm not sure how hard it would be. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Circular blend arc RC1 pushed
ran the experimental3 branch on real hardware tonight. The LHchips4 sounded real good. Now it peaks across the belly at close to the y axis velocity. Very nice! Now running steve.ngc you can really see the arc issue. X is MAX_VELOCITY = 2.33 MAX_ACCELERATION = 10 Y is MAX_VELOCITY = 1.33 MAX_ACCELERATION = 15 http://imagebin.org/298016 notice the whole profile runs mostly at 1.33in/sec - with a few peaks. Now this profile has a great portion of the motion in the x axis. sam On 03/08/2014 11:50 AM, Robert Ellenberg wrote: It would be really nice to have consistent behavior between lines and arcs that way, though I think the limitation is not in the blend arcs themselves. Currently, maximum speed and acceleration are calculated in canon with conservative assumptions. For short arc segments, it should be possible to squeeze a bit more speed / acceleration out. Unfortunately, there isn't a good way to do the same thing with a large arc (like 90 deg). Since the velocity changes direction so much, the overall maximum velocity is more likely to be constrained by axis limits. One way around this could be to have CAM break up segments into short (20 deg or less) arcs. Unfortunately, to prevent slowdowns, you'd have to keep the segments longer than the minimum length for your feed (approximately 2 * v_max / servo_period). It might be possible to do something like this in canon too, though I'm not sure how hard it would be. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Circular blend arc RC1 pushed
Close I think.. If you look at the arcspiral vs the spiral.. Now the spiral (made up of short line segments) will increase and decrease in speed as the motion goes between the x and y axis. (x set to 500ipm y set to 180) arcspiral (and for that matter a circle) with be capped at the y axis speed. I think we would want the same behavior as the spiral made up of line segment (speed up and down as it passes bettween 2 different axis velocities.) Here is my rational.. If you have a machine that has a fast and slow axis. (be it say fast x and slow z) you would generate your engraving to run on the fastest axis. But if your cam software outputs fitted arcs - the segments will be capped by the slowest axis. (does this makes sense?) as always - awesome work! sam On 03/07/2014 03:55 PM, Robert Ellenberg wrote: On Thu, Mar 6, 2014 at 10:44 PM, sam sokolik sa...@empirescreen.com wrote: Now the issues.. Rob asked about other transistions this would be arc-arc... I do see the same issue. If I do a circle like this g20g64 g0x1y0z0 G2x1y0i-1j0f999 g0x1 m30 It peaks out at 127ipm (which doesn't quite make sense to me..) (should peak around 300 I think - atleast that is what the line segment circle does...) master runs it at 180.. maybe g2/3 circles never acc/de-acc with different axis velocities.. Arcspiral.ngc peaks at 180ipm and stays there - which is the limit of the y axis. I think the latest commit should fix that. I saw the same slowdown, and tracked it down to the function that limits maximum velocity of circular segments. I had done this a lazy way here by scaling max velocity down to sqrt(1/2) of the original value, but that's only necessary if the max velocity is limited by the normal acceleration. If the radius is large enough, reducing the acceleration for a parabolic blend won't affect the max velocity since the normal acceleration is small. Now, it checks for this explicitly and doesn't shrink the max velocity unless it has to. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Circular blend arc RC1 pushed
I got an email from Rob at about 1:00 in the morning saying he has a branch to test.. Now that is dedication! :) I tested it a bit today and I think it fixes the problem I was seeing.. Couple examples - here is what I first say (across the belly of the penguin) http://imagebin.org/297550 Notice it stays pretty steady at 60ipm(1ips) - z vel limit - when it should be going faster as most of the motion is in the x axis. (200ipm) This is with robs fix. http://imagebin.org/297549 Notice as the belly peaks (mostly x movement) the velocity peaks. This seems correct. Here is a 2 inch diameter circle made up of short line segments. This is before robs fix. http://imagebin.org/297557 Peaks at 180ipm(3ips) which is the limit of the Y axis. with robs fix http://imagebin.org/297556 You can see the velocity speeding up and slowing down (in the middle it peaks at the centripetal limit of the circle I think - around 300ipm with my acc) Now the issues.. Rob asked about other transistions this would be arc-arc... I do see the same issue. If I do a circle like this g20g64 g0x1y0z0 G2x1y0i-1j0f999 g0x1 m30 It peaks out at 127ipm (which doesn't quite make sense to me..) (should peak around 300 I think - atleast that is what the line segment circle does...) master runs it at 180.. maybe g2/3 circles never acc/de-acc with different axis velocities.. Arcspiral.ngc peaks at 180ipm and stays there - which is the limit of the y axis. I don't know about line-arc... I played with rogge.ngc but could not really figure out what was going on. it might be fine.. *But it is late... sam On 03/05/2014 10:05 PM, Robert Ellenberg wrote: Sam, another thought: Do you see this on any particular kind of intersection (line-line, arc-line, etc.)? On Wed, Mar 5, 2014 at 9:42 PM, sam sokolik sa...@empirescreen.com wrote: Ok - I finally got a chance to test some more real hardware. This is a bastard router that has 3 different steppers/drive (it was a converted step/repeat machine.) I built robs latest (RC3) from the linuxcnc git and ran some of the test programs. some good news one bad. Good news. The motion is very smooth. The program I was testing was the LHchips4.ngc. It sounds very nice. http://electronicsam.com/images/KandT/testing/LHchips4.ngc I found one issue. A cutting profile containing more than 1 axis will only go as fast as the slowest axis. This machine has 3 different axis velocities X 150ipm Y 78IPM Z 50IPM On the 'belly' of chips - there are long x-z profiles (mostly X moves). The profiles would peak at 50ipm. (they should peak at something between X and Z. The current TP actually runs that profile faster (closer to 100ipm) There are long XY profiles also - they peak at 78ipm but should peak pretty close to 150ipm in some areas.. I talked to Rob about this - he said I should post here in case others have seen this issue and didn't know what was happening. He has some Ideas on solutions and will keep us posted. sam On 03/03/2014 05:12 PM, Robert Ellenberg wrote: Hi All, I just created a release candidate branch for circular arc blending: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/circular-blend-arc-rc1 It's identical to my github branch that Sam and others have been testing. There was one small hiccup in pushing the new branch: remote: fatal: bad object However, it looks like the build failed here: http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-rtpreempt-amd64/builds/193 I'm not sure how to interpret this error, but I suspect that since I forked from master back in October, there have been fixes that my branch is missing. As a possible solution, I've been able to rebase the RC branch onto the lastest master with minimal changes. If there is a recent build that we know is solid, I can rebase my branch onto that and push it. If I go down this route, should I increment the branch's name, or just overwrite the bad branch? -Rob -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN
Re: [Emc-developers] Circular blend arc RC1 pushed
Ok - I finally got a chance to test some more real hardware. This is a bastard router that has 3 different steppers/drive (it was a converted step/repeat machine.) I built robs latest (RC3) from the linuxcnc git and ran some of the test programs. some good news one bad. Good news. The motion is very smooth. The program I was testing was the LHchips4.ngc. It sounds very nice. http://electronicsam.com/images/KandT/testing/LHchips4.ngc I found one issue. A cutting profile containing more than 1 axis will only go as fast as the slowest axis. This machine has 3 different axis velocities X 150ipm Y 78IPM Z 50IPM On the 'belly' of chips - there are long x-z profiles (mostly X moves). The profiles would peak at 50ipm. (they should peak at something between X and Z. The current TP actually runs that profile faster (closer to 100ipm) There are long XY profiles also - they peak at 78ipm but should peak pretty close to 150ipm in some areas.. I talked to Rob about this - he said I should post here in case others have seen this issue and didn't know what was happening. He has some Ideas on solutions and will keep us posted. sam On 03/03/2014 05:12 PM, Robert Ellenberg wrote: Hi All, I just created a release candidate branch for circular arc blending: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/circular-blend-arc-rc1 It's identical to my github branch that Sam and others have been testing. There was one small hiccup in pushing the new branch: remote: fatal: bad object However, it looks like the build failed here: http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-rtpreempt-amd64/builds/193 I'm not sure how to interpret this error, but I suspect that since I forked from master back in October, there have been fixes that my branch is missing. As a possible solution, I've been able to rebase the RC branch onto the lastest master with minimal changes. If there is a recent build that we know is solid, I can rebase my branch onto that and push it. If I go down this route, should I increment the branch's name, or just overwrite the bad branch? -Rob -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] (Circular Arc Blending) Experimental support for intersections other than line-line
The realtime now builds. Yay!
On 2/19/2014 3:40 PM, Robert Ellenberg wrote:
Excellent! I think I fixed the build issue, and that rtapi error as well. I
left an error message in there that was no longer valid, so that's been
removed. To fix the build issue, I made a few tweaks to rtapi_math.h to
include fmin and fmax. I don't know if this is the best long term solution
since there's probably a reason it was omitted. However, since I'm using it
anyway, it might as well be there for now.
My next step is to squash all this down onto v2.5_branch so that it can be
merged into future releases. I had some issues building v2.5_branch
('failed to remake Makefile'), but if I can get it built, it shouldn't be
much work to get it running.
-Rob
On Wed, Feb 19, 2014 at 10:41 AM, sam sokolik sa...@empirescreen.comwrote:
I get 2 'aborting after length change!' on tort.ngc. I was wondering
why it runs almost all paraboc blends until it dawned on me that none of
the arc-arc, arc-line segments are coplanar.. :) The tool path and
actual path do line up now. Yay!
sam
On 2/19/2014 7:07 AM, sam sokolik wrote:
I do get the same (I think) fmin error on the reatime build though.
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-122-rtai'
/home/samco/linuxcnc-arc-case/src/emc/tp/tc.c: In function
‘tcFindBlendTolerance’:
/home/samco/linuxcnc-arc-case/src/emc/tp/tc.c:397: error: implicit
declaration of function ‘fmin’
make[2]: *** [/home/samco/linuxcnc-arc-case/src/emc/tp/tc.o] Error 1
make[1]: *** [_module_/home/samco/linuxcnc-arc-case/src] Error 2
make: *** [modules] Error 2
make: Leaving directory `/home/samco/linuxcnc-arc-case/src'
samco@samco-desktop:~/linuxcnc-arc-case/src$ git pull
Already up-to-date.
samco@samco-desktop:~/linuxcnc-arc-case/src$ git describe
v2.5.3-2703-g0b74121
samco@samco-desktop:~/linuxcnc-arc-case/src$
sam
On 2/18/2014 5:29 PM, Robert Ellenberg wrote:
Good news, I think I've solved the drift issue. The Line-Arc case didn't
correctly handle segments that were consumed (i.e. merged into the arc
blend), so it ended up moving twice the distance needed for these very
short segments. Now it properly removes the previous segment like the
Line-Line case. I'll push an update shortly that fixes this issue and
the
fmin issue. I'm not sure I can fix the little overages quite so easily,
since they are due to imperfect tangency between the blends and circular
segments. I've made a bunch of little tweaks that have improved it
slightly, but there's something in the geometry I'm not accounting for
properly. The good news is, since the violations are coming from the
tangents, then we can fix it by scaling back acceleration if need be.
-Rob
On Tue, Feb 18, 2014 at 2:13 PM, Robert Ellenberg rwe...@gmail.com
wrote:
I got that too, recently. That means I used fmin somewhere outside of
tp.c. This makes me wish that rtapi_math had fmin and fmax, since I
use it
so often anyway.
On Feb 18, 2014 2:11 PM, sam sokolik sa...@empirescreen.com
wrote:
I just tried to do a realtime build.. I get these errors
1.
/home/samco/linuxcnc-arc-case/src/emc/tp/tc.c: In function
'tcFindBlendTolerance':
2.
/home/samco/linuxcnc-arc-case/src/emc/tp/tc.c:391: error:
implicit
declaration of function 'fmin'
3.
make[2]: *** [/home/samco/linuxcnc-arc-case/src/emc/tp/tc.o]
Error 1
4.
make[1]: *** [_module_/home/samco/linuxcnc-arc-case/src] Error 2
5.
make: *** [modules] Error 2
6.
make: Leaving directory `/home/samco/linuxcnc-arc-case/src'
7.
samco@samco-desktop:~/linuxcnc-arc-case/src$
sam
On 2/18/2014 10:54 AM, Robert Ellenberg wrote:
Thanks for the additional info! I've been working on correcting the
overages, which seem to come from the blend arc not being perfectly
tangent
to the arc segments. As for the drift seen in that image, that's a
bigger
issue, because it means that we're losing or gaining distance
somewhere.
I'm 90% sure it's a simple issue with the Line-Arc case, so if that's
true,
I should be able to fix it pretty easily. I've been using this
program
as
well, which has a good combination of lines and arcs:
https://www.dropbox.com/s/cae1gaez3xvi6ia/blur_torus.ngc
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common
Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer
Re: [Emc-developers] (Circular Arc Blending) Experimental support for intersections other than line-line
If I understand it right - it is master.
sam
On 2/20/2014 8:32 AM, EBo wrote:
So is this on 2.5_branch, 2.6, or the master?
On Feb 20 2014 7:29 AM, sam sokolik wrote:
The realtime now builds. Yay!
On 2/19/2014 3:40 PM, Robert Ellenberg wrote:
Excellent! I think I fixed the build issue, and that rtapi error as
well. I
left an error message in there that was no longer valid, so that's
been
removed. To fix the build issue, I made a few tweaks to rtapi_math.h
to
include fmin and fmax. I don't know if this is the best long term
solution
since there's probably a reason it was omitted. However, since I'm
using it
anyway, it might as well be there for now.
My next step is to squash all this down onto v2.5_branch so that it
can be
merged into future releases. I had some issues building v2.5_branch
('failed to remake Makefile'), but if I can get it built, it
shouldn't be
much work to get it running.
-Rob
On Wed, Feb 19, 2014 at 10:41 AM, sam sokolik
sa...@empirescreen.comwrote:
I get 2 'aborting after length change!' on tort.ngc. I was
wondering
why it runs almost all paraboc blends until it dawned on me that
none of
the arc-arc, arc-line segments are coplanar.. :) The tool path and
actual path do line up now. Yay!
sam
On 2/19/2014 7:07 AM, sam sokolik wrote:
I do get the same (I think) fmin error on the reatime build
though.
make[1]: Leaving directory
`/usr/src/linux-headers-2.6.32-122-rtai'
/home/samco/linuxcnc-arc-case/src/emc/tp/tc.c: In function
‘tcFindBlendTolerance’:
/home/samco/linuxcnc-arc-case/src/emc/tp/tc.c:397: error: implicit
declaration of function ‘fmin’
make[2]: *** [/home/samco/linuxcnc-arc-case/src/emc/tp/tc.o] Error
1
make[1]: *** [_module_/home/samco/linuxcnc-arc-case/src] Error 2
make: *** [modules] Error 2
make: Leaving directory `/home/samco/linuxcnc-arc-case/src'
samco@samco-desktop:~/linuxcnc-arc-case/src$ git pull
Already up-to-date.
samco@samco-desktop:~/linuxcnc-arc-case/src$ git describe
v2.5.3-2703-g0b74121
samco@samco-desktop:~/linuxcnc-arc-case/src$
sam
On 2/18/2014 5:29 PM, Robert Ellenberg wrote:
Good news, I think I've solved the drift issue. The Line-Arc case
didn't
correctly handle segments that were consumed (i.e. merged into
the arc
blend), so it ended up moving twice the distance needed for these
very
short segments. Now it properly removes the previous segment like
the
Line-Line case. I'll push an update shortly that fixes this issue
and
the
fmin issue. I'm not sure I can fix the little overages quite so
easily,
since they are due to imperfect tangency between the blends and
circular
segments. I've made a bunch of little tweaks that have improved
it
slightly, but there's something in the geometry I'm not
accounting for
properly. The good news is, since the violations are coming from
the
tangents, then we can fix it by scaling back acceleration if need
be.
-Rob
On Tue, Feb 18, 2014 at 2:13 PM, Robert Ellenberg
rwe...@gmail.com
wrote:
I got that too, recently. That means I used fmin somewhere
outside of
tp.c. This makes me wish that rtapi_math had fmin and fmax,
since I
use it
so often anyway.
On Feb 18, 2014 2:11 PM, sam sokolik
sa...@empirescreen.com
wrote:
I just tried to do a realtime build.. I get these errors
1.
/home/samco/linuxcnc-arc-case/src/emc/tp/tc.c: In
function
'tcFindBlendTolerance':
2.
/home/samco/linuxcnc-arc-case/src/emc/tp/tc.c:391:
error:
implicit
declaration of function 'fmin'
3.
make[2]: ***
[/home/samco/linuxcnc-arc-case/src/emc/tp/tc.o]
Error 1
4.
make[1]: *** [_module_/home/samco/linuxcnc-arc-case/src]
Error 2
5.
make: *** [modules] Error 2
6.
make: Leaving directory
`/home/samco/linuxcnc-arc-case/src'
7.
samco@samco-desktop:~/linuxcnc-arc-case/src$
sam
On 2/18/2014 10:54 AM, Robert Ellenberg wrote:
Thanks for the additional info! I've been working on
correcting the
overages, which seem to come from the blend arc not being
perfectly
tangent
to the arc segments. As for the drift seen in that image,
that's a
bigger
issue, because it means that we're losing or gaining distance
somewhere.
I'm 90% sure it's a simple issue with the Line-Arc case, so if
that's
true,
I should be able to fix it pretty easily. I've been using this
program
as
well, which has a good combination of lines and arcs:
https://www.dropbox.com/s/cae1gaez3xvi6ia/blur_torus.ngc
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common
Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https
Re: [Emc-developers] (Circular Arc Blending) Experimental support for intersections other than line-line
The bit of testing this morning - no overage (at all) and follows path. I think you nailed it! sam On 2/18/2014 5:29 PM, Robert Ellenberg wrote: Good news, I think I've solved the drift issue. The Line-Arc case didn't correctly handle segments that were consumed (i.e. merged into the arc blend), so it ended up moving twice the distance needed for these very short segments. Now it properly removes the previous segment like the Line-Line case. I'll push an update shortly that fixes this issue and the fmin issue. I'm not sure I can fix the little overages quite so easily, since they are due to imperfect tangency between the blends and circular segments. I've made a bunch of little tweaks that have improved it slightly, but there's something in the geometry I'm not accounting for properly. The good news is, since the violations are coming from the tangents, then we can fix it by scaling back acceleration if need be. -Rob On Tue, Feb 18, 2014 at 2:13 PM, Robert Ellenberg rwe...@gmail.com wrote: I got that too, recently. That means I used fmin somewhere outside of tp.c. This makes me wish that rtapi_math had fmin and fmax, since I use it so often anyway. On Feb 18, 2014 2:11 PM, sam sokolik sa...@empirescreen.com wrote: I just tried to do a realtime build.. I get these errors 1. /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c: In function 'tcFindBlendTolerance': 2. /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c:391: error: implicit declaration of function 'fmin' 3. make[2]: *** [/home/samco/linuxcnc-arc-case/src/emc/tp/tc.o] Error 1 4. make[1]: *** [_module_/home/samco/linuxcnc-arc-case/src] Error 2 5. make: *** [modules] Error 2 6. make: Leaving directory `/home/samco/linuxcnc-arc-case/src' 7. samco@samco-desktop:~/linuxcnc-arc-case/src$ sam On 2/18/2014 10:54 AM, Robert Ellenberg wrote: Thanks for the additional info! I've been working on correcting the overages, which seem to come from the blend arc not being perfectly tangent to the arc segments. As for the drift seen in that image, that's a bigger issue, because it means that we're losing or gaining distance somewhere. I'm 90% sure it's a simple issue with the Line-Arc case, so if that's true, I should be able to fix it pretty easily. I've been using this program as well, which has a good combination of lines and arcs: https://www.dropbox.com/s/cae1gaez3xvi6ia/blur_torus.ngc -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] (Circular Arc Blending) Experimental support for intersections other than line-line
I do get the same (I think) fmin error on the reatime build though. make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-122-rtai' /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c: In function ‘tcFindBlendTolerance’: /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c:397: error: implicit declaration of function ‘fmin’ make[2]: *** [/home/samco/linuxcnc-arc-case/src/emc/tp/tc.o] Error 1 make[1]: *** [_module_/home/samco/linuxcnc-arc-case/src] Error 2 make: *** [modules] Error 2 make: Leaving directory `/home/samco/linuxcnc-arc-case/src' samco@samco-desktop:~/linuxcnc-arc-case/src$ git pull Already up-to-date. samco@samco-desktop:~/linuxcnc-arc-case/src$ git describe v2.5.3-2703-g0b74121 samco@samco-desktop:~/linuxcnc-arc-case/src$ sam On 2/18/2014 5:29 PM, Robert Ellenberg wrote: Good news, I think I've solved the drift issue. The Line-Arc case didn't correctly handle segments that were consumed (i.e. merged into the arc blend), so it ended up moving twice the distance needed for these very short segments. Now it properly removes the previous segment like the Line-Line case. I'll push an update shortly that fixes this issue and the fmin issue. I'm not sure I can fix the little overages quite so easily, since they are due to imperfect tangency between the blends and circular segments. I've made a bunch of little tweaks that have improved it slightly, but there's something in the geometry I'm not accounting for properly. The good news is, since the violations are coming from the tangents, then we can fix it by scaling back acceleration if need be. -Rob On Tue, Feb 18, 2014 at 2:13 PM, Robert Ellenberg rwe...@gmail.com wrote: I got that too, recently. That means I used fmin somewhere outside of tp.c. This makes me wish that rtapi_math had fmin and fmax, since I use it so often anyway. On Feb 18, 2014 2:11 PM, sam sokolik sa...@empirescreen.com wrote: I just tried to do a realtime build.. I get these errors 1. /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c: In function 'tcFindBlendTolerance': 2. /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c:391: error: implicit declaration of function 'fmin' 3. make[2]: *** [/home/samco/linuxcnc-arc-case/src/emc/tp/tc.o] Error 1 4. make[1]: *** [_module_/home/samco/linuxcnc-arc-case/src] Error 2 5. make: *** [modules] Error 2 6. make: Leaving directory `/home/samco/linuxcnc-arc-case/src' 7. samco@samco-desktop:~/linuxcnc-arc-case/src$ sam On 2/18/2014 10:54 AM, Robert Ellenberg wrote: Thanks for the additional info! I've been working on correcting the overages, which seem to come from the blend arc not being perfectly tangent to the arc segments. As for the drift seen in that image, that's a bigger issue, because it means that we're losing or gaining distance somewhere. I'm 90% sure it's a simple issue with the Line-Arc case, so if that's true, I should be able to fix it pretty easily. I've been using this program as well, which has a good combination of lines and arcs: https://www.dropbox.com/s/cae1gaez3xvi6ia/blur_torus.ngc -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers
Re: [Emc-developers] (Circular Arc Blending) Experimental support for intersections other than line-line
I get 2 'aborting after length change!' on tort.ngc. I was wondering why it runs almost all paraboc blends until it dawned on me that none of the arc-arc, arc-line segments are coplanar.. :) The tool path and actual path do line up now. Yay! sam On 2/19/2014 7:07 AM, sam sokolik wrote: I do get the same (I think) fmin error on the reatime build though. make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-122-rtai' /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c: In function ‘tcFindBlendTolerance’: /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c:397: error: implicit declaration of function ‘fmin’ make[2]: *** [/home/samco/linuxcnc-arc-case/src/emc/tp/tc.o] Error 1 make[1]: *** [_module_/home/samco/linuxcnc-arc-case/src] Error 2 make: *** [modules] Error 2 make: Leaving directory `/home/samco/linuxcnc-arc-case/src' samco@samco-desktop:~/linuxcnc-arc-case/src$ git pull Already up-to-date. samco@samco-desktop:~/linuxcnc-arc-case/src$ git describe v2.5.3-2703-g0b74121 samco@samco-desktop:~/linuxcnc-arc-case/src$ sam On 2/18/2014 5:29 PM, Robert Ellenberg wrote: Good news, I think I've solved the drift issue. The Line-Arc case didn't correctly handle segments that were consumed (i.e. merged into the arc blend), so it ended up moving twice the distance needed for these very short segments. Now it properly removes the previous segment like the Line-Line case. I'll push an update shortly that fixes this issue and the fmin issue. I'm not sure I can fix the little overages quite so easily, since they are due to imperfect tangency between the blends and circular segments. I've made a bunch of little tweaks that have improved it slightly, but there's something in the geometry I'm not accounting for properly. The good news is, since the violations are coming from the tangents, then we can fix it by scaling back acceleration if need be. -Rob On Tue, Feb 18, 2014 at 2:13 PM, Robert Ellenberg rwe...@gmail.com wrote: I got that too, recently. That means I used fmin somewhere outside of tp.c. This makes me wish that rtapi_math had fmin and fmax, since I use it so often anyway. On Feb 18, 2014 2:11 PM, sam sokolik sa...@empirescreen.com wrote: I just tried to do a realtime build.. I get these errors 1. /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c: In function 'tcFindBlendTolerance': 2. /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c:391: error: implicit declaration of function 'fmin' 3. make[2]: *** [/home/samco/linuxcnc-arc-case/src/emc/tp/tc.o] Error 1 4. make[1]: *** [_module_/home/samco/linuxcnc-arc-case/src] Error 2 5. make: *** [modules] Error 2 6. make: Leaving directory `/home/samco/linuxcnc-arc-case/src' 7. samco@samco-desktop:~/linuxcnc-arc-case/src$ sam On 2/18/2014 10:54 AM, Robert Ellenberg wrote: Thanks for the additional info! I've been working on correcting the overages, which seem to come from the blend arc not being perfectly tangent to the arc segments. As for the drift seen in that image, that's a bigger issue, because it means that we're losing or gaining distance somewhere. I'm 90% sure it's a simple issue with the Line-Arc case, so if that's true, I should be able to fix it pretty easily. I've been using this program as well, which has a good combination of lines and arcs: https://www.dropbox.com/s/cae1gaez3xvi6ia/blur_torus.ngc -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] (Circular Arc Blending) Experimental support for intersections other than line-line
The lhchips3.ngc is a good file for testing.. If you run it strait G64 (touch every segment) it fails constraints a hand full of times. (darn impressive.) I can give you exact examples if you would like? The big thing is - I don't think it is following the preview path. I mentioned it on the tort.ngc. It is hard to tell. (shorter programs don't exhibit this..) the tool path seems to be shifted to the left.. http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-02-18%2010:29:30.png http://electronicsam.com/images/KandT/testing/LHchips3.ngc Even the splash screen has an unreal improvement in speed. (the letters are made up of arcs..) Darn awesome! sam On 2/16/2014 12:03 PM, Robert Ellenberg wrote: That error means that it's failing to resize one of the arcs, but since it's resized the other one already, the result is a broken state. The fix is to work on a temporary copy of each segment, then copy it over to the real segments if it passes all the checks. Instead of weird failures like this, any errors will just fall back to parabolic blends. I should have that fix ready in a day or two. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] (Circular Arc Blending) Experimental support for intersections other than line-line
I just tried to do a realtime build.. I get these errors 1. /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c: In function 'tcFindBlendTolerance': 2. /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c:391: error: implicit declaration of function 'fmin' 3. make[2]: *** [/home/samco/linuxcnc-arc-case/src/emc/tp/tc.o] Error 1 4. make[1]: *** [_module_/home/samco/linuxcnc-arc-case/src] Error 2 5. make: *** [modules] Error 2 6. make: Leaving directory `/home/samco/linuxcnc-arc-case/src' 7. samco@samco-desktop:~/linuxcnc-arc-case/src$ sam On 2/18/2014 10:54 AM, Robert Ellenberg wrote: Thanks for the additional info! I've been working on correcting the overages, which seem to come from the blend arc not being perfectly tangent to the arc segments. As for the drift seen in that image, that's a bigger issue, because it means that we're losing or gaining distance somewhere. I'm 90% sure it's a simple issue with the Line-Arc case, so if that's true, I should be able to fix it pretty easily. I've been using this program as well, which has a good combination of lines and arcs: https://www.dropbox.com/s/cae1gaez3xvi6ia/blur_torus.ngc -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] (Circular Arc Blending) Experimental support for intersections other than line-line
Nice work! Can't wait to test! if you are talking about the slight overages (ie.. 30.0013 and such..) In my opinion - that is close enough. :) (the 'other software' seems to go over by much more) sam On 02/18/2014 05:29 PM, Robert Ellenberg wrote: Good news, I think I've solved the drift issue. The Line-Arc case didn't correctly handle segments that were consumed (i.e. merged into the arc blend), so it ended up moving twice the distance needed for these very short segments. Now it properly removes the previous segment like the Line-Line case. I'll push an update shortly that fixes this issue and the fmin issue. I'm not sure I can fix the little overages quite so easily, since they are due to imperfect tangency between the blends and circular segments. I've made a bunch of little tweaks that have improved it slightly, but there's something in the geometry I'm not accounting for properly. The good news is, since the violations are coming from the tangents, then we can fix it by scaling back acceleration if need be. -Rob On Tue, Feb 18, 2014 at 2:13 PM, Robert Ellenberg rwe...@gmail.com wrote: I got that too, recently. That means I used fmin somewhere outside of tp.c. This makes me wish that rtapi_math had fmin and fmax, since I use it so often anyway. On Feb 18, 2014 2:11 PM, sam sokolik sa...@empirescreen.com wrote: I just tried to do a realtime build.. I get these errors 1. /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c: In function 'tcFindBlendTolerance': 2. /home/samco/linuxcnc-arc-case/src/emc/tp/tc.c:391: error: implicit declaration of function 'fmin' 3. make[2]: *** [/home/samco/linuxcnc-arc-case/src/emc/tp/tc.o] Error 1 4. make[1]: *** [_module_/home/samco/linuxcnc-arc-case/src] Error 2 5. make: *** [modules] Error 2 6. make: Leaving directory `/home/samco/linuxcnc-arc-case/src' 7. samco@samco-desktop:~/linuxcnc-arc-case/src$ sam On 2/18/2014 10:54 AM, Robert Ellenberg wrote: Thanks for the additional info! I've been working on correcting the overages, which seem to come from the blend arc not being perfectly tangent to the arc segments. As for the drift seen in that image, that's a bigger issue, because it means that we're losing or gaining distance somewhere. I'm 90% sure it's a simple issue with the Line-Arc case, so if that's true, I should be able to fix it pretty easily. I've been using this program as well, which has a good combination of lines and arcs: https://www.dropbox.com/s/cae1gaez3xvi6ia/blur_torus.ngc -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] (Circular Arc Blending) Experimental support for intersections other than line-line
I did some testing with robs experimental branch (before the arc blending) http://electronicsam.com/images/KandT/testing/DSC_1412.JPG Threading works! sam On 02/15/2014 10:08 PM, sam sokolik wrote: wow - can I say wow again? I have your first constraint violation. (it was the only one in the whole program) http://electronicsam.com/images/KandT/testing/LHchips3.ngc is the whole program. I paired it down to. First the coolness. Master http://electronicsam.com/images/KandT/testing/master1LHchips3.png New arcblend http://electronicsam.com/images/KandT/testing/arc-cases-experimentalLHchipsrun.png that is almost twice as fast.. the path just flies. Here is the only violation that I saw (well there was a 30.016 iirc but I wasn't worried about that.) http://electronicsam.com/images/KandT/testing/arc-cases-experimentalLHchips3.png you can see it is around line 8182. I reduced it down to this program (around line 32-33) http://electronicsam.com/images/KandT/testing/lhchips3error.ngc I will keep testing. Great work! sam On 02/15/2014 06:10 PM, Robert Ellenberg wrote: Hi All, I've been working on adding support for line-arc and arc-arc intersections to the new TP. My latest code is on this feature branch here: https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/arc-cases-experimental This branch has so far only been run in simulation, but it's behaved well on a few test cases. At this point, it would be very helpful if anyone could find any violations or jumps that shouldn't happen. Thanks! Rob -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] (Circular Arc Blending) Experimental support for intersections other than line-line
another issue. Running tort.ngc - I get this output. 'aborting after length change!' 8 times. it doesn't follow that preview at some point also. http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-02-16%2011:50:16.png sam On 02/15/2014 06:10 PM, Robert Ellenberg wrote: Hi All, I've been working on adding support for line-arc and arc-arc intersections to the new TP. My latest code is on this feature branch here: https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/arc-cases-experimental This branch has so far only been run in simulation, but it's behaved well on a few test cases. At this point, it would be very helpful if anyone could find any violations or jumps that shouldn't happen. Thanks! Rob -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] (Circular Arc Blending) Experimental support for intersections other than line-line
wow - can I say wow again? I have your first constraint violation. (it was the only one in the whole program) http://electronicsam.com/images/KandT/testing/LHchips3.ngc is the whole program. I paired it down to. First the coolness. Master http://electronicsam.com/images/KandT/testing/master1LHchips3.png New arcblend http://electronicsam.com/images/KandT/testing/arc-cases-experimentalLHchipsrun.png that is almost twice as fast.. the path just flies. Here is the only violation that I saw (well there was a 30.016 iirc but I wasn't worried about that.) http://electronicsam.com/images/KandT/testing/arc-cases-experimentalLHchips3.png you can see it is around line 8182. I reduced it down to this program (around line 32-33) http://electronicsam.com/images/KandT/testing/lhchips3error.ngc I will keep testing. Great work! sam On 02/15/2014 06:10 PM, Robert Ellenberg wrote: Hi All, I've been working on adding support for line-arc and arc-arc intersections to the new TP. My latest code is on this feature branch here: https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/arc-cases-experimental This branch has so far only been run in simulation, but it's behaved well on a few test cases. At this point, it would be very helpful if anyone could find any violations or jumps that shouldn't happen. Thanks! Rob -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Proper behavior when blending rapid / feed moves
actually - it looks like the last part of the arc is also de-accelerating at a lower rate. Is this part of the problem where you don't know if that is the end of the program? sam On 2/13/2014 9:02 AM, sam sokolik wrote: cool. 'Flexable' I have a question - I am running your experimental branch This program % (1 square with rounded corners) G90 G54 G20 G64 G0 X0 Y.25 Z.25 z0 G1 Y.75 F999 G2 X.25 Y1 I.25 G1 X.75 G2 X1 Y.75 J-.25 G1 Y.25 G2 X.75 Y0 I-.25 G1 X.25 G2 X0 Y.25 J.25 G0z.25 M30 shows this on the velocity plot. http://imagebin.org/293091 Lead in and lead out of .25 - you can see the the exact stops for the rapid/feed transistions. You can see the lead-in acc is much higher than the lead out.. Should they be the same? It is like lead-in is using full acc while the lead out is using 1/2 (maybe) thanks sam On 2/13/2014 8:43 AM, Robert Ellenberg wrote: I can add an INI setting fairly easily, and default to not allowing blends between rapids and feed moves. On Feb 13, 2014 9:20 AM, sam sokolik sa...@empirescreen.com wrote: How hard would that be to make an INI setting? I can't think of an application (maybe something that is positioning...) that might want blended moves between rapid and feed moves.. sam On 2/6/2014 7:25 AM, Robert Ellenberg wrote: On Thu, Feb 6, 2014 at 8:13 AM, EBo e...@sandien.com wrote: On Feb 6 2014 5:53 AM, andy pugh wrote: On 6 February 2014 09:27, Robert Ellenberg rwe...@gmail.com wrote: Is there a standard way to treat blends between rapid moves and regular feed moves? I don't know if there is a standard way, but I think I would normally expect there to be no blending between G0 and G1. ie, exact-stop mode to be active. You are likely correct here. Agreed, an exact stop seems like a safe choice. I'm assuming we'd still want blends between rapid moves? (If the G0 to G1 transition is in contact with the workpiece something is wrong anyway). Not quite. Picture a straight plunge cut -- you can go in at speed, and then retract at rapid. I see nothing wrong with that, and if there is a reason that must retract at speed instead of rapid I would like to hear the rationale. That would be a G1 to G0 transition, though. A G0 to G1 transition in contact would mean that the tool hits the work at rapid speed, which is probably not safe. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
Re: [Emc-developers] HEADS UP: RT-preempt and network I/O/system calls from RTthreads probably not viable
I have been helping test the mesa 7i80 (ethernet). I started with the RTnet setup but what a pain. Supported nics are very limited. When micges switched to rt_preempt there was a watchdog bug that bit the 7i80 (pun intended..) but through all the testing I don't think I once got a realtime delay erorr - that was testing a few different motherboards. I certainly isn't high performance - latency seems to stay consistently under 100us (hovering around 60-80us). Currently .5 to 1ms servo loops are possible. The thought is with some driver tuning - this could get better. The machines that I have been testing run overnight without any real time delays - peter has had a system running for weeks.. I think it may work well for now. (pretty darn awesome if you ask me - realtime communication over Ethernet ) sam PS - this would not have been possible without the Unified build. - Thanks to all that have worked on it Michael H, John M, Seb (and those I have missed...) On 1/30/2014 2:47 PM, Charles Steinkuehler wrote: On 1/30/2014 2:14 PM, Michael Haberler wrote: Once ethernet level packet I/O is settled as fast enough, we can tu to add the minimal IP/UDP framing needed. This will be bare bones (no ping, arp, and other amenenities) but should have pretty much the same timing behavior and good enough for the task at hand. these are desk wisdoms, so handle with care. More driving from behind the desk, but I've always thought the netmap folks have a good approach: http://info.iet.unipi.it/~luigi/netmap/ -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] reports on rt-preempt / latency-test: max jitter going down - FIXED
cool - thanks for finding that. Sorry I could not test - nothing setup here - but I can test the fix monday. sam On 01/26/2014 02:07 PM, Michael Haberler wrote: I have a fix which works for me: https://github.com/mhaberler/linuxcnc/commit/10924b5509a2d2e38533a9f9e876d139a2cf5d4b (branch unified-build-candidate-3) I'd appreciate reports - this should repair the latency-test: jitter going down error NB: this error did show only on i386 kernels, not on x86_64 the clocksource was not involved - Michael Am 26.01.2014 um 18:02 schrieb Peter C. Wallace p...@mesanet.com: On Sun, 26 Jan 2014, Michael Haberler wrote: Date: Sun, 26 Jan 2014 17:40:19 +0100 From: Michael Haberler mai...@mah.priv.at To: Peter C. Wallace p...@mesanet.com, EMC developers emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] reports on rt-preempt / latency-test: max jitter going down Am 26.01.2014 um 17:28 schrieb Peter C. Wallace p...@mesanet.com: On Sun, 26 Jan 2014, Michael Haberler wrote: Date: Sun, 26 Jan 2014 09:59:52 +0100 From: Michael Haberler mai...@mah.priv.at To: EMC developers emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] reports on rt-preempt / latency-test: max jitter going down could the folks observing this behaviour please run the following commands on their systems: cat /sys/devices/system/clocksource/clocksource0/available_clocksource cat /sys/devices/system/clocksource/clocksource0/current_clocksource background: Answer 2 of: http://stackoverflow.com/questions/5930621/problem-of-understanding-clock-gettime thanks! cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc acpi_pm cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc hm, I would have expected to find 'hpet' there (see also link below) maybe for some reason HPET isnt enabled in the kernel so not settable (is that by chance my howegrown 3.1x-mah rt-preempt kernel..?) Yes I changed the clocksource to acpi_pm but the error remains acpi_pm is probably the worst of all in terms of resolution, 3.58Mhz: http://stackoverflow.com/questions/7987671/what-is-the-acpi-pm-linux-clocksource-used-for-what-hardware-implements-it it's probably a good idea to figure out the best clock source, and make sure in the startup phase it's actually selected (assuming this is related at all) One interesting thing is that the error is periodic with a ~4 second period (like an uncaught 32 bit ns count wrap) hm, thats an interesting observation. Need to read the timedelta and rtapi_time code once more to see if there's something smelly. does that 4 second period show up with either clock source just alike? if so, this would suggest the clock source not be the cause Yes, same ~4 second period with either clock source, I HAL 'scoped the baddelta staircase and its 4.3 seconds as you would expect with a uncaught 32 bit wrap I should be next to real hardware soon thanks! - Michael - Michael Am 25.01.2014 um 17:03 schrieb Michael Haberler mai...@mah.priv.at: Peter Wallace kindly help to locate the error, it is rtapi_get_time() going backwards occasionally on rt-preempt, suggesting the cause is this function: https://github.com/mhaberler/linuxcnc/blob/e3de5bb74857bbd9935c1a1d1f031a0558ca0f85/src/rtapi/rtapi_time.c#L166 this cause the 'del' variable in https://github.com/mhaberler/linuxcnc/blob/e3de5bb74857bbd9935c1a1d1f031a0558ca0f85/src/hal/components/timedelta.comp to become negative at times, causing the decreasing jitter no fix yet, but we know where to look -m Am 25.01.2014 um 08:43 schrieb Michael Haberler mai...@mah.priv.at: Reading back on IRC I found hints at rt-preempt ubc3 builds showing the max latency going down occasionally. Please: 1. report the exact kernel version, in particular if this is stock debian rt-preempt kernel. 2. check if ntp is running or not, i.e. the output of 'ps ax|grep ntp' 3. If yes, please stop the ntp demon with 'sudo /etc/init.d/ntp stop' or equivalent 4. Re-run latency-test after ntp is stopped. Does the problem reoccur? 5. Please report your results using the ubc issue tracker as mentioned here http://static.mah.priv.at/public/html/common/UnifiedBuild.html#_issue_tracker , for this issue: https://github.com/zultron/linuxcnc/issues/72 background: there is a chance that the issue is related to the behavior described here, in particular the subtle difference between CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW: http://stackoverflow.com/questions/3657289/linux-clock-gettimeclock-monotonic-strange-non-monotonic-behavior http://markmail.org/thread/54bb663vi47kjxnu - Michael -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments
Re: [Emc-developers] Beta release of circular arc blending
Ok - todd on the forum seems to have found an ussue with W http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted#42547 He has some picuteres showing that the W axis seems to be overshooting. sam On 1/8/2014 4:39 PM, Robert Ellenberg wrote: I should point out that there are still interactions that are hard to test for on my equipment, such as 4+ axis behavior, spindle synchronization, rigid tapping, and digital / analog inputs. The changes shouldn't affect these areas, but it is possible that subtle bugs could affect these functions. So, for anyone with more than 3 axes and/or a spindle encoder, it would be very helpful to verify that these functions work as expected. On Wed, Jan 8, 2014 at 5:27 PM, EBo e...@sandien.com wrote: WOOHOO... Thanks! EBo -- On Jan 8 2014 3:16 PM, Robert Ellenberg wrote: Hi All, After fixing a few persistent but minor issues with arc blending, I think the code is ready for beta status. I've pushed a branch on my github fork called circular-blend-arc-beta: https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-beta This branch has code that does not violate velocity or acceleration constraints on any of the test programs. As such, it's ready for (carefully supervised) hardware testing. Once it's running on a few machines without issue, it should be merge-ready for the master branch. Thanks again to everyone who's helped out with extensive advice and testing! -Rob -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
Todd on the forum brought up http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted I think you guys working on this are defonately on the right track. It can offer a significant improvement depending on the code used. I wish that it would be possible to easily extend this to other axis beyond XYZ. Several of the routers we use have double vertical axis with 2 spindles using Z and W. The new traj planner shaved a min off running the code included (went from 4.5 to 3.5) That was nearly a 25% improvement. Using the G64P0.005 vs G64P0.005Q0.005 difference was less significant on the new planner run times were, 3:37 vs. 3:30. PS The same carving with the W code (W is identical to Z) takes about 6 minuts using either planner. Maybe I need to try harder to build a ZZ configuration that will work for us. Thanks again I will be playing with this some more. On 1/7/2014 9:16 PM, sam sokolik wrote: I posted on cnczone and linuxcnc for testing.. Hopefully some of the more adventurous users will give it a try http://www.cnczone.com/forums/linuxcnc_formerly_emc2/206712-new_trajectory_planner_-_testers_programs_wanted.html http://www.cnczone.com/forums/linuxcnc_formerly_emc2/206712-new_trajectory_planner_-_testers_programs_wanted.html If there is anything I should add - let me know. I may have been a bit vague on purpose. sam On 01/07/2014 11:52 AM, Robert Ellenberg wrote: I'm thinking about changing how that constant works. Right now, it represents how much of the segment has to be consumed by a blend arc before we enable smoothing. If it's set at 0.50, this means smooth any lines that are shortened by more than 50%. Smoothing in this case means limiting the velocity to not exceed the initial or final velocity, to remove the rapid acceleration and deceleration. As a debugging constant, it worked fine, but as an INI setting, it does seem hard to use. If we're lucky, there may be an algorithmic way to do this. Maybe if a segment isn't long enough to reach a cruise phase at the requested velocity, or if the velocity bump is less than some amount. On Tue, Jan 7, 2014 at 11:45 AM, sam sokolik sa...@empirescreen.com wrote: I have a question about Controls how aggressive velocity smoothing is. It's a bit counterintuitive, a value of 0.5 means no smoothing, a value of 0.0 means every segment is smoothed. Decrease this value if the velocity profile seems to be too bumpy. ARC_BLEND_SMOOTHING_THRESHOLD = 0.4 I see in the email you had the threshold set to .75? (I am confused..) sam On 1/7/2014 2:19 AM, Robert Ellenberg wrote: Ok, good news on the testing front, I think I've finally eliminated the little acceleration overages by making TP_TIME_EPSILON smaller, from 10^-7 to 10^-10 or so. Properly initializing the ABC and UVW parts of the blend arc seem to have eliminated the graphical glitches as well. With these last issues being fixed, I've moved development over to the beta branch here: https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-beta The beta status means that it's been tested on multiple builds and shows no apparent constraint violations or crashes. My top priority for the near future will be squashing any bugs on this branch, though if there's time I might add some additional features. On Tue, Jan 7, 2014 at 2:03 AM, phill carter phill.car...@oztime.com.au wrote: I'm still a few steps away from surface mount yet. All the gcode I have has probing for variable z height, I'll rip the probing out of one and post it. On Tue, 7 Jan 2014 01:48:47 -0500 Robert Ellenberg rwe...@gmail.com wrote: On Tue, Jan 7, 2014 at 1:33 AM, phill carter phill.car...@oztime.com.au wrote: I do a bit of repair work around the home, a few pcb's and lots of learning and trying things out. What got me interested in what you are doing is my original pcb etching was slooowww so I figured your changes would help. Sounds like fun! Do you do any surface mount stuff? I bought a set of PCB mills / drills recently, though I haven't had much time to make any boards yet. It turns out I had my acceleration way too low. The pcb gcode I am using is all very short line-line transitions. Would you mind sharing an example of such a program that ran really slow? The greater variety of test cases I can find, the easier it will be to improve and troubleshoot. For a mill with a low top speed, increasing acceleration seems to be a viable solution, but it's probably not ideal since it means you're hitting your drive system harder. If you could get the same performance with lower acceleration, it could help your machine in the long term. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application
Re: [Emc-developers] Initial tests of circular arc blending
I have a question about Controls how aggressive velocity smoothing is. It's a bit counterintuitive, a value of 0.5 means no smoothing, a value of 0.0 means every segment is smoothed. Decrease this value if the velocity profile seems to be too bumpy. ARC_BLEND_SMOOTHING_THRESHOLD = 0.4 I see in the email you had the threshold set to .75? (I am confused..) sam On 1/7/2014 2:19 AM, Robert Ellenberg wrote: Ok, good news on the testing front, I think I've finally eliminated the little acceleration overages by making TP_TIME_EPSILON smaller, from 10^-7 to 10^-10 or so. Properly initializing the ABC and UVW parts of the blend arc seem to have eliminated the graphical glitches as well. With these last issues being fixed, I've moved development over to the beta branch here: https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-beta The beta status means that it's been tested on multiple builds and shows no apparent constraint violations or crashes. My top priority for the near future will be squashing any bugs on this branch, though if there's time I might add some additional features. On Tue, Jan 7, 2014 at 2:03 AM, phill carter phill.car...@oztime.com.auwrote: I'm still a few steps away from surface mount yet. All the gcode I have has probing for variable z height, I'll rip the probing out of one and post it. On Tue, 7 Jan 2014 01:48:47 -0500 Robert Ellenberg rwe...@gmail.com wrote: On Tue, Jan 7, 2014 at 1:33 AM, phill carter phill.car...@oztime.com.au wrote: I do a bit of repair work around the home, a few pcb's and lots of learning and trying things out. What got me interested in what you are doing is my original pcb etching was slooowww so I figured your changes would help. Sounds like fun! Do you do any surface mount stuff? I bought a set of PCB mills / drills recently, though I haven't had much time to make any boards yet. It turns out I had my acceleration way too low. The pcb gcode I am using is all very short line-line transitions. Would you mind sharing an example of such a program that ran really slow? The greater variety of test cases I can find, the easier it will be to improve and troubleshoot. For a mill with a low top speed, increasing acceleration seems to be a viable solution, but it's probably not ideal since it means you're hitting your drive system harder. If you could get the same performance with lower acceleration, it could help your machine in the long term. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net
Re: [Emc-developers] Initial tests of circular arc blending
I posted on cnczone and linuxcnc for testing.. Hopefully some of the more adventurous users will give it a try http://www.cnczone.com/forums/linuxcnc_formerly_emc2/206712-new_trajectory_planner_-_testers_programs_wanted.html http://www.cnczone.com/forums/linuxcnc_formerly_emc2/206712-new_trajectory_planner_-_testers_programs_wanted.html If there is anything I should add - let me know. I may have been a bit vague on purpose. sam On 01/07/2014 11:52 AM, Robert Ellenberg wrote: I'm thinking about changing how that constant works. Right now, it represents how much of the segment has to be consumed by a blend arc before we enable smoothing. If it's set at 0.50, this means smooth any lines that are shortened by more than 50%. Smoothing in this case means limiting the velocity to not exceed the initial or final velocity, to remove the rapid acceleration and deceleration. As a debugging constant, it worked fine, but as an INI setting, it does seem hard to use. If we're lucky, there may be an algorithmic way to do this. Maybe if a segment isn't long enough to reach a cruise phase at the requested velocity, or if the velocity bump is less than some amount. On Tue, Jan 7, 2014 at 11:45 AM, sam sokolik sa...@empirescreen.com wrote: I have a question about Controls how aggressive velocity smoothing is. It's a bit counterintuitive, a value of 0.5 means no smoothing, a value of 0.0 means every segment is smoothed. Decrease this value if the velocity profile seems to be too bumpy. ARC_BLEND_SMOOTHING_THRESHOLD = 0.4 I see in the email you had the threshold set to .75? (I am confused..) sam On 1/7/2014 2:19 AM, Robert Ellenberg wrote: Ok, good news on the testing front, I think I've finally eliminated the little acceleration overages by making TP_TIME_EPSILON smaller, from 10^-7 to 10^-10 or so. Properly initializing the ABC and UVW parts of the blend arc seem to have eliminated the graphical glitches as well. With these last issues being fixed, I've moved development over to the beta branch here: https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-beta The beta status means that it's been tested on multiple builds and shows no apparent constraint violations or crashes. My top priority for the near future will be squashing any bugs on this branch, though if there's time I might add some additional features. On Tue, Jan 7, 2014 at 2:03 AM, phill carter phill.car...@oztime.com.au wrote: I'm still a few steps away from surface mount yet. All the gcode I have has probing for variable z height, I'll rip the probing out of one and post it. On Tue, 7 Jan 2014 01:48:47 -0500 Robert Ellenberg rwe...@gmail.com wrote: On Tue, Jan 7, 2014 at 1:33 AM, phill carter phill.car...@oztime.com.au wrote: I do a bit of repair work around the home, a few pcb's and lots of learning and trying things out. What got me interested in what you are doing is my original pcb etching was slooowww so I figured your changes would help. Sounds like fun! Do you do any surface mount stuff? I bought a set of PCB mills / drills recently, though I haven't had much time to make any boards yet. It turns out I had my acceleration way too low. The pcb gcode I am using is all very short line-line transitions. Would you mind sharing an example of such a program that ran really slow? The greater variety of test cases I can find, the easier it will be to improve and troubleshoot. For a mill with a low top speed, increasing acceleration seems to be a viable solution, but it's probably not ideal since it means you're hitting your drive system harder. If you could get the same performance with lower acceleration, it could help your machine in the long term. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
Awesome! I have finally built a sim on my laptop so I can play. Is there still an issue with the preview jumping? I think I am seeing that.with pulling this afternoon - I ran the default spiral set at 999ipm. at the end the cone jumps off the screen and then back again. http://imagebin.org/285329 there doesn't seem to bbe any constraint violations.. sam On 01/05/2014 01:26 PM, Robert Ellenberg wrote: That looks like a good demo, Sam. I just added it to my dropbox folder of nc test files. As both you and Phill have identified, the issue here seems to be how short it's cutting the corner, even at relatively low speeds. Here's a screenshot of the same issue on my machine: https://dl.dropboxusercontent.com/u/10948059/linuxcnc-trajectory-tests/corner_cut_arcblends.png This happens because there are no tolerances applied to the blend here, and arc blending is greedy, in that it can consume essentially all of a segment to get the fastest speed. A tight corner leads to huge tolerance for a very small increase in blend radius. I just pushed a simple fix for this, which is to limit the blend tolerance to the parabolic equivalent. Even with no tolerance applied, the worst-case blend tolerance is still bounded by the size of the segments. The maximum tolerance for parabolic blending is effectively 1/4 of the segment length, at the extreme case when the corner is 0 deg. (i.e. reverse direction). This wasn't explicitly programmed since it happened naturally, but we don't have that luxury for arc blending. My fix just adds this as a maximum tolerance. Here's what it looks like now with parabolic blends: https://dl.dropboxusercontent.com/u/10948059/linuxcnc-trajectory-tests/tight%20corner%20arc%20blend.png Here's the same motion with arc blends now: https://dl.dropboxusercontent.com/u/10948059/linuxcnc-trajectory-tests/tight%20corner%20arc%20blend.png -Rob On Sun, Jan 5, 2014 at 1:46 PM, sam sokolik sa...@empirescreen.com wrote: well I just ran the program - what seems to hapen is the angle between the last 2 moves is very small. So it blends them quite early.. If you say G64P.001 - it then runs the path pretty much the same speed - makes it all the way to the corner (well within .001) http://imagebin.org/285301 You can see the blend between the 2 lines right in the middle - it is odd though that it seems to be right at x0.. maybe coincidence.. (that shows both runs - G64 and G64P.001) this really isn't a good test to see the performance improvement for the new tp.. This would.. (and I think it should fit on your machine) The new tp peaks (with my config) at 270ipm vs 60ipm on current TP. g20 g64 g90 g0 z.1 g0 x1 y0 g1 z-.1 f999 o100 repeat [370] g91 g1 @-.0025 ^4.5 o100 endrepeat g90 g0 z.1 m2 sam On 01/05/2014 11:32 AM, Robert Ellenberg wrote: Hi Phill, Those screenshots look the same, are they duplicates? In any case, the fact that it skipped the parabolic blend entirely at that corner is not supposed to happen. I'm going to run that test again on my machines to confirm. What commit are you building on? I had to do a roll-back of some changes a few days ago, so that could be contributing to this issue. -Rob On Sun, Jan 5, 2014 at 2:18 AM, phill carter phill.car...@oztime.com.au wrote: I ran the arc-arc test after changing Y3 in lines 3 7 to Y2 and Y-3 in line 6 to Y-2 to better suit the envelope of my mill. Using 2.6 standard it ran ok, using 2.6 with arc-blend when running line 6, it jumped to line 7 when it reached Y0 rather than Y-2. Screenshots at https://www.dropbox.com/sh/wb05n11coih47ld/gJ6AY1Drch Cheers, Phill On Sat, 4 Jan 2014 01:43:23 -0500 Robert Ellenberg rwe...@gmail.com wrote: I just noticed a weird bug in a recent commit on the circular arc branch that causes acceleration violations when pausing / stopping. I've rolled back the circular arc branch to a known good commit to be safe. If anyone has pulled from that branch in the last three days, please reset to the current circular-blend-arc-alpha branch, which should point to this commit: 689e5cb185f87deba62391cd184f21f360ce2246 I'll push an update once I'm sure the bug is fixed. On Mon, Dec 30, 2013 at 1:20 PM, Robert Ellenberg rwe...@gmail.com wrote: On Dec 30, 2013 12:24 PM, sam sokolik sa...@empirescreen.com wrote: Could you explain your 'small gain'? from what I am seeing - you have to slow down to do a parabolic blend (If I understand it - it is a read-ahead buster) There are paths (like steve.ngc) which would be able to keep the speed up if there was arc-arc, arc-line blends and you can optimize the path (depth). And yes - I know it is a lot of work. (you are doing a great job - it is very impressive how quick you got to this point) What i mean by small gain is more statistical. It seems like most engraving-type g-code is made up of line segments, so the biggest overall gain is from making arc blends
Re: [Emc-developers] Initial tests of circular arc blending
I just ran your program in my config. It does seem to slow down more in spots than the current TP The left side for sure runs at full speed in the current tp vs the new. I think Robert should weigh in on it. Current TP http://imagebin.org/284460 New TP http://imagebin.org/284458 Here is the program (added Q0.5 so it matches current TP Naive cam setting) http://pastebin.ca/2520447 This is an example where the new TP shines. (sort line segements) G64P.0025Q.0025 Current TP http://imagebin.org/284455 New TP http://imagebin.org/284454 On 12/25/2013 6:17 AM, Julian Wingert wrote: Hi I have been testing but the new tp has always been slower than the old one... I also noticed that in halscope there seems to be a lot more following error on segment ends (jitter) in the circ blend branch. Movement seems to be more rough but slower? Run time from 0*0*0 starting is ~44s in 2.5.2 standard and ~48s in circ-blend-alpha. Especially @the end loops of the code (u-turns) it seems to run very rough. Config and test ngc file: https://www.dropbox.com/sh/9hyxjdmw4hhmoap/yn3Kw5Kk0X Merry Christmas! And I hope this will work out! Keep up :-) Best regards julian Robert Ellenberg rwe...@gmail.com wrote: Darn, I was hoping it would just work :). I'll take a look later today, chances are I forgot to commit / push something. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
Could you explain your 'small gain'? from what I am seeing - you have to slow down to do a parabolic blend (If I understand it - it is a read-ahead buster) There are paths (like steve.ngc) which would be able to keep the speed up if there was arc-arc, arc-line blends and you can optimize the path (depth). And yes - I know it is a lot of work. (you are doing a great job - it is very impressive how quick you got to this point) sam On 12/30/2013 11:02 AM, Robert Ellenberg wrote: Thanks for confirming that, Sam. Julian, I think the reason for the slowdown is there are a lot of arc-arc intersections, which fall back to parabolic blends. It will run slower (slightly) than the original because of a crude fix I made to arc acceleration. I cut the circular arc acceleration in half for parabolic blends to prevent a violation in this code: http://pastebin.com/Dpyr1jrY The problem with this fix is that it's a relatively rare case, and the cost is noticeable (as you can see with your code). In the long term, the fix for this is to add line-arc and arc-arc blends. I've prioritized other features since it's a lot of work for a relatively small gain, but I'm hoping to add these features in the future. -Rob On Mon, Dec 30, 2013 at 7:37 AM, sam sokolik sa...@empirescreen.com wrote: I just ran your program in my config. It does seem to slow down more in spots than the current TP The left side for sure runs at full speed in the current tp vs the new. I think Robert should weigh in on it. Current TP http://imagebin.org/284460 New TP http://imagebin.org/284458 Here is the program (added Q0.5 so it matches current TP Naive cam setting) http://pastebin.ca/2520447 This is an example where the new TP shines. (sort line segements) G64P.0025Q.0025 Current TP http://imagebin.org/284455 New TP http://imagebin.org/284454 On 12/25/2013 6:17 AM, Julian Wingert wrote: Hi I have been testing but the new tp has always been slower than the old one... I also noticed that in halscope there seems to be a lot more following error on segment ends (jitter) in the circ blend branch. Movement seems to be more rough but slower? Run time from 0*0*0 starting is ~44s in 2.5.2 standard and ~48s in circ-blend-alpha. Especially @the end loops of the code (u-turns) it seems to run very rough. Config and test ngc file: https://www.dropbox.com/sh/9hyxjdmw4hhmoap/yn3Kw5Kk0X Merry Christmas! And I hope this will work out! Keep up :-) Best regards julian Robert Ellenberg rwe...@gmail.com wrote: Darn, I was hoping it would just work :). I'll take a look later today, chances are I forgot to commit / push something. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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
Re: [Emc-developers] circular-blend-arc-alpha
Robert just pushed some changes today..I have not tested it. If you go back to commit 7709c21 from the 27th - I know that built. sam On 12/30/2013 09:01 PM, phill carter wrote: I am intending to test the new arc-blending with my Sherline mill by engraving pcb's. I am using Lubuntu 12.04 with the 3.4.55-rtai-2 kernel and LinuxCNC-2.6.0~pre. I am not sure if I should be trying circular-blend-arc-alpha or 3d-blend-arc-techdemos. 3d-blend-arc-techdemos makes ok but circular-blend-arc-alpha gives the following error... /home/phill/Downloads/src/git/linuxcnc-dev-circular-blend-arc-alpha/src/emc/kinematics/tc.c: In function ‘tcConnectBlendArc’: /home/phill/Downloads/src/git/linuxcnc-dev-circular-blend-arc-alpha/src/emc/kinematics/tc.c:481:5: error: implicit declaration of function ‘fmin’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [/home/phill/Downloads/src/git/linuxcnc-dev-circular-blend-arc-alpha/src/emc/kinematics/tc.o] Error 1 make[1]: *** [_module_/home/phill/Downloads/src/git/linuxcnc-dev-circular-blend-arc-alpha/src] Error 2 make: *** [modules] Error 2 make: Leaving directory `/home/phill/Downloads/src/git/linuxcnc-dev-circular-blend-arc-alpha/src' Cheers, Phill -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] circular-blend-arc-alpha
and you do want to use circular-blend-arc-alpha.. sam On 12/30/2013 09:07 PM, sam sokolik wrote: Robert just pushed some changes today..I have not tested it. If you go back to commit 7709c21 from the 27th - I know that built. sam On 12/30/2013 09:01 PM, phill carter wrote: I am intending to test the new arc-blending with my Sherline mill by engraving pcb's. I am using Lubuntu 12.04 with the 3.4.55-rtai-2 kernel and LinuxCNC-2.6.0~pre. I am not sure if I should be trying circular-blend-arc-alpha or 3d-blend-arc-techdemos. 3d-blend-arc-techdemos makes ok but circular-blend-arc-alpha gives the following error... /home/phill/Downloads/src/git/linuxcnc-dev-circular-blend-arc-alpha/src/emc/kinematics/tc.c: In function ‘tcConnectBlendArc’: /home/phill/Downloads/src/git/linuxcnc-dev-circular-blend-arc-alpha/src/emc/kinematics/tc.c:481:5: error: implicit declaration of function ‘fmin’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [/home/phill/Downloads/src/git/linuxcnc-dev-circular-blend-arc-alpha/src/emc/kinematics/tc.o] Error 1 make[1]: *** [_module_/home/phill/Downloads/src/git/linuxcnc-dev-circular-blend-arc-alpha/src] Error 2 make: *** [modules] Error 2 make: Leaving directory `/home/phill/Downloads/src/git/linuxcnc-dev-circular-blend-arc-alpha/src' Cheers, Phill -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
never mind... You changed Q to default to zero - so I had a G64P.5 and in the previous build - that (as you have found out) also sets the Q to .5. So changing to G64P.5Q.5 I get the same speed. sorry sam On 12/27/2013 12:55 PM, Robert Ellenberg wrote: Ok, I'll take a look at those versions and see what changed. On Dec 27, 2013 1:53 PM, sa...@empirescreen.com wrote: Question - I have a build running samco@samco-desktop:~/linuxcnc-beta8real$ git describe v2.5.3-2516-g3f0c527 and it runs steve.ngc with just 2-3 slow downs that I can tell. currently a fresh pull from your repository as of today (v2.5.3-2521-g0c13743) - steve.ngc slows down quite a few spots. 9 seconds vs 7 seconds. sam On Fri, 27 Dec 2013 02:25:17 -0500 Robert Ellenberg rwe...@gmail.com wrote: One odd issue. If I set the ARC_BLEND_ENABLE to 0 the spiral runs as expected.. (around 100ipm) but the arcspiral still seems to use the read ahead as it runs at top speed (420ipm) and I can make it run as the original tp by setting the ARC_BLEND_OPTIMIZATION_DEPTH to 1 (runs about 80ish-ipm). BTW setting it to 0 causes what looks like exact stop mode - pretty neat :) I don't know if that is bad or not.. but it surely doesn't act like the original trajectory planner. Excellent! I think this quirk is because it's always looking for tangent segments, since I didn't explicitly include a flag to disable tangent detection. It will still try to run the optimizer over segments that are already tangent, unless the optimization depth is 1. I'm working on a fix that will revert to stock behavior if the depth is less than 2. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Breaking Free of the Box
The way I understand it - the kins are 'on top' of motion at the moment. (I don't know if ja4 solves this - but I think it is the start).. So motion calculates the xyzabcuvw limits - then they get run through the kins module which could depending on the machine layout - multiply or divide these calculations for each 'joint'. sam On 12/26/2013 11:03 AM, Charles Steinkuehler wrote: On 12/26/2013 10:17 AM, Chris Radek wrote: On Thu, Dec 26, 2013 at 09:17:18AM -0600, Charles Steinkuehler wrote: simple move the joint until the switch closes. IMHO there needs to be a way to write programmable homing routines that can perform coordinated motion in joint and/or world space, But one thing at a time... I don't see how you can possibly move in world space before homing. I do see how you could move all joints simultaneously, for instance, which might be what you mean? This is a form of coordinated motion but it is not how we usually use the term coordinated, which means in world mode and in lines and arcs, etc. PROPOSAL: It seems to me that the limit check functions should be plug-able, like the kinematics module. The limits could then be as simple or complex as required by any particular machine. Have you tried just having your inverse kins return a failure in the situations you've identified as bad? in JA4 this is dealt with nicely I think. Endpoints are checked before a move is started. Not sure about how world mode jogs handle it. I've had kinematics return invalid results for position, and I suppose it behaves similar to hitting a limit (the machine shuts off and an error is presented on-screen). So position might not be too bad as-is (although it's nice to be told if gcode exceeds the machine limits on program load instead of 90% of the way through!). I'm more concerned about being able to set coordinated acceleration and velocity limits, so I can avoid having to perform X and Y moves at 57 % of my available max velocity and acceleration just so the occasional XYZ move doesn't exceed 100% of machine limits. Details: Given a maximum X, Y, and Z velocity of 1.0, the maximum speed of an XY move is 1.414 (or SQRT(2)), and the maximum speed of an XYZ move is 1.73 (or SQRT(3)), so I have to set my limits to 1/1.73 (0.577) of the actual limits or the machine will exceed them in the corner case. (pun intended) ...or is there already a way to limit the directional speed and acceleration of the head and not just the maximums in each Cartesian coordinate? -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
Did you get a chance to see if the ini settings are working for you? I have not tested it since tuesday. could it be something I am doing wrong? thanks sam On 12/26/2013 10:54 AM, Robert Ellenberg wrote: I like this idea, as it would make it much easier to make changes without messing up other people's work. It would take a bit of reorganization, since the motion module code is spread out over a few folders. I'm thinking it would help to rearrange these files into motion_common, trajectory_planners, kinematics, and then motion and motion2_experimental for module-specific code. Otherwise, we'll have a ton of code duplication. Another issue I can see is that whitespace is a crapshoot in most of the motion files. I'd really like to reindent all of them with spaces and 4-column indents, but this should probably be done across all of the major branches at once to prevent merge headaches. An alternative idea in a similar vein: would it be possible to specify a trajectory planner module in HAL, separate from the motion module? We'd have to agree on an API, but I can see that being less duplication and reorganization than two entirely separate motion modules. -Rob On Thu, Dec 26, 2013 at 5:34 AM, Andy Pugh bodge...@gmail.com wrote: On 26 Dec 2013, at 07:16, Michael Haberler mai...@mah.priv.at wrote: however: why not have more than one motion component? Motmod is already an INI entry. How difficult would it be to separately compile a separate motmod2_experimental ? -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
will do! thanks sam On 12/26/2013 04:07 PM, Robert Ellenberg wrote: It seems to be working on my end, in that I can enable and disable various setting from the INI file, and see the correct behavior in simulation. Can you try running my test config to see if it works on your build? tests/trajectory-planner/circular-arcs/circular_arcs.ini If that works then I'd suspect a typo. On Dec 26, 2013 2:37 PM, sam sokolik sa...@empirescreen.com wrote: Did you get a chance to see if the ini settings are working for you? I have not tested it since tuesday. could it be something I am doing wrong? I've run it on my laptop and desktop without issue, and I've tested that enabling/disabling each setting has the intended effect. Try running the config in tests/trajectory thanks sam -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
Ok - I must have had some odd characters on those lines - I deleted the last few characters and re-typed them and it seems to be working as expected. One odd issue. If I set the ARC_BLEND_ENABLE to 0 the spiral runs as expected.. (around 100ipm) but the arcspiral still seems to use the read ahead as it runs at top speed (420ipm) and I can make it run as the original tp by setting the ARC_BLEND_OPTIMIZATION_DEPTH to 1 (runs about 80ish-ipm). BTW setting it to 0 causes what looks like exact stop mode - pretty neat :) I don't know if that is bad or not.. but it surely doesn't act like the original trajectory planner. sam On 12/26/2013 04:07 PM, Robert Ellenberg wrote: It seems to be working on my end, in that I can enable and disable various setting from the INI file, and see the correct behavior in simulation. Can you try running my test config to see if it works on your build? tests/trajectory-planner/circular-arcs/circular_arcs.ini If that works then I'd suspect a typo. On Dec 26, 2013 2:37 PM, sam sokolik sa...@empirescreen.com wrote: Did you get a chance to see if the ini settings are working for you? I have not tested it since tuesday. could it be something I am doing wrong? I've run it on my laptop and desktop without issue, and I've tested that enabling/disabling each setting has the intended effect. Try running the config in tests/trajectory thanks sam -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
if you pulled as of the 23rd.. - I could not get it to work. (seems to run like the old tp.) Things to note - the lookahead works (circular arc blending) if - line-line segments - tangent line-arc, arc-line - tangent arc-arc so if you have a bunch of non tangent arc-arc or arc-line segments - it may just act like the current TP. for the above constraints - I have seen a great improvement... ie... http://youtu.be/oUajH5BCOUQ first run is current tp - second run is circular arc blending. (almost 4 times as fast for the given acc/vel) sam On 12/25/2013 06:17 AM, Julian Wingert wrote: Hi I have been testing but the new tp has always been slower than the old one... I also noticed that in halscope there seems to be a lot more following error on segment ends (jitter) in the circ blend branch. Movement seems to be more rough but slower? Run time from 0*0*0 starting is ~44s in 2.5.2 standard and ~48s in circ-blend-alpha. Especially @the end loops of the code (u-turns) it seems to run very rough. Config and test ngc file: https://www.dropbox.com/sh/9hyxjdmw4hhmoap/yn3Kw5Kk0X Merry Christmas! And I hope this will work out! Keep up :-) Best regards julian Robert Ellenberg rwe...@gmail.com wrote: Darn, I was hoping it would just work :). I'll take a look later today, chances are I forgot to commit / push something. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
I added these to the traj section (from what it looks like from your expamples) ARC_BLEND_ENABLE = 1 ARC_BLEND_FEEDBACK_ENABLE = 1 ARC_BLEND_OPTIMIZATION_DEPTH = 50 ARC_BLEND_SMOOTHING_THRESHOLD = 0.4 but it seems to be running like it is only doing parabolic blends.. sam On 12/23/2013 5:54 PM, Robert Ellenberg wrote: Yes, I added that one too. Keep in mind the tradeoff with this method: a large max feed override means blend arc radii are larger than you'd expect for a given feed rate. On Dec 23, 2013 6:50 PM, sam sokolik sa...@empirescreen.com wrote: Is it seeing the feedrate override from the ini also? again - great work! sam On 12/23/2013 02:50 PM, Robert Ellenberg wrote: I just pushed an update that moves a few settings into the INI file. To make your config use circular arc blends, you should add these 4 lines to your config: This setting enables arc blends: ARC_BLEND_ENABLE = 1 This setting enables fallback to parabolic blends if the arc-blend is slower ARC_BLEND_FALLBACK_ENABLE = 1 Equivalent to lookahead depth, how far back in # of segments the optimizer will look. ARC_BLEND_OPTIMIZATION_DEPTH = 50 Controls how aggressive velocity smoothing is. It's a bit counterintuitive, a value of 0.5 means no smoothing, a value of 0.0 means every segment is smoothed. Decrease this value if the velocity profile seems to be too bumpy. ARC_BLEND_SMOOTHING_THRESHOLD = 0.4 -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
(and I did use fallback.. (copy and paste error)) I tried for grins setting the fallback to 0 with the same result. ARC_BLEND_FALLBACK_ENABLE = 1 sam On 12/24/2013 9:45 AM, sam sokolik wrote: I added these to the traj section (from what it looks like from your expamples) ARC_BLEND_ENABLE = 1 ARC_BLEND_FEEDBACK_ENABLE = 1 ARC_BLEND_OPTIMIZATION_DEPTH = 50 ARC_BLEND_SMOOTHING_THRESHOLD = 0.4 but it seems to be running like it is only doing parabolic blends.. sam On 12/23/2013 5:54 PM, Robert Ellenberg wrote: Yes, I added that one too. Keep in mind the tradeoff with this method: a large max feed override means blend arc radii are larger than you'd expect for a given feed rate. On Dec 23, 2013 6:50 PM, sam sokolik sa...@empirescreen.com wrote: Is it seeing the feedrate override from the ini also? again - great work! sam On 12/23/2013 02:50 PM, Robert Ellenberg wrote: I just pushed an update that moves a few settings into the INI file. To make your config use circular arc blends, you should add these 4 lines to your config: This setting enables arc blends: ARC_BLEND_ENABLE = 1 This setting enables fallback to parabolic blends if the arc-blend is slower ARC_BLEND_FALLBACK_ENABLE = 1 Equivalent to lookahead depth, how far back in # of segments the optimizer will look. ARC_BLEND_OPTIMIZATION_DEPTH = 50 Controls how aggressive velocity smoothing is. It's a bit counterintuitive, a value of 0.5 means no smoothing, a value of 0.0 means every segment is smoothed. Decrease this value if the velocity profile seems to be too bumpy. ARC_BLEND_SMOOTHING_THRESHOLD = 0.4 -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
Unless I am doing something wrong :) Thanks for looking at this! sam On 12/24/2013 11:09 AM, Robert Ellenberg wrote: Darn, I was hoping it would just work :). I'll take a look later today, chances are I forgot to commit / push something. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
Wow - great work! I hope to test this tomorrow. sam On 12/23/2013 02:50 PM, Robert Ellenberg wrote: I just pushed an update that moves a few settings into the INI file. To make your config use circular arc blends, you should add these 4 lines to your config: This setting enables arc blends: ARC_BLEND_ENABLE = 1 This setting enables fallback to parabolic blends if the arc-blend is slower ARC_BLEND_FALLBACK_ENABLE = 1 Equivalent to lookahead depth, how far back in # of segments the optimizer will look. ARC_BLEND_OPTIMIZATION_DEPTH = 50 Controls how aggressive velocity smoothing is. It's a bit counterintuitive, a value of 0.5 means no smoothing, a value of 0.0 means every segment is smoothed. Decrease this value if the velocity profile seems to be too bumpy. ARC_BLEND_SMOOTHING_THRESHOLD = 0.4 -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
Is it seeing the feedrate override from the ini also? again - great work! sam On 12/23/2013 02:50 PM, Robert Ellenberg wrote: I just pushed an update that moves a few settings into the INI file. To make your config use circular arc blends, you should add these 4 lines to your config: This setting enables arc blends: ARC_BLEND_ENABLE = 1 This setting enables fallback to parabolic blends if the arc-blend is slower ARC_BLEND_FALLBACK_ENABLE = 1 Equivalent to lookahead depth, how far back in # of segments the optimizer will look. ARC_BLEND_OPTIMIZATION_DEPTH = 50 Controls how aggressive velocity smoothing is. It's a bit counterintuitive, a value of 0.5 means no smoothing, a value of 0.0 means every segment is smoothed. Decrease this value if the velocity profile seems to be too bumpy. ARC_BLEND_SMOOTHING_THRESHOLD = 0.4 -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
one last question on smoothing.. Does that in effect 'average' out the velocity? So smoothing would make the machine run less 'bumpy' with a hit on speed? Thanks sam On 12/23/2013 02:50 PM, Robert Ellenberg wrote: I just pushed an update that moves a few settings into the INI file. To make your config use circular arc blends, you should add these 4 lines to your config: This setting enables arc blends: ARC_BLEND_ENABLE = 1 This setting enables fallback to parabolic blends if the arc-blend is slower ARC_BLEND_FALLBACK_ENABLE = 1 Equivalent to lookahead depth, how far back in # of segments the optimizer will look. ARC_BLEND_OPTIMIZATION_DEPTH = 50 Controls how aggressive velocity smoothing is. It's a bit counterintuitive, a value of 0.5 means no smoothing, a value of 0.0 means every segment is smoothed. Decrease this value if the velocity profile seems to be too bumpy. ARC_BLEND_SMOOTHING_THRESHOLD = 0.4 -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
Did you push your changes last night? I don't see them in the circular-blend-arc-alpha branch. (last commit is on the 18th.) (no rush - have a good trip!) sam On 12/19/2013 08:54 PM, sam sokolik wrote: awesome - can't wait to try it! Great work! sam On 12/19/2013 06:32 PM, Robert Ellenberg wrote: It turned out that I was giving the arc too high a velocity. Now it checks to make sure the arc is tangent with the next and the previous move. On Dec 19, 2013 12:46 PM, Robert Ellenberg rwe...@gmail.com wrote: Ahh, I see, I didn't commit all of the changes. Unfortunately I'm traveling for the next few days, but I should be able to push a fix by tonight. here are the errors /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c: In function ‘tpComputeBlendVelocity’: /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:1642: error: ‘v_reachable’ undeclared (first use in this function) /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:1642: error: (Each undeclared identifier is reported only once /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:1642: error: for each function it appears in.) make[2]: *** [/home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.o] Error 1 make[1]: *** [_module_/home/samco/linuxcnc-beta8real/src] Error 2 make: *** [modules] Error 2 make: Leaving directory `/home/samco/linuxcnc-beta8real/src' samco@samco-desktop:~/linuxcnc-beta8real/src$ On Wed, 18 Dec 2013 20:57:23 -0600 sam sokolik sa...@empirescreen.com wrote: also - your current pushes didn't compile for me.. I did a git pull this afternoon and I noticed it failed. (sorry I didn't have time to copy the error) sam On 12/18/2013 08:26 AM, sa...@empirescreen.com wrote: Ok - found on constraint violation This re-produces it.. G21 G64p.127 S6000 M4 g0 X-13.908 Y111.435 Z-4.825F999500.0 Z-8.0 F999500.0 X-13.441 Y111.251 F9991200.0 G3 X-12.993 Y111.281 I0.181 J0.648 X-12.297 Y111.735 I-0.771 J1.942 G1 X-11.952 Y112.062 X-11.607 Y112.388 X-11.597 Y112.385 X-11.595 Y112.375 X-12.601 Y111.419 G3 X-13.16 Y110.003 I1.451 J-1.391 G1 Y107.172 G3 X-12.528 Y106.931 I0.362 J0.0 G2 X-9.072 Y110.409 I35.958 J-32.276 X-5.796 Y113.163 I32.254 J-35.045 G1 Z0.175 F9995000.0 X-13.16 Y108.124 Z-4.825 Z-8.0 F999500.0 G0 Z60.0 M09 M2 () On Tue, 17 Dec 2013 09:21:01 -0500 Robert Ellenberg rwe...@gmail.com wrote: Excellent! I just now fixed a dumb mistake with spindle-sync motion, which seems to be working in simulation with no overages. I still see the occasional jump up to 30.01 or 30.02 in some runs, which I haven't pinned down exactly. Still, a ~.1% overage is probably tolerable in the short term. On Tue, Dec 17, 2013 at 8:46 AM, sam sokolik sa...@empirescreen.com wrote: Running your current pushes as of this morning - I have had no overages!! I will keep hammering away at it. Thanks again - this is very impressive sam. On 12/16/2013 8:49 PM, Robert Ellenberg wrote: Ok, I just got it to work. It turns out that it runs fine if the G43 command is on its own line, but if it is run exactly as you have it, then it chokes. Time to investigate... On Mon, Dec 16, 2013 at 9:17 PM, Robert Ellenberg rwe...@gmail.com wrote: Do you have the whole program handy? I'm having trouble reproducing the acceleration violation with just that snippet. I'd like to run all the way through on the RT machine. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture
Re: [Emc-developers] Initial tests of circular arc blending
Ok - the changes showed up - built and ran the program that was causing the violations - YAY! I will keep hammering on it thanks again - impressive work! sam On 12/20/2013 4:52 AM, sam sokolik wrote: Did you push your changes last night? I don't see them in the circular-blend-arc-alpha branch. (last commit is on the 18th.) (no rush - have a good trip!) sam On 12/19/2013 08:54 PM, sam sokolik wrote: awesome - can't wait to try it! Great work! sam On 12/19/2013 06:32 PM, Robert Ellenberg wrote: It turned out that I was giving the arc too high a velocity. Now it checks to make sure the arc is tangent with the next and the previous move. On Dec 19, 2013 12:46 PM, Robert Ellenberg rwe...@gmail.com wrote: Ahh, I see, I didn't commit all of the changes. Unfortunately I'm traveling for the next few days, but I should be able to push a fix by tonight. here are the errors /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c: In function ‘tpComputeBlendVelocity’: /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:1642: error: ‘v_reachable’ undeclared (first use in this function) /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:1642: error: (Each undeclared identifier is reported only once /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:1642: error: for each function it appears in.) make[2]: *** [/home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.o] Error 1 make[1]: *** [_module_/home/samco/linuxcnc-beta8real/src] Error 2 make: *** [modules] Error 2 make: Leaving directory `/home/samco/linuxcnc-beta8real/src' samco@samco-desktop:~/linuxcnc-beta8real/src$ On Wed, 18 Dec 2013 20:57:23 -0600 sam sokolik sa...@empirescreen.com wrote: also - your current pushes didn't compile for me.. I did a git pull this afternoon and I noticed it failed. (sorry I didn't have time to copy the error) sam On 12/18/2013 08:26 AM, sa...@empirescreen.com wrote: Ok - found on constraint violation This re-produces it.. G21 G64p.127 S6000 M4 g0 X-13.908 Y111.435 Z-4.825F999500.0 Z-8.0 F999500.0 X-13.441 Y111.251 F9991200.0 G3 X-12.993 Y111.281 I0.181 J0.648 X-12.297 Y111.735 I-0.771 J1.942 G1 X-11.952 Y112.062 X-11.607 Y112.388 X-11.597 Y112.385 X-11.595 Y112.375 X-12.601 Y111.419 G3 X-13.16 Y110.003 I1.451 J-1.391 G1 Y107.172 G3 X-12.528 Y106.931 I0.362 J0.0 G2 X-9.072 Y110.409 I35.958 J-32.276 X-5.796 Y113.163 I32.254 J-35.045 G1 Z0.175 F9995000.0 X-13.16 Y108.124 Z-4.825 Z-8.0 F999500.0 G0 Z60.0 M09 M2 () On Tue, 17 Dec 2013 09:21:01 -0500 Robert Ellenberg rwe...@gmail.com wrote: Excellent! I just now fixed a dumb mistake with spindle-sync motion, which seems to be working in simulation with no overages. I still see the occasional jump up to 30.01 or 30.02 in some runs, which I haven't pinned down exactly. Still, a ~.1% overage is probably tolerable in the short term. On Tue, Dec 17, 2013 at 8:46 AM, sam sokolik sa...@empirescreen.com wrote: Running your current pushes as of this morning - I have had no overages!! I will keep hammering away at it. Thanks again - this is very impressive sam. On 12/16/2013 8:49 PM, Robert Ellenberg wrote: Ok, I just got it to work. It turns out that it runs fine if the G43 command is on its own line, but if it is run exactly as you have it, then it chokes. Time to investigate... On Mon, Dec 16, 2013 at 9:17 PM, Robert Ellenberg rwe...@gmail.com wrote: Do you have the whole program handy? I'm having trouble reproducing the acceleration violation with just that snippet. I'd like to run all the way through on the RT machine. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net
Re: [Emc-developers] Initial tests of circular arc blending
awesome - can't wait to try it! Great work! sam On 12/19/2013 06:32 PM, Robert Ellenberg wrote: It turned out that I was giving the arc too high a velocity. Now it checks to make sure the arc is tangent with the next and the previous move. On Dec 19, 2013 12:46 PM, Robert Ellenberg rwe...@gmail.com wrote: Ahh, I see, I didn't commit all of the changes. Unfortunately I'm traveling for the next few days, but I should be able to push a fix by tonight. here are the errors /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c: In function ‘tpComputeBlendVelocity’: /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:1642: error: ‘v_reachable’ undeclared (first use in this function) /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:1642: error: (Each undeclared identifier is reported only once /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:1642: error: for each function it appears in.) make[2]: *** [/home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.o] Error 1 make[1]: *** [_module_/home/samco/linuxcnc-beta8real/src] Error 2 make: *** [modules] Error 2 make: Leaving directory `/home/samco/linuxcnc-beta8real/src' samco@samco-desktop:~/linuxcnc-beta8real/src$ On Wed, 18 Dec 2013 20:57:23 -0600 sam sokolik sa...@empirescreen.com wrote: also - your current pushes didn't compile for me.. I did a git pull this afternoon and I noticed it failed. (sorry I didn't have time to copy the error) sam On 12/18/2013 08:26 AM, sa...@empirescreen.com wrote: Ok - found on constraint violation This re-produces it.. G21 G64p.127 S6000 M4 g0 X-13.908 Y111.435 Z-4.825F999500.0 Z-8.0 F999500.0 X-13.441 Y111.251 F9991200.0 G3 X-12.993 Y111.281 I0.181 J0.648 X-12.297 Y111.735 I-0.771 J1.942 G1 X-11.952 Y112.062 X-11.607 Y112.388 X-11.597 Y112.385 X-11.595 Y112.375 X-12.601 Y111.419 G3 X-13.16 Y110.003 I1.451 J-1.391 G1 Y107.172 G3 X-12.528 Y106.931 I0.362 J0.0 G2 X-9.072 Y110.409 I35.958 J-32.276 X-5.796 Y113.163 I32.254 J-35.045 G1 Z0.175 F9995000.0 X-13.16 Y108.124 Z-4.825 Z-8.0 F999500.0 G0 Z60.0 M09 M2 () On Tue, 17 Dec 2013 09:21:01 -0500 Robert Ellenberg rwe...@gmail.com wrote: Excellent! I just now fixed a dumb mistake with spindle-sync motion, which seems to be working in simulation with no overages. I still see the occasional jump up to 30.01 or 30.02 in some runs, which I haven't pinned down exactly. Still, a ~.1% overage is probably tolerable in the short term. On Tue, Dec 17, 2013 at 8:46 AM, sam sokolik sa...@empirescreen.com wrote: Running your current pushes as of this morning - I have had no overages!! I will keep hammering away at it. Thanks again - this is very impressive sam. On 12/16/2013 8:49 PM, Robert Ellenberg wrote: Ok, I just got it to work. It turns out that it runs fine if the G43 command is on its own line, but if it is run exactly as you have it, then it chokes. Time to investigate... On Mon, Dec 16, 2013 at 9:17 PM, Robert Ellenberg rwe...@gmail.com wrote: Do you have the whole program handy? I'm having trouble reproducing the acceleration violation with just that snippet. I'd like to run all the way through on the RT machine. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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
Re: [Emc-developers] Initial tests of circular arc blending
also - your current pushes didn't compile for me.. I did a git pull this afternoon and I noticed it failed. (sorry I didn't have time to copy the error) sam On 12/18/2013 08:26 AM, sa...@empirescreen.com wrote: Ok - found on constraint violation This re-produces it.. G21 G64p.127 S6000 M4 g0 X-13.908 Y111.435 Z-4.825F999500.0 Z-8.0 F999500.0 X-13.441 Y111.251 F9991200.0 G3 X-12.993 Y111.281 I0.181 J0.648 X-12.297 Y111.735 I-0.771 J1.942 G1 X-11.952 Y112.062 X-11.607 Y112.388 X-11.597 Y112.385 X-11.595 Y112.375 X-12.601 Y111.419 G3 X-13.16 Y110.003 I1.451 J-1.391 G1 Y107.172 G3 X-12.528 Y106.931 I0.362 J0.0 G2 X-9.072 Y110.409 I35.958 J-32.276 X-5.796 Y113.163 I32.254 J-35.045 G1 Z0.175 F9995000.0 X-13.16 Y108.124 Z-4.825 Z-8.0 F999500.0 G0 Z60.0 M09 M2 () On Tue, 17 Dec 2013 09:21:01 -0500 Robert Ellenberg rwe...@gmail.com wrote: Excellent! I just now fixed a dumb mistake with spindle-sync motion, which seems to be working in simulation with no overages. I still see the occasional jump up to 30.01 or 30.02 in some runs, which I haven't pinned down exactly. Still, a ~.1% overage is probably tolerable in the short term. On Tue, Dec 17, 2013 at 8:46 AM, sam sokolik sa...@empirescreen.com wrote: Running your current pushes as of this morning - I have had no overages!! I will keep hammering away at it. Thanks again - this is very impressive sam. On 12/16/2013 8:49 PM, Robert Ellenberg wrote: Ok, I just got it to work. It turns out that it runs fine if the G43 command is on its own line, but if it is run exactly as you have it, then it chokes. Time to investigate... On Mon, Dec 16, 2013 at 9:17 PM, Robert Ellenberg rwe...@gmail.com wrote: Do you have the whole program handy? I'm having trouble reproducing the acceleration violation with just that snippet. I'd like to run all the way through on the RT machine. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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
Re: [Emc-developers] Initial tests of circular arc blending
awesome - I think I have found some more constraint violations in master.. I think you may be fixing those issues in your branch :) This program in master causes violations.. - around 35in/sec^2 - I need to send a bug report but have been a bit busy.. http://electronicsam.com/images/KandT/testing/circblendlatest/LHchips3error.ngc sam On 12/18/2013 08:46 PM, Robert Ellenberg wrote: It looks like that's an issue with my tweaks to parabolic blends. I added a fix so that it uses the old method of choosing blend velocities for arcs and the violation disappears. Good catch! On Wed, Dec 18, 2013 at 9:26 AM, sa...@empirescreen.com wrote: Ok - found on constraint violation This re-produces it.. G21 G64p.127 S6000 M4 g0 X-13.908 Y111.435 Z-4.825F999500.0 Z-8.0 F999500.0 X-13.441 Y111.251 F9991200.0 G3 X-12.993 Y111.281 I0.181 J0.648 X-12.297 Y111.735 I-0.771 J1.942 G1 X-11.952 Y112.062 X-11.607 Y112.388 X-11.597 Y112.385 X-11.595 Y112.375 X-12.601 Y111.419 G3 X-13.16 Y110.003 I1.451 J-1.391 G1 Y107.172 G3 X-12.528 Y106.931 I0.362 J0.0 G2 X-9.072 Y110.409 I35.958 J-32.276 X-5.796 Y113.163 I32.254 J-35.045 G1 Z0.175 F9995000.0 X-13.16 Y108.124 Z-4.825 Z-8.0 F999500.0 G0 Z60.0 M09 M2 () On Tue, 17 Dec 2013 09:21:01 -0500 Robert Ellenberg rwe...@gmail.com wrote: Excellent! I just now fixed a dumb mistake with spindle-sync motion, which seems to be working in simulation with no overages. I still see the occasional jump up to 30.01 or 30.02 in some runs, which I haven't pinned down exactly. Still, a ~.1% overage is probably tolerable in the short term. On Tue, Dec 17, 2013 at 8:46 AM, sam sokolik sa...@empirescreen.com wrote: Running your current pushes as of this morning - I have had no overages!! I will keep hammering away at it. Thanks again - this is very impressive sam. On 12/16/2013 8:49 PM, Robert Ellenberg wrote: Ok, I just got it to work. It turns out that it runs fine if the G43 command is on its own line, but if it is run exactly as you have it, then it chokes. Time to investigate... On Mon, Dec 16, 2013 at 9:17 PM, Robert Ellenberg rwe...@gmail.com wrote: Do you have the whole program handy? I'm having trouble reproducing the acceleration violation with just that snippet. I'd like to run all the way through on the RT machine. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
you can really see it if you slow down the acceleration to 1in/sec^2 sam On 12/16/2013 10:34 AM, sam sokolik wrote: This program (which should be tangent arcs) seems to slow down to a stop at the beginning of the first and last arc. % (1 square with rounded corners) G90 G54 G20 G64 G0 X0 Y.25 Z0 G1 Y.75 F50 G2 X.25 Y1 I.25 G1 X.75 G2 X1 Y.75 J-.25 G1 Y.25 G2 X.75 Y0 I-.25 G1 X.25 G2 X0 Y.25 J.25 M30 On 12/15/2013 9:40 PM, sam sokolik wrote: Arcspiral.ngc now runs at a peak of 400+ipm - only switches to parabolic blends at the very end of the program (probably where the arcs are not 'tangent' enough). Awesome! steve.ngc runs in 7 seconds and seems to slow down down in 2 spots (switches to parabolic blends..) Awesome! :) stellabee1 runs a lot faster but.. When running G64P.005 - I get a overage around line 44545. Here is a short example that shows the errror - if you run the program farther - it will have a hand full more of these. says line 23 http://imagebin.org/282452 G20 G0 Z0.0120 G17 G40 G80 G90 G94 S1000 M3 (G04 P3) G64P.005 F999. G18 F999. G0 X3.0560 Z-0.1065 X3.0660 Z-0.0958 G2 X3.0800 Y3.3700 Z-0.0853 I-0.0126 K0.0314 G1 X3.0940 Z-0.0824 X3.1040 Z-0.0889 G3 X3.1160 Y3.3700 Z-0.0814 I0.0122 K-0.0061 G1 X3.1220 Z-0.0830 X3.1260 Z-0.0824 X3.1340 Z-0.0735 X3.1380 Z-0.0745 X3.1420 Z-0.0791 X3.1500 Z-0.0941 X3.1600 Z-0.1020 X3.1660 Z-0.0990 X3.1740 Z-0.1000 G3 X3.1880 Y3.3700 Z-0.0922 I0.0188 K-0.0172 G3 X3.1960 Y3.3700 Z-0.0736 I0.0697 K-0.0189 G1 X3.1980 Z-0.0706 M2 Great work!! sam On 12/15/2013 03:37 PM, Robert Ellenberg wrote: I think I fixed the issue in the latest commit. It turned out that I wasn't checking the type of segment properly in an error check, so it would flag some arcs as not tangent even when they were. Along with some other fixes to get acceleration right, it should be running at nearly full speed now. Since my last push, I also added a few optimization fixes that should run code like stellabee a bit faster. In particular transitions from tangent to parabolic blending in some cases forced two unnecessary exact stops, which caused more ripple and slowdown than would otherwise be expected. I also ran the 3D chips code on my Sherline, off of an Atom CPU. I didn't see any RT interruptions even with the base thread running. My plan for testing next is to set up a version of the test config with a base thread, and spoof an e-stop. This way, the parallel port can be disconnected to do build tests. -Rob On Fri, Dec 13, 2013 at 2:44 PM, sam sokolik sa...@empirescreen.com wrote: I forgot to say - I just pulled your latest changes before testing... sam On 12/13/2013 1:37 PM, Robert Ellenberg wrote: Can you send a link to that G code? I'd like to run it myself and see if I can pinpoint the slowdown. I've identified and fixed a bunch of little slowdowns over the last week, so the problem may already be solved. Thanks! Rob On Fri, Dec 13, 2013 at 2:00 PM, sam sokolik sa...@empirescreen.com wrote: Couple of things. arc-arc blends are slower than current TP... current tp does arcspiral at a peak of 100ipm while the new TP does it at about 70. So current TP http://imagebin.org/282155 1:19 minutes New TP http://imagebin.org/282156 1:51 (you can see it does parabolic blends) The neat thing is.. If you do a G64P.003 the naive cam detector converts the short arcs to line segments and you get... http://imagebin.org/282156 21 seconds that peaks at almost 400ipm sam On 12/12/2013 2:49 PM, Robert Ellenberg wrote: I agree with Sam that we're ready for testing from other users. However, there are a few features that we may want to add before a merged into a main build. One limitation now is that there are a bunch of configuration variables that are hard coded: - Optimization depth (currently set to ~40 segments) - Enable / disable arc blend flag - Max feed override (for sizing blend arcs, assumed to be 200%) Given these extra settings, I'm curious what the best way is get them from an INI file to the trajectory planner. For the experts, how are INI settings propagated into motion currently? Is there an easy way to tack on a few more config options? Thanks, Rob -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc
Re: [Emc-developers] Initial tests of circular arc blending
You might want to double check that - it seems to violate the constraint at the point between the line and the first arc.. (I don't see a parabolic blend at that point) sam On 12/16/2013 1:59 PM, Robert Ellenberg wrote: I suspect my tweaks to parabolic blending are the culprit here. I'm going to quickly revert those changes tonight and see if we can get this 100% working. So running this program strait G64 old http://imagebin.org/282644 new http://imagebin.org/282645 This one runs fine until you re-run it(entry segment is much longer.. and you get http://imagebin.org/282646 This seems to cause it. G21g64p.1 S6000 M4 G0 X0.779 Y-1.317 Z60.0 Z5.0 G43 H00 M8 Z-11.97 F9991300.0 G18 G2 X5.779 Z-16.97 I5.0 K0.0 G1 X5.905 Z-16.868 X6.032 Z-16.778 X6.853 Z-16.246 X6.916 Z-16.195 M2 On Mon, 16 Dec 2013 11:56:36 -0500 Robert Ellenberg rwe...@gmail.com wrote: That's by design, though it's not optimal. I abort optimization if a segment is already in progress , to prevent stepping on tp 's toes. Also, the optimization doesn't run on the last segment in the queue, because that segment has the potential to be shortened by a future blend arc. Both of these problems are fixable. I was looking into how to detect end if file in the code, and it seems that the interp_waiting state corresponds to the interpreter running out of valid moves (rather than just having a full queue). If this is the case, then a simple check should be enough to flag the last move. Similarly, I could make blend arc creation work on the unchanged portion of a segment in progress. Rob On Dec 16, 2013 11:34 AM, sam sokolik sa...@empirescreen.com wrote: This program (which should be tangent arcs) seems to slow down to a stop at the beginning of the first and last arc. % (1 square with rounded corners) G90 G54 G20 G64 G0 X0 Y.25 Z0 G1 Y.75 F50 G2 X.25 Y1 I.25 G1 X.75 G2 X1 Y.75 J-.25 G1 Y.25 G2 X.75 Y0 I-.25 G1 X.25 G2 X0 Y.25 J.25 M30 On 12/15/2013 9:40 PM, sam sokolik wrote: Arcspiral.ngc now runs at a peak of 400+ipm - only switches to parabolic blends at the very end of the program (probably where the arcs are not 'tangent' enough). Awesome! steve.ngc runs in 7 seconds and seems to slow down down in 2 spots (switches to parabolic blends..) Awesome! :) stellabee1 runs a lot faster but.. When running G64P.005 - I get a overage around line 44545. Here is a short example that shows the errror - if you run the program farther - it will have a hand full more of these. says line 23 http://imagebin.org/282452 G20 G0 Z0.0120 G17 G40 G80 G90 G94 S1000 M3 (G04 P3) G64P.005 F999. G18 F999. G0 X3.0560 Z-0.1065 X3.0660 Z-0.0958 G2 X3.0800 Y3.3700 Z-0.0853 I-0.0126 K0.0314 G1 X3.0940 Z-0.0824 X3.1040 Z-0.0889 G3 X3.1160 Y3.3700 Z-0.0814 I0.0122 K-0.0061 G1 X3.1220 Z-0.0830 X3.1260 Z-0.0824 X3.1340 Z-0.0735 X3.1380 Z-0.0745 X3.1420 Z-0.0791 X3.1500 Z-0.0941 X3.1600 Z-0.1020 X3.1660 Z-0.0990 X3.1740 Z-0.1000 G3 X3.1880 Y3.3700 Z-0.0922 I0.0188 K-0.0172 G3 X3.1960 Y3.3700 Z-0.0736 I0.0697 K-0.0189 G1 X3.1980 Z-0.0706 M2 Great work!! sam On 12/15/2013 03:37 PM, Robert Ellenberg wrote: I think I fixed the issue in the latest commit. It turned out that I wasn't checking the type of segment properly in an error check, so it would flag some arcs as not tangent even when they were. Along with some other fixes to get acceleration right, it should be running at nearly full speed now. Since my last push, I also added a few optimization fixes that should run code like stellabee a bit faster. In particular transitions from tangent to parabolic blending in some cases forced two unnecessary exact stops, which caused more ripple and slowdown than would otherwise be expected. I also ran the 3D chips code on my Sherline, off of an Atom CPU. I didn't see any RT interruptions even with the base thread running. My plan for testing next is to set up a version of the test config with a base thread, and spoof an e-stop. This way, the parallel port can be disconnected to do build tests. -Rob On Fri, Dec 13, 2013 at 2:44 PM, sam sokolik sa...@empirescreen.com wrote: I forgot to say - I just pulled your latest changes before testing... sam On 12/13/2013 1:37 PM, Robert Ellenberg wrote: Can you send a link to that G code? I'd like to run it myself and see if I can pinpoint the slowdown. I've identified and fixed a bunch of little slowdowns over the last week, so the problem may already be solved. Thanks! Rob On Fri, Dec 13, 2013 at 2:00 PM, sam sokolik sa...@empirescreen.com wrote: Couple of things. arc-arc blends are slower than current TP... current tp does arcspiral at a peak of 100ipm while the new TP does it at about 70. So current TP http://imagebin.org/282155 1:19 minutes New TP http://imagebin.org/282156 1:51 (you can
Re: [Emc-developers] Initial tests of circular arc blending
wow - can't wait to try it! thanks! sam On 12/15/2013 03:37 PM, Robert Ellenberg wrote: I think I fixed the issue in the latest commit. It turned out that I wasn't checking the type of segment properly in an error check, so it would flag some arcs as not tangent even when they were. Along with some other fixes to get acceleration right, it should be running at nearly full speed now. Since my last push, I also added a few optimization fixes that should run code like stellabee a bit faster. In particular transitions from tangent to parabolic blending in some cases forced two unnecessary exact stops, which caused more ripple and slowdown than would otherwise be expected. I also ran the 3D chips code on my Sherline, off of an Atom CPU. I didn't see any RT interruptions even with the base thread running. My plan for testing next is to set up a version of the test config with a base thread, and spoof an e-stop. This way, the parallel port can be disconnected to do build tests. -Rob On Fri, Dec 13, 2013 at 2:44 PM, sam sokolik sa...@empirescreen.com wrote: I forgot to say - I just pulled your latest changes before testing... sam On 12/13/2013 1:37 PM, Robert Ellenberg wrote: Can you send a link to that G code? I'd like to run it myself and see if I can pinpoint the slowdown. I've identified and fixed a bunch of little slowdowns over the last week, so the problem may already be solved. Thanks! Rob On Fri, Dec 13, 2013 at 2:00 PM, sam sokolik sa...@empirescreen.com wrote: Couple of things. arc-arc blends are slower than current TP... current tp does arcspiral at a peak of 100ipm while the new TP does it at about 70. So current TP http://imagebin.org/282155 1:19 minutes New TP http://imagebin.org/282156 1:51 (you can see it does parabolic blends) The neat thing is.. If you do a G64P.003 the naive cam detector converts the short arcs to line segments and you get... http://imagebin.org/282156 21 seconds that peaks at almost 400ipm sam On 12/12/2013 2:49 PM, Robert Ellenberg wrote: I agree with Sam that we're ready for testing from other users. However, there are a few features that we may want to add before a merged into a main build. One limitation now is that there are a bunch of configuration variables that are hard coded: - Optimization depth (currently set to ~40 segments) - Enable / disable arc blend flag - Max feed override (for sizing blend arcs, assumed to be 200%) Given these extra settings, I'm curious what the best way is get them from an INI file to the trajectory planner. For the experts, how are INI settings propagated into motion currently? Is there an easy way to tack on a few more config options? Thanks, Rob -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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
Re: [Emc-developers] Initial tests of circular arc blending
Arcspiral.ngc now runs at a peak of 400+ipm - only switches to parabolic blends at the very end of the program (probably where the arcs are not 'tangent' enough). Awesome! steve.ngc runs in 7 seconds and seems to slow down down in 2 spots (switches to parabolic blends..) Awesome! :) stellabee1 runs a lot faster but.. When running G64P.005 - I get a overage around line 44545. Here is a short example that shows the errror - if you run the program farther - it will have a hand full more of these. says line 23 http://imagebin.org/282452 G20 G0 Z0.0120 G17 G40 G80 G90 G94 S1000 M3 (G04 P3) G64P.005 F999. G18 F999. G0 X3.0560 Z-0.1065 X3.0660 Z-0.0958 G2 X3.0800 Y3.3700 Z-0.0853 I-0.0126 K0.0314 G1 X3.0940 Z-0.0824 X3.1040 Z-0.0889 G3 X3.1160 Y3.3700 Z-0.0814 I0.0122 K-0.0061 G1 X3.1220 Z-0.0830 X3.1260 Z-0.0824 X3.1340 Z-0.0735 X3.1380 Z-0.0745 X3.1420 Z-0.0791 X3.1500 Z-0.0941 X3.1600 Z-0.1020 X3.1660 Z-0.0990 X3.1740 Z-0.1000 G3 X3.1880 Y3.3700 Z-0.0922 I0.0188 K-0.0172 G3 X3.1960 Y3.3700 Z-0.0736 I0.0697 K-0.0189 G1 X3.1980 Z-0.0706 M2 Great work!! sam On 12/15/2013 03:37 PM, Robert Ellenberg wrote: I think I fixed the issue in the latest commit. It turned out that I wasn't checking the type of segment properly in an error check, so it would flag some arcs as not tangent even when they were. Along with some other fixes to get acceleration right, it should be running at nearly full speed now. Since my last push, I also added a few optimization fixes that should run code like stellabee a bit faster. In particular transitions from tangent to parabolic blending in some cases forced two unnecessary exact stops, which caused more ripple and slowdown than would otherwise be expected. I also ran the 3D chips code on my Sherline, off of an Atom CPU. I didn't see any RT interruptions even with the base thread running. My plan for testing next is to set up a version of the test config with a base thread, and spoof an e-stop. This way, the parallel port can be disconnected to do build tests. -Rob On Fri, Dec 13, 2013 at 2:44 PM, sam sokolik sa...@empirescreen.com wrote: I forgot to say - I just pulled your latest changes before testing... sam On 12/13/2013 1:37 PM, Robert Ellenberg wrote: Can you send a link to that G code? I'd like to run it myself and see if I can pinpoint the slowdown. I've identified and fixed a bunch of little slowdowns over the last week, so the problem may already be solved. Thanks! Rob On Fri, Dec 13, 2013 at 2:00 PM, sam sokolik sa...@empirescreen.com wrote: Couple of things. arc-arc blends are slower than current TP... current tp does arcspiral at a peak of 100ipm while the new TP does it at about 70. So current TP http://imagebin.org/282155 1:19 minutes New TP http://imagebin.org/282156 1:51 (you can see it does parabolic blends) The neat thing is.. If you do a G64P.003 the naive cam detector converts the short arcs to line segments and you get... http://imagebin.org/282156 21 seconds that peaks at almost 400ipm sam On 12/12/2013 2:49 PM, Robert Ellenberg wrote: I agree with Sam that we're ready for testing from other users. However, there are a few features that we may want to add before a merged into a main build. One limitation now is that there are a bunch of configuration variables that are hard coded: - Optimization depth (currently set to ~40 segments) - Enable / disable arc blend flag - Max feed override (for sizing blend arcs, assumed to be 200%) Given these extra settings, I'm curious what the best way is get them from an INI file to the trajectory planner. For the experts, how are INI settings propagated into motion currently? Is there an easy way to tack on a few more config options? Thanks, Rob -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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
Re: [Emc-developers] Initial tests of circular arc blending
Couple of things. arc-arc blends are slower than current TP... current tp does arcspiral at a peak of 100ipm while the new TP does it at about 70. So current TP http://imagebin.org/282155 1:19 minutes New TP http://imagebin.org/282156 1:51 (you can see it does parabolic blends) The neat thing is.. If you do a G64P.003 the naive cam detector converts the short arcs to line segments and you get... http://imagebin.org/282156 21 seconds that peaks at almost 400ipm sam On 12/12/2013 2:49 PM, Robert Ellenberg wrote: I agree with Sam that we're ready for testing from other users. However, there are a few features that we may want to add before a merged into a main build. One limitation now is that there are a bunch of configuration variables that are hard coded: - Optimization depth (currently set to ~40 segments) - Enable / disable arc blend flag - Max feed override (for sizing blend arcs, assumed to be 200%) Given these extra settings, I'm curious what the best way is get them from an INI file to the trajectory planner. For the experts, how are INI settings propagated into motion currently? Is there an easy way to tack on a few more config options? Thanks, Rob -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
oops http://imagebin.org/282157 sam On 12/13/2013 1:20 PM, Gene Heskett wrote: On Friday 13 December 2013 14:19:45 sam sokolik did opine: Couple of things. arc-arc blends are slower than current TP... current tp does arcspiral at a peak of 100ipm while the new TP does it at about 70. So current TP http://imagebin.org/282155 1:19 minutes New TP http://imagebin.org/282156 1:51 (you can see it does parabolic blends) The neat thing is.. If you do a G64P.003 the naive cam detector converts the short arcs to line segments and you get... http://imagebin.org/282156 21 seconds wrong pix Sam. that peaks at almost 400ipm sam On 12/12/2013 2:49 PM, Robert Ellenberg wrote: I agree with Sam that we're ready for testing from other users. However, there are a few features that we may want to add before a merged into a main build. One limitation now is that there are a bunch of configuration variables that are hard coded: - Optimization depth (currently set to ~40 segments) - Enable / disable arc blend flag - Max feed override (for sizing blend arcs, assumed to be 200%) Given these extra settings, I'm curious what the best way is get them from an INI file to the trajectory planner. For the experts, how are INI settings propagated into motion currently? Is there an easy way to tack on a few more config options? Thanks, Rob -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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.cl ktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers Cheers, Gene -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
This is the arcspiral.ngc I am using. http://electronicsam.com/images/KandT/testing/arcspiral.ngc Thanks! sam On 12/13/2013 1:37 PM, Robert Ellenberg wrote: Can you send a link to that G code? I'd like to run it myself and see if I can pinpoint the slowdown. I've identified and fixed a bunch of little slowdowns over the last week, so the problem may already be solved. Thanks! Rob On Fri, Dec 13, 2013 at 2:00 PM, sam sokolik sa...@empirescreen.com wrote: Couple of things. arc-arc blends are slower than current TP... current tp does arcspiral at a peak of 100ipm while the new TP does it at about 70. So current TP http://imagebin.org/282155 1:19 minutes New TP http://imagebin.org/282156 1:51 (you can see it does parabolic blends) The neat thing is.. If you do a G64P.003 the naive cam detector converts the short arcs to line segments and you get... http://imagebin.org/282156 21 seconds that peaks at almost 400ipm sam On 12/12/2013 2:49 PM, Robert Ellenberg wrote: I agree with Sam that we're ready for testing from other users. However, there are a few features that we may want to add before a merged into a main build. One limitation now is that there are a bunch of configuration variables that are hard coded: - Optimization depth (currently set to ~40 segments) - Enable / disable arc blend flag - Max feed override (for sizing blend arcs, assumed to be 200%) Given these extra settings, I'm curious what the best way is get them from an INI file to the trajectory planner. For the experts, how are INI settings propagated into motion currently? Is there an easy way to tack on a few more config options? Thanks, Rob -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
I forgot to say - I just pulled your latest changes before testing... sam On 12/13/2013 1:37 PM, Robert Ellenberg wrote: Can you send a link to that G code? I'd like to run it myself and see if I can pinpoint the slowdown. I've identified and fixed a bunch of little slowdowns over the last week, so the problem may already be solved. Thanks! Rob On Fri, Dec 13, 2013 at 2:00 PM, sam sokolik sa...@empirescreen.com wrote: Couple of things. arc-arc blends are slower than current TP... current tp does arcspiral at a peak of 100ipm while the new TP does it at about 70. So current TP http://imagebin.org/282155 1:19 minutes New TP http://imagebin.org/282156 1:51 (you can see it does parabolic blends) The neat thing is.. If you do a G64P.003 the naive cam detector converts the short arcs to line segments and you get... http://imagebin.org/282156 21 seconds that peaks at almost 400ipm sam On 12/12/2013 2:49 PM, Robert Ellenberg wrote: I agree with Sam that we're ready for testing from other users. However, there are a few features that we may want to add before a merged into a main build. One limitation now is that there are a bunch of configuration variables that are hard coded: - Optimization depth (currently set to ~40 segments) - Enable / disable arc blend flag - Max feed override (for sizing blend arcs, assumed to be 200%) Given these extra settings, I'm curious what the best way is get them from an INI file to the trajectory planner. For the experts, how are INI settings propagated into motion currently? Is there an easy way to tack on a few more config options? Thanks, Rob -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
I have been testing off and on.. everything that I have thrown at it program wise has worked - run to finish. Only slight violations (like 30.0something for acc) It is quite impressive. Running the internet.ngc strait G64 (no naive cam detector combining segments - so it has to touch every segment). The new TP runs 2.5 hours - the old was over 4 hours before I had to leave - I I think it probably had at least an hour to go. The steve.ngc runs better with the latest push from the 10th - it only seems to fall back to parabolic blends in 2 spots iirc. And as of late - spiral runs very fast. (I should try arcspiral.) If I get some time - I will try some threading on real hardware. I think more people need to start testing this. As always - great work! sam On 12/10/2013 05:33 PM, Robert Ellenberg wrote: On Dec 10, 2013 6:25 PM, sam sokolik sa...@empirescreen.com wrote: cool - the only thing is that the internet.ngc I don't think has any arcs... The algorithm detects close-to-tangent line segments too. I'll run that program with a tight tolerance and a loose one to see if it's the cause of the small violations. http://imagebin.org/281714 (it didn't go over by much) sam On 12/10/2013 04:52 PM, Robert Ellenberg wrote: That's certainly promising! I have a fix in progress for the discriminant error you saw. The small blips in acceleration at likely due to not-quite-tangent segments, since I increased the tolerance allowed. One fix could be to reduce the acceleration that tp uses. This might give a margin to allow for small acceleration blips due to the almost-tangent segments. This is kind of an ugly answer, but it might work. Rob -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
Cool - but how long does that take - I am not seeing a commit nor does it build yet.. https://github.com/robEllenberg/linuxcnc-mirror/compare/circular-blend-arc-alpha Thanks! sam On 12/10/2013 8:13 AM, Robert Ellenberg wrote: Sorry about that, I just pushed a fix. I had the debug flags enabled and didn't check if it compiled with them off. On Tue, Dec 10, 2013 at 7:35 AM, sa...@empirescreen.com wrote: When I make - I get this error http://pastebin.com/RqJr0G1F /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c: In function ‘tpRunCycle’: /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:2628: error: ‘pos_before’ undeclared (first use in this function) /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:2628: error: (Each undeclared identifier is reported only once /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:2628: error: for each function it appears in.) make[2]: *** [/home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.o] Error 1 make[1]: *** [_module_/home/samco/linuxcnc-beta8real/src] Error 2 make: *** [modules] Error 2 make: Leaving directory `/home/samco/linuxcnc-beta8real/src' samco@samco-desktop:~/linuxcnc-beta8real/src$ On Tue, 10 Dec 2013 02:47:44 -0500 Robert Ellenberg rwe...@gmail.com wrote: Ok, I think I've isolated the issue to tpCheckEndCondition. The latest commit ran through all of the stellabee program without a significant acceleration overage on my atom box. However, I am noticing a graphical glitch in axis that shows the tool moving off to infinity, but the actual machine position as reported by the status window is correct. Could you do a run through on your P4 machine with the latest version? I'd like to know if it makes it all the way through, and if you get the same graphical issue I'm seeing. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Initial tests of circular arc blending
ah - now I see it. trying now thanks again! sam On 12/10/2013 8:30 AM, sam sokolik wrote: Cool - but how long does that take - I am not seeing a commit nor does it build yet.. https://github.com/robEllenberg/linuxcnc-mirror/compare/circular-blend-arc-alpha Thanks! sam On 12/10/2013 8:13 AM, Robert Ellenberg wrote: Sorry about that, I just pushed a fix. I had the debug flags enabled and didn't check if it compiled with them off. On Tue, Dec 10, 2013 at 7:35 AM, sa...@empirescreen.com wrote: When I make - I get this error http://pastebin.com/RqJr0G1F /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c: In function ‘tpRunCycle’: /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:2628: error: ‘pos_before’ undeclared (first use in this function) /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:2628: error: (Each undeclared identifier is reported only once /home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.c:2628: error: for each function it appears in.) make[2]: *** [/home/samco/linuxcnc-beta8real/src/emc/kinematics/tp.o] Error 1 make[1]: *** [_module_/home/samco/linuxcnc-beta8real/src] Error 2 make: *** [modules] Error 2 make: Leaving directory `/home/samco/linuxcnc-beta8real/src' samco@samco-desktop:~/linuxcnc-beta8real/src$ On Tue, 10 Dec 2013 02:47:44 -0500 Robert Ellenberg rwe...@gmail.com wrote: Ok, I think I've isolated the issue to tpCheckEndCondition. The latest commit ran through all of the stellabee program without a significant acceleration overage on my atom box. However, I am noticing a graphical glitch in axis that shows the tool moving off to infinity, but the actual machine position as reported by the status window is correct. Could you do a run through on your P4 machine with the latest version? I'd like to know if it makes it all the way through, and if you get the same graphical issue I'm seeing. -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- 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-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
