n't normally "top post" as you did above, but usually reply by mixing
our replies into the "conversation". As I'm doing here.
> - Original Message -
> From: Gene Heskett
> Sent: 11/10/13 02:58 PM
> To: emc-users@lists.sourceforge.net
> Sub
-users] (no subject)Rotary problems
On Sunday 10 November 2013 09:38:22 andy pugh did opine: > As I appear to have
been ignored... > > The problem probably is linked to the limited lookahead,
but if you > only notice it when the rotary is involved, then it may be that
the > rotary
On Sunday 10 November 2013 09:38:22 andy pugh did opine:
> As I appear to have been ignored...
>
> The problem probably is linked to the limited lookahead, but if you
> only notice it when the rotary is involved, then it may be that the
> rotary acceleration is much too low.
> It is acceleration
As I appear to have been ignored...
The problem probably is linked to the limited lookahead, but if you
only notice it when the rotary is involved, then it may be that the
rotary acceleration is much too low.
It is acceleration that limits how fast a particular segment is
allowed to run, and the l
Aaron,
Marius L. is right about current LinuxCNC behaviour, but I would not say so
about "any CNC machine" when you can let some amount of error in your
toolpath, what G64P..Q.. (BTW, I suggest using Q parameter too) should do,
but it does not do much in LinuxCNC and your case actually yet. Th
Aaron
G64 will have some effect but I cannot say how much. The amount of
moves are really determined by you cam software. Some people do an
aggressive roughing cycle to use as little time as possible and then
they can afford the time spent on the finishing cut.
What you can try is to make your
Marius
Thanks for your replymakes sense. Does G64 p# work on rotary files/systems?
It didn't seem to when I ran it.
Do you have any tips for reducing the numer of moves in a job?
Sorry. I forgot to put a subject up top,
Aaron
- Original Message -
From: Marius Liebenberg
Sent: 11/09/13
