The rotor current controls the strength of the magnetic field of the rotor. This will vary the torque, but maximum torque is still determined by magnetic saturation and by the amount of current in the field. The rate of change of the field current and thus the torque at speed is limited by the inductance of the field winding. This is what limits the torque at speed of stepper motors and varying the rotor current will not correct this limitation.
It is a cruel world. Torque is related to amperes of coil current times the number of turns, while inductance is also related to the number of turns and fights the rate of change in the current that is needed to generate the torque at speed. don't shoot the messenger... Steve Stallings > -----Original Message----- > From: Stuart Stevenson [mailto:stus...@gmail.com] > Sent: Monday, January 05, 2009 10:06 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] Steppers with Encoders > > Gentlemen, > I have seen (youtube) the conversion of an automotive > alternator to a stepper motor. The fields are pulsed and no > motion occurs until the rotor has dc voltage applied. Would > it be possible to use this type of stepper to overcome some > of the speed and torque limitations of a PM stepper? Could > you reduce the voltage at faster speeds and get better > performance. Maybe you could size it so more voltage to the > rotor could give more torque during the cut? > Just thoughts of someone who knows NOTHING about stepper > motors. :) Just more smoke. > thanks > Stuart > > On Mon, Jan 5, 2009 at 8:24 PM, Greg Bentzinger > <skullwo...@yahoo.com> wrote: > > and a voice spoke out from the one lurking in the shadows. > > > > I may be just blowing smoke here - but there might be a functional > > compromise. > > > > I honestly have not been under the hood of EMC (interp or trajectory > > planner) so I don't know if what I'm proposing is even > possible with > > the existing code structure. > > > > A steppers weakest point is at its peak velocity, or maybe > depending > > on the accell settings the beginning of decell/breaking > from peak vel. > > So basically Rapid G00 moves are the Achilles heal. > > > > I am not proposing using an encoder for coordinated > movement feedback > > like a servo would require, that would still be handled by counting > > the stepgen output. What I propose would be having an aux input for > > the encoders and a separate DRO display on the GUI like > XA/YA/ZA. With > > the proper ini file setting an "in position check" could be > done (with > > a acceptable tolerance factor) after each G00 or fixed > cycle position > > move. If an out of tolerance position is detected an alarm > could occur > > (the easy way) or a correction move could be applied (much more > > difficult). Normally if a G00 is issued the tool is free of > the work > > so applying a correction should be as safe, if the tool failed to > > clear the work, then the damage was all ready done. > > > > I'm guessing this would be very resource intensive. So a > alternative > > might be to use a non-modal user defined M or G code to > compare and/or > > reset position. This option would be handy for people using > Step/dir > > servo drives where they are unable to adjust the in-drive following > > error such as Gecko 320/340 drives. Geckos allow 128 count error > > before tripping a servo fault. > > > > This won't help a machine fighting mid-band resonance, or one > > overloaded in a cut. That is a hardware/software issue where the > > builder needs to know the weakness and limits of the > machine. However > > these comparisons if logged could help the builder tweak > accel & max > > vel settings to an acceptable range that will run error > free 95+% of > > the time. > > > > I could see how a machine which ran great all summer start losing > > steps in a cold garage in January, Vactra #2 (Way oil) can get like > > honey due to age and very cold temps. > > > > Greg Bentzinger > > > > > ---------------------------------------------------------------------- > > -------- _______________________________________________ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > -------------------------------------------------------------- > ---------------- > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
