On 03/05/2014 10:44 AM, Kenneth Lerman wrote:
> On 3/3/2014 12:41 PM, John Kasunich wrote:
>>
>> I agree 110% with John. "sudo make setuid" shouldn't be considered
>> an obstacle.
> sudo make setcap... is probably more appropriate. These days, we can set
> individual capabilities rather than ha
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 Sun, Mar 2, 2014, at 02:29 PM, Michael Haberler wrote:
>
> I have read up on the data flow in stepgen.c and I found the following for
> normal (i.e. not disabled, and setup disregarded):
>
> make_pulses reads:
> stepgen->accum
> stepgen->target_addval
> stepgen->deltalim
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
On 3/5/14 11:36 , Michael Haberler wrote:
> btw it occurred to me since atomic update and fetch is a given for 64bit on
> x86/amd64 and arm, one could add HAL_S64 and HAL_U64 as a data type for
> pins+signals
>
> not that I see an immediate use case
hal_float_t is double, which is 64 bit wide.
btw it occurred to me since atomic update and fetch is a given for 64bit on
x86/amd64 and arm, one could add HAL_S64 and HAL_U64 as a data type for
pins+signals
not that I see an immediate use case
- Michael
--
Subversi
On 3/4/2014 11:55 AM, Jon Elson wrote:
> On 03/04/2014 06:59 AM, andy pugh wrote:
>> On 4 March 2014 12:52, Stuart Stevenson wrote:
>>
>>> Gentlemen,
>>> It would help me understand and follow some of the current threads if I
>>> knew the definition of atomic as used in this context.
>> It ref
On 3/3/2014 12:41 PM, John Kasunich wrote:
>
> On Mon, Mar 3, 2014, at 12:26 PM, John Morris wrote:
>> If it were possible to set SCHED_FIFO with the fast thread prio 0 (no
>> special privs needed), and other thread prio relatively lower, it might
>> achieve the same effect. This could be implemen
On 3/4/2014 8:42 PM, Jon Elson wrote:
> On 03/04/2014 11:48 AM, Charles Steinkuehler wrote:
>> On 3/4/2014 10:55 AM, Jon Elson wrote:
>>> Another way this can be dealt with is to have double buffers
>>> shared between the two tasks, the "master" task swaps out a
>>> pointer
>>> to the most recent b
12 matches
Mail list logo
