2015-03-09 2:59 GMT+02:00 Robert Ellenberg <[email protected] <https://mail.google.com/mail/u/0/?view=cm&fs=1&tf=1&[email protected]>>:
> > Sorry, I meant in this list of times: > > > KMotionCNC - 2:59 > > NCStudio v5.5.60 - 3:12 > > EdingCNC - 3:47 > > Mach3 - 5:25 > > PlanetCNC - 11:24 > > Which test program was this for? > I understood you, Rob. This is I was unclear. They don't say which program. Probably the best result of two. And some software just breaks arcs to lines anyways. As for "4 units", I think that refers to either machine or trajectory > units, so maybe 4mm or 4 in? > > http://www.machsupport.com/wp-content/uploads/2013/02/Mach3_CVSettings_v2.pdf I just wonder what kind of "units" is it? It defaults to 180: 180mm, 180in? That's ridiculous. That is why I can't say which actual tolerance Mach3 has. And they can't explain it either. The "winner" is KMotionCNC. Hard to say how exactly they tested... but it breaks arcs to lines by default. Seems to have more intelligent settings http://www.dynomotion.com/Help/KMotionCNC/TrajectoryPlanner.htm But judging by their own graphs it violates acceleration limits repeatedly and severely. I tried to set the same parameters to LinuxCNC and it showed 3:05. Without any violations! Wow, that surface finish is quite ugly when using those Mach3 settings. It > may be that different settings would do a better job (see this forum post > <http://www.machsupport.com/forum/index.php?topic=4113.0> looking into > tuning Mach3), but I bet LinuxCNC 2.7 would give better finish and maybe > even a shorter run time. I'd love to see a side-by-side with linuxcnc. > > I have no doubts that LinuxCNC now has the best planner! At least for lines (arcs processing is not perfect, e.g. run arcs.ngc and check how it slows down a few times on the large ellipse) Interesting to compare the new TP to industrial CNCs. Say, to Fanuc nano smoothing https://www.youtube.com/watch?v=oEvrCK3p9Hg > > > > > > @Andrew, I'm taking a look at the current velocity display issue, I > think > > > it will be a simple fix. > > > > I just pushed a fix to my github repo that may take care of the currentvel > issue. When the motion queue was empty, some fields of emcmotStatus weren't > being reset to the default values. I think it was difficult to notice on > slower machines, because the velocity would change slowly enough that the > last value before stopping was quite small. > Looks like it. It never shows non-zero when paused, only when stopped completely, exactly with the empty queue. I'll check when it gets to 2.7 Thanks again for the bug report! Thinking back, I think others have had > this issue too, but for some reason I never made the connection as to what > was causing it. > > Anytime. Thanks for the new TP, it's great! Are you planning to extend it to 5axis machining? -- Andrew ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
