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
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 120ip
On Monday 17 March 2014 14:34:34 Robert Ellenberg did opine:
> > 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 s
>
> 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
On Monday 17 March 2014 12:30:14 John Kasunich did opine:
> On Mon, Mar 17, 2014, at 03:48 AM, Gene Heskett wrote:
> > This seems like a potential problem for those of us with toy powered
> > spindles. I often set a straight line cut, not to the tool limit, but
> > to the spindle power limit, and
On Mon, Mar 17, 2014, at 03:48 AM, Gene Heskett wrote:
> This seems like a potential problem for those of us with toy powered
> spindles. I often set a straight line cut, not to the tool limit, but to
> the spindle power limit, and that diagonal over speed move could lead to a
> spindle stall
On Monday 17 March 2014 03:31:58 Robert Ellenberg did opine:
> It looks to be from the different maximum velocities of lines and arc
> segments. The circular arc segments are limited to the minimum of the
> two axes in the current plane. The short line segments in between arcs
> are limited by th
It looks to be from the different maximum velocities of lines and arc
segments. The circular arc segments are limited to the minimum of the two
axes in the current plane. The short line segments in between arcs are
limited by the maximum velocity along the direction of the line. If the
line is som
Out of curiosity, can you explain the 5 small mesa's that appear to be
running slightly faster than the programmed velocity? Other than that,
the jaggy at the very end is the only thing that looks like it might be
a little off.
EBo --
On Mar 16 2014 8:10 PM, sam sokolik wrote:
> Should hav
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_
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
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 ma
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 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 shoul
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, wrote:
> I think there is still an issue on how it picks cal
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 who
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
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
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
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" wrote:
>
>> Just a
Ok, it turned out to be a stupid mistake, and the latest commit fixes it.
On Mar 9, 2014 3:52 AM, "Robert Ellenberg" 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
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, wrot
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 wrote:
> ran the experimental3 branch on real hardware tonight. The LHchips4
> sounded real good. Now it peaks across the belly at close to
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
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 exper
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 s
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 s
On Thu, Mar 6, 2014 at 10:44 PM, sam sokolik 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
2014-03-06 5:08 GMT+02:00 Robert Ellenberg :
> 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
>
Thank you, Robert!
I installed it today on
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
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 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 co
>>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
<<
I thought I saw a similar interaction with the standard planner.
We were setting up a system and the X axis was much faster than the Y axis
On Wed, Mar 5, 2014 at 9:42 PM, sam sokolik 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
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,
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 motio
Robert, are you on IRC? If so, what's your nickname?
There was a failure in a sim build that looks like an actual bug, rather
than yet another problem with the buildbot. Check this out:
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/1847/steps/runtests/logs/stdio
On 3/3/14 16:18 , Sebastian Kuzminsky wrote:
> On 3/3/14 16:12 , Robert Ellenberg wrote:
>>
>> 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 pu
On 3/3/14 16:12 , 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
Sweet!
> It's identical to my github branch that Sam and others have bee
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 bran
38 matches
Mail list logo
