2009/11/4 Jon Elson el...@pico-systems.com:
axis will just come to a stop and remain in sync. You can manually turn the
spindle over to see that Z is still slaved to the spindle. You can then use
caliper points to try to estimate the the offset needed, or just align
the tool in
the thread
It does take longer on a lathe without a compound. You must watch the
motion, make adjustments and watch again until you have the tool tip aligned
with the threads. The more material you need to take off the part the less
accurate your position must be to restart the cutting of the part.
Stuart
Andy Pugh wrote:
2009/11/4 Jon Elson el...@pico-systems.com:
axis will just come to a stop and remain in sync. You can manually turn the
spindle over to see that Z is still slaved to the spindle. You can then use
caliper points to try to estimate the the offset needed, or just align
Gentlemen,
I have cut multistart threads and adjusted the machine to recut threads by
adjusting the start point Z coordinate. I would think it would work very
similar in EMC2.
Stuart
On Tue, Nov 3, 2009 at 2:40 PM, Andy Pugh a...@andypugh.fsnet.co.uk wrote:
2009/11/3 Chris Radek
2009/11/3 Chris Radek ch...@timeguy.com:
If you try a git master build and find that it works for you, that
would be helpful and would be another push for us to put it in the
next 2.3 release.
Machines++
I just tried the 4mm pitch M39 thread that I rather suspect kicked off
this whole thing,
On Mon, 2 Nov 2009 21:48:49 -0600, you wrote:
On Mon, Nov 02, 2009 at 11:34:25PM +, Steve Blackmore wrote:
On Wed, 28 Oct 2009 17:06:48 +0100, you wrote:
Am 27.10.2009 um 23:35 schrieb Michael Haberler:
I tried with a build from latest master, and a second build from just
before
Andy Pugh wrote:
It does pose one question, though. With a leadscrew you can pick up
an existing thread by engaging the nut, stopping the spindle and and
using the compound slide to align the tool with the thread.
Is there an equivalent with EMC2? I am thinking you could perhaps stop
the
On Mon, Nov 02, 2009 at 11:34:25PM +, Steve Blackmore wrote:
On Wed, 28 Oct 2009 17:06:48 +0100, you wrote:
Am 27.10.2009 um 23:35 schrieb Michael Haberler:
I tried with a build from latest master, and a second build from just
before Chris' fix
Am 27.10.2009 um 23:35 schrieb Michael Haberler:
I tried with a build from latest master, and a second build from just
before Chris' fix
http://git.linuxcnc.org/gitweb?p=emc2.git;a=commit;h=be0dad0cd18f980aacdc6e2e0b7884304a5fb9f7
.
It seems that particular fix really got rid of the
Since I'm a bit at wit's end - if anybody wants to give it a stab:
Here is a hardware-free emc2 config which shows the oscillation. It
needs hal, so I guess it wont work on emc-sim, but it doesnt touch any
hardware (simulated encoder, and stepgen outputs etc not connected).
(EMC)emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] threading Z oscillation depends on encoder PPR
Am 23.10.2009 um 20:07 schrieb Peter C. Wallace:
I did search for such a knob,
http://www.linuxcnc.org/docs/devel/html/drivers_hostmot2.html
remains silent on the case
On Tue, Oct 27, 2009 at 08:41:06PM +0100, Michael Haberler wrote:
http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove-without-hardware.tar.gz?root=CVSview=tar
Thanks for sending this config.
Running this config on git master (14b8248a) gives me
On Tue, Oct 27, 2009 at 02:54:53PM -0500, Mark Cason wrote:
OK, here come stupid question of the day...
Why does it matter if the encoder tells the computer which direction
the spindle is turning?? Or is this just a side effect of quadrature.
For lathe threading you don't need to
On 10/27/2009 03:27 PM, Chris Radek wrote:
On Tue, Oct 27, 2009 at 02:54:53PM -0500, Mark Cason wrote:
OK, here come stupid question of the day...
Why does it matter if the encoder tells the computer which direction
the spindle is turning?? Or is this just a side effect of
Mark Cason wrote:
On 10/27/2009 03:27 PM, Chris Radek wrote:
On Tue, Oct 27, 2009 at 02:54:53PM -0500, Mark Cason wrote:
OK, here come stupid question of the day...
Why does it matter if the encoder tells the computer which direction
the spindle is turning?? Or is this just
2009/10/27 Mark Cason farmerboy1...@yahoo.com:
For lathe threading you don't need to know it. For tapping you
do.
That part I understand, but, if a spindle is under computer control,
then the computer should already know which direction the spindle is
turning, right?
It knows that it
I've pulled a fresh copy of master and now get the same (clean) plot
like you in the test setup I sent - superb!
There's a chance I created a snafu as I blunder down the git learning
curve.. I'll see wether I can isolate what will cause the change from
bad to good in my old setup, or it's
AH, now I understand. Thanks guys!
-
Ne M'oubliez ---Family Motto
Hope for the best, plan for the worst ---Personal Motto
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
()_() signature to help him gain world domination.
@lists.sourceforge.net
Subject: Re: [Emc-users] threading Z oscillation depends on encoder
PPR
On Fri, Oct 23, 2009 at 11:33:15AM -0700, Peter C. Wallace wrote:
Its still is a quadrature decoder but it only counts on one edge
(rising edge
of A in this case, state of B on rising edge
Oh yes. The work piece blanks start out at about 550 lbs.
There is a gantry and chainfall over the lathe to handle the parts.
Everything is way to heavy to handle without assistance.
The largest lathe I have seen first hand is in Evansville, IN at a motor
rewind shop. This 3 foot swing lathe
On Saturday 24 October 2009, Dave wrote:
Oh yes. The work piece blanks start out at about 550 lbs.
There is a gantry and chainfall over the lathe to handle the parts.
Everything is way to heavy to handle without assistance.
The largest lathe I have seen first hand is in Evansville, IN at a
2009/10/23 Jon Elson el...@pico-systems.com:
Which is an interesting point. It seems that a hardware quadrature
counter is likely to be counterproductive if you have a low-count
encoder.
I'm not sure it is COUNTER-productive, but if the spindle encoder
resolution times
the maximum spindle
Andy Pugh wrote:
Perhaps I should have elaborated further. What I was saying is that if
the hardware encoder and driver does not offer an interpolated
position every servo cycle and the encoder pulse rate is low enough to
have multiple servo threads per encoder count, then EMC will see a
Yet another situation where more is less.. ;-)
In a more perfect world I guess it might be best if everyone was running
1024 ppr encoders on their spindles and threading at 1000+ rpm and using
a hardware interface.
Ironically if you want to thread on a really large lathe and need to run
at
I concur that having position-interpolated in the hardware drivers
would be most valuable (hm2 for me, but missing as well)
since Xmas is forthcoming.. could we have x1-mode as well in the
hardware drivers?
I am aware of the consequences wrt resolution BUT: x4-mode only works
well if the
Michael Haberler wrote:
I concur that having position-interpolated in the hardware drivers
would be most valuable (hm2 for me, but missing as well)
It *would* be a good feature to have. I'll put this on The List. ;-)
--
Sebastian Kuzminsky
the sky calls to us -- carl sagan
: [Emc-users] threading Z oscillation depends on encoder PPR
I concur that having position-interpolated in the hardware drivers
would be most valuable (hm2 for me, but missing as well)
since Xmas is forthcoming.. could we have x1-mode as well in the
hardware drivers?
I am aware
On Friday 23 October 2009, Dave wrote:
Yet another situation where more is less.. ;-)
In a more perfect world I guess it might be best if everyone was running
1024 ppr encoders on their spindles and threading at 1000+ rpm and using
a hardware interface.
Ironically if you want to thread on a
Am 23.10.2009 um 19:06 schrieb Peter C. Wallace:
HostMot2 supports X1 mode, and with velocity estimation, postition
...
I am delighted!
I did search for such a knob,
http://www.linuxcnc.org/docs/devel/html/drivers_hostmot2.html
remains silent on the case
so I took Sebastian's note from
: [Emc-users] threading Z oscillation depends on encoder PPR
Am 23.10.2009 um 19:06 schrieb Peter C. Wallace:
HostMot2 supports X1 mode, and with velocity estimation, postition
...
I am delighted!
I did search for such a knob,
http://www.linuxcnc.org/docs/devel/html/drivers_hostmot2.html
16 feet maybe... No, just over 3 feet. I think it may have been
originally setup to machine titanium alloys.
Dave
Gene Heskett wrote:
On Friday 23 October 2009, Dave wrote:
Yet another situation where more is less.. ;-)
In a more perfect world I guess it might be best if
: [Emc-users] threading Z oscillation depends on encoder PPR
Am 23.10.2009 um 20:07 schrieb Peter C. Wallace:
I did search for such a knob,
http://www.linuxcnc.org/docs/devel/html/drivers_hostmot2.html
remains silent on the case
Set counter_mode true for x1 mode...
I assumed a q-decoder
Michael Haberler wrote:
How do I go about putting a hm2 encoder in x1-mode ?
The hm2 driver does not currently support encoder x1 mode. Look for it
later this fall.
--
Sebastian Kuzminsky
the sky calls to us -- carl sagan
http://www.youtube.com/watch?v=zSgiXGELjbc
Peter C. Wallace wrote:
On Fri, 23 Oct 2009, Michael Haberler wrote:
Am 23.10.2009 um 20:07 schrieb Peter C. Wallace:
Set counter_mode true for x1 mode...
I assumed a q-decoder in x1-mode is still a q-decoder which gives
position *and* direction which is why ignored that option..
Its
: [Emc-users] threading Z oscillation depends on encoder PPR
Michael Haberler wrote:
How do I go about putting a hm2 encoder in x1-mode ?
The hm2 driver does not currently support encoder x1 mode. Look for it
later this fall.
unless this is another sematic issue, x1 mode (count on only one
Am 23.10.2009 um 20:33 schrieb Peter C. Wallace:
Set counter_mode true for x1 mode...
I assumed a q-decoder in x1-mode is still a q-decoder which gives
position *and* direction which is why ignored that option..
instant stop of delight..
- Michael
Its still is a quadrature decoder but
On Fri, Oct 23, 2009 at 11:33:15AM -0700, Peter C. Wallace wrote:
Its still is a quadrature decoder but it only counts on one edge (rising edge
of A in this case, state of B on rising edge of A determines direction)
If this is true, it is not a correct decoding.
Imagine B is high, and A goes
Peter C. Wallace wrote:
On Fri, 23 Oct 2009, Sebastian Kuzminsky wrote:
The hm2 driver does not currently support encoder x1 mode. Look for it
later this fall.
unless this is another sematic issue, x1 mode (count on only one edge
bidirectional counter mode) is supported, its a totally
On Fri, Oct 23, 2009 at 01:26:53PM -0600, Sebastian Kuzminsky wrote:
... and that x1 quadrature mode the same as
what the manpage calls step/dir mode.
No, it's not (or if it is, it doesn't work right) - see my reply to
Peter a few minutes ago.
Chris Radek wrote:
On Fri, Oct 23, 2009 at 11:33:15AM -0700, Peter C. Wallace wrote:
Its still is a quadrature decoder but it only counts on one edge (rising
edge
of A in this case, state of B on rising edge of A determines direction)
If this is true, it is not a correct decoding.
] threading Z oscillation depends on encoder PPR
On Fri, Oct 23, 2009 at 11:33:15AM -0700, Peter C. Wallace wrote:
Its still is a quadrature decoder but it only counts on one edge (rising edge
of A in this case, state of B on rising edge of A determines direction)
If this is true
: [Emc-users] threading Z oscillation depends on encoder PPR
Peter C. Wallace wrote:
On Fri, 23 Oct 2009, Sebastian Kuzminsky wrote:
The hm2 driver does not currently support encoder x1 mode. Look for it
later this fall.
unless this is another sematic issue, x1 mode (count on only one edge
2009/10/22 Jon Elson el...@pico-systems.com:
Good hypothesis and data taking! So, it seems the problem is the
encoder counter sees
a zero velocity between actual encoder counts, and tells the slaved axis
to stop NOW! Then a
count comes in, and it says MOVE NOW! Yes, I can see this is a
Andy Pugh wrote:
2009/10/22 Jon Elson el...@pico-systems.com:
Good hypothesis and data taking! So, it seems the problem is the
encoder counter sees
a zero velocity between actual encoder counts, and tells the slaved axis
to stop NOW! Then a
count comes in, and it says MOVE NOW! Yes,
Andy Pugh wrote:
snip
An alternative might be to keep things much as they are, but to have a
parameter in the G-code for how much run up it has. It then becomes
a somewhat simpler trajectory planner issue to get to the thread start
at the right speed next time the index comes round on the
Am 22.10.2009 um 12:21 schrieb Andy Pugh:
2009/10/22 Jon Elson el...@pico-systems.com:
Good hypothesis and data taking! So, it seems the problem is the
encoder counter sees
a zero velocity between actual encoder counts, and tells the slaved
axis
to stop NOW! Then a
count comes in,
2009/10/22 Michael Haberler mai...@mah.priv.at:
yes - I ran into the problem when switching to hm2 which doesnt
currently provide position-interpolated
Which is an interesting point. It seems that a hardware quadrature
counter is likely to be counterproductive if you have a low-count
encoder.
Am 22.10.2009 um 20:04 schrieb Jon Elson:
...
limit, and then the system becomes violently unstable. This is all
just
guessing from too little info,
hopefully we can get some plots of other signals from the stepgen to
see
in more detail what is
happening inside.
Also note that G33
Andy Pugh wrote:
2009/10/22 Michael Haberler mai...@mah.priv.at:
yes - I ran into the problem when switching to hm2 which doesnt
currently provide position-interpolated
Which is an interesting point. It seems that a hardware quadrature
counter is likely to be counterproductive if
Michael Haberler wrote:
stepgen just does what axis tells it to do:
http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove/pos-cmd-steprate.png?revision=1.1root=CVSview=markup
the wobble is already in axis.2.motor-pos-cmd so that takes stepgen
out of the picture IMHO
Well, the
Jon Elson wrote:
Andy Pugh wrote:
Is there any reason not to use position-interpolated by default?
There might be. I don't know how position-interpolated works, but I
assume it might
introduce a delay in the position reports.
It does not introduce a delay.
It uses the velocity between
John Kasunich wrote:
It does not introduce a delay.
It uses the velocity between the last two edges to predict the position
as time moves on, until the next edge arrives, at which point it uses
that edge to correct any error in the prediction.
Below is a halscope plot from when I was
Am 21.10.2009 um 07:08 schrieb Jon Elson:
Haberler Michael wrote:
Am 21.10.2009 um 02:40 schrieb Jon Elson:
Well, there's the problem, the sampling rate is just too low.
well that's what Steve said about his setup, but it's not the problem
I described
Well, that HalScope trace sure
Am 21.10.2009 um 03:04 schrieb Stephen Wille Padnos:
Haberler Michael wrote:
[snip]
here's a halscope shot of severe Z axis oscillation:
http://mah.priv.at/gallery2/main.php?g2_view=core.DownloadItemg2_itemId=70522
Could you post the config (HAL/ini) files you used to see this?
2009/10/21 Haberler Michael mai...@mah.priv.at:
Here are the configs:
http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove/?root=CVS
I suspect that your max axis velocity and accelleration are part of
the problem. They both seem rather low.
Can you run with higher accell rates? 70 is very low,
Am 21.10.2009 um 14:33 schrieb Haberler Michael:
ok, following up to myself once more:
- set acceleration from 300 back to 70
- changed
net spindle_rev_count encoder.1.position = motion.spindle-revs
to
net spindle_rev_count encoder.1.position-interpolated =
Haberler Michael wrote:
well, it's a stepper system, no PID's on the axes.
Any signals (motion, axis etc) you're suggesting to plot?
OK, now I'm confused. There was a trace at the top of the screen that
looked like
a sawtooth, and had error in the signal name. What was that? (I
couldn't
Haberler,
OK, the trajectory planner saeems to be running at 1 KHz, same as the
servo thread.
The sawtooth is in signal axis.2.f-error I don't know what other
signals you can get
out of stepgen to help diagnose it. A commanded velocity signal (which
it has to have
internally) would be MOST
Haberler Michael wrote:
good point - I just tried that with acceleration 300 instead of 70 and
45ppr.
The wild oscillations are gone :
http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove/45ppr-accel300-dampened-oscillation.png?revision=1.1root=CVSview=markup
The wild oscillations are
So this was the key
- set acceleration from 300 back to 70
net spindle_rev_count encoder.1.position-interpolated = motion.spindle-revs
With the working setup you have now, what version of EMC2 are you using and
what patches have you applied?
Thanks,
Dave
Haberler Michael wrote:
Jon,
I just saw hm2 stepgen has velocity-cmd and velocity-fb, that would be
more to the point; I'll see wether that produces a better visual
explanation.
but by now I'm sure it's just playing catch-up with erratic position
updates - TP figures the spindle has stopped if it doesnt see
On Tue, 20 Oct 2009 18:18:33 -0500, you wrote:
On Wed, Oct 21, 2009 at 12:11:20AM +0100, Andy Pugh wrote:
patch:
http://timeguy.com/cradek-files/emc/0001-Improve-initial-threading-synchronization.patch
Before : http://imagebin.ca/view/XLxWqSm.html
After :
Haberler Michael wrote:
360 RPM - fine
320 RPM - still ok, some wobble
270 RPM - heavy oscillation one some passes
Good hypothesis and data taking! So, it seems the problem is the
encoder counter sees
a zero velocity between actual encoder counts, and tells the slaved axis
to stop NOW!
several folks (including me) reported problems with threading - namely
oscillations of the spindle-synchronized feed (G33 and G76), mostly
with homebrew encoders. Most people looked at their encoders and
signal properties.
I've isolated the problem now with a *simulated encoder* - decoder
On Tue, 20 Oct 2009 23:26:27 +0200, you wrote:
several folks (including me) reported problems with threading - namely
oscillations of the spindle-synchronized feed (G33 and G76), mostly
with homebrew encoders. Most people looked at their encoders and
signal properties.
It's not only home
2009/10/20 Haberler Michael mai...@mah.priv.at:
I dont fully understand the trajectory planner, but my gut feeling
it's a control loop oscillation which gets excited with the encoder
quantization/noise spectrum gets too close to the loop frequency.
The problem seems to be with a bad initial
On Wed, Oct 21, 2009 at 12:11:20AM +0100, Andy Pugh wrote:
patch:
http://timeguy.com/cradek-files/emc/0001-Improve-initial-threading-synchronization.patch
Before : http://imagebin.ca/view/XLxWqSm.html
After : http://imagebin.ca/view/RYa7Qqpm.html
I put a similar change in git; it will
Steve Blackmore wrote:
It's not only home made encoders, expensive commercial encoders have the
same problem.
The problem is, without using external hardware, anything above 150 ppr
or so limits the spindle speed severely. 240 rpm is very slow for a CNC
machine threading. Most of my
Am 21.10.2009 um 02:40 schrieb Jon Elson:
Steve Blackmore wrote:
..
Here, with my hardware and PC, EMC can't read pulses reliably over
about
200 rpm with a 1024 encoder, which is totally impractical.
Well, there's the problem, the sampling rate is just too low.
well that's what Steve
Am 21.10.2009 um 00:21 schrieb Steve Blackmore:
On Tue, 20 Oct 2009 23:26:27 +0200, you wrote:
several folks (including me) reported problems with threading -
namely
oscillations of the spindle-synchronized feed (G33 and G76), mostly
with homebrew encoders. Most people looked at their
Am 21.10.2009 um 01:11 schrieb Andy Pugh:
2009/10/20 Haberler Michael mai...@mah.priv.at:
I dont fully understand the trajectory planner, but my gut feeling
it's a control loop oscillation which gets excited with the encoder
quantization/noise spectrum gets too close to the loop frequency.
On Wed, Oct 21, 2009 at 02:37:47AM +0200, Haberler Michael wrote:
I'm a CNC retard, so here's my question: where is the benefit in
incrementally controlling the feed depending on continuous spindle
position updates as opposed to just assuming the spindle angular speed
stays constant
Haberler Michael wrote:
Am 21.10.2009 um 02:40 schrieb Jon Elson:
Well, there's the problem, the sampling rate is just too low.
well that's what Steve said about his setup, but it's not the problem
I described
Well, that HalScope trace sure indicates SOMETHING is really
73 matches
Mail list logo
