: Sunday, October 11, 2009 8:59 AM
To: 'Enhanced Machine Controller (EMC)'
Subject: Re: [Emc-users] Encoders
Passive fiber optic rotary encoders do exist and have many
benefits. Unfortunately, low cost is not among them. See:
http://www.micronor.com/products.php?category=Fiber%20Optic%20
On Sunday 11 October 2009, Sven Wesley wrote:
2009/10/11 Gene Heskett gene.hesk...@gmail.com
[Gene gives a lesson]
Sometimes I wonder if I shouldn't take all these mail and make a book out
of them. :)
Be my guest as long as you give a credit line. I did have a copyright notice
in my sig,
A twisted pair, or any long piece of wire coming out of the back of a PC, is
first and foremost, a transmission line, and needs to be terminated
properly. This has nothing to do with the DC bias. The impedance of such a
line is generally 50R to 75R.
In the case of a printer port line, which is
Roland Jollivet wrote:
A twisted pair, or any long piece of wire coming out of the back of a PC, is
first and foremost, a transmission line, and needs to be terminated
properly. This has nothing to do with the DC bias. The impedance of such a
line is generally 50R to 75R.
Actually, twised
2009/10/10 Jon Elson el...@pico-systems.com
Roland Jollivet wrote:
A twisted pair, or any long piece of wire coming out of the back of a PC,
is
first and foremost, a transmission line, and needs to be terminated
properly. This has nothing to do with the DC bias. The impedance of such
a
Oops, yes. Thats what you said. Differential impedance = 100R
Roland
2009/10/10 Roland Jollivet roland.jolli...@gmail.com
2009/10/10 Jon Elson el...@pico-systems.com
Roland Jollivet wrote:
A twisted pair, or any long piece of wire coming out of the back of a
PC, is
first and
Steve Blackmore wrote:
The 120 Ohm are not pull-ups, they are to balance the twisted pair.
More specifically to absorb the transmision line energy when it reaches
the end of the
cable. There is significant energy contained in the
inductive/capacitive effect as the transient
signal edges flow
If 120 ohms from the inputs to +5 is too much of a load, try 470 or 510 ohms.
Any pull up action should work against the noise. If that's where the noise
is attacking,
some is better than none, and even 1K ohm might be enough to hold the noise at
bay.
Of course it's easy for me to talk, when
On Sun, 04 Oct 2009 23:46:48 -0500, you wrote:
Steve Blackmore wrote:
Hi Jon
Encoder is connected to a couple of UA9637ACP differential line
receivers. I'm putting A+ A-, B+ B-, I+ I- in and getting A, B, I out at
3.5V, should I connect the resistors on the outputs of the line
receiver?
Steve Blackmore wrote:
Hi Jon - tried 120 Ohm across the inputs - it stopped the line receiver
working?
It didn't stop the RECEIVER, it stopped the TRANSMITTER from working.
I was already suspecting this, and your report the pull-ups helped
confirms that the
encoder's transmitter has weak or
On Tuesday 06 October 2009, Steve Blackmore wrote:
On Sun, 04 Oct 2009 23:46:48 -0500, you wrote:
Steve Blackmore wrote:
Hi Jon
Encoder is connected to a couple of UA9637ACP differential line
receivers. I'm putting A+ A-, B+ B-, I+ I- in and getting A, B, I out at
3.5V, should I connect the
I finally got the chance to try Chris' threading 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
Watching it cycle after cycle it was very inconsistent
On Fri, 02 Oct 2009 11:34:45 -0500, you wrote:
I would think a 1 K Ohm
resistor from +5 V to the A and B would make a big difference. You can
get +5 V from the game port or a
hard drive plug. Yup, also looking closer, I see COORDINATED spikes in
both A and B on a number of
cycles. That
Note also, that if the pullup that's already there is very weak, the rise
time would be slowed down, but the fall time would be fast. This could
produce what we see in the encoder-a trace. The 1k pullups might bring
that trace closer to 50% duty cycle.
. I would think a 1 K Ohm
resistor
On Fri, 02 Oct 2009 15:24:24 -0400, you wrote:
Page 5 and 6 show it but not at a good time scale, page 7 from the base
thread sample shows it very clearly Steve. Noise. Until that is gone (and
encoder A output could have a closer to 50% duty cycle too, I'd almost return
that one in fact if
On Saturday 03 October 2009, Steve Blackmore wrote:
On Fri, 02 Oct 2009 15:24:24 -0400, you wrote:
Page 5 and 6 show it but not at a good time scale, page 7 from the base
thread sample shows it very clearly Steve. Noise. Until that is gone
(and encoder A output could have a closer to 50% duty
when you get a chance - try the interpolated output from the encoder.
sam
Steve Blackmore wrote:
On Fri, 02 Oct 2009 15:24:24 -0400, you wrote:
Page 5 and 6 show it but not at a good time scale, page 7 from the base
thread sample shows it very clearly Steve. Noise. Until that is gone
2009/10/4 sam sokolik sa...@empirescreen.com:
when you get a chance - try the interpolated output from the encoder.
He already has, though perhaps not since fixing the noise.
--
atp
--
Come build with us! The
Andy Pugh wrote:
2009/10/4 Gene Heskett gene.hesk...@gmail.com:
That looks better, but something is still giving the encoder.0.velocity a big
kick occasionally.
I think those are on the occasions that both channels change state in
the same sample. That does mean infinite velocity,
On Saturday 03 October 2009, Steve Blackmore wrote:
On Fri, 02 Oct 2009 15:24:24 -0400, you wrote:
Page 5 and 6 show it but not at a good time scale, page 7 from the base
thread sample shows it very clearly Steve. Noise. Until that is gone
(and encoder A output could have a closer to 50% duty
On Thu, 01 Oct 2009 12:32:48 -0400, you wrote:
And what I think I'm seeing is quantization noise in the time domain, the
occasionally very narrow spike probably isn't there on your o-scope. But it
(to me anyway) points to a problem in that the sampling is probably not being
done in the base
2009/10/2 Steve Blackmore st...@pilotltd.net:
On page 6 I changed the sampling rate to base thread.
http://filebin.ca/wacbfm/screenshots.pdf
Aha! I see noisy encoder signals. That seems to be confusing the
velocity calculation (but possibly not the position calculation)
I am also a little
2009/10/2 Andy Pugh a...@andypugh.fsnet.co.uk:
Aha! I see noisy encoder signals.
To see if that is the problem, you could debounce the signals in HAL.
None of the glitches looks to be longer than one sample, so a single
sample debounce should do. The drawback is that you potentially lose
On Fri, Oct 02, 2009 at 12:37:05PM +0100, Steve Blackmore wrote:
On page 6 I changed the sampling rate to base thread.
http://filebin.ca/wacbfm/screenshots.pdf
Excellent, page 7 shows the problem very clearly. You have really
awful spindle feedback. I'm surprised this works at all.
You
On Fri, 02 Oct 2009 12:37 +0100, Steve Blackmore st...@pilotltd.net
wrote:
I've redone that at 100 rpm, and out of interest looked at the pulses
out for the Z axis, the position interpolation is linear, as shown in
halscope, the pulses out are anything but! Surely they should be linear
Andy Pugh wrote:
2009/10/2 Steve Blackmore st...@pilotltd.net:
On page 6 I changed the sampling rate to base thread.
http://filebin.ca/wacbfm/screenshots.pdf
Aha! I see noisy encoder signals. That seems to be confusing the
velocity calculation (but possibly not the position
Jon Elson wrote:
OK, things look worse, and obvious noise is showing in the A and B
traces when you do this.
I think it shows that the sampling was being done at the faster rate
before.
OOps, I misread what you had changed. Chris said it right. This is
allowing you to see what is actually
Steve Blackmore wrote:
I've redone that at 100 rpm, and out of interest looked at the pulses
out for the Z axis, the position interpolation is linear, as shown in
halscope, the pulses out are anything but! Surely they should be linear
too?
There are several screenshots so I bundled them
On Friday 02 October 2009, Steve Blackmore wrote:
On Thu, 01 Oct 2009 12:32:48 -0400, you wrote:
And what I think I'm seeing is quantization noise in the time domain, the
occasionally very narrow spike probably isn't there on your o-scope. But
it (to me anyway) points to a problem in that the
On Fri, 02 Oct 2009 11:34:45 -0500, you wrote:
. I would think a 1 K Ohm
resistor from +5 V to the A and B would make a big difference. You can
get +5 V from the game port or a
hard drive plug. Yup, also looking closer, I see COORDINATED spikes in
both A and B on a number of
cycles. That
On page 6 I changed the sampling rate to base thread.
good, the first 5 pages are in respect to phase-a b irrelevant.
Looking at page 6 however, AB look really bad, try running them through a
debounce first.
That might increase chances of success.
http://filebin.ca/wacbfm/screenshots.pdf
On Friday 02 October 2009, Andy Pugh wrote:
2009/10/2 Steve Blackmore st...@pilotltd.net:
On page 6 I changed the sampling rate to base thread.
http://filebin.ca/wacbfm/screenshots.pdf
Aha! I see noisy encoder signals. That seems to be confusing the
velocity calculation (but possibly not the
On Wed, 30 Sep 2009 21:07:45 -0500, you wrote:
OK, good, but what is the rate of the bate thread set to? That value is
brought over
from a line in your .ini file. There are probably 3 lines that read
something like :
# Base task period, in nanoseconds - this is the fastest thread in the
2009/10/1 Jon Elson el...@pico-systems.com:
Somebody posted a pastebin that showed large jumps in some variable.
I was never real clear
what that column in the file was showing,
If you mean http://www.pastebin.ca/1583502 then that was me.
The columns (which are messed up, but tab-delimited)
2009/10/1 Steve Blackmore st...@pilotltd.net:
http://imagebin.ca/view/lUA3lv.html
I am amazed that G33 works at all with that velocity noise. Mine is no
more than 10% dither and is being blamed for my inability to thread.
What sort of encoder is it? It looks to have a slot that isn't
Kirk Wallace wrote:
On Thu, 2009-10-01 at 00:46 -0400, John Kasunich wrote:
... snip
The software encoder counter has TWO functions.
update-counters should always be run as fast as possible - that means
the base thread. update-counters is the function that actually looks
at the encoder
Hi Andy,
with your open encoder, have you checked the possibility of interference
from a flourescent light that might hang somewhere above your machine? I
have encountered this phenomenon at my shop trying to test a DRO. Look at
the flickering of the display of a digital camera with flourescent
On Thu, 1 Oct 2009 11:17:51 +0100, you wrote:
2009/10/1 Steve Blackmore st...@pilotltd.net:
http://imagebin.ca/view/lUA3lv.html
I am amazed that G33 works at all with that velocity noise. Mine is no
more than 10% dither and is being blamed for my inability to thread.
What sort of encoder is
2009/10/1 Peter blodow p.blo...@dreki.de:
Hi Andy,
with your open encoder, have you checked the possibility of interference
from a flourescent light that might hang somewhere above your machine?
In my case the encoder is inside the spindle casting, in the dark.
I have just had a look at
2009/10/1 Steve Blackmore st...@pilotltd.net:
What sort of encoder is it? It looks to have a slot that isn't registering.
Heidenhain - there's nothing wrong with the encoder, it's the third one
I've tried, all with the same effect.
No, now you have the pulses on there I retract that
On Thursday 01 October 2009, Steve Blackmore wrote:
On Thu, 1 Oct 2009 11:17:51 +0100, you wrote:
2009/10/1 Steve Blackmore st...@pilotltd.net:
http://imagebin.ca/view/lUA3lv.html
I am amazed that G33 works at all with that velocity noise. Mine is no
more than 10% dither and is being blamed for
Andy Pugh wrote:
2009/10/1 Jon Elson el...@pico-systems.com:
Somebody posted a pastebin that showed large jumps in some variable.
I was never real clear
what that column in the file was showing,
If you mean http://www.pastebin.ca/1583502 then that was me.
The columns (which are
Steve Blackmore wrote:
On Thu, 01 Oct 2009 00:46:54 -0400, you wrote:
Steve should set up halscope as others have instructed. Capture
position, velocity, and position-interpolated. Trigger on a falling
edge of index-enable, so that the scope will take data at the beginning
of a
Steve Blackmore wrote:
Here's a halscope of the encoder pulses
http://imagebin.ca/view/1SkQrEB.html
what you can determine from the pulse widths/spikes is inconclusive.
OK, now that we have the A and B signals there, we can determine the raw
count rate.
It is between about 25 quadrature
On Tue, 29 Sep 2009 22:02:51 +0100, you wrote:
2009/9/29 Kirk Wallace kwall...@wallacecompany.com:
I still think your threading problem is due to the Z acceleration issue.
You may try cutting an air thread that is as long as your Z axis will
allow. If your thread wanders the same across the
it occurred to me that it is an error to use both edges of the opto
signal due to it not being exactly 50% mark space so one edge has a
positional error that must be ignored
Dave Caroline
--
Come build with us! The
On Wed, 30 Sep 2009 10:50:58 +0100, you wrote:
I am intending to make a better encoder. I think my problem is an
unfortunate combination of things one of which is too-infrequent
position updates,
I think one of the problems I have is that there seems to be no
averaging on my spindle encoder
Check to see what output you are using from the encoder hal componant..
*encoder.*/N/*.position-interpolated does what you need.
'*Position in scaled units, interpolated between encoder counts. Only
valid when velocity is approximately constant, do not use for position
control'
2009/9/30 Steve Blackmore st...@pilotltd.net:
I've no idea how, or if it's possible to average the encoder readout?
Yes, you need to make a small change to your HAL file, see:
2009/9/30 Steve Blackmore st...@pilotltd.net:
The Z stepper is machine gunning, stop/start/stop/start etc and not running
smoothly.
I am not sure if there is any lookahead in the trajectory planner
for G33/G76 moves. It might almost make sense to put two copies of the
current move into the
On Wed, 30 Sep 2009 14:26:24 +0100, you wrote:
2009/9/30 Steve Blackmore st...@pilotltd.net:
I've no idea how, or if it's possible to average the encoder readout?
Yes, you need to make a small change to your HAL file, see:
2009/9/30 Steve Blackmore st...@pilotltd.net:
position-interpolated - that's even worse :(
Interesting. I think we need help from the big brains here :-)
--
atp
--
Come build with us! The BlackBerryreg; Developer
2009/9/30 Steve Blackmore st...@pilotltd.net:
setp encoder.0.position-scale 500.00
net spindle-position encoder.0.position = motion.spindle-revs
net spindle-velocity encoder.0.velocity = motion.spindle-speed-in
net spindle-index-enable encoder.0.index-enable =
motion.spindle-index-enable
2009/9/30 Andy Pugh a...@andypugh.fsnet.co.uk:
If you run Halscope at a fast rate and look at
encoder.0.position,
encoder.0.position-interpolated
axis.2.motor-pos-cmd
Sorry: encoder.0.velocity might be interesting too.
--
atp
sorry - I meant replace the line with
net spindle-position *encoder.*/0/*.position-interpolated* =
motion.spindle-revs
sam
Steve Blackmore wrote:
On Wed, 30 Sep 2009 15:57:12 +0100, you wrote:
On Wed, 30 Sep 2009 14:26:24 +0100, you wrote:
2009/9/30 Steve Blackmore
Try changning
net spindle-position encoder.0.position = motion.spindle-revs
to
*net encoder.0**.position-interpolated *= motion.spindle-revs
(if I did that right) and see if the low rpm jitter is gone.
sam
Steve Blackmore wrote:
On Wed, 30 Sep 2009 15:57:12 +0100, you wrote:
On Wed,
lets try that one more time. (again - sorry) I have to stop copy and
pasting
net spindle-position encoder.0.position-interpolated = motion.spindle-revs
Steve Blackmore wrote:
On Wed, 30 Sep 2009 15:57:12 +0100, you wrote:
On Wed, 30 Sep 2009 14:26:24 +0100, you wrote:
Steve Blackmore wrote:
I've no idea how, or if it's possible to average the encoder readout?
The pastebin you showed indicated it is missing counts. You say scope
traces
indicate the encoder is working OK. So, it has something to do with the
way the
computer is reading the counts.
Andy Pugh wrote:
2009/9/30 Steve Blackmore st...@pilotltd.net:
position-interpolated - that's even worse :(
Interesting. I think we need help from the big brains here :-)
Well, that depends on whether Steve was telling us that he had tried it
and saw worse results, or if he was
Dave Caroline wrote:
it occurred to me that it is an error to use both edges of the opto
signal due to it not being exactly 50% mark space so one edge has a
positional error that must be ignored.
Well, that would likely be a small error, and probably smaller than the
error
caused by a slow
Andy Pugh wrote:
2009/9/30 Steve Blackmore st...@pilotltd.net:
position-interpolated - that's even worse :(
Interesting. I think we need help from the big brains here :-)
Are you saying you tried it, and it made things worse? Well, I am not
surprised
at all. The velocity
Steve Blackmore wrote:
On Wed, 30 Sep 2009 15:57:12 +0100, you wrote:
On Wed, 30 Sep 2009 14:26:24 +0100, you wrote:
2009/9/30 Steve Blackmore st...@pilotltd.net:
I've no idea how, or if it's possible to average the encoder readout?
Yes, you need to make a small
On Wed, 30 Sep 2009 13:00:23 -0500, you wrote:
Andy Pugh wrote:
2009/9/30 Steve Blackmore st...@pilotltd.net:
position-interpolated - that's even worse :(
Interesting. I think we need help from the big brains here :-)
Are you saying you tried it, and it made things worse?
On Wed, 30 Sep 2009 13:02:12 -0500, you wrote:
For interest, these are the only lines in my hal file that refer to
encoder, can anybody see anything wrong or missing?
loadrt encoder num_chan=1
setp encoder.0.position-scale 500.00
net spindle-position encoder.0.position =
On Wed, 30 Sep 2009 10:32:22 -0500, you wrote:
lets try that one more time. (again - sorry) I have to stop copy and
pasting
net spindle-position encoder.0.position-interpolated = motion.spindle-revs
Thanks Sam - I'll give that a go tomorrow
Steve Blackmore
--
Steve Blackmore wrote:
Jon - I've not posted any pastebin stuff, that's Andy.
OK, I am getting confused with related threads, then.
Jon
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is
Steve Blackmore wrote:
On Wed, 30 Sep 2009 13:02:12 -0500, you wrote:
For interest, these are the only lines in my hal file that refer to
encoder, can anybody see anything wrong or missing?
loadrt encoder num_chan=1
setp encoder.0.position-scale 500.00
net spindle-position
On Wed, 2009-09-30 at 21:07 -0500, Jon Elson wrote:
But, at least, you have the encoder counters running at the base-thread
rate. I was afraid you might have
been running the counter at the servo thread rate, which would really
slow the sampling rate. (Note the
above quoted numbers are
Kirk Wallace wrote:
On Wed, 2009-09-30 at 21:07 -0500, Jon Elson wrote:
But, at least, you have the encoder counters running at the base-thread
rate. I was afraid you might have
been running the counter at the servo thread rate, which would really
slow the sampling rate. (Note the
John Kasunich wrote:
The extreme jitter that Jon Elson keeps mentioning will NOT happen if
you use position-interpolated. capture-position doesn't just use the
number of edges seen since the last time it ran - it also looks at when
those edges occurred, in order to calculate a more
(Sorry to start yet another thread on much the same subject, but this
is a bit broader-ranging)
It seems that spindle-synchronised motion is very sensitive to encoder
regularity.
Using the p-port to read the encoder position means that as the
encoder linecount goes up, quantisation error in the
do you need one of use to make/cut a disk
Dave Caroline (archivist)
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
2009/9/29 Dave Caroline dave.thearchiv...@gmail.com:
do you need one of use to make/cut a disk
My machine has a milling head and a 4th axis, so making my own is
fairly straightforward (But thanks for the offer).
However I run the risk of doing a lot of machining and still having
exactly the
you need a good contrast with reflective, I prefer a gap type, ambient
light is another problem to watch for
Dave Caroline
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer
On Tue, 2009-09-29 at 17:43 +0100, Andy Pugh wrote:
2009/9/29 Dave Caroline dave.thearchiv...@gmail.com:
do you need one of use to make/cut a disk
My machine has a milling head and a 4th axis, so making my own is
fairly straightforward (But thanks for the offer).
However I run the risk
2009/9/29 Kirk Wallace kwall...@wallacecompany.com:
I still think your threading problem is due to the Z acceleration issue.
You may try cutting an air thread that is as long as your Z axis will
allow. If your thread wanders the same across the thread then I would
look into your encoder more.
Andy Pugh wrote:
(Sorry to start yet another thread on much the same subject, but this
is a bit broader-ranging)
It seems that spindle-synchronised motion is very sensitive to encoder
regularity.
Using the p-port to read the encoder position means that as the
encoder linecount goes up,
Andy Pugh wrote:
My system seems to track a 50-line encoder adequately, would that
nromally be considered enough resolution for threading?
50 lines is 200 quadrature counts, should be fine for threading, I would
think.
That is a unique position reading for every 360/200 = 1.8 degrees of
Hi Dave,
The motors are Minertia brand by Yaskawa Electric of Japan and are model
mos FA5S-CA11 and FA5X-CA31. I can't find any info about these on the
web. The encoders are 1000 line with no index pulse. I have put some
pictures up on my website - *http://tinyurl.com/6nf3sz
You are likely to see two kinds of encoders: TTL and differential
(rs422).
TTL means there's a single wire for the each signal (e.g. A), and it
roughly follows TTL voltage level for high and low signals.
differential means there are two wires for each signal (e.g., A+ and
A-). The logic-level
Hi guys,
I haven't played with servo motors yet but I have a little one out of a
plotter that I thought I would like to mess about with using something
like the Etch configs in EMC2. The encoder board is a bit odd (to me) in
that the connections at present are some form of analogue voltage
any make on the motor and what plotter it was from helps, the opto
(look for a part number on it) may be found on google, possibly
pullups and a comparator is all thats required
Dave Caroline
-
This SF.Net email is sponsored
hi,
i use gecko drives with 10 micro steps and i don't know if i ever lost
a step or not. i would like to add encoders to the back of my double
shafted stepper motors. i would like emc to stop all motors and report
any lost steps. i definitely don't want emc to try to make up for the
://cnczone.com/forums/showthread.php?t=53960highlight=encoders
sam
- Original Message -
From: David Szakovits [EMAIL PROTECTED]
To: emc-users@lists.sourceforge.net
Sent: Saturday, March 15, 2008 9:54 AM
Subject: [Emc-users] encoders and stepper motors
hi,
i use gecko drives with 10 micro
David Szakovits wrote:
hi,
i use gecko drives with 10 micro steps and i don't know if i ever lost
a step or not. i would like to add encoders to the back of my double
shafted stepper motors. i would like emc to stop all motors and report
any lost steps. i definitely don't want emc to
On Sat, 2008-01-19 at 21:51 +, Ian Wright wrote:
Hi,
I have a couple of servo motors out of an old Olivetti printer which I'd
like to try to use, however, I can't find any information about the
encoders fitted to them. The encoders are in flat brown plastic
enclosures on the end of
Hi,
I have a couple of servo motors out of an old Olivetti printer which I'd
like to try to use, however, I can't find any information about the
encoders fitted to them. The encoders are in flat brown plastic
enclosures on the end of the motors and have 7 pin plugs with 6 wires
connected (the
Dear All,
I am considering adding encoders and home switches to my Sherline CNC mill.
I see 2 benefits:
1) Being *sure* of not loosing steps (estop, ...)
2) Using (low precision) home switches and the index of the encoder, I get
*excellent* repeatability when homing.
The mill is equipped with
Michel Gouget wrote:
Dear All,
I am considering adding encoders and home switches to my Sherline CNC mill.
I see 2 benefits:
1) Being *sure* of not loosing steps (estop, ...)
2) Using (low precision) home switches and the index of the encoder, I get
*excellent* repeatability when homing.
Michel Gouget wrote:
Dear All,
I am considering adding encoders and home switches to my Sherline CNC mill.
I see 2 benefits:
1) Being *sure* of not loosing steps (estop, ...)
2) Using (low precision) home switches and the index of the encoder, I get
*excellent* repeatability when homing.
I'm
sure there is a way to solve that problem, but nothing springs to mind
right now.
how about a long limit switch (between 2 encoder indexes), just use a latch
to toggle the state.
to summarize: actual switch AND encoder index - toggle signal for the
latch.
latch output - emc home-sw
- Original Message -
From: John Kasunich [EMAIL PROTECTED]
To: Enhanced Machine Controller (EMC)
emc-users@lists.sourceforge.net
Sent: Wednesday, August 15, 2007 8:59 AM
Subject: Re: [Emc-users] Encoders with steppers
snip
PID's response to feedback falling behind command is to drive
101 - 192 of 192 matches
Mail list logo
