Yes, most other offerings out there are PC based using either the parallel port for the interface or some other intermediate device providing the real-time signals for the interface. This is a bit easier than trying to do everything on micros. As you know, micros are no where near as fast as micoprocessors which run MUCH faster and perform floating point math efficiently.
Currently I am running bresenham, but the previous attempt was to use one cog per axis so I had enough time to handle all the calcs. The problem with that is coordinating the cogs for precisely synchronized motion - never got that as good as I wanted.
My next direction is being figured out right now. I know I will put all of the step & direction outputs into one cog to help insure accurate synchronization. I have a few other ideas I have to work out but these require lot's of time to think through. Having just started a new job, my "think time" is not as clear as I would like, but that is life.
The other thing that just came up that could help a lot is that FP32 object someone posted. That appears to be very efficient which could help me out substantially if I can figure out how to exploit its power.
Is Floating point an issue? I "think" I have a way around it by using counters. It worked for me about 10years ago on an AVR Mega32 I can's see why it wouldn't work here.
Sorry, I can't read 'C' very well (or at all for that matter). I suspect that the FP32 object that was posted should be fast enough to do what I need and seeing as I have 1 COG to spare, it should do the trick.
I will have to post in that thread some questions about it though so that I understand it better.
to apply accelleartion and decelleration I coded it this way:
through acc the time to wait until the next pulse has to be created
gets shorter from step to step.
It starts at a frequency the steppermotor can handle from 0 rpm and stops
at a max frequency.
With deccelartion it is simply the opposite way. The waittime from pulse to pulse gets longer down to the frequency the steppermotor can handle to
go from low-freq to 0 Hz within ONE step.
The waittime-values for acc and dec are stored in an array of 100 eelements.
Let's use easy values for explaining it:
waittime(0) = 10 msec
waittime(1) = 9 msecs
waittime(2) = 8 msecs
etc. etc
Now my my stepout-methods divides the complete way into three parts
1.) acc
2.) hold on max speed
3.) decc
(if the complete amout of steps is lower than 200 example 120 steps you go up acc for 60 steps and down for 60 steps)
the loop that creates the pulses has a waitcommand to create the applied frequency.
Inside the loop a counter counts up the steps and this step-variable is used as index for the waittime-array
with the example-values from above:
first loop
variable step has value 0
wait(waittime(step)) which means waittime(waittime(0)) = wait(10msecs)
second loop step has value 1
wait(waittime(step)) which means waittime(waittime(1)) = wait(9msecs)
third loop step has value 2
wait(waittime(step)) which means waittime(waittime(2)) = wait(8msecs)
etc. etc.
The complete amount of steps is divided by 2 to get the two halfs
first half for acc and hold max-speed
and second half for max-speed and decc
the loop contains a condition
if step > maxWaittime
wait(waittime(maxwaittime)) which means wait(waittime(100) which is the max-speed
else
wait(waittime(step))
and you are done about acc and decc always automatically in the right amount of steps.
Of course creating an array in PASM is a bit more difficult than in spin
but not that much more difficult.
Thanks for the explanation. I too have tried that method in an earlier attempt and found there are two problems...
1) You are adjusting the velocity by changing the wait time between steps. This results in an ever increasing ramp up to speed. It is actually a curve that is not going the good way. The method you describe will work when you are well within the limits of the mechanicals.
However, if you are pushing towards the limits, the chance the stepper motor stalls out increases dramatically. Ideally for steppers, you want an S curve ACC & DEC but this is much more difficult to program than a trapzoidal ACC & DEC. In the example you described, you have neither. Acceleration and Deceleration has to be time based and not based on position. Time is the constant, 10 mSecs is alway 10 mSecs so acceleration that is applied in timed intervals becomes a constant increase (stright line ramp up/down). However, your time between steps keeps getting shorter with each step and if you keep subtracting time from each step it is like a runaway snowball growing exponentially. Again, I must clarify, what you describe will work, it is not as ideal as I would like.
2) You motion planner method seems to indicate that every move will start from zero speeed, accelerate up to run speed, then decelerate back to zero speed. This is okay for point-to-point positioning, but in practice, it is not good for CNC machining in metals. This start-stop motion causes tool chatter at the vertices between movements. CNC machines have a much more fluid motion, wherein the next moves starts before the current moves is completed. Yes, it causes corner rounding which is acceptable in many contouring cases. When it is not acceptable, you would use the CNC feature called exact stop check (G09 or G61) to cause "stops" at every vertice.
Your thinking about breaking up the motion into 3 phases is spot on though. The process I am developing right now is doing that too. In all my previous attempts, I command the motion as a "whole unit" and allowed ACC and DEC to occur dynamically, thus breaking the motion down into the 3 phases. This method works pretty good but it can easily get out of control. So on my latest attempt, I am breaking the motion into the 3 phases in the planner before I run the motion. I suspect this will allow me to synchronize the 4 axes better than previous attempts. The down side is I won't know for a month or two as I just do not have the time to keep working on it.
I must say, this thread is getting very interesting and indepth. I sure hope anyone that is thinking about creating a CNC control is giving this a read.
I must admit that your knowledge about CNC is a lot greater than mine.
My experience is based on diamond engraving. As you have mentioned it now
it is really obvious to me that complete stops are causing more problems with tools that are turning around an axle than with a still standing diamond peak.
Anyway I agree the thread becomes more and more interesting.
Interesting challenge to code a motion-planner that smoothens the direction changes. I have an idea how edge-rounding can be avoided for a part of all possible movings. If the motion-planner adds a "mill out of material" movement
and start a "mill into material again" movement this will avoid bad (and
chattering) forward to turning speed ratios. Of course for the cost of more
time it needs to move the additional way.
So a good motion-planner would have to take care of each next movement
and do the calculation of acc / dec based on the angle-difference between
the actual direction and the next direction.
Small angle only a few decceleration and acc after changing the direction.
Big angle more decceleration and acc after changing the direction.
how much acc/dec is needed depending on the angle would be evaluated through tests in real metal.
Or as second best in the air to have the inertia of the machine itself.
Maybe this is even better because cutting metal is always like a brake.
As the propeller offers 8 cogs that can work in parallel I suggest one cog is just creating the pulses based on a set of parameters.
So this cog needs only a little time to load these values and then executes stepping-loops.
Another cog will do all the calculations like amount of steps acc / dec values allowed corner-rounding based on
tool-overlapping from turn to turn etc.
As you want to push the machine to its limits I guess servomotors will pull the limits pretty far beyond what a steppermotor can do. I know a manufacturer of small servomotors and control-units.
The control-unit for one motor for currents up to 6Ampere is around 300 Euro. I don't have prices of the motors. I have worked with these controls.
The have parameters to adjust almost everything you would like to.
The control has a position, speed and acceleration-controller which are working hand in hand or maybe as one above the other. So all in all a PID-control where you can adjust P, I, D and even more parameters
each to his own value to adapt to almost every mechanical situation
like different inertia or "stiffness" of the mechanic to be as fast as possible without making the system swing for and back.
If I remember right you can even adjust the allowed edge-rounding for direction changes. An interesting question is how much motion-planning these servocontrollers can do for TWO or more axis. To find the optimum between maximum-speed and edge-sharpness. They have a serial and a CAN-Bus interface which can be used to reconfigure parameters on the fly.
I'm not a big expert about servo-controls on the market but I guess this is pretty muc
The motion Planner is a very key element in the CNC system. It is what creates a smooth flowing contour which results in efficient machining and reliable operation.
Executing the step & direction output is fairly simple by comparison, create a consistant pulse stream for all the axes based on a common clock source to keep them synchronized.
You concept of overshoot, then come back to the cut would be very difficult to impliment and certainly inefficient. In the case of milling, the tool can be cutting on either side of the programmed path. From our perspective, we can see which side of the path the part is on, from the CNC's perspective it doesn't know. The only way you could perform the overshoot and cut back in is to also use the feature tool radius compensation (G41 or G42) which compensates for the tool's radius and offsets the tool's path. But that then adds another level of complexity to the tool path. The fun part of working with the PROP chips is to figure out ways to get all the tasks done in the required time by dividing up those tasks across multiple cores - a luxury not offered in most other micros.
All in all, creating a CNC control that mimics industrial controls is very challenging. You can certainly get away with a lot of "kludges" if performance isn't being chased, but in the end there is a reason why industrial controls cost so much - a lot of engineering goes into them.
While I like to mess around with steppers, servos are the king in CNC. Probably 99.9% of all industrial CNC machines use servos. I suspect there are good engineering based reasons for this ;-)
I have been thinking a bit about what I am wanting to achieve, and how I am going to achieve it (Thanks to Chris for his experience here). So this morning I thought I would procrastinate a bit (I am supposed to be doing a customers job).
I have hacked the EMC GCodeCompiler a bit so that I can read in a complete gcode file (on Windows) and then output 6 axis positional commands at an interval of 1mSec per reading i.e:
These coordinates are in milimeters (sorry I am an Aussie). Because they have been precompiled, they are taking into account ramping up and down, and constant velocity contouring (I think - I haven't plotted the points yet) arcs etc etc.
I am now thinking that this may be the better way to go - precompile my gcode on the pc - send the info to the prop via ethernet - store on an sd/compact flash card - run, pause, stop, overrides, limits etc etc can easily be monitored by the prop. Pausing/Feed holding will be my only issue, but I don't think it will be to huge of a job to figure out.
If I wasn't so stuborn and bullheaded, I would do it.
Years back I wrote a program that would graphically plot the tool paths for CNC programs. In order to get the performance I wanted, I converted the CNC Code into an intermediate code, then plotted that intermediate code. It was very fast and efficient.
You are right, working out the details to make this run won't be too bad. The only "tricky" thing is that you have to create a variable clock source. This variable clock source is how you handle feedrate override and feed hold. Here is how it will work...
Select a frequency, say 50kHz as your basetime, this would represent 100% feedrate. If you turn up the feedrate override to 200% your basetime is now 100kHz and likewise if you turn it down to 10%, your basetime is 5Khz, and 0% is zero clock output. This is how you control the velocity with the override - simply by changing the time element. For feedhold, you would ramp down the timebase to zero (simulating a deceleration) and then ramp the timebase back up upon cycle restart. The same is true for single-block operation.
Before all that can work, you have to take those small linear movements, determine their "size constant" or "Time constant" and work out a frequency that will create a motion in the correct period of time. I am not sure what EMC is doing in this regard. It could be creating small linear moves that are 10 discrete positions "size constant" or it could be creating small linear moves that are 1 millisecond worth of motion "time constant". I would wager a guess that it is a time constant interval.
That should get you going with some thoughts to consider and I hope it helps.
Chris
Ahhh, I just re-read your post and realized you already determined that it is a time constant data block - that should be a lot easier to work with!
Servomotors can be driven on very fast RPMs and still have a lot of torque.
Servomotors have an encoder that gives a very accurate feedback about
the motorspeed and angleposition of the motor-axle
steppermotors loose torque with increasing rpm
steppermotors DON'T have a feedback about speed and angleposition
Of course you could add an encoder to a steppermotor but then you are
half way to a servomotor with the disadvantage of loosing torque at high rpms.
StefanL38, Thanks for replying. I always thought a stepper was the best 'digital' motor because you could count steps without adding an encoder. In addition, unlike a servo, you could remove power without losing position.
Please tell me what kind of 'rotational' servo I need. I modified a servo by removing the 'notch' and replacing the potentiometer with two equally matched resistors. I controlled speed with PWM. I still need position.
can you please tell details what you want to do "in the end".
Which motor fits your demands best depends highly on what you want to do.
Without this details I could only give a quarter professional overview which
motor has which advantages / disandvantages.
If you tell us what you want to do in the end you open the oportunity that
more solutions can be found and their pro's and cont's can be discussed.
I have experienced as soon as the whole thing is known sometimes
complete different but much better (cheeper, faster, easier) fitting solutions can be found.
As long as your maximal demanded torque stays below what a certain
steppermotor can hold/drive - in all situations -
a steppermotor is a good solution because
you don't need extra effort for encoders to keep track of the position.
I designed and built a programmable slider for my camera. My other hobby is taking 3D lenticular pictures. I used a stepper and it is perfect.
For my next project I may work on a turntable that will turn my TV to face me. I can do it with a stepper but servos are easier to find and they are stronger.
The other reason is that I have motors with quadrature encoders and standard servos that I want to experiment with.
Maby I have to clarify what I mean when talking about servos.
With servo I meant a DC-Motor with an encoder and a servo-control-unit
which realises that the DC-Motor can turn just a 1/100 degree or 3,8 rotations or whatever - by the help of the encoder on the motoraxle.
Do you mean servo in this way? Or do you mean with servo a "model-servo"
these tiny little things used in RC-modelplanes, RC-modelcars etc.?
So for your projects what rotational speeds and accuracy do you need for them?
I don't require anything close to the precision you need for a CNC. The Bresenham algorithm is beyond me. From what I'm seeing I can probably accomplish what I want by learning to program my quadrature encoder.
Stefan answered already but to help add some clarity here is a bit more about why servos are used over steppers...
Servos have an encoder which is used to provide velocity and positional feedback to the drive system. The drive can then use that feedback along with motor current draw to determine what is actually happening during the motion. This creates a relativly closed loop monitoring system. For steppers, you have zero feedback - it is completely blind.
Consider the comparison to a person walking...
You are walking with your eyes closed - how do you know where you are? The only reference in position you have is your estimate that if you take 400 steps you should be 400 steps away from where you started. What if you sumbled and skipped a step, would your destination be accurate at the end of the walk?
During the same walk, you have to arrive exactly 1.252 minutes later. Without velocity feedback you may have slowed down because of the hill you walked up required more effort. The result is you arrive .3 minutes too late.
Continuing this thought, what if the hill you tried to climb up was so steep you didn't have enough power to take the next step? Do you want to keep trying and fail or should you trust the feedback from your legs saying you are about to stall so stop gracefully?
Steppers are wonderful motors and I love playing with them. They are economical, their drives are economical, their interface (via the drives) is very simple, they don't require any maintance, but they are stupid. They only TRY to do what you tell them to do and if they fail in doing it, they won't tell you anything.
So, now let's see how that works out relative to industrial applications and the reality of business....
Your CNC lathe has stepper motors. It is very accurate in testing, you have the machine designed and setup to operate well within the limits of the motors. It has produced many good parts for months / perhaps years. Now you are machining a critical component for a jet engine - a bit tougher material than you normally have machined. Your trustly "blind" machine has done you good in the past so you trust it to faithfully machine this critical part for the jet engine. But, at some point during the machining, some chips bound up on the cutting tool causing the stepper to skip a few steps which caused all the remaining dimensions to be off and the resulting part is out of spec. 18 months later, there is a breaking news story, a plane crashed with 300 people on board, all died. After the NTSB investigation, they found that the cause of the plane crash was a faulty component in the engine.
For another example, you CNC grinder uses steppers. It has been a good machine that faithfully produces accurate parts. Its a big one too, it has 24" diameter wheels that are 4" wide and the spindle runs at 1400 RPM so it is fast! One day after months of a long production run, the grinding wheel attepts to retract away from the part so the part can be changed. However, swarf has built up on the slide and the axis stalls out and stops short of the retract position. The operator changes parts, presses cycle start, and that was the last experience of his life. What caused his untimely death was an exploding grinding wheel. The reason the grinding wheel exploded was the CNC system had no idea the axis never retracted completely - it just assumed it did. Well, with that assumption, the next move command has the grinding wheel moving at full speed towards the part. Being that it was closer than expected, the wheel crashed into the part and exploded with tremendous force.
Feedback systems are critical elements that cannot be underestimated. If you have never worked in manufacturing, the two examples above might seem a bit extreme. However, I can assure you they are certainly well within the bounds of reality.
As mentioned by one of the other posters, the encoder on a servo can be of great precision, many counts per revolution. The highest number of counts i have seen on a rotary axis is 1 million counts per revolution. This allows for very accurate positional feedback. However, in some cases, even servos do not provide for enough feedback to truly close the loop. Even though the enoder provides feedback to the rotary position of the motor, it does not provide you with feedback of the actual slide. All mechanical devices have clearances to allow the moving components to slide or move. This is "Slop" in the mechanical drive system which results in slight miss-positioning - usually < .0002". However, depending on the part being machined .0002" (which is 1/15 the thickness of paper) can be a country mile. So, for very high precision applications, another encoder is added to the feedback loop. This encoder is not rotary, rather it is linear, but it works on the same principle as a rotary encoder. The actual scale portion is made up of glass which is thermally stable and therefore maintains its accuracy well. If you have ever seen a digital caliper, it works on a very similar principle. This type of scale is connected to the machine base/slide and measures the physical movement between the two components providing near-perfect feedback of position.
I hope that the information above sheds some light onto why servos are better than steppers. It actually doesn't have much to do with the units themselves but rather their application in industry and the seriousness of their role in manufacturing products that our lives depend on. The little machines i build at home are for personal use and for fun and learning. They will never be used by anyone other than myself and they certainly won't ever machine critical components. So steppers are the "perfect" choice in this case ;-)
...
Servos have an encoder which is used to provide velocity and positional feedback to the drive system..... For steppers, you have zero feedback - it is completely blind.....
Chris,
thanks for the explanation.
I've heard of steppers using encoder feedback so they don't run blind. Any idea how a stepper+encoder system like that might compare with a servo+encoder? In the case of the stepper+encoder, does the encoder buy you anything besides warning you when the stepper might have skipped some steps?
It has been a number of years since I have done a project for the aircraft industry so I can't say what the current situation is in that regard. However, in nearly every other industry, this is how inspection is performed....
When a company buys a machine to make parts, it starts out with a qualifying run-off. The sample size can be anywhere from a hundred parts to a couple thousand parts. The purpose of the run-off is to determine if the machining process (and machine) are statistically capable of producing consistant parts that mathematically assure a high percentage of the parts are perfect. Over the years, the name for this has changed ( capability study, six sigma, 8 sigma, cpk run-off, capability run-off, etc. etc.) Most of the "common" names for this are localized to the customer but basically it is all the same thing. Anyway, basically what happens is you run the sample quantity, you inspect every parts, record every size, process the data to see if it statistally is acceptable. Two elements are important: consistancy and amount of deviation (size change). If you have a tolerance of .001" on the engineering print, your goal is to use about 1/2 of that during the process (very general rule).
After this qualifying run-off is completed, the machine is put into production. From that point on, not every part is 100% inspected, only perhaps 1 in 5 or 1 in 10 because statistcally the process is "Capable" of producing perfect parts. Therefore in most industries every part is NOT inspected, generally it is the minority.
@ElectricAye...
When a stepper has an encoder it does close the positional and velocity loop, but only if the driver or controller software has the logic for it. Many servo drives monitor that loop and report back to the controller software. Not too many stepper drives (I don't know of any off hand) that allow for encoder feedback. So to close the loop, the encoder is fed back to the control software where the loop is closed. As to how well that data is processed, is up to the control software.
The control software may only check for a "disconect" meaning that there is a difference between where the position should be and where the encoder says it is at. It might also try to correct the problem by adding a few more steps to the pulse stream. But I really don't know what pre-existing drives or controllers do specifically - closed loop stepper systems don't appear to be as "standard" as servo drive systems.
Mariss at geckodrive was working on an "unstallable" stepper, of course that is not really possible but what he did was use the encoder feedback to reduce the feedrate to reduce the error and as we know the stepper torque increases at lower speed. Just like a servo there will come a point when it faults but it was a neat cheap solution to boost performance a little.
That was a neat idea but certainly not for CNC applications. The "adaptive" drive concept would adapt the feedrate to compensate for the additional resistive forces (heavier cutting, heavy load, mechanical binding, etc). However this would be performed at the drive level, not the CNC level. So, lets walk through why this is just as bad as missed steps...
You command a 3 axes motion, all three axes have to start and stop at the exact same time to create a straight vector (line) between the start and end points. If any one of the axes is not moving in synch with the others, your vector is not straight. Because his idea was to put this "Solution" in the drive, it creates a gapping hole in the CNC system. One drive could slow down to accomodate the problem, while the two other drives continue at the commanded velocity. How is this any different than missed steps? In a CNC application, the part would already be scrapped.
Now, is this a neat idea or concept for conventional automation type projects? In many cases yes. In general motion control, you are not concerned that you have a perfect vector between two or more axes. Therefore, you can get away with one axis moving slower.
But there is the next level of the problem, in many automation projects, timing is critical to the process' efficiency. If a drive allows the process to slow, the net output of that process could become a variable or even just simply slow down. If in the "whole system" you need a throughput of 1 piece every 10 seconds, one of the elements slowing down causes problems for the rest of the system with the final result being slowed production.
A perfect example of this is a gantry loader feeding a CNC machine. If the gantry loader slows down to the point where the CNC is waiting for the loader, cycle time increases, productivity and profits drop.
The concept of what Gecko drive was working on is an old technology for CNC systems. I don't know of the exact earliest date it was first utilized but it was in the 70's. It is also used extensively on EDM machines and it is called "adaptive control". But because this is performed at the CNC (control) level of the system, all axes would slow so the vector remains true during the motion.
It was to be performed by the motion controller (g-100/r-rex) otherwise it would be pointless as you say. If a motor starts to miss then its speed is reduced along with the other drives to maintain the correct motion profile.
Otherwise feedback from steppers only warns you when things go wrong, steppers always apply full drive so if you are losing steps the only thing you can do is stop or slow down to increase torque and try to reduce the error. This is a basic feedback loop which technically makes them a servo of sorts (servo being a general term for an actuator and feedback system). It has nothing to do with adaptive control where the control law itself is adapted.
Hi Guys,
I have been a bit busy this week and havn't really achieved much - so I can't really report any progress at this stage.
As I mentioned at some other time, I have a modified EMC gcode compiler running on a windows machine, which produced coordinates based on a 1mSec time base i.e. move to this position in this period. I have been thinking that possibly I should modify it a little more so that it is actually outputting a number of steps to execute per 1mSec period.. What are peoples thoughts on that??? Good idea or not??? This way I can take more load off the prop, because it doesn't need to even bother with how many steps to do per mm, it just recieves do this many steps in this period.
Ah yes, the G100/GRex thing that failed on so many levels. Okay, so they were planning on adding the logic to that to create the "unstallable stepper". That would make more sense than what was originally talked about "The unstallable stepper [drive]". I guess I just gave up reading about it early on when they were talking about the unstallable stepper and everyone was thinking how great it would be. I suspect that it still never came to life though because the G100 had so many problems etc.
@ Andrew,
One way or the other you are working with a series of steps. Either you take the coordinate and compare it to a position then substract to the number of steps in the Prop or you do it on the PC side. I suspect that will be the least of your challenges and certainly one of the easiest to change should you need to.
The one thing that concerns me with that method of time slices is balancing the spacing between steps. You have to make sure that the spacing between steps (velocity control) carries over from one time slice to the next. I have not yet had time to really focus on this but the few brief moments I have had to think about it, I keep stalling on the timming issues. It very welll could be very simple but I just have not been comfortable enough with the concept yet.
I just watched you video and going by the sound alone I would say that you have a very good pulse stream using the counters. It also sounds like there is accel / decel being applied. Yup, you got to document and post the information on this.
Andrew, if you have a sytem that works on a given number of steps in a given time then you have something that is basically a velocity based system becuas it is a distance in a given time. This means you can also think in terms of step frequency in a given time. This is what my program is based on, i will try to write something tomorrow about how it works.
Chris,
I don't know what happened to the g-rex, i read abiut it with interest and copied some of the ideas for my work but had not looked at the page for at least 2 years, i expected a perfected product but instead see it has been canned. Shame because parallel ports are getting rarer.
And yes the motion has accel and decel, I want to program some multiaxis soon and then look at how to tie vectors together, I just finished up a little mill project that will make a good test bed.
Comments
Currently I am running bresenham, but the previous attempt was to use one cog per axis so I had enough time to handle all the calcs. The problem with that is coordinating the cogs for precisely synchronized motion - never got that as good as I wanted.
My next direction is being figured out right now. I know I will put all of the step & direction outputs into one cog to help insure accurate synchronization. I have a few other ideas I have to work out but these require lot's of time to think through. Having just started a new job, my "think time" is not as clear as I would like, but that is life.
The other thing that just came up that could help a lot is that FP32 object someone posted. That appears to be very efficient which could help me out substantially if I can figure out how to exploit its power.
Chris
Is Floating point an issue? I "think" I have a way around it by using counters. It worked for me about 10years ago on an AVR Mega32 I can's see why it wouldn't work here.
Andrew
Sorry, I can't read 'C' very well (or at all for that matter). I suspect that the FP32 object that was posted should be fast enough to do what I need and seeing as I have 1 COG to spare, it should do the trick.
I will have to post in that thread some questions about it though so that I understand it better.
Thanks
Chris
to apply accelleartion and decelleration I coded it this way:
through acc the time to wait until the next pulse has to be created
gets shorter from step to step.
It starts at a frequency the steppermotor can handle from 0 rpm and stops
at a max frequency.
With deccelartion it is simply the opposite way. The waittime from pulse to pulse gets longer down to the frequency the steppermotor can handle to
go from low-freq to 0 Hz within ONE step.
The waittime-values for acc and dec are stored in an array of 100 eelements.
Let's use easy values for explaining it:
waittime(0) = 10 msec
waittime(1) = 9 msecs
waittime(2) = 8 msecs
etc. etc
Now my my stepout-methods divides the complete way into three parts
1.) acc
2.) hold on max speed
3.) decc
(if the complete amout of steps is lower than 200 example 120 steps you go up acc for 60 steps and down for 60 steps)
the loop that creates the pulses has a waitcommand to create the applied frequency.
Inside the loop a counter counts up the steps and this step-variable is used as index for the waittime-array
with the example-values from above:
first loop
variable step has value 0
wait(waittime(step)) which means waittime(waittime(0)) = wait(10msecs)
second loop step has value 1
wait(waittime(step)) which means waittime(waittime(1)) = wait(9msecs)
third loop step has value 2
wait(waittime(step)) which means waittime(waittime(2)) = wait(8msecs)
etc. etc.
The complete amount of steps is divided by 2 to get the two halfs
first half for acc and hold max-speed
and second half for max-speed and decc
the loop contains a condition
if step > maxWaittime
wait(waittime(maxwaittime)) which means wait(waittime(100) which is the max-speed
else
wait(waittime(step))
and you are done about acc and decc always automatically in the right amount of steps.
Of course creating an array in PASM is a bit more difficult than in spin
but not that much more difficult.
best regards
Stefan
Thanks for the explanation. I too have tried that method in an earlier attempt and found there are two problems...
1) You are adjusting the velocity by changing the wait time between steps. This results in an ever increasing ramp up to speed. It is actually a curve that is not going the good way. The method you describe will work when you are well within the limits of the mechanicals.
However, if you are pushing towards the limits, the chance the stepper motor stalls out increases dramatically. Ideally for steppers, you want an S curve ACC & DEC but this is much more difficult to program than a trapzoidal ACC & DEC. In the example you described, you have neither. Acceleration and Deceleration has to be time based and not based on position. Time is the constant, 10 mSecs is alway 10 mSecs so acceleration that is applied in timed intervals becomes a constant increase (stright line ramp up/down). However, your time between steps keeps getting shorter with each step and if you keep subtracting time from each step it is like a runaway snowball growing exponentially. Again, I must clarify, what you describe will work, it is not as ideal as I would like.
2) You motion planner method seems to indicate that every move will start from zero speeed, accelerate up to run speed, then decelerate back to zero speed. This is okay for point-to-point positioning, but in practice, it is not good for CNC machining in metals. This start-stop motion causes tool chatter at the vertices between movements. CNC machines have a much more fluid motion, wherein the next moves starts before the current moves is completed. Yes, it causes corner rounding which is acceptable in many contouring cases. When it is not acceptable, you would use the CNC feature called exact stop check (G09 or G61) to cause "stops" at every vertice.
Your thinking about breaking up the motion into 3 phases is spot on though. The process I am developing right now is doing that too. In all my previous attempts, I command the motion as a "whole unit" and allowed ACC and DEC to occur dynamically, thus breaking the motion down into the 3 phases. This method works pretty good but it can easily get out of control. So on my latest attempt, I am breaking the motion into the 3 phases in the planner before I run the motion. I suspect this will allow me to synchronize the 4 axes better than previous attempts. The down side is I won't know for a month or two as I just do not have the time to keep working on it.
I must say, this thread is getting very interesting and indepth. I sure hope anyone that is thinking about creating a CNC control is giving this a read.
Chris
I must admit that your knowledge about CNC is a lot greater than mine.
My experience is based on diamond engraving. As you have mentioned it now
it is really obvious to me that complete stops are causing more problems with tools that are turning around an axle than with a still standing diamond peak.
Anyway I agree the thread becomes more and more interesting.
Interesting challenge to code a motion-planner that smoothens the direction changes. I have an idea how edge-rounding can be avoided for a part of all possible movings. If the motion-planner adds a "mill out of material" movement
and start a "mill into material again" movement this will avoid bad (and
chattering) forward to turning speed ratios. Of course for the cost of more
time it needs to move the additional way.
So a good motion-planner would have to take care of each next movement
and do the calculation of acc / dec based on the angle-difference between
the actual direction and the next direction.
Small angle only a few decceleration and acc after changing the direction.
Big angle more decceleration and acc after changing the direction.
how much acc/dec is needed depending on the angle would be evaluated through tests in real metal.
Or as second best in the air to have the inertia of the machine itself.
Maybe this is even better because cutting metal is always like a brake.
As the propeller offers 8 cogs that can work in parallel I suggest one cog is just creating the pulses based on a set of parameters.
So this cog needs only a little time to load these values and then executes stepping-loops.
Another cog will do all the calculations like amount of steps acc / dec values allowed corner-rounding based on
tool-overlapping from turn to turn etc.
As you want to push the machine to its limits I guess servomotors will pull the limits pretty far beyond what a steppermotor can do. I know a manufacturer of small servomotors and control-units.
ecostep motors
The control-unit for one motor for currents up to 6Ampere is around 300 Euro. I don't have prices of the motors. I have worked with these controls.
The have parameters to adjust almost everything you would like to.
The control has a position, speed and acceleration-controller which are working hand in hand or maybe as one above the other. So all in all a PID-control where you can adjust P, I, D and even more parameters
each to his own value to adapt to almost every mechanical situation
like different inertia or "stiffness" of the mechanic to be as fast as possible without making the system swing for and back.
If I remember right you can even adjust the allowed edge-rounding for direction changes. An interesting question is how much motion-planning these servocontrollers can do for TWO or more axis. To find the optimum between maximum-speed and edge-sharpness. They have a serial and a CAN-Bus interface which can be used to reconfigure parameters on the fly.
I'm not a big expert about servo-controls on the market but I guess this is pretty muc
Executing the step & direction output is fairly simple by comparison, create a consistant pulse stream for all the axes based on a common clock source to keep them synchronized.
You concept of overshoot, then come back to the cut would be very difficult to impliment and certainly inefficient. In the case of milling, the tool can be cutting on either side of the programmed path. From our perspective, we can see which side of the path the part is on, from the CNC's perspective it doesn't know. The only way you could perform the overshoot and cut back in is to also use the feature tool radius compensation (G41 or G42) which compensates for the tool's radius and offsets the tool's path. But that then adds another level of complexity to the tool path. The fun part of working with the PROP chips is to figure out ways to get all the tasks done in the required time by dividing up those tasks across multiple cores - a luxury not offered in most other micros.
All in all, creating a CNC control that mimics industrial controls is very challenging. You can certainly get away with a lot of "kludges" if performance isn't being chased, but in the end there is a reason why industrial controls cost so much - a lot of engineering goes into them.
While I like to mess around with steppers, servos are the king in CNC. Probably 99.9% of all industrial CNC machines use servos. I suspect there are good engineering based reasons for this ;-)
Chris
I have been thinking a bit about what I am wanting to achieve, and how I am going to achieve it (Thanks to Chris for his experience here). So this morning I thought I would procrastinate a bit (I am supposed to be doing a customers job).
I have hacked the EMC GCodeCompiler a bit so that I can read in a complete gcode file (on Windows) and then output 6 axis positional commands at an interval of 1mSec per reading i.e:
motion id 11
0.000000 0.000000 -0.039967 0.000000 0.000000 0.000000
0.000000 0.000000 -0.042104 0.000000 0.000000 0.000000
0.000000 0.000000 -0.044299 0.000000 0.000000 0.000000
0.000000 0.000000 -0.046550 0.000000 0.000000 0.000000
0.000000 0.000000 -0.048858 0.000000 0.000000 0.000000
0.000000 0.000000 -0.051224 0.000000 0.000000 0.000000
0.000000 0.000000 -0.053647 0.000000 0.000000 0.000000
0.000000 0.000000 -0.056126 0.000000 0.000000 0.000000
0.000000 0.000000 -0.058662 0.000000 0.000000 0.000000
0.000000 0.000000 -0.061256 0.000000 0.000000 0.000000
0.000000 0.000000 -0.063907 0.000000 0.000000 0.000000
0.000000 0.000000 -0.066614 0.000000 0.000000 0.000000
0.000000 0.000000 -0.069379 0.000000 0.000000 0.000000
0.000000 0.000000 -0.072200 0.000000 0.000000 0.000000
0.000000 0.000000 -0.075079 0.000000 0.000000 0.000000
0.000000 0.000000 -0.078014 0.000000 0.000000 0.000000
0.000000 0.000000 -0.081007 0.000000 0.000000 0.000000
0.000000 0.000000 -0.084056 0.000000 0.000000 0.000000
0.000000 0.000000 -0.087163 0.000000 0.000000 0.000000
0.000000 0.000000 -0.090326 0.000000 0.000000 0.000000
0.000000 0.000000 -0.093547 0.000000 0.000000 0.000000
0.000000 0.000000 -0.096824 0.000000 0.000000 0.000000
0.000000 0.000000 -0.100159 0.000000 0.000000 0.000000
0.000000 0.000000 -0.103550 0.000000 0.000000 0.000000
0.000000 0.000000 -0.106999 0.000000 0.000000 0.000000
0.000000 0.000000 -0.110504 0.000000 0.000000 0.000000
0.000000 0.000000 -0.114067 0.000000 0.000000 0.000000
0.000000 0.000000 -0.117686 0.000000 0.000000 0.000000
0.000000 0.000000 -0.121363 0.000000 0.000000 0.000000
0.000000 0.000000 -0.125096 0.000000 0.000000 0.000000
0.000000 0.000000 -0.128887 0.000000 0.000000 0.000000
0.000000 0.000000 -0.132734 0.000000 0.000000 0.000000
0.000000 0.000000 -0.136639 0.000000 0.000000 0.000000
0.000000 0.000000 -0.140600 0.000000 0.000000 0.000000
0.000000 0.000000 -0.144619 0.000000 0.000000 0.000000
0.000000 0.000000 -0.148694 0.000000 0.000000 0.000000
0.000000 0.000000 -0.152827 0.000000 0.000000 0.000000
0.000000 0.000000 -0.157016 0.000000 0.000000 0.000000
0.000000 0.000000 -0.161263 0.000000 0.000000 0.000000
These coordinates are in milimeters (sorry I am an Aussie). Because they have been precompiled, they are taking into account ramping up and down, and constant velocity contouring (I think - I haven't plotted the points yet) arcs etc etc.
I am now thinking that this may be the better way to go - precompile my gcode on the pc - send the info to the prop via ethernet - store on an sd/compact flash card - run, pause, stop, overrides, limits etc etc can easily be monitored by the prop. Pausing/Feed holding will be my only issue, but I don't think it will be to huge of a job to figure out.
What are your thoughts????
Regards
Andrew
If I wasn't so stuborn and bullheaded, I would do it.
Years back I wrote a program that would graphically plot the tool paths for CNC programs. In order to get the performance I wanted, I converted the CNC Code into an intermediate code, then plotted that intermediate code. It was very fast and efficient.
You are right, working out the details to make this run won't be too bad. The only "tricky" thing is that you have to create a variable clock source. This variable clock source is how you handle feedrate override and feed hold. Here is how it will work...
Select a frequency, say 50kHz as your basetime, this would represent 100% feedrate. If you turn up the feedrate override to 200% your basetime is now 100kHz and likewise if you turn it down to 10%, your basetime is 5Khz, and 0% is zero clock output. This is how you control the velocity with the override - simply by changing the time element. For feedhold, you would ramp down the timebase to zero (simulating a deceleration) and then ramp the timebase back up upon cycle restart. The same is true for single-block operation.
Before all that can work, you have to take those small linear movements, determine their "size constant" or "Time constant" and work out a frequency that will create a motion in the correct period of time. I am not sure what EMC is doing in this regard. It could be creating small linear moves that are 10 discrete positions "size constant" or it could be creating small linear moves that are 1 millisecond worth of motion "time constant". I would wager a guess that it is a time constant interval.
That should get you going with some thoughts to consider and I hope it helps.
Chris
Ahhh, I just re-read your post and realized you already determined that it is a time constant data block - that should be a lot easier to work with!
Servomotors can be driven on very fast RPMs and still have a lot of torque.
Servomotors have an encoder that gives a very accurate feedback about
the motorspeed and angleposition of the motor-axle
steppermotors loose torque with increasing rpm
steppermotors DON'T have a feedback about speed and angleposition
Of course you could add an encoder to a steppermotor but then you are
half way to a servomotor with the disadvantage of loosing torque at high rpms.
best regards
Stefan
Please tell me what kind of 'rotational' servo I need. I modified a servo by removing the 'notch' and replacing the potentiometer with two equally matched resistors. I controlled speed with PWM. I still need position.
Larry
can you please tell details what you want to do "in the end".
Which motor fits your demands best depends highly on what you want to do.
Without this details I could only give a quarter professional overview which
motor has which advantages / disandvantages.
If you tell us what you want to do in the end you open the oportunity that
more solutions can be found and their pro's and cont's can be discussed.
I have experienced as soon as the whole thing is known sometimes
complete different but much better (cheeper, faster, easier) fitting solutions can be found.
As long as your maximal demanded torque stays below what a certain
steppermotor can hold/drive - in all situations -
a steppermotor is a good solution because
you don't need extra effort for encoders to keep track of the position.
So please tell us what you want to do in the end
best regards
Stefan
For my next project I may work on a turntable that will turn my TV to face me. I can do it with a stepper but servos are easier to find and they are stronger.
The other reason is that I have motors with quadrature encoders and standard servos that I want to experiment with.
With servo I meant a DC-Motor with an encoder and a servo-control-unit
which realises that the DC-Motor can turn just a 1/100 degree or 3,8 rotations or whatever - by the help of the encoder on the motoraxle.
Do you mean servo in this way? Or do you mean with servo a "model-servo"
these tiny little things used in RC-modelplanes, RC-modelcars etc.?
So for your projects what rotational speeds and accuracy do you need for them?
best regards
Stefan
I hope I didn't hyjack this thread. Thanks
Larry
If you want to discover yourself how quadrature encoders work
and how a program has to be to read them that's really OK.
If your main goal is to realise the project you could do
a search in the obex for keyword quadrature
and find some things already coded.
best regards
Stefan
Stefan answered already but to help add some clarity here is a bit more about why servos are used over steppers...
Servos have an encoder which is used to provide velocity and positional feedback to the drive system. The drive can then use that feedback along with motor current draw to determine what is actually happening during the motion. This creates a relativly closed loop monitoring system. For steppers, you have zero feedback - it is completely blind.
Consider the comparison to a person walking...
You are walking with your eyes closed - how do you know where you are? The only reference in position you have is your estimate that if you take 400 steps you should be 400 steps away from where you started. What if you sumbled and skipped a step, would your destination be accurate at the end of the walk?
During the same walk, you have to arrive exactly 1.252 minutes later. Without velocity feedback you may have slowed down because of the hill you walked up required more effort. The result is you arrive .3 minutes too late.
Continuing this thought, what if the hill you tried to climb up was so steep you didn't have enough power to take the next step? Do you want to keep trying and fail or should you trust the feedback from your legs saying you are about to stall so stop gracefully?
Steppers are wonderful motors and I love playing with them. They are economical, their drives are economical, their interface (via the drives) is very simple, they don't require any maintance, but they are stupid. They only TRY to do what you tell them to do and if they fail in doing it, they won't tell you anything.
So, now let's see how that works out relative to industrial applications and the reality of business....
Your CNC lathe has stepper motors. It is very accurate in testing, you have the machine designed and setup to operate well within the limits of the motors. It has produced many good parts for months / perhaps years. Now you are machining a critical component for a jet engine - a bit tougher material than you normally have machined. Your trustly "blind" machine has done you good in the past so you trust it to faithfully machine this critical part for the jet engine. But, at some point during the machining, some chips bound up on the cutting tool causing the stepper to skip a few steps which caused all the remaining dimensions to be off and the resulting part is out of spec. 18 months later, there is a breaking news story, a plane crashed with 300 people on board, all died. After the NTSB investigation, they found that the cause of the plane crash was a faulty component in the engine.
For another example, you CNC grinder uses steppers. It has been a good machine that faithfully produces accurate parts. Its a big one too, it has 24" diameter wheels that are 4" wide and the spindle runs at 1400 RPM so it is fast! One day after months of a long production run, the grinding wheel attepts to retract away from the part so the part can be changed. However, swarf has built up on the slide and the axis stalls out and stops short of the retract position. The operator changes parts, presses cycle start, and that was the last experience of his life. What caused his untimely death was an exploding grinding wheel. The reason the grinding wheel exploded was the CNC system had no idea the axis never retracted completely - it just assumed it did. Well, with that assumption, the next move command has the grinding wheel moving at full speed towards the part. Being that it was closer than expected, the wheel crashed into the part and exploded with tremendous force.
Feedback systems are critical elements that cannot be underestimated. If you have never worked in manufacturing, the two examples above might seem a bit extreme. However, I can assure you they are certainly well within the bounds of reality.
As mentioned by one of the other posters, the encoder on a servo can be of great precision, many counts per revolution. The highest number of counts i have seen on a rotary axis is 1 million counts per revolution. This allows for very accurate positional feedback. However, in some cases, even servos do not provide for enough feedback to truly close the loop. Even though the enoder provides feedback to the rotary position of the motor, it does not provide you with feedback of the actual slide. All mechanical devices have clearances to allow the moving components to slide or move. This is "Slop" in the mechanical drive system which results in slight miss-positioning - usually < .0002". However, depending on the part being machined .0002" (which is 1/15 the thickness of paper) can be a country mile. So, for very high precision applications, another encoder is added to the feedback loop. This encoder is not rotary, rather it is linear, but it works on the same principle as a rotary encoder. The actual scale portion is made up of glass which is thermally stable and therefore maintains its accuracy well. If you have ever seen a digital caliper, it works on a very similar principle. This type of scale is connected to the machine base/slide and measures the physical movement between the two components providing near-perfect feedback of position.
I hope that the information above sheds some light onto why servos are better than steppers. It actually doesn't have much to do with the units themselves but rather their application in industry and the seriousness of their role in manufacturing products that our lives depend on. The little machines i build at home are for personal use and for fun and learning. They will never be used by anyone other than myself and they certainly won't ever machine critical components. So steppers are the "perfect" choice in this case ;-)
Chris
Graham
Chris,
thanks for the explanation.
I've heard of steppers using encoder feedback so they don't run blind. Any idea how a stepper+encoder system like that might compare with a servo+encoder? In the case of the stepper+encoder, does the encoder buy you anything besides warning you when the stepper might have skipped some steps?
thanks again,
Mark
It has been a number of years since I have done a project for the aircraft industry so I can't say what the current situation is in that regard. However, in nearly every other industry, this is how inspection is performed....
When a company buys a machine to make parts, it starts out with a qualifying run-off. The sample size can be anywhere from a hundred parts to a couple thousand parts. The purpose of the run-off is to determine if the machining process (and machine) are statistically capable of producing consistant parts that mathematically assure a high percentage of the parts are perfect. Over the years, the name for this has changed ( capability study, six sigma, 8 sigma, cpk run-off, capability run-off, etc. etc.) Most of the "common" names for this are localized to the customer but basically it is all the same thing. Anyway, basically what happens is you run the sample quantity, you inspect every parts, record every size, process the data to see if it statistally is acceptable. Two elements are important: consistancy and amount of deviation (size change). If you have a tolerance of .001" on the engineering print, your goal is to use about 1/2 of that during the process (very general rule).
After this qualifying run-off is completed, the machine is put into production. From that point on, not every part is 100% inspected, only perhaps 1 in 5 or 1 in 10 because statistcally the process is "Capable" of producing perfect parts. Therefore in most industries every part is NOT inspected, generally it is the minority.
@ElectricAye...
When a stepper has an encoder it does close the positional and velocity loop, but only if the driver or controller software has the logic for it. Many servo drives monitor that loop and report back to the controller software. Not too many stepper drives (I don't know of any off hand) that allow for encoder feedback. So to close the loop, the encoder is fed back to the control software where the loop is closed. As to how well that data is processed, is up to the control software.
The control software may only check for a "disconect" meaning that there is a difference between where the position should be and where the encoder says it is at. It might also try to correct the problem by adding a few more steps to the pulse stream. But I really don't know what pre-existing drives or controllers do specifically - closed loop stepper systems don't appear to be as "standard" as servo drive systems.
Chris
Graham
That was a neat idea but certainly not for CNC applications. The "adaptive" drive concept would adapt the feedrate to compensate for the additional resistive forces (heavier cutting, heavy load, mechanical binding, etc). However this would be performed at the drive level, not the CNC level. So, lets walk through why this is just as bad as missed steps...
You command a 3 axes motion, all three axes have to start and stop at the exact same time to create a straight vector (line) between the start and end points. If any one of the axes is not moving in synch with the others, your vector is not straight. Because his idea was to put this "Solution" in the drive, it creates a gapping hole in the CNC system. One drive could slow down to accomodate the problem, while the two other drives continue at the commanded velocity. How is this any different than missed steps? In a CNC application, the part would already be scrapped.
Now, is this a neat idea or concept for conventional automation type projects? In many cases yes. In general motion control, you are not concerned that you have a perfect vector between two or more axes. Therefore, you can get away with one axis moving slower.
But there is the next level of the problem, in many automation projects, timing is critical to the process' efficiency. If a drive allows the process to slow, the net output of that process could become a variable or even just simply slow down. If in the "whole system" you need a throughput of 1 piece every 10 seconds, one of the elements slowing down causes problems for the rest of the system with the final result being slowed production.
A perfect example of this is a gantry loader feeding a CNC machine. If the gantry loader slows down to the point where the CNC is waiting for the loader, cycle time increases, productivity and profits drop.
The concept of what Gecko drive was working on is an old technology for CNC systems. I don't know of the exact earliest date it was first utilized but it was in the 70's. It is also used extensively on EDM machines and it is called "adaptive control". But because this is performed at the CNC (control) level of the system, all axes would slow so the vector remains true during the motion.
Chris
Otherwise feedback from steppers only warns you when things go wrong, steppers always apply full drive so if you are losing steps the only thing you can do is stop or slow down to increase torque and try to reduce the error. This is a basic feedback loop which technically makes them a servo of sorts (servo being a general term for an actuator and feedback system). It has nothing to do with adaptive control where the control law itself is adapted.
Graham
p.s. Here is the prop driving a stepper using the counters:
http://www.youtube.com/watch?v=bAgV2vtI468
Still need to sit down and write the explanation.
I have been a bit busy this week and havn't really achieved much - so I can't really report any progress at this stage.
As I mentioned at some other time, I have a modified EMC gcode compiler running on a windows machine, which produced coordinates based on a 1mSec time base i.e. move to this position in this period. I have been thinking that possibly I should modify it a little more so that it is actually outputting a number of steps to execute per 1mSec period.. What are peoples thoughts on that??? Good idea or not??? This way I can take more load off the prop, because it doesn't need to even bother with how many steps to do per mm, it just recieves do this many steps in this period.
Regards
Andrew
Ah yes, the G100/GRex thing that failed on so many levels. Okay, so they were planning on adding the logic to that to create the "unstallable stepper". That would make more sense than what was originally talked about "The unstallable stepper [drive]". I guess I just gave up reading about it early on when they were talking about the unstallable stepper and everyone was thinking how great it would be. I suspect that it still never came to life though because the G100 had so many problems etc.
@ Andrew,
One way or the other you are working with a series of steps. Either you take the coordinate and compare it to a position then substract to the number of steps in the Prop or you do it on the PC side. I suspect that will be the least of your challenges and certainly one of the easiest to change should you need to.
The one thing that concerns me with that method of time slices is balancing the spacing between steps. You have to make sure that the spacing between steps (velocity control) carries over from one time slice to the next. I have not yet had time to really focus on this but the few brief moments I have had to think about it, I keep stalling on the timming issues. It very welll could be very simple but I just have not been comfortable enough with the concept yet.
Chris
I just watched you video and going by the sound alone I would say that you have a very good pulse stream using the counters. It also sounds like there is accel / decel being applied. Yup, you got to document and post the information on this.
Chris
Chris,
I don't know what happened to the g-rex, i read abiut it with interest and copied some of the ideas for my work but had not looked at the page for at least 2 years, i expected a perfected product but instead see it has been canned. Shame because parallel ports are getting rarer.
And yes the motion has accel and decel, I want to program some multiaxis soon and then look at how to tie vectors together, I just finished up a little mill project that will make a good test bed.
Graham