I have played with mach's trajectory planner when rob started working on
the new TP. I actually used linuxcnc to show what mach was doing. I
used the step/dir output from mach -> mesa 7i80 encoder input ->
linuxcnc. Not only was there acceleration constraint violations - its
path following show
On Sun, Mar 8, 2015 at 7:37 PM, Andrew wrote:
> 2015-03-09 1:11 GMT+02:00 Robert Ellenberg :
>
> > Nice catch, Sam! those variables definitely should have been doubles, not
> > ints. I'm not sure whether the comparison numbers Andrew posted were for
> > the lines or arcs example, but it looks lik
On 03/08/2015 12:40 AM, Slavko Kocjancic wrote:
> From my point of view you hit all the troubles.
> -it needs little cleaning (I don't know what's wrong at all)
> -I really don't know how to edit documentation.
I just pushed some code to master that now lets you write manpages using
asciidoc mark
2015-03-09 1:11 GMT+02:00 Robert Ellenberg :
> Nice catch, Sam! those variables definitely should have been doubles, not
> ints. I'm not sure whether the comparison numbers Andrew posted were for
> the lines or arcs example, but it looks like 2.7 is at least competitive.
> 3:04 is second place on
Nice catch, Sam! those variables definitely should have been doubles, not
ints. I'm not sure whether the comparison numbers Andrew posted were for
the lines or arcs example, but it looks like 2.7 is at least competitive.
3:04 is second place on that list!
It surprises me a little that Mach3 isn't
2015-03-09 0:20 GMT+02:00 sam sokolik :
> is this correct?
> x 100mm/s 25mm/s^2
> y 100mm/s 25mm/s^2
> z 100mm/s 250mm/s^2
>
That's correct Sam!
>
> Lines
> enabled 3:04
>
> Yes. And 3:15 for P0.01.
arcs
> enabled 3:27
>
And 3:44 for P0.01. I noticed a few unnecessary slowdowns on arc-to-arc
t
2 screen shots arc/line... G64P.1
http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-03-08%2017:49:49.png
http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-03-08%2017:45:24.png
sam
On 03/08/2015 05:20 PM, sam sokolik wrote:
> is this correct?
> x 100mm/s
On Sun, Mar 08, 2015 at 05:13:35PM -0400, Robert Ellenberg wrote:
> I'll take a look at this tonight.
Hi Robert,
Sam might have saved you the trouble by doing a bisect that pointed
me to a little mistake:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=8dca131abda87da4fc850f5b6c8aa
is this correct?
x 100mm/s 25mm/s^2
y 100mm/s 25mm/s^2
z 100mm/s 250mm/s^2
Lines
enabled 3:04
disabled 4:50
arcs
enabled 3:27
disabled 5:03
there is a fix now in 2.7 - rob when you get a chance - look it over.
sam
On 03/08/2015 02:40 PM, Andrew wrote:
> Hello,
>
> Today I ran into a compar
2015-03-08 22:35 GMT+02:00 Peter C. Wallace :
> I have also noticed something that looks wrong with CAB recently I suspect
> that the ARC_BLEN_ENABLE switch is correct but something is wrong with CAB
> (changed setup defaults maybe?) that makes it slower than the old TP (It
> looks
> to me like it
I'll take a look at this tonight. I've made a few changes to how the
optimization works that may have had some unintended consequences. Blends
behaving like exact stop mode sounds like what would happen if the
optimization was aborted early. With any luck it will be a simple fix,
since I haven't ch
On Sun, 8 Mar 2015, Andrew wrote:
> Date: Sun, 8 Mar 2015 21:40:27 +0200
> From: Andrew
> Reply-To: EMC developers
> To: EMC developers
> Subject: [Emc-developers] New TP bugs?
>
> Hello,
>
> Today I ran into a comparison of hobby CNC software on a russian forum. The
> guy made a test traject
Hello,
Today I ran into a comparison of hobby CNC software on a russian forum. The
guy made a test trajectory and run it on a few CNC's. Here's the results:
KMotionCNC - 2:59
NCStudio v5.5.60 - 3:12
EdingCNC - 3:47
Mach3 - 5:25
PlanetCNC - 11:24
LinuxCNC was not tested.
So I installed a fresh 2.7
> Date: Thu, 5 Mar 2015 21:21:13 -0700
> From: s...@highlab.com
> To: emc-us...@lists.sourceforge.net; emc-developers@lists.sourceforge.net
> Subject: [Emc-developers] Google Summer of Code students wanted!
>
> Some possible projects are listed on the BRL-CAD GSoC project ideas
> wiki, but fee
On Mar 8 2015 9:25 AM, Kirk Wallace wrote:
> On 03/08/2015 06:47 AM, EBo wrote:
>> I agree. The tab-stop debate/issues have caused no end of problems
>> not
>> only in LCNC but in every distributed source code project I have
>> worked
>> on. I would rather there be a no new tab's rule, but that
On 03/08/2015 06:47 AM, EBo wrote:
> I agree. The tab-stop debate/issues have caused no end of problems not
> only in LCNC but in every distributed source code project I have worked
> on. I would rather there be a no new tab's rule, but that would cause a
> lot of issues with the legacy code. Ma
On 08. 03. 2015 14:00, John Thornton wrote:
> Not trying to make any more confusion but I find Geany to be a bit
> confusing about spaces and tabs as you can not see them. While it is
> great for Python programs because you can run them from within Geany.
> Gedit is much less confusing to look at e
I agree. The tab-stop debate/issues have caused no end of problems not
only in LCNC but in every distributed source code project I have worked
on. I would rather there be a no new tab's rule, but that would cause a
lot of issues with the legacy code. Maybe a version 3.x constraint.
EBo --
Not trying to make any more confusion but I find Geany to be a bit
confusing about spaces and tabs as you can not see them. While it is
great for Python programs because you can run them from within Geany.
Gedit is much less confusing to look at especially if you have the Draw
Spaces Plugin. Wi
On 08. 03. 2015 10:03, Dave Caroline wrote:
> It was a quick attempt at showing the changes not needed
> see http://linuxcnc.org/docs/html/code/Style_Guide.html
> the first paragraph about do no harm
>
> Most cannot help with the docs because you understand the changes not us
> so again some indica
Hi
The below from my Qt HAL access libraries demonstrates a way to access
components.
Note that the pointer is passed and from that the name is read, so you
have all you need once you find the right one.
regards
void HAL_Access::getAllComponentNames(QStringList& list)
{
int next;
hal_comp_t *
It was a quick attempt at showing the changes not needed
see http://linuxcnc.org/docs/html/code/Style_Guide.html
the first paragraph about do no harm
Most cannot help with the docs because you understand the changes not us
so again some indication what the changes do and what others need to
know,
On 08. 03. 2015 09:38, Dave Caroline wrote:
> With a diff program or better a merge program like meld one can easily
> see the white space changes that are extra to the real code changes
> and can confuse or waste time of a reviewer. Whitespace changes are
> often made by badly set editorr or a fee
With a diff program or better a merge program like meld one can easily
see the white space changes that are extra to the real code changes
and can confuse or waste time of a reviewer. Whitespace changes are
often made by badly set editorr or a feeling that formatting may not
be as you wish.
I down
Hi Sebastian,
Thanks for the prompt reply.
I am from India and currently enrolled with National Institute of
Electronics & Information Technology (NIELIT), an Autonomous Scientific
Society under the administrative control of Ministry of Communications and
Information Technology, Government of Ind
25 matches
Mail list logo
