You can not just shift the extents by +2" on a non-cartesian machine - you
have to recheck every point. We tend to forget how complex the general
case can be when we're used to running cartesian mills/routers.
Stephen
On Mon, Jun 27, 2016 at 1:18 PM, andy pugh wrote:
> On 27 June 2016 at 17:16
On 27 June 2016 at 17:16, wrote:
> Yeah I don't expect any immediate solution, but this is a significant problem
> which doesn't need to be. If you've done an X-offset by +2", then the limits
> check and live preview just needs to offset by +2". They don't need to
> recalculate every line of
Yeah I don't expect any immediate solution, but this is a significant problem
which doesn't need to be. If you've done an X-offset by +2", then the limits
check and live preview just needs to offset by +2". They don't need to
recalculate every line of g-code.
Unless, of course, you use a G10
54:11 AM
Subject: Re: [Emc-users] Major lags when zeroing axes
On 27 June 2016 at 09:16, Danny Miller wrote:
> When I go to zero the work coordinates, EACH axis results in
> recalculating the entire file, which can take minutes.
The delay is actually probably the toolpath preview (and limits c
On 27 June 2016 at 09:16, Danny Miller wrote:
> When I go to zero the work coordinates, EACH axis results in
> recalculating the entire file, which can take minutes.
The delay is actually probably the toolpath preview (and limits check)
updating. The motion system doesn't need to read the whole f
I work a lot with 3D carving. The files are often quite huge.
When I go to zero the work coordinates, EACH axis results in
recalculating the entire file, which can take minutes. Really it
shouldn't require any recalculation (Mach3 doesn't) since it's just
offsetting the coordinates, but I can