On Saturday 19 March 2016 12:52:55 Chris Albertson wrote: > On Fri, Mar 18, 2016 at 11:46 AM, Nicklas Karlsson < > > nicklas.karlsso...@gmail.com> wrote: > > I am planning to use a micro controller for stepper step pulse > > generation. I have considered to use an inverter card but special > > purpose stepper circuits are cheap so I use one of these instead. It > > should be possible to feed timer values then toggle should happen > > via DMA timer output compare values. > > > > Can anyone suggest how an ideal step generation curve should look? > > Constant acceleration up to top speed? Constant deceleration from > > top speed to zero? Or just stop generating pulses? > > So you are NOT using LinuxCNC. You are planning to roll your own? > > I've done this a few times. My purpose for using CNC is robotics and > these robots use motors of various type and move not unlike CNC > machines. All of these motors I always control using some > microprocessor. (ARM or AVR) > > Generally the pulse rate generator is at the lowest "layer" of > abstraction in your software and gets requests from some high layers > to do things like move at some rate to some location. Your software > has to try to do what it is requested but subject to physical > properties of the motor and mechanical system. You have to program > this in. Likely maximum acceleration is a function of current speed. > Likely the range of position is limited and so on. Some requests > might have speed or acceleration limits embedded in them > > After this there is one more important thing that really is done my > some layer above the pulse generator and that is planning. Say you > are going to make a U-turn (reverse a motor direction) you might need > to slow down before. This is called "planning" and it's always hard > and with robots who work in a changing environment maybe not possible. > But if you are interpreting G-Code you can always just read ahead. > > Ok there is one case where the pulse generator CAN and should do some > planning. If it gets a request to "move to location X" it should > accelerate to maximum speed, move for some time then DECELERATE and > stop at "X" using other max > > There are some cases where the pulse generator MUST work with more > then one motor at the same time. What if the request is to "move in a > circle" or if doing threading on a lathe to move the spindle and > leadscrew in "lock-step". In my case I want to move a > caterpillar-tread robot along an arc of given radios so that it passes > through the center of a doorway. The limiting factor is the > performance of the "outside" tread motor. In general what running > multiple motors one of then will hit a performance limit first and the > others need to have their accelerations limited. > > The easiest thing for you to do is use software that others have > written and get it to work some how on the platform your choose (An > ARM based SBC like the beagle bored or "Pi") For CNC work LinucCNC > already does what you need and for robotics look up "ROS". Both of > these can run on a computer the size of a credit card. > > > > Now getting to your specific question of wetter to use constant > acceleration (linearly increasing speed) or some kind of curve. The > above should have answered this. The pulse generator will try for > maximum performance which is constant acceleration but may run into > physical limitation of the motor and mechanics where available torque > is a function of speed and this will cause acceleration if tapper off.
But the stepper generator itself does NOT know when this limit is encountered, so the acceleration tapers off alright, to a loss of synchronization stop, usually in less than another 90 degrees of rotation, determined by its mass and the load pushing it. AKA a stall. Lost part, broken tool, what have you mayhem follows. The only way for the software to know the motor has lost synch, is with an encoder on the motor with a resolution equal to or better than the microstepping in use. Unless and until the drivers develop a method to detect that, AND return a FAIL signal to our software, we are stuck with that situation. Servo systems can do this quite well simply by watching the PID.error output. But steppers, which normally have no such feedback path, are crippled in that reporting, so you have the stalls and broken tooling and wrecked parts that go with pushing a stepper out of its comfort zone. > On the other hand if the request has an embedded limit you may not > het mechanical limitations and you can actually do constant > acceleration up to the commanded speed. Which is what we do. But violated accel limits seem easy to detect. Run the x table at full speed to the limit which should be 50 thou or so away from the hard limit. This because of the unbalance weight of the table hanging out out, adds to the way friction quite a bit if it hasn't been oiled in the last 10 minutes. Then try to move it back the other way from that stopped position. If it moves a bit but then stalls, your accel settings are too fast, reduce them by 50% & try it again. If that works, then add 10% to the MAXVEL and try again. When the stall returns, reduce the MAXVEL by 25%, and you should be ok as long as the lube is reasonably fresh. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
