2009/9/29 Jon Elson <el...@pico-systems.com> > Sven Wesley wrote: > > I can cannot see any changes in speed even if I push put all my body > weight > > on the Z-axis, it just runs super easy and the motors never gets warm. It > > doesn't _seem_ to be a force/power problem. > > I have put so much money and time in building a servo system. It's REALLY > > annoying if I have to go back to steppers. To me, these eBay-items looks > > pretty small too. Are they really going to make it? > > > I am now CONVINCED that your problem is a step timing issue, possibly a > step-vs-direction > setup time issue. I am also sure the Rutex has some kind of a fault > output, but you may not be using it. > I remember the fault window is programmable, as opposed to Gecko's fixed > limit. > > If you were to put stepper motors and a stepper drive on the machine, > you might well have > the exact same problem - many people have. The timing of the > step/direction pulses MUST > meet what the manufacturer needs. If the manufacturer's specs are > non-existant or just wrong, > that makes fixing this much harder. > > The basic problem is either the drive fails to detect some of the step > pulses, often just after a direction change, > or counts a step pulse in the wrong direction. Gecko once had a problem > with the pulse multiplier in their > Gecko 210 (stepper) and 340 (servo) where if the direction changed while > the multiplier was still putting out > multiplied pulses, those steps would go in the wrong direction. It led > to errors in fractions of the commanded > steps. The fix was to either remove the pulse multiplier or make sure > the software didn't generate a step pulse > for some specific time after a direction change. That's just one > possible way such a problem could happen. > > Unless somebody knows the specific settings for your drives, you may > need to systematically explore the > range of settings and motion to see if you can identify which adjustment > affects the problem. And, if you find a setting that > makes it WORSE, that may be an important clue to what the underlying > problem is. > > You can make a chain of short moves in the same direction, with a pause > between each move, and see if there > is no error. Then, make moves back and forth, with delay between each > move - again, check for error. > Then, move back and forth with NO delay between moves. Does this make > the error worse? If you see it is > worse with back and forth moves with no delay than either of the other > movements, that is a BIG clue it > has something to do with step timing vs the direction signal. > > Jon > > The only thing I've got about the settings is "you should be safe with 2us in step" and in the same reply the I got to learn that the direction settings were unknown but low values are known to work. I've tried step time/space between 1500 and 15 000 and direction hold/setup to as high values as 200 000 but it doesn't make any difference.
I can try to run the machine in the same direction stepwise (instead of changing direction), lets say 10 mm steps, to see if there's any difference. Gene, I have tried to run a test program with 10 % feed and it looses position anyway. If the amount of lost position is the same I didn't check. I can do that as well. A guy is going to send me a couple of other drivers and a another servo. Then I can change one at a time to see what happens. Right know these are the suggestions were it can be wrong: 1. Bad signal. Two different computers have been tested with the same result though. 2. Wrong setup in step timing. Much likely, I'm not the only one who experienced tuning problems with these. 3. Encoder problem. Not really tested. Only changed to the same type of encoder. 4. Small servo's. Well, they may be small and think I'll change them, but there are lost steps even at low feeds. 5. The drivers have an error. Have no idea, I don't get the feedback. New drivers are on the way to test. 6. Servo/Driver combination doesn't work. Maybe, as I wrote, new stuff on the way. ------------------------------------------------------------------------------ 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 skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
