From: Ian W. <wat...@fa...> - 2008-01-19 21:50:44
|
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 motor power wires are separate). Looking inside there appears to probably be 3 photo sensing elements and a clear plastic encoder disk with, I think, 100 prismatic lumps on it and so I assume that the 6 wires must somehow represent a quadrature encoder with index mark???? - or maybe a quadrature encoder with two power connections - I don't know. Has anyone come across this type of motor and worked out the connections or is there some way I could work it out for myself?? thanks. -- Best wishes, Ian ____________ Ian W. Wright Sheffield UK "The difference between theory and practice is much smaller in theory than in practice..." |
From: Andy P. <an...@an...> - 2009-10-05 23:27:04
|
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 before, and totally consistent after. As far as I am concerned it is a success, though I have not tried to cut metal yet after blowing up two of my drivers and demagnetising a motor last week. -- atp -- atp |
From: Robert P. <rob...@co...> - 2011-12-13 00:34:52
|
Where do you guys buy yours? Looking for affordable, quality units. Need .25" hollow shaft quadrature encoder, 2000ppr with L-D output. Anyone know a good source? Rob |
From: Jon E. <el...@pi...> - 2011-12-13 02:38:29
|
Robert Pabon wrote: > Where do you guys buy yours? Looking for affordable, quality units. Need .25" hollow shaft quadrature encoder, 2000ppr with L-D output. Anyone know a good source Avago, US Digital and Renco come to mind. By hollow-shaft, do you mean "kit" encoders? Real hollow-shaft encoders with bearings are quite expensive, BEI and Danaher come to mind. The Kit encoders have a free-floating wheel that is supported by a shaft on the motor or machine, and have no bearings. They are much cheaper due to this. You can search on Digi-Key, Mouser and Avnet. Renco has been bought out by Heidenhain, but they are still available. Watch out for the CUI AMT-10x encoders at Digi-Key, they have a lag responding to acceleration, and may not be well-suited to CNC systems such as EMC2. Jon |
From: Tom E. <to...@bg...> - 2011-12-13 04:53:48
|
On Dec 12, 2011, at 9:38 PM, Jon Elson wrote: > Watch out for the CUI AMT-10x encoders at Digi-Key, they have a lag > responding to acceleration, and > may not be well-suited to CNC systems such as EMC2. Jon, We are using these encoders on a gantry machine and are currently trying to debug a small spike (0.001) of error we see on start and stop of the motor. I wonder if this is related to the lag you refer to. How and why does this present itself in these encoders? How would be see it? Thanks, Tom |
From: Jon E. <el...@pi...> - 2011-12-13 05:21:52
|
Tom Easterday wrote: > On Dec 12, 2011, at 9:38 PM, Jon Elson wrote: > >> Watch out for the CUI AMT-10x encoders at Digi-Key, they have a lag >> responding to acceleration, and >> may not be well-suited to CNC systems such as EMC2. >> > > Jon, > We are using these encoders on a gantry machine and are currently trying to debug a small spike (0.001) of error we see on start and stop of the motor. I wonder if this is related to the lag you refer to. How and why does this present itself in these encoders? How would be see it? > Yes, that is EXACTLY the kind of problem I saw. This encoder is highly interpolated, so it has a tracking counter that is incremented or decremented by an estimate of the current velocity. If you don't do these computations correctly, there is a lag in responding to changes in velocity. As far as I can tell, the interpolator in such devices as the Analog Devices AD2S1200 has a really fine 2nd or 3rd order filter to make this work well. Obviously, CUI did not go to the trouble of such mathematics. After never being happy with these encoders and having a bit of customer feedback, I decided to compare to a standard HP optical encoder (with no interpolation.) So, I put the optical encoder on the other end of the motor, and fed both to encoder inputs on my PWM controller board. Most useful was to plot velocity derived from both encoders at the same time. This comes up often enough, I have the plots permanently on my web site. See http://pico-systems.com/images/compare_encoder2.png The red trace is the CUI encoder, which was controlling the motor (badly). The white trace is the HP encoder. Both are providing 4000 counts/rev. You can clearly see the velocity peaks of the CUI encoder are higher, and if you look closely at the slopes, you can see the CUI is slow to react to velocity changes, and then has to overshoot significantly so the position can catch up. This of course accounts for the bad servo behavior. As the Halscope is set for 20 ms/div, the velocity lag is easily 3-5 ms in duration! If you have a plain optical encoder handy, you could easily set up the same arrangement to compare the encoders. Jon |
From: Tom E. <to...@bg...> - 2011-12-13 16:45:53
|
Thanks for the info Jon. We are seeing a small (about 0.001) position error just on initial acceleration and deceleration that we cannot account for. It may be due to the encoder. Since this is mainly a plasma machine we will probably live with it. If we need to do better we'll look at replacing the encoders. We now know the string attached to our cheap encoder :-) -Tom On Dec 13, 2011, at 12:21 AM, Jon Elson wrote: > Yes, that is EXACTLY the kind of problem I saw. This encoder is highly > interpolated, so > it has a tracking counter that is incremented or decremented by an > estimate of the current > velocity. If you don't do these computations correctly, there is a lag > in responding to > changes in velocity. As far as I can tell, the interpolator in such > devices as the Analog > Devices AD2S1200 has a really fine 2nd or 3rd order filter to make this > work well. > Obviously, CUI did not go to the trouble of such mathematics. > > After never being happy with these encoders and having a bit of customer > feedback, > I decided to compare to a standard HP optical encoder (with no > interpolation.) > So, I put the optical encoder on the other end of the motor, and fed > both to encoder > inputs on my PWM controller board. Most useful was to plot velocity > derived from > both encoders at the same time. This comes up often enough, I have the > plots > permanently on my web site. See > http://pico-systems.com/images/compare_encoder2.png > > The red trace is the CUI encoder, which was controlling the motor > (badly). The white > trace is the HP encoder. Both are providing 4000 counts/rev. You can > clearly see > the velocity peaks of the CUI encoder are higher, and if you look > closely at the > slopes, you can see the CUI is slow to react to velocity changes, and > then has to > overshoot significantly so the position can catch up. This of course > accounts for > the bad servo behavior. As the Halscope is set for 20 ms/div, the > velocity lag > is easily 3-5 ms in duration! > > If you have a plain optical encoder handy, you could easily set up the same > arrangement to compare the encoders. > > Jon |
From: Jon E. <el...@pi...> - 2011-12-13 18:09:18
|
Tom Easterday wrote: > Thanks for the info Jon. We are seeing a small (about 0.001) position error just on initial acceleration and deceleration that we cannot account for. It may be due to the encoder. Since this is mainly a plasma machine we will probably live with it. If we need to do better we'll look at replacing the encoders. We now know the string attached to our cheap encoder If you can send me a picture form Halscope, I can compare it to what I get. Are you using FF2? This can be quite helpful in fixing errors on acceleration. You have to use it in VERY small amounts, though, like .005 or even less. It is easy to add too MUCH FF2 and cause jerks in the response. Also, there is a manufacturing issue in these, where the encoder ring may fit loosely on the splined hub that mounts to the shaft. On some units you need to put a little dab of RTV, super glue or whatever on the splined hub to lock the ring to it. You can poke the ring with an X-acto knife to see if there is any play between it and the hub when the whole thing is assembled. Jon |
From: Tom E. <to...@bg...> - 2011-12-13 18:20:40
|
On Dec 13, 2011, at 1:09 PM, Jon Elson wrote: > If you can send me a picture form Halscope, I can compare it to what I > get. Are you using FF2? > This can be quite helpful in fixing errors on acceleration. You have to > use it in VERY small > amounts, though, like .005 or even less. It is easy to add too MUCH FF2 > and cause jerks > in the response. Yes, see post in response to Peter Wallace. > Also, there is a manufacturing issue in these, where > the encoder ring may > fit loosely on the splined hub that mounts to the shaft. On some units > you need to put a > little dab of RTV, super glue or whatever on the splined hub to lock the > ring to it. You > can poke the ring with an X-acto knife to see if there is any play > between it and the hub > when the whole thing is assembled. Mariss from Gecko suggested this to me early on, so we super glued the collars to the shafts. This did indeed help a little, one of them was slipping badly, the others perhaps a small amount. He also suggested adding a tiny bit of silicone caulk to one of the cogs in the gear to take up any slop in the fit (both pieces are plastic after all). I did that as well, but I don't think there was much slop to begin with so that provided no noticeable improvement. -Tom |
From: Peter C. W. <pc...@me...> - 2011-12-13 18:43:13
|
On Tue, 13 Dec 2011, Tom Easterday wrote: > Date: Tue, 13 Dec 2011 13:20:28 -0500 > From: Tom Easterday <to...@bg...> > Reply-To: "Enhanced Machine Controller (EMC)" > <emc...@li...> > To: "Enhanced Machine Controller (EMC)" <emc...@li...> > Subject: Re: [Emc-users] Encoders > Theres a FAQ fom AMT that mentions a jumper on the card that can be removed to approximately 1/2 the filter time constant (at the expense of more noise) Might be worth a try www.amtencoder.com/Resources/Frequently-Asked-Questions Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. |
From: Jon E. <el...@pi...> - 2011-12-14 04:04:03
|
Peter C. Wallace wrote: > Theres a FAQ fom AMT that mentions a jumper on the card that can be removed > to approximately 1/2 the filter time constant (at the expense of more noise) > And, that is real hard to do once the hub has been glued! Oops! Jon |
From: Tom E. <to...@bg...> - 2011-12-14 14:53:56
|
On Dec 13, 2011, at 11:03 PM, Jon Elson wrote: > Peter C. Wallace wrote: >> Theres a FAQ fom AMT that mentions a jumper on the card that can be removed >> to approximately 1/2 the filter time constant (at the expense of more noise) >> > And, that is real hard to do once the hub has been glued! Oops! Even with the hub glued to the shaft, the encoder still pops out, so you can remove the jumper. We did that yesterday but if it helped it was not obvious. -Tom |
From: Tom E. <to...@bg...> - 2011-12-13 20:17:09
|
On Dec 13, 2011, at 1:09 PM, Jon Elson wrote: > If you can send me a picture form Halscope, I can compare it to what I > get. See: http://bgp.nu/~tom/pub/XPosErr-VelCmd.png These are versions without the velocity command at 250ipm and ~1500ipm: http://bgp.nu/~tom/pub/XPosError-250ipm.png http://bgp.nu/~tom/pub/XPosError-Rpaid.png -Tom |
From: Jon E. <el...@pi...> - 2011-12-14 04:07:22
|
Tom Easterday wrote: > On Dec 13, 2011, at 1:09 PM, Jon Elson wrote: > >> If you can send me a picture form Halscope, I can compare it to what I >> get. >> > > See: > http://bgp.nu/~tom/pub/XPosErr-VelCmd.png > Doesn't look that bad. I'm a little surprised the FF2 can't make it better. But, then these systems with multiple smart controllers can be quite hard to tune. Jon |
From: Jon E. <el...@pi...> - 2011-12-14 04:08:25
|
Tom Easterday wrote: > > These are versions without the velocity command at 250ipm and ~1500ipm Oh, at 1500 IPM, maybe you need to turn up the servo thread to faster than 1 ms, or have you tried that already? Jon |
From: Tom E. <to...@bg...> - 2011-12-14 14:51:56
|
On Dec 13, 2011, at 11:08 PM, Jon Elson wrote: > Tom Easterday wrote: >> >> These are versions without the velocity command at 250ipm and ~1500ipm > Oh, at 1500 IPM, maybe you need to turn up the servo thread to faster > than 1 ms, or > have you tried that already? We did try that. But, I am only able to turn it to down to about 600,000. Below that I get realtime errors on the system for some reason (that I don't understand). At 600,000 it didn't seem to help. -Tom |
From: Viesturs L. <vie...@gm...> - 2011-12-13 07:25:54
|
2011/12/13 Jon Elson <el...@pi...>: > > Watch out for the CUI AMT-10x encoders at Digi-Key, they have a lag > responding to acceleration, and > may not be well-suited to CNC systems such as EMC2. Thanks for the warning, Jon! I happen to have bought these encoders for one of the machines... Do I understand correctly that they are working fine, but I will need to decrease max acceleration to get better performance of the encoder? Viesturs |
From: Jon E. <el...@pi...> - 2011-12-13 18:03:11
|
Viesturs Lācis wrote: > 2011/12/13 Jon Elson <el...@pi...>: > >> Watch out for the CUI AMT-10x encoders at Digi-Key, they have a lag >> responding to acceleration, and >> may not be well-suited to CNC systems such as EMC2. >> > > Thanks for the warning, Jon! > I happen to have bought these encoders for one of the machines... > Do I understand correctly that they are working fine, but I will need > to decrease max acceleration to get better performance of the encoder? > The problem is there is a lag between acceleration and the encoder responding to it. If your servo loop can be tuned for good performance, you are lucky. The more massive the load, the better, I guess. The worst case is a low-inertia motor sitting on the bench. But, if you cannot get the loop response tuned properly, then there really is nothing you can do to fix that. The problem is that when velocity changes, the encoder does not correctly report position. It reports what the position WOULD have been if there had not been an acceleration. Decreasing max accel will help prevent exciting any unstable response from G-code, but external forces acting on the system cannot be controlled that way, and may excite instability. In other words, reducing accel masks the problem, instead of solving it. Reducing gain will help, but can make the servo response less accurate. Jon |
From: Tom E. <to...@bg...> - 2011-12-13 18:15:01
|
On Dec 13, 2011, at 1:02 PM, Jon Elson wrote: > The more massive the load, the better, I guess. The worst case is a low-inertia motor sitting on the bench. Yes, this is an important point - that we have learned the hard way. We were about to throw in the towel trying to tune our machine. We have some fairly torquey (I can't believe that is actually a word:-) ) motors given the mass of the machine. We finally got a little education on servos and ended up changing our gearing from 2:1 to 5:1 (and using an initial 10:1 gearbox attached to the motor). This made ALL the difference in the world. The machine runs smooth as silk now as there is a constant load on the motor to overcome the 10:1 gearing. Tom |
From: Peter C. W. <pc...@me...> - 2011-12-13 17:58:28
|
On Tue, 13 Dec 2011, Tom Easterday wrote: > Date: Tue, 13 Dec 2011 11:45:41 -0500 > From: Tom Easterday <to...@bg...> > Reply-To: "Enhanced Machine Controller (EMC)" > <emc...@li...> > To: "Enhanced Machine Controller (EMC)" <emc...@li...> > Subject: Re: [Emc-users] Encoders > > Thanks for the info Jon. We are seeing a small (about 0.001) position error > just on initial acceleration and deceleration that we cannot account for. > It may be due to the encoder. Since this is mainly a plasma machine we will > probably live with it. If we need to do better we'll look at replacing the > encoders. We now know the string attached to our cheap encoder :-) -Tom > Have you tried using FF2 to tune out the lag/lead during accel/decel? (a jerk limited profile would also help) Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. |
From: Tom E. <to...@bg...> - 2011-12-13 18:06:43
|
On Dec 13, 2011, at 12:52 PM, Peter C. Wallace wrote: > On Tue, 13 Dec 2011, Tom Easterday wrote: > >> Date: Tue, 13 Dec 2011 11:45:41 -0500 >> From: Tom Easterday <to...@bg...> >> Reply-To: "Enhanced Machine Controller (EMC)" >> <emc...@li...> >> To: "Enhanced Machine Controller (EMC)" <emc...@li...> >> Subject: Re: [Emc-users] Encoders >> >> Thanks for the info Jon. We are seeing a small (about 0.001) position error >> just on initial acceleration and deceleration that we cannot account for. >> It may be due to the encoder. Since this is mainly a plasma machine we will >> probably live with it. If we need to do better we'll look at replacing the >> encoders. We now know the string attached to our cheap encoder :-) -Tom >> > > > Have you tried using FF2 to tune out the lag/lead during accel/decel? > Yes. Peter (working with me) spent a long time playing with FF2. We were seeing large spikes at first and had FF2 set to 0.007 which helped to lower it to .002-.003. We then realized we had the Granite Devices input filtering (which introduces a delay and is documented as doing so) turned on. Turning that off has allowed us to lower FF2 to 0.000105, not zero but getting there. The remainder of the delay is now (possibly) coming from the encoder issue Jon has pointed out. > (a jerk limited profile would also help) What'd you call me? :-) What is a jerk limited profile? -Tom |
From: Peter C. W. <pc...@me...> - 2011-12-13 18:23:27
|
On Tue, 13 Dec 2011, Tom Easterday wrote: > Date: Tue, 13 Dec 2011 13:06:31 -0500 > From: Tom Easterday <to...@bg...> > Reply-To: "Enhanced Machine Controller (EMC)" > <emc...@li...> > To: "Enhanced Machine Controller (EMC)" <emc...@li...> > Subject: Re: [Emc-users] Encoders > > On Dec 13, 2011, at 12:52 PM, Peter C. Wallace wrote: >> On Tue, 13 Dec 2011, Tom Easterday wrote: >> >>> Date: Tue, 13 Dec 2011 11:45:41 -0500 >>> From: Tom Easterday <to...@bg...> >>> Reply-To: "Enhanced Machine Controller (EMC)" >>> <emc...@li...> >>> To: "Enhanced Machine Controller (EMC)" <emc...@li...> >>> Subject: Re: [Emc-users] Encoders >>> >>> Thanks for the info Jon. We are seeing a small (about 0.001) position error >>> just on initial acceleration and deceleration that we cannot account for. >>> It may be due to the encoder. Since this is mainly a plasma machine we will >>> probably live with it. If we need to do better we'll look at replacing the >>> encoders. We now know the string attached to our cheap encoder :-) -Tom >>> >> >> >> Have you tried using FF2 to tune out the lag/lead during accel/decel? >> > > Yes. Peter (working with me) spent a long time playing with FF2. We were seeing large spikes at first and had FF2 set to 0.007 which helped to lower it to .002-.003. We then realized we had the Granite Devices input filtering (which introduces a delay and is documented as doing so) turned on. Turning that off has allowed us to lower FF2 to 0.000105, not zero but getting there. The remainder of the delay is now (possibly) coming from the encoder issue Jon has pointed out. > >> (a jerk limited profile would also help) > > What'd you call me? :-) > > What is a jerk limited profile? A cubic profile Currently EMC uses a trapezoidal (linear) velocity profile (so parabolic position profile) This means the acceleration profile is a step function. The beginning of this step is whats hard to tune around (as you have found) Jerk is the derivative of acceleration so is infinite with stepped acceleration (the current situation with EMC). By using a cubic profile where the acceleration is ramped (like velocity is now) starts and stops are much "gentler" and contain less high frequency components that make it hard to tune > > -Tom > > > ------------------------------------------------------------------------------ > Systems Optimization Self Assessment > Improve efficiency and utilization of IT resources. Drive out cost and > improve service delivery. Take 5 minutes to use this Systems Optimization > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ > _______________________________________________ > Emc-users mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-users > Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. |
From: Tom E. <to...@bg...> - 2011-12-13 18:44:09
|
On Dec 13, 2011, at 1:17 PM, Peter C. Wallace wrote: > A cubic profile > > Currently EMC uses a trapezoidal (linear) velocity profile (so parabolic > position profile) This means the acceleration profile is a step function. The > beginning of this step is whats hard to tune around (as you have found) > > Jerk is the derivative of acceleration so is infinite with stepped > acceleration (the current situation with EMC). By using a cubic profile where > the acceleration is ramped (like velocity is now) starts and stops are much > "gentler" and contain less high frequency components that make it hard to tune Thanks Peter. And how/where does one set this as the velocity profile? Tom |
From: Peter C. W. <pc...@me...> - 2011-12-13 18:48:58
|
On Tue, 13 Dec 2011, Tom Easterday wrote: > Date: Tue, 13 Dec 2011 13:44:01 -0500 > From: Tom Easterday <to...@bg...> > Reply-To: "Enhanced Machine Controller (EMC)" > <emc...@li...> > To: "Enhanced Machine Controller (EMC)" <emc...@li...> > Subject: Re: [Emc-users] Encoders > > > On Dec 13, 2011, at 1:17 PM, Peter C. Wallace wrote: >> A cubic profile >> >> Currently EMC uses a trapezoidal (linear) velocity profile (so parabolic >> position profile) This means the acceleration profile is a step function. The >> beginning of this step is whats hard to tune around (as you have found) >> >> Jerk is the derivative of acceleration so is infinite with stepped >> acceleration (the current situation with EMC). By using a cubic profile where >> the acceleration is ramped (like velocity is now) starts and stops are much >> "gentler" and contain less high frequency components that make it hard to tune > > > Thanks Peter. And how/where does one set this as the velocity profile? > Tom Apply ~0.5 man year to Trajectory Planner > ------------------------------------------------------------------------------ > Systems Optimization Self Assessment > Improve efficiency and utilization of IT resources. Drive out cost and > improve service delivery. Take 5 minutes to use this Systems Optimization > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ > _______________________________________________ > Emc-users mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-users > Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. |
From: andy p. <bod...@gm...> - 2011-12-13 18:50:49
|
On 13 December 2011 18:44, Tom Easterday <to...@bg...> wrote: > Thanks Peter. And how/where does one set this as the velocity profile? It isn't currently an option with EMC2. Though I think at least some work has been done around adding it. -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. |