I once did a four-axis stepper controller with a Zilog Super8 8-bit microcontroller. It did 16-bit position/velocity control in the background using both linear and cubic spline interpolation, with built-in ramping and resonance avoidance. The foreground part was a command processor written in compiled Forth. That's with a single 8-bit processor. So it's unimaginable to me that the P1's eight 32-bit processors couldn't handle something much more complex.
The hard parts of GCODE processing are velocity control: limiting the max acceleration on tight curves (which means
limiting the speed in advance in (one or more) previous motion segments in preparation). Where possible you
want to achieve the set feed rate unless these physical machine limits would be violated. Its a fairly hard problem,
especially when you factor in the manual speed override input - basically a corner constraint can push back through
several motion segments by an amount depending on the current programmed and manual speeds, which means you
have to maintain a lookahead before starting any motion until the constraints can no longer affect the first segment.
I've encountered the results of getting this wrong in chinese laser-cutter software which stalls/jitters out of control if
you give it small circles to cut/etch at fast speeds, it doesn't about angular acceleration and when you link circlular
arcs together it doesn't try to slow down at all.
I have developed nothing but bespoke systems so, thankfully, I have been able to avoid RS274 (G code) so I really don't know what is involved....just can't see it being that big of a deal BUT I feel more comfortable reserving precious P1 resources for time-critical functions rather than data processing.
The hard parts of GCODE processing are velocity control: limiting the max acceleration on tight curves (which means
limiting the speed in advance in (one or more) previous motion segments in preparation). Where possible you
want to achieve the set feed rate unless these physical machine limits would be violated. Its a fairly hard problem,
especially when you factor in the manual speed override input - basically a corner constraint can push back through
several motion segments by an amount depending on the current programmed and manual speeds, which means you
have to maintain a lookahead before starting any motion until the constraints can no longer affect the first segment.
I've encountered the results of getting this wrong in chinese laser-cutter software which stalls/jitters out of control if
you give it small circles to cut/etch at fast speeds, it doesn't about angular acceleration and when you link circlular
arcs together it doesn't try to slow down at all.
Not sure how things work out with steppers but my path-point spacing controls the speed.
If my PID is running at 1KHz and I wanted to travel 1000mm in one second, each iteration of the PID loop would add the equivalent of 1mm to the axis command. Corners would have closely-spaced path-points and so the axis velocities reduce accordingly.
Show me a four axis mill, running on a single P1, that can accurately and effectively machine steel. That will be the code that I would like to examine.
And when you are done, would you please share your source code with the Parallax forum community
We already have most of it....BUT..we need to look at pin count.
We are talking 9 encoders which include A, B, I signals, then we need home sensors (gated with the I signals for accurate homing), then we need 9 motor commands....these are +/- 10v and Phil already came up with the PWM filtering circuit for JonnyMac. The motor command resolution was only 8 bit.
T Chap has successfully interfaced the 7366 quad decode/counter via SPI so these can be daisy-chained.
PID for the 9 axes is a breeze for the Prop.
Other GPIO can be I2C.
Now...I would stick a Micromite on the front end because I like interactive interpreters but I am sure that the Prop would still have sufficient resources to process the G-codes. GRBL appears to be more about struggling to generate pulses for multiple axes...Ugh! Get with the program and be like real CNC
well Bruce, the code in the last post of the thread runs on a Demo Board with serial input and output. So you can test it with almost any board providing serial and unused pins
.
I do not had (and have) any hardware to test it on, it was just a experiment to get my brain off a major problem at work. Sometimes I need to take myself completely off-topic for some days to get a new view of the problem I really need to solve.
And that is what programming the propeller does to me.
I need to examine the code by myself, not sure why I stopped and when.
But if I remember correct I stopped at implementing the circular G code commands, the rest was working.
The code is mostly assembler, I have to look at it more closely if and how I can port it to the P2. But @Ahle2 said the conversion from PASM to PASM2 is not so bad as I expected, so I will try it.
But I just do baby steps with the P2 right now, it is sort of overwhelming, I need to get very basic steps done to understand and use the smart pins more before I start to dive into a full project.
I did run out of speed on the P1 somehow, not really out of memory. The P2 changes a lot here and I am sure that the P2 will be a nice CNC controller.
I wish I had one to learn on, but honestly, at the moment, I have too much on my plate.
The P2 changes a lot here and I am sure that the P2 will be a nice CNC controller.
I believe that also, but then again, up pops the subject of firmware. Someone will either have to create it from scratch or someone will have to port existing firmware. Either way, there is still a lot of work to be done, before any of us have access to a P2 CNC controller that can actually perform some nice machine work.
I still think that porting GRBL would be the way to go with steppers, and as for the servos, we will have to rely on Mickster
We can simply keep our speeds and feed rates low and bypass the fancy hoopla in programming. As long as the end mill doesn't try to push through to much metal it will work.
Bridgeports have been around for years and they are simply a motor driving a belt on a pulley that turns the spindle, proof that slow and steady works and has worked for decades (prior to and after computers). I have personally used Bridgeports that were 50 and 60 years old, and they worked just fine. K.I.S. Keep It Simple.
Yeah but the title of the thread is "CNC machine".
I'm not sure that any knee-mill is regarded CNC(????).
Lots of kits with bolt-on pulleys/motors etc. Dunno, I've had a bunch of them and Taiwanese knock-offs but we only ever used them for one-offs.
Get the speeds wrong and steppers will miss-step, ruining the whole workpiece, so in a stepper based system
you have to get this right - if you want production level feed-rates you can't just go slowly and avoid the complexity,
you have to back-propagate speed constraints through motion segments, just like you don't fly a small plane up
an unmapped valley! Yes, you can take the mule-train up the valley, to continue the analogy, and avoid crashing
Ever heard of a 2-1/2 axis machine?
The X and Y axis are computer controlled but the Z is controlled by a 'biological unit'.
Retrofitted Bridgeport mills are basically 2-1/2 axis.
Absolute encoders running motor control for a motor that is NOT a stepper. The encoder is mounted on the motor shaft and each motor is geared down to about 300 RPM. In short, from a motor speed of about 1750 its a lot of extra torque when dropped to 300rpm. Reality is DC motors may turn at 2,000 or 3,000 RPM but its figured based on 1750.
Lead screws with dual parallel rails account for movement on each axis and are held in place by pillow block bearings on each end. I went pillow block instead of linear bearings for reasons of mounting and increased rail diameter to 5/8 inch to help remove flex.
The spindle is attached to a small gantry crane with allows for 3 axis movement (forward, backward, left, right, up and down). I also worked in a chuck like is on a metal lathe to allow for the object being cut to rotate as needed when milling. The gantry crane is made from channeled aluminum with thicker walls to give strength and be lighter weight. Also, bearings are used on the part of the gantry where wheels would be, except they are inserted into a roller channel much like a garage door wheel is in a metal channel.
Since its not a full size production machine and meant to be a desktop, the motors go slow, however its still faster than doing it by hand.
Each pass is limited to a max of 1/8th inch cutting depth.
Still working on how to get the design to adjust for changing out bits. I think I am going to have preset bits in certain locations so the spindle can change out its own bits instead of being dependent on people.
I know, nothing new... I've shown this somewhere here in the forum some years ago. But some of you probably havent't seen it, yet...
This machine is almost fully propeller controlled. There is one central axis controller for trajectory planning and handling all the accelleration ramp stuff. Then there is one propeller in each of the servo controllers. Only the spinlde motor is controlled by a traditional VFD. A PC serves as file server, memory expansion and GUI platform.
Unfortunatelly, I have no video of it doing real work. Here are some photos of machined parts:
a simple 3 axis cnc controller and spindle can be built using one propellor and a pc with an visual basic interface. i actually still have 2 cogs left....NO MEMORY THO!
servo with 14000 counts per rev.....all the pids fit into a multi threaded cog
gd job ManAtWork
hint: use t-base interpolator so u can change the feedrate in middle of move...ramping is easy then...just add count up to a feedrate remember how long it took so u can count down at the end of the line.....but with servos...they just go where u tell them to go anyway here is a pic that was cut with one propellor
honestly tho...u better be great with math and geometry.....the programming is simple
Comments
Okay.... I'll bite... Just how much and what would be preprocessed?
I once did a four-axis stepper controller with a Zilog Super8 8-bit microcontroller. It did 16-bit position/velocity control in the background using both linear and cubic spline interpolation, with built-in ramping and resonance avoidance. The foreground part was a command processor written in compiled Forth. That's with a single 8-bit processor. So it's unimaginable to me that the P1's eight 32-bit processors couldn't handle something much more complex.
-Phil
limiting the speed in advance in (one or more) previous motion segments in preparation). Where possible you
want to achieve the set feed rate unless these physical machine limits would be violated. Its a fairly hard problem,
especially when you factor in the manual speed override input - basically a corner constraint can push back through
several motion segments by an amount depending on the current programmed and manual speeds, which means you
have to maintain a lookahead before starting any motion until the constraints can no longer affect the first segment.
I've encountered the results of getting this wrong in chinese laser-cutter software which stalls/jitters out of control if
you give it small circles to cut/etch at fast speeds, it doesn't about angular acceleration and when you link circlular
arcs together it doesn't try to slow down at all.
I totally agree, in fact that is my point.
I have developed nothing but bespoke systems so, thankfully, I have been able to avoid RS274 (G code) so I really don't know what is involved....just can't see it being that big of a deal BUT I feel more comfortable reserving precious P1 resources for time-critical functions rather than data processing.
Not sure how things work out with steppers but my path-point spacing controls the speed.
If my PID is running at 1KHz and I wanted to travel 1000mm in one second, each iteration of the PID loop would add the equivalent of 1mm to the axis command. Corners would have closely-spaced path-points and so the axis velocities reduce accordingly.
Doubting Thomas here
And when you are done, would you please share your source code with the Parallax forum community
http://forums.parallax.com/discussion/167016/gcode-multi-axis-control-in-pasm/p1
I have to admit that I stopped working on it long ago.
But the basics are there
Enjoy!
Mike
Show me a four axis mill, running on a single P1, that can accurately and effectively machine steel. That will be the code that I would like to examine.
We already have most of it....BUT..we need to look at pin count.
We are talking 9 encoders which include A, B, I signals, then we need home sensors (gated with the I signals for accurate homing), then we need 9 motor commands....these are +/- 10v and Phil already came up with the PWM filtering circuit for JonnyMac. The motor command resolution was only 8 bit.
T Chap has successfully interfaced the 7366 quad decode/counter via SPI so these can be daisy-chained.
PID for the 9 axes is a breeze for the Prop.
Other GPIO can be I2C.
Now...I would stick a Micromite on the front end because I like interactive interpreters but I am sure that the Prop would still have sufficient resources to process the G-codes. GRBL appears to be more about struggling to generate pulses for multiple axes...Ugh! Get with the program and be like real CNC
Admittedly, I need to start messing around with some servos.
.
I do not had (and have) any hardware to test it on, it was just a experiment to get my brain off a major problem at work. Sometimes I need to take myself completely off-topic for some days to get a new view of the problem I really need to solve.
And that is what programming the propeller does to me.
I need to examine the code by myself, not sure why I stopped and when.
But if I remember correct I stopped at implementing the circular G code commands, the rest was working.
Enjoy!
Mike
But I just do baby steps with the P2 right now, it is sort of overwhelming, I need to get very basic steps done to understand and use the smart pins more before I start to dive into a full project.
I did run out of speed on the P1 somehow, not really out of memory. The P2 changes a lot here and I am sure that the P2 will be a nice CNC controller.
Enjoy!
Mike
I wish I had one to learn on, but honestly, at the moment, I have too much on my plate.
I believe that also, but then again, up pops the subject of firmware. Someone will either have to create it from scratch or someone will have to port existing firmware. Either way, there is still a lot of work to be done, before any of us have access to a P2 CNC controller that can actually perform some nice machine work.
I still think that porting GRBL would be the way to go with steppers, and as for the servos, we will have to rely on Mickster
I'll be doing motion but I have no use for RS274.
Yep, LinuxCNC is another one.
We can simply keep our speeds and feed rates low and bypass the fancy hoopla in programming. As long as the end mill doesn't try to push through to much metal it will work.
Bridgeports have been around for years and they are simply a motor driving a belt on a pulley that turns the spindle, proof that slow and steady works and has worked for decades (prior to and after computers). I have personally used Bridgeports that were 50 and 60 years old, and they worked just fine. K.I.S. Keep It Simple.
I'm not sure that any knee-mill is regarded CNC(????).
Lots of kits with bolt-on pulleys/motors etc. Dunno, I've had a bunch of them and Taiwanese knock-offs but we only ever used them for one-offs.
CNC = Computer Numerical Control
My stance is that anything that is not human operated, but driven by ones and zeros is CNC
Regardless if it only has one axis that moves a quarter of an inch. Of course there is very staunch opposition
you have to get this right - if you want production level feed-rates you can't just go slowly and avoid the complexity,
you have to back-propagate speed constraints through motion segments, just like you don't fly a small plane up
an unmapped valley! Yes, you can take the mule-train up the valley, to continue the analogy, and avoid crashing
Sure but would you build a temperature control system without a thermostat?
No feedback = no control.
Ever heard of a 2-1/2 axis machine?
The X and Y axis are computer controlled but the Z is controlled by a 'biological unit'.
Retrofitted Bridgeport mills are basically 2-1/2 axis.
My CNC design so far:
Absolute encoders running motor control for a motor that is NOT a stepper. The encoder is mounted on the motor shaft and each motor is geared down to about 300 RPM. In short, from a motor speed of about 1750 its a lot of extra torque when dropped to 300rpm. Reality is DC motors may turn at 2,000 or 3,000 RPM but its figured based on 1750.
Lead screws with dual parallel rails account for movement on each axis and are held in place by pillow block bearings on each end. I went pillow block instead of linear bearings for reasons of mounting and increased rail diameter to 5/8 inch to help remove flex.
The spindle is attached to a small gantry crane with allows for 3 axis movement (forward, backward, left, right, up and down). I also worked in a chuck like is on a metal lathe to allow for the object being cut to rotate as needed when milling. The gantry crane is made from channeled aluminum with thicker walls to give strength and be lighter weight. Also, bearings are used on the part of the gantry where wheels would be, except they are inserted into a roller channel much like a garage door wheel is in a metal channel.
Since its not a full size production machine and meant to be a desktop, the motors go slow, however its still faster than doing it by hand.
Each pass is limited to a max of 1/8th inch cutting depth.
Still working on how to get the design to adjust for changing out bits. I think I am going to have preset bits in certain locations so the spindle can change out its own bits instead of being dependent on people.
That's the general gist.
This machine is almost fully propeller controlled. There is one central axis controller for trajectory planning and handling all the accelleration ramp stuff. Then there is one propeller in each of the servo controllers. Only the spinlde motor is controlled by a traditional VFD. A PC serves as file server, memory expansion and GUI platform.
Unfortunatelly, I have no video of it doing real work. Here are some photos of machined parts:
G0..G1..G2..G3 M3..M4..M5..M8...M9...M81...M83....M73...M90...M91....G53...G54....G55...G56
XX.XXXX precision...all integer math
servo with 14000 counts per rev.....all the pids fit into a multi threaded cog
gd job ManAtWork
hint: use t-base interpolator so u can change the feedrate in middle of move...ramping is easy then...just add count up to a feedrate remember how long it took so u can count down at the end of the line.....but with servos...they just go where u tell them to go anyway here is a pic that was cut with one propellor
honestly tho...u better be great with math and geometry.....the programming is simple