2009/10/10 Jon Elson
> 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 gen
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, twi
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 unb
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 a
On Thu, 08 Oct 2009 21:34:12 -0400, you wrote:
>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 nois
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 I
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, shoul
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
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 lin
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?
>
>
Oh, my! This is getting messy, for
On Sunday 04 October 2009, Steve Blackmore wrote:
>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
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. Tha
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%
Andy Pugh wrote:
> 2009/10/4 Gene Heskett :
>
>
>> 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, after all.
2009/10/4 sam sokolik :
>
> 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 BlackBerry® Developer Confer
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
2009/10/4 Gene Heskett :
> 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, after all. (Does
the encoder code cap velocity at
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%
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 i
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 Friday 02 October 2009, Andy Pugh wrote:
>2009/10/2 Steve Blackmore :
>> 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 c
> 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, A&B look really bad, try running them through a
debounce first.
That might increase chances of success.
> http://filebin.ca/wacbfm/screenshots.pdf
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. Th
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
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
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 actua
Andy Pugh wrote:
> 2009/10/2 Steve Blackmore :
>
>
>> 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 calculatio
On Fri, 02 Oct 2009 12:37 +0100, "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?
>
> Ther
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
2009/10/2 Andy Pugh :
> 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
encoder at full speed.
This is
2009/10/2 Steve Blackmore :
> 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 surprised that the
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 ba
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 quadra
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
Andy Pugh wrote:
> 2009/10/1 Jon Elson :
>
>
>> 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
Steve Blackmore wrote:
> 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
On Thursday 01 October 2009, Steve Blackmore wrote:
>On Thu, 1 Oct 2009 11:17:51 +0100, you wrote:
>>2009/10/1 Steve Blackmore :
>>> 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 inab
2009/10/1 Steve Blackmore :
>>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 suggestion.
> what you
2009/10/1 Peter blodow :
>
> 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 Steve's trace, and
On Thu, 1 Oct 2009 11:17:51 +0100, you wrote:
>2009/10/1 Steve Blackmore :
>
>> 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 look
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
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 th
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 inputs and counts t
2009/10/1 Steve Blackmore :
> 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 registering.
--
atp
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 threading pass. Sample at the s
2009/10/1 Jon Elson :
> 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) show timestamp
(on
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
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 accu
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
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 a
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
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 BlackBerry® Developer Conference in SF, CA
is
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
--
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 13:00:23 -0500, you wrote:
>Andy Pugh wrote:
>> 2009/9/30 Steve Blackmore :
>>
>>
>>> 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?
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 :
>>>
>>>
I've no idea how, or if it's possible to average the encoder readout?
>>> Yes, you need to ma
Andy Pugh wrote:
> 2009/9/30 Steve Blackmore :
>
>
>> 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 info from
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 s
Andy Pugh wrote:
>2009/9/30 Steve Blackmore :
>
>
>>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 telling
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. A
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:
>>
>>
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
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 Bl
2009/9/30 Andy Pugh :
> 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
--
Come build
2009/9/30 Steve Blackmore :
> 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
> net spi
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 :
>>
>>> 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:
>>http://www.linuxcnc.org/com
2009/9/30 Steve Blackmore :
> position-interpolated - that's even worse :(
Interesting. I think we need help from the big brains here :-)
--
atp
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is
On Wed, 30 Sep 2009 14:26:24 +0100, you wrote:
>2009/9/30 Steve Blackmore :
>
>> 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:
>http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,24/id
2009/9/30 Steve Blackmore :
> 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 queue so that it
2009/9/30 Steve Blackmore :
> 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:
http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,24/id,369/limit,6/limitstart,42/lang,en/#891
--
atp
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'
http://linuxcn
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 va
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 BlackB
2009/9/30 Steve Blackmore :
> I watched your video, but couldn't determine how much lead in you were
> giving the thread?
I am trying to cut a 4mm lead at 200rpm. After a suggestion from
alex_joni on IRC last night I intend trying a bunch of stuff tonight
with the motors turned off so that I can
On Tue, 29 Sep 2009 22:02:51 +0100, you wrote:
>2009/9/29 Kirk Wallace :
>
>> 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
>
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
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
2009/9/29 Kirk Wallace :
> 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. If the wander settles t
On Tuesday 29 September 2009, Andy Pugh wrote:
>2009/9/29 Dave Caroline :
>> 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 sti
On Tue, 2009-09-29 at 17:43 +0100, Andy Pugh wrote:
> 2009/9/29 Dave Caroline :
> >
> > 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 ma
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 BlackBerry® Developer Conference in SF, CA
is the only developer event
2009/9/29 Dave Caroline :
>
> 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 same problems if it turns out
do you need one of use to make/cut a disk
Dave Caroline (archivist)
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing
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-le
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
**http://tinyurl
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
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
There is atleast one person doing this.. Here is some light reading.
(jlmjvm on #emc)
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Steppers_With_Encoders
http://cnczone.com/forums/showthread.php?t=43517&highlight=encoders
http://cnczone.com/forums/showthread.php?t=37309
This gives good inf
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
Thanks to all who replied for the very good information.
To summarise:
- Adding encoders to steppers can be done, and HAL has all the components
needed. using encoder-PID-freqgen creates basically a "servo system with
steppers". Freqgen has parameters for capping velocity and acceleration.
On Wed, Aug 15, 2007 at 11:40:35AM -0500, RogerN wrote:
> Instead of PID speeding up the stepper, could it be connected to feed
> rate override and slow the feed until the stepper caught up?
emc2 offers "feedhold" and "adaptive-feed" pins in HAL (the latter is
activated by M52, not on by default)
- Original Message -
From: "John Kasunich" <[EMAIL PROTECTED]>
To: "Enhanced Machine Controller (EMC)"
Sent: Wednesday, August 15, 2007 8:59 AM
Subject: Re: [Emc-users] Encoders with steppers
> PID's response to feedback falling behind command is to
> 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-s
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
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
101 - 195 of 195 matches
Mail list logo
