The Propeller, Stepper Motors, CNC, And Multi-Axis Synchronization
idbruce
Posts: 6,197
Once again, I got sidetracked. Instead of spending my spare time on finishing the remaining hardware for my 3D printer, I have been researching synchronized motion control.
There are of course several routes to choose from, pertaining to multi-axis control of a CNC system, and of course they all involve work, money, or settling for less than an optimum solution. My first instinct was to use open source code to achieve synchronization, but to be perfectly honest, there really is not a lot of open source code out there to choose from, and for the code that is available, a lot of it relies upon interrupts, which makes it difficult to achieve a Propeller solution. In an effort to overcome this obstacle, I have been trying to find CNC code, which uses the serial port of a PC to send step signals, hoping that it would include ramping. Once again, there is not a whole lot of code out there. LinuxCNC might be worth looking at, but at this point, I still have not been able to locate any C source code.
Many folks believe that Bresenham's Line algorithm is the way to go for sychronization, while several people disagree, saying it causes too much jitter. According to the documentation that I have read, this so called jitter seems to become meaningless, when used in combination with microstepping of stepper motors. I personally do not know the true effects of this jitter, when used in combination with microstepping of stepper motors, but I do know that Jason Dorie gave me some Bresenham code to run, and it appeared to work very well for my 1/10 microstepping drivers.
From another perspective, I also came across a motion controller IC solution, but it required one IC per motor, and at first glance, it appeared to be nothing more than a glorified step translator, however it was capable of working with servos also. As it pertained to stepper motors, I believe the Propeller could achieve the same tasks as this IC, providing the proper source code was written.
During the course of my research, I came across a couple of good articles written by John Rathkey, Parker Motion, which outlined multi-axis sychronization. Within these articles, there is no mention of Bresenham's algorithm, although from my limited knowledge of Bresenham's algorithm, I think they pretty much have the same principle, however I do believe that different math formulas would be used. Instead of me trying to get all scientific and mathematical (since I am not very good at these subjects
), I will simply provide links to the articles, which are as follows:
Hosting Domain: machinedesign.com
Author: John Rathkey
Article Title: Synchronicity in motion
Link: http://machinedesign.com/mechanical-drives/synchronicity-motion
Hosting Domain: automation.com
Author: John Rathkey
Article Title: Multi-Axis Synchronization
Link: http://www.automation.com/library/articles-white-papers/motion-control/multi-axis-synchronization
Main PDF: http://www.parkermotion.com/whitepages/Multi-axis.pdf
In my opinion, the most significant and informative of the two articles, is the one titled "Multi-Axis Sychronization", although they pretty much say the same thing. It has always been my belief that the Propeller chip is well suited for CNC applications, due to it's capabilities of parallel processing, however the problem has always been the lack of source code. As it pertains to the forementioned document, I now have a deeper belief in the Propeller for CNC applications, but it still lacks the source code.
For those that may be interested, please take the time to thoroughly study the "Multi-Axis Sychronization" document linked to above and provide comment, because I think the Propeller would be well suited for this type of application, and I would like to hear your thoughts on the subject. However, please keep in mind that I am talking about stepper motor control and not servos.
Additionally, my deepest gratitude goes out to those who fought, served, and/or died for the United States of America.
There are of course several routes to choose from, pertaining to multi-axis control of a CNC system, and of course they all involve work, money, or settling for less than an optimum solution. My first instinct was to use open source code to achieve synchronization, but to be perfectly honest, there really is not a lot of open source code out there to choose from, and for the code that is available, a lot of it relies upon interrupts, which makes it difficult to achieve a Propeller solution. In an effort to overcome this obstacle, I have been trying to find CNC code, which uses the serial port of a PC to send step signals, hoping that it would include ramping. Once again, there is not a whole lot of code out there. LinuxCNC might be worth looking at, but at this point, I still have not been able to locate any C source code.
Many folks believe that Bresenham's Line algorithm is the way to go for sychronization, while several people disagree, saying it causes too much jitter. According to the documentation that I have read, this so called jitter seems to become meaningless, when used in combination with microstepping of stepper motors. I personally do not know the true effects of this jitter, when used in combination with microstepping of stepper motors, but I do know that Jason Dorie gave me some Bresenham code to run, and it appeared to work very well for my 1/10 microstepping drivers.
From another perspective, I also came across a motion controller IC solution, but it required one IC per motor, and at first glance, it appeared to be nothing more than a glorified step translator, however it was capable of working with servos also. As it pertained to stepper motors, I believe the Propeller could achieve the same tasks as this IC, providing the proper source code was written.
During the course of my research, I came across a couple of good articles written by John Rathkey, Parker Motion, which outlined multi-axis sychronization. Within these articles, there is no mention of Bresenham's algorithm, although from my limited knowledge of Bresenham's algorithm, I think they pretty much have the same principle, however I do believe that different math formulas would be used. Instead of me trying to get all scientific and mathematical (since I am not very good at these subjects
), I will simply provide links to the articles, which are as follows:Hosting Domain: machinedesign.com
Author: John Rathkey
Article Title: Synchronicity in motion
Link: http://machinedesign.com/mechanical-drives/synchronicity-motion
Hosting Domain: automation.com
Author: John Rathkey
Article Title: Multi-Axis Synchronization
Link: http://www.automation.com/library/articles-white-papers/motion-control/multi-axis-synchronization
Main PDF: http://www.parkermotion.com/whitepages/Multi-axis.pdf
In my opinion, the most significant and informative of the two articles, is the one titled "Multi-Axis Sychronization", although they pretty much say the same thing. It has always been my belief that the Propeller chip is well suited for CNC applications, due to it's capabilities of parallel processing, however the problem has always been the lack of source code. As it pertains to the forementioned document, I now have a deeper belief in the Propeller for CNC applications, but it still lacks the source code.
For those that may be interested, please take the time to thoroughly study the "Multi-Axis Sychronization" document linked to above and provide comment, because I think the Propeller would be well suited for this type of application, and I would like to hear your thoughts on the subject. However, please keep in mind that I am talking about stepper motor control and not servos.
Additionally, my deepest gratitude goes out to those who fought, served, and/or died for the United States of America.
Comments
Which thread are you referring to?
anyway here are some
http://forums.parallax.com/showthread.php/130235-FAST-6-AXIS-linear-interpolative-CNC-Controller.?highlight=starkey
http://forums.parallax.com/showthread.php/145237-3-axis-CNC-control-packages-uploaded-to-the-OBEX-by-Don-Starkey?highlight=starkey
http://forums.parallax.com/showthread.php/142705-Step-Dir-signal-generator-for-CNC
best regards
Stefan
The original idea started in this thread:
http://forums.parallax.com/showthread.php/160856-3D-Printer-3D-Bresenham-s-Line-in-SPIN.
David Saunders wrote and posted some code for it here:
http://forums.parallax.com/showthread.php/160860-Smoother-%28X-Y-Z%29-movement-for-3D-printers-and-CNC.
Thanks for the links, but I have seen them all before. I am now geared toward C source, because I am PASM illiterate
Are you still working with machinery?
The biggest obstacle that I can foresee at this point is performing all the necessary calculations, without dramatically slowing down the pulse train going to the individual steppers. I suppose it all boils down to the shortest cycle offset (shortest delay duration) + 1uS high pulse width (for Gecko drives). Can the calculations for all steppers be performed within this period of time? I highly doubt it, so throughout the day, I will be pondering just exactly where to perform and store these calcutions within the firmware.
The code Dave Saunders posted can handle 3 steppers using one cog. Perhaps you can modify that so it gets it's parameters from hub ram variable. That way you can have the "main" program update those parameters on the fly. By splitting a movement into short segments you can move in curves as well as changing the speed on the fly. The parameters would still be the time between motor steps, and since they are done by an independent cog the main program has the time to perform the calculations or read the next parameters from a file.
I drove the steppers (1/2 step ) through a timing belt setup in a 5 to 1 ratio so each step was 1/10,000 of an inch.
I did the step driving with a commode 64 and was able to drive it pretty fast.
Instead of driving it with the bigger move being the master (did not know anything about Bresenham algorithm) I drove the vector ( hypotenuse for 2 axis move) as the main one and derived the X,Y,(Z) moves from that.
When cutting in a metal you don't want the speed to change (unless you have huge supply of end mills) so driving the bigger axis(with the same pulse rate for each move) would have the SFM change. Driving the vector the SFM would always be the same.
For a 3d printer it's not an issue so much but in cutting metal it will be an issue.
Now have HAAS cnc's so my converted machine now sits collecting dust.
Rapid prototyped parts, such as from a 3D printer, are built layer-by-layer so only the X and Y axes are coordinated.
Also, 3D contouring on a CNC is used for making complex surfaces such as for a mold but most CNC parts are made in stepped layers. Endmills cut better on the sides than they do on the bottom and in machining it's all about MRR or Material Removal Rate.
Well the E axis (extruder) also has to be or else the layer will not be consistent.
As far as metal removal rate the plunge method is one of the best ways to remove stock. Think about the forces on the end mill.
That depends a lot on the machine. Newer extrusion-based machines often control the Z-axis during X/Y moves to compensate for a print bed that isn't perfectly flat. Many of the "automatic leveling" printers work this way.
I am not sure if I mentioned it earlier, but I believe I have fairly good plan in my head for ramping synchronized movement and I believe this plan should work well for 3D printing. And I further believe I have a fairly good plan constant speed sychronized movement.
That being said, since the subject of milling was brought up, I am really not sure how all this will work in milling, because CNC mills are a little out of my league. So I ask, is milling operations all pretty much a constant speed, or is ramping involved?
I suppose it really doesn't matter, because ramping should be selectable through conditional compilation.
As mentioned, I can picture it, but I am not so sure how I will do at explaining it.... but here goes.
The master has a high pulse width and a delay between high pulse widths, with a predetermined number of steps for a movement. Each of the "following" axes would a have a step ratio as a function of the master's high pulse width and a delay. The master intervals or cycles are the individual steps themselves, so that acceleration of the "followers" can steadily increase, remain steady, or decrease based upon the action of the master. Since it is simply a ratio of the master, this should not be to hard to determine with uniform or accelerated motion functions. In reality, the math should be fairly easily, but the speed at which the calculations can be made is quite a different story.
Uniform and accelerated motion functions can be found in the Motion Control Handbook under the heading Motion Calculations. The Motion Control Handbook can be found here: http://www.hep.ucl.ac.uk/lc/T474/Documentation/motion_control-neat.com.pdf
// Ramp up the stepper motor a predetermined amount of steps while(current_gcode.y_ramp_up_steps != 0) { // Send out a high pulse on the step pin for the desired duration. PHSA = -Y_PULSE_WIDTH; // Wait for a specified period of time before sending another // high pulse to the step pin. waitcnt(y_counter += current_gcode.y_start_stop_speed -= current_gcode.y_ramp_inc_dec); // Decrement ramp_up_steps current_gcode.y_ramp_up_steps--; } // Run the stepper motor at the current speed for a predetermined amount of steps while(current_gcode.y_running_steps != 0) { // Send out a high pulse on the step pin for the desired duration. PHSA = -Y_PULSE_WIDTH; // Wait for a specified period of time before sending another // high pulse to the step pin. waitcnt(y_counter += current_gcode.y_start_stop_speed); // Decrement running_steps current_gcode.y_running_steps--; } // Ramp down the stepper motor a predetermined amount of steps while(current_gcode.y_ramp_down_steps != 0) { // Send out a high pulse on the step pin for the desired duration. PHSA = -Y_PULSE_WIDTH; // Wait for a specified period of time before sending another // high pulse to the step pin. waitcnt(y_counter += current_gcode.y_start_stop_speed += current_gcode.y_ramp_inc_dec); // Decrement ramp_down_steps current_gcode.y_ramp_down_steps--; }I have a CNC-Mill working space 700x420x125mm. I'm using a propeller-driven prototype in combination with a PC-software both from benezan-electronics
The PC-Software sends 1ms-vectors to the propeller. It's still in development and I'm a betatester for it. But it's already in a useful development stage.
The perfomance of this control and software goes far beyond things like GRBL. Highspeed traveling with speedy accelaration/deccelaration at 4000 mm/minute is no problem.
I adjusted the stepperdrivers to 2000 micro-steps per revolution. I haven't hit a speed-limit for the step-pulses yet.
It also has a constant velocity mode.
Speeds greater than 800mm/min seems to be a problem for GRBL. At least the ramping of GRBL becomes bad.
Too slow or too fast but nothing useful in between.
So as I have a working solution for me I stopped developing code.
best regards
Stefan
Glad to hear that you are still into CNC and that you have a solution in the works. I do believe that a PC driven would be much easier to accomplish than just a Propeller solution. I was just curious if your interests had changed.
After I wrote that, I came to the conclusion that there is a flaw in my line of thinking
I am not sure how well this code will perform, as compared to other code, but since I am creating an etch-a-sketch test platform, I will run it just to see how it works.
For the sake of completeness and sharing of information, here is a link to the new C code that I found: http://goldberg.berkeley.edu/pubs/XY-Interpolation-Algorithms.pdf
Times are changing!
Yea, I got a little snicker out of that
Very interesting! Are you running a full PID?
Single chip solution is nice but most industrial encoders use RS422 line drivers to provide complementary outputs for noise immunity, plus, most dedicated quad decoders filter the encoder signals which is the reason I abandoned trying to use the Prop as a single-chip solution and decided to use dedicated motion ICs on a 485 bus.
A well designed system would have a position feedback resolution sufficient that a "Following Error Limit" (the difference between the actual axis position and the calculated axis position for that servo loop update) well within axis position tolerance could be implemented.
Should the Following Error (updated every servo-loop cycle, typically every 1ms or less) exceed this limit, the machine stops and raises an alarm instead of making a bad part. But you need PID and a trajectory generator for this.
*I* certainly am not talking steppers. I have absolutely no interest in them.
CNC using steppers, to me means Computer Numerical Command, not Computer Numerical Control. How can it be controlled when you don't know what it's doing?
When I first discovered the Prop, 5 years ago, it immediately struck me as having great potential as a motion controller.....pity the counters don't do quad decode. Still a very impressive micro controller.