I just found an error I overlooked that may be causing those spikes. I'm
seeing similar issues with the straight-line case, which I'm also seeing on
my sherline mill on the straight line example. Hopefully it will be a quick
fix.
-Rob
On Tue, Dec 3, 2013 at 9:08 PM, sam sokolik wrote:
> I will
I will try that tomorrow. One thought - there is no following errror -
so I motion is doing what the tp is telling it to do...
cool.
thanks again - I didn't notice that many arcs in the stellabee - but
that could be... I will look for some more line segment programs that
are long in length.
On Tuesday 03 December 2013 20:58:04 Sebastian Kuzminsky did opine:
> On 12/3/13 10:05 , John Morris wrote:
> > On 12/03/2013 01:16 AM, Sebastian Kuzminsky wrote:
> >>> During the testing, I encountered another problem building the docs
> >>> with -j. I think this one is also present in master.
>
On 12/3/13 16:39 , Frank Tkalcevic wrote:
> In my kinematics module, when I do a real time build, my rtapi_print
> statements are not print correctly. The calls.
>
>
>
> rtapi_print("ikfastkins kinematicsForward\n");
>
> rtapi_print("ikfastkins::kinematicsForward(joints: %f %f %f %f %f %f - ",
> j
In my kinematics module, when I do a real time build, my rtapi_print
statements are not print correctly. The calls.
rtapi_print("ikfastkins kinematicsForward\n");
rtapi_print("ikfastkins::kinematicsForward(joints: %f %f %f %f %f %f - ",
joint[0],joint[1],joint[2],joint[3],joint[4],joint[5]);
On Dec 3, 2013 2:42 PM, "sam sokolik" wrote:
>
> I have not seen the blip.. (but surprisingly I may have found a blip in
> master...)
> Ok - spiral - wow. Running at almost 400ipm at the largest diameter.
> Damn impressive.
>
> I am a bit perplexed though.. If I run stellabee1.ngc (
> http://e
It's definitely good that it's repeatable on one machine. What are the
specs of your pc? I'm doing my development on a relatively fast core2 duo,
but I just got a slower machine to do comparison testing.
--
Sponsored by Int
I ran it one more time and it failed showing the same line number - so
that is good. (I think ;) )
sam
On 12/3/2013 1:54 PM, sam sokolik wrote:
> heh - I had a screenshot
>
> http://imagebin.org/280366
>
> (showing line 32142)
>
>
> On 12/3/2013 1:39 PM, sam sokolik wrote:
>> I have not seen the
heh - I had a screenshot
http://imagebin.org/280366
(showing line 32142)
On 12/3/2013 1:39 PM, sam sokolik wrote:
> I have not seen the blip.. (but surprisingly I may have found a blip in
> master...)
>
> Ok - spiral - wow. Running at almost 400ipm at the largest diameter.
> Damn impressive.
I have not seen the blip.. (but surprisingly I may have found a blip in
master...)
Ok - spiral - wow. Running at almost 400ipm at the largest diameter.
Damn impressive.
I am a bit perplexed though.. If I run stellabee1.ngc (
http://electronicsam.com/images/KandT/testing/stellabee1.ngc ) w
Am 03.12.2013 um 17:38 schrieb Charles Steinkuehler :
> On 10/31/2013 1:22 PM, Michael Haberler wrote:
>>
>> Am 31.10.2013 um 18:57 schrieb Jeff Epler :
>>
>>> In two messages a few months ago, I raised the issue of new source
>>> files without license declarations in master branch and unified
On 12/3/13 10:05 , John Morris wrote:
> On 12/03/2013 01:16 AM, Sebastian Kuzminsky wrote:
>>> During the testing, I encountered another problem building the docs
>>> with -j. I think this one is also present in master.
>>
>> This one i don't know about. I always build the docs (in 2.5 and
>> mas
On 12/03/2013 01:16 AM, Sebastian Kuzminsky wrote:
>> During the testing, I encountered another problem building the docs
>> with -j. I think this one is also present in master.
>
> This one i don't know about. I always build the docs (in 2.5 and
> master) with -j20 on my dev machine, never had
On 10/31/2013 1:22 PM, Michael Haberler wrote:
>
> Am 31.10.2013 um 18:57 schrieb Jeff Epler :
>
>> In two messages a few months ago, I raised the issue of new source
>> files without license declarations in master branch and unified
>> build branch, and non-Free files in the UB branch.
>>
>> I
I just pushed another update that seems to fix the occasional acceleration
spikes in your example. There was a case where I wasn't doing the check for
split-cycles, so it would overshoot on very short segments. I also
temporarily reverted some changes to parabolic blending (back to default
behavior
On 11/4/2013 10:01 AM, EBo wrote:
> On Nov 4 2013 8:44 AM, Michael Haberler wrote:
>> Am 04.11.2013 um 16:30 schrieb EBo :
>>
>>>
>>> What hard real-time ARM kernels have been found suitable for
>>> LinuxCNC?
>>
>> The only one I found both to have some build support for raspberry
>> and beaglebon
16 matches
Mail list logo
