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
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.
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
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 -
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
--
-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
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
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
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
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
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
= 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
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
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
/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
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
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
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
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
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
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
[#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
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
, 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
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
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
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
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
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
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
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
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
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
:
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
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
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
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 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
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
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
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
/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
, 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
/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
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
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 =
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
: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
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
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
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
.
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
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
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
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
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]: ***
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
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
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:
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
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
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
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
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,
.
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_
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
, 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
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
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
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
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
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
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
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
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
/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
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
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 -
/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
(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
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.
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:
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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 - 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
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
101 - 200 of 313 matches
Mail list logo
