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 -
Cool! But things are a little confusing. Is this 2.6_rc3, 2.5.4_rc3,
or 2.6.0-UBC3_rc3? I cannot keep them strait any more...
EBo --
On Apr 17 2014 10:56 PM, Robert Ellenberg wrote:
Hi Sam,
I think I fixes the remaining errors now. tort.ngc doesn't violate
the
velocity constraints on
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
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 =
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
Very important as you seem to be the only one with the proper know how
to make real sense of the test. I just look at the pictures and go aah!!
On 2014-04-02 11:57, sam sokolik wrote:
Just to clarify.. This is all rob.
I only try to test the crap out of it. :)
sam
On 04/01/2014 11:48
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?
On 2014-03-21 20:55, John Thornton wrote:
I have a friend that is very interested in the new trajectory planner
with an X, Z, A machine. Is
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
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
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
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?
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
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
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
On 28 March 2014 11:40, sam sokolik sa...@empirescreen.com wrote:
adaptive-feed seems to work as expected.. This is setting it from 1 to .5
Great, I just wanted to be sure it had been tested :-)
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
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
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
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
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
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
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:
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
Thanks everyone for the kind words! Grad school has been a long but
rewarding road. My topic is stability estimation for humanoid robots. It's
a bit less exciting than it sounds, in that 90% of the work is mucking
around in a robot simulator. Still, it's been a lot of fun to work on, and
if the
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 -
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.
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,
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 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
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
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
Rob,
Best of luck on finishing up and your defence!
EBo --
On Mar 21 2014 1: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
Rob,
Thanks for the update, if there is anything I can do let me know. This
would be a big boost to people who run production machines like the one
my friend has.
JT
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
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
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
What U. will you be graduating from, what is the topic of you thesis,
and will the defence be open to the public? Maybe we can do something
to recognize your contribution to the community...
EBo --
On Mar 21 2014 7:50 PM, sam sokolik wrote:
I hope you can get credit somehow for the work
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.
Thank you very much for all your work
Best
57 matches
Mail list logo
