This is master running on debian wheezy and rt_preemt. It has been up
for 9 days so far. It is running the splash screen in an infinite loop.
The stepgens in the 7i80 are in velocity mode and running with pid.
http://electronicsam.com/images/KandT/testing/weekplus.png
sam
On 7/26/2014 11:18
Can you explain the steps that brought you to needing those 2 files?
(I have been running the new livecd for the past couple weeks with both
the 7i80, 5i20 and rtai/rt-preempt with no issues.)
sam
On 8/5/2014 8:17 AM, David Armstrong wrote:
> Then why did i have to install the 2 files reference
If anyone is interested...
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/145043
http://www.machsupport.com/forum/index.php/topic,27747.0.html
http://www.machsupport.com/software/mach4/
sam
--
Sorry - this was supposed to be on the users list.
sam
On 8/1/2014 10:22 AM, sam sokolik wrote:
> If anyone is interested...
>
> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/145043
>
> http://www.machsupport.com/forum/index.php/topic,27747.
I will take a stab...
The short answer is linuxcnc Ethernet motion is no different than any of
the other interface card solution..
The longer (as I understand it) answer is...
Remember that linuxcnc doesn't use motion devices like smoothstepper or
galil. (these are buffering devices that move
I have been testing the Ethernet branch. (mesa 7i80) no issues what
so ever.
Some of the hardware I have been testing is the
GIGABYTE GA-J1800N-D2H rt-preempt latency 36us
http://electronicsam.com/images/KandT/testing/j1800.png
GIGABYTE GA-J1900N-D3V rt-preempt latency 66us
http://electroni
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 A
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 w
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 ex
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 - thi
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
>
--
I just pushed a small fix to the circular-blend-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 wrote:
>
>> Great!
>>
>> Running the current TP on the K&T with it
ure that if
> we're doing synced motion, to ignore 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 wrote:
>
>> Here is a cell phone picture of the new TP cutting jmk's
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 t
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 K&T this weekend.. It is quite imp
I am seeing the same path here on circular arc blending... it isn't like a
tolerance thing (normally it would cut the corner short.) Seems like a bug
bruno wrote:
>I tried reducing the G64 values, I also set G61.
>I also tried running it at very slow feed rate. I increased the maximum
>veloc
could you pastebin the program? running through the list really hacked
up the gcode...
sam
On 05/30/2014 10:29 AM, bruno wrote:
> ;;
> ;
> # = 5
>
> ( some init )
> G21 (Unit in mm)
> G90 (Absolute distance mode)
> G64 P0.01 (Exact Path 0.001 tol.)
> G17
> G40 (Cancel diamete
Look - actual hardware...
http://youtu.be/HPzow8L1dxw
I think it would run a bit faster... But I my be a bit chicken...
the same-ish section running with the current TP (peaks at about 70ipm
vs the machine limit of 200ipm)
http://youtu.be/djlUG3ZF_tE
sam
On 05/29/2014 01:35 PM, Chris Radek w
= 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
> A
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 n
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
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 wrot
/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&#x
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 fig
ting the axis length. Now we should
> be able to set an arbitrary XY rotation, and still satisfy velocity limits.
> I ran through 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 1
the lone 'K[#*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 20
[#*-13.189] J[#*0.0]
K[#*5.0]
G0Z[#*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
>
> (z velocity is peaking at 74ipm - set for 60ipm)
> On 04/14/201
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 confi
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:
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
> the RT hangups that Mark was seeing. I'll push a fix today as soon as I'm
> sure.
60ipm 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 eq
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 wrote:
>
>> Ok - I found another
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 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 mode, I'll hav
ixed (I moved the vLimit check to always be called in the function that
> calculates target velocity).
>
> On Fri, Mar 28, 2014 at 7:27 AM, sam sokolik wrote:
>
>> inital testing now the feed override acts as expected. (This is going
>> from 100% to 90%)
>>
>>
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 bu
s 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 with Sam Sokolik and Robert Ellenberg a
ing 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 th
aused 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
> calculates target velocity).
>
> On Fri, Mar 28, 2014 at 7:27 AM, sam sokolik wr
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 wrote:
>> I did a quick test - Doesn't run full speed now. There are some spikes
>> (if
city was
> calculated though, so let me know if you see any unexpected changes.
>
>
>
>
> On Thu, Mar 27, 2014 at 10:57 PM, sam sokolik 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 -
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 should fix that.
>
>
> On Thu, Mar 27, 2014 at 9:59 PM, sam sokolik wrote:
>
>> here
the RC3 branch should fix that.
>
>
> On Thu, Mar 27, 2014 at 9:59 PM, sam sokolik 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=4Mz7tzVSsYk&fea
take off and goes at a much higher feedrate..
>
> sam
>
>
> On Wed, 26 Mar 2014 15:03:50 -0500
> sam sokolik wrote:
>> here is 50% (1750mm/min)
>>
>> http://imagebin.org/301967
>>
>> sam
>>
>>
>> On 03/26/2014 02:49 PM, Rober
* 0.1 in) ~= 1.73 in/sec (about 7%
>>> difference).
>>>
>>> I just hard-coded this because it seemed to give me the best speed on my
>>> test runs. Maybe it could be an INI parameter? You could potentially get
>> a
>>> little performance from a program
am with lots of circular arcs by reducing
> the tangential acceleration in favor of normal acceleration. Conversely,
> making tangential and normal acceleration both sqrt(2) * a_max might move
> more quickly in programs with a lot of detail like stellabee1.ngc.
>
> -Rob
>
> On Mon,
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 3
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 l
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 cann
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
140ipm)
>>>>
>>>> The current TP actually does 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://imagebi
org/299492
>>>>
>>>> Even if I have no z moves in the profile - it still runs mostly at
>> 50ipm
>>>> If I set the z axis so it is the same velocity - then it works as
>>>> expected. (runs the profile at 140ipm)
>>>>
>>>> The
;
> http://buildbot.linuxcnc.org/dists/lucid/scratch-rt/
>
>
> On Tue, Mar 11, 2014 at 10:50 PM, sam sokolik wrote:
>
>> 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 ;)
inuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=120#44419
> http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=130#44474
>
>
>
> On Wed
ed when I find the issue.
>>
>>
>> On Sat, Mar 8, 2014 at 10:15 PM, 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
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
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 wrote:
>
t; 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
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
finally got around to making a 4 axis constraints config. So far so
good! (If I understand it - >3 axis falls back to parabolic blends..)
http://imagebin.org/296431
sam
On 02/20/2014 10:09 PM, Robert Ellenberg wrote:
> It's based on the master branch from a few months ago. I'm working on
> bac
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/201
onto v2.5_branch so that it can be
> merged 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, s
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
too, recently. That means I used fmin somewhere 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" wrote:
>>
>>> I just tried to do a realtime build.. I
e 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" wrote:
>>
>>> I just tried to do a realtime build.. I get these errors
>>>
>>> 1.
&
Tue, Feb 18, 2014 at 2:13 PM, Robert Ellenberg wrote:
>
>> I got that too, recently. That means I used fmin somewhere 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"
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]: *** [/home/samco/l
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 t
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:
>
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
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
http://electronicsam.com/images/KandT/testing/master1L
Wow!!
great work!
I can't wait to test it.
On a related note. Ran one of the emco laths (gasp! Actual hardware!). No
issues - threaded and every thing. (Have a video)
Sam
Robert Ellenberg wrote:
>Hi All,
>
>I've been working on adding support for line-arc and arc-arc intersections
>to the
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 ques
ad
out is using 1/2 (maybe)
thanks
sam
On 2/13/2014 8:43 AM, Robert Ellenberg wrote:
> I can add an INI setting fairly easily, and default to not allowing blends
> between rapids and feed moves.
> On Feb 13, 2014 9:20 AM, "sam sokolik" wrote:
>
>> How hard would that
How hard would that be to make an INI setting? I can't think of an
application (maybe something that is positioning...) that might want
blended moves between rapid and feed moves..
sam
On 2/6/2014 7:25 AM, Robert Ellenberg wrote:
> On Thu, Feb 6, 2014 at 8:13 AM, EBo wrote:
>
>> On Feb 6 2014
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 d
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, Robert
.
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_traject
the
> requested velocity, or if the velocity "bump" is less than some amount.
>
>
> On Tue, Jan 7, 2014 at 11:45 AM, sam sokolik wrote:
>
>> I have a question about
>>
>> Controls how aggressive velocity smoothing is. It's a bit counterintuitive,
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
boxusercontent.com/u/10948059/linuxcnc-trajectory-tests/tight%20corner%20arc%20blend.png
>
> Here's the same motion with arc blends now:
>
> https://dl.dropboxusercontent.com/u/10948059/linuxcnc-trajectory-tests/tight%20corner%20arc%20blend.png
>
> -Rob
>
>
> On Sun
to be safe. If anyone
>>> has pulled from that branch in the last three days, please reset to the
>>> current circular-blend-arc-alpha branch, which should point to this
>> commit:
>>> 689e5cb185f87deba62391cd184f21f360ce2246
>>>
>>> I'll push an
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
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.
nce it's a lot of work for a relatively small gain, but I'm
> hoping to add these features in the future.
>
> -Rob
>
>
> On Mon, Dec 30, 2013 at 7:37 AM, sam sokolik wrote:
>
>> I just ran your program in my config. It does seem to slow down more in
>>
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 the
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
st config to see if it works 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" wrote:
>> Did you get a chance to see if the ini settings are working for
n 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" wrote:
>> Did you get a chance to see if the ini settings are working for you? I
>> have not tested it
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
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 the
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 -
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.
> -
(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
> exp
/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" wrote:
>
>>
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
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:
>
> T
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 ble
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-blen
101 - 200 of 365 matches
Mail list logo
