Do you see this same effect on a config with trivial kinematics? If so, it
would point to something within motion (likely the TP).
Rob
On Mon, Oct 19, 2015, 8:46 AM Jullian wrote:
> May be reise is right.
>
> On Mon, Oct 19, 2015 at 8:40 PM, Jullian wrote:
>
> > I'm wrong??
> >
> > On Sun, Oct
May be reise is right.
On Mon, Oct 19, 2015 at 8:40 PM, Jullian wrote:
> I'm wrong??
>
> On Sun, Oct 18, 2015 at 2:59 PM, reise tiet wrote:
>
>> Thanks,Seb,
>>
>> But, i don't think it's the fault of the genserkins kinematics, but the
>> TP's fault.
>>
>> Because in control.c, in the case EMCMO
I'm wrong??
On Sun, Oct 18, 2015 at 2:59 PM, reise tiet wrote:
> Thanks,Seb,
>
> But, i don't think it's the fault of the genserkins kinematics, but the
> TP's fault.
>
> Because in control.c, in the case EMCMOT_MOTION_COORD, after the
> tpRunCycle() , the tpGetPos() gets a different
> "&emcmotS
On Oct 19 2015 3:57 AM, andy pugh wrote:
> On 19 October 2015 at 05:19, EBo wrote:
>> So, what is standard configuration for the machine? Tool or Part
>> movement?
>
> ...
>
> My little knee-mill is an interesting sample case. It is a
> fixed-spindle machine so in vertical milling mode X+ moves t
On 19 October 2015 at 05:19, EBo wrote:
> So, what is standard configuration for the machine? Tool or Part
> movement?
It depends on whether the machine moves the tool or the part, or both.
Z will always be along the tool spindle, and increasing Z increases
the distance between the tool and the
