CNC Machine with Propeller?
AIman
Posts: 531
I was wandering through the web this week and came across a CNC DIY kit for the Arduino. It occurred to me I could make my own using a propeller and improve on the simple synchronous belt system with both stability and finer measurements.
This is the general overview.
Use lead screws for X,Y and Z axis with linear scales and a gear on the output motors shaft to run past a hall sensor for counting ticks. The motor would run through a gear reducer so that a steppers resolution would be greatly increased. The gearing down is important to achieve higher resolution and the lead screw will eliminate some of the problems with using a belt, it will also improve a stepper motors resolution if the motor shaft is used for counting ticks.
For railing, use simple rods with linear ball bearings (two per rail and maybe more), preferable pillow blocks.
Then for the up and down, mount a fixed cut out above the max height with a L shaped bracket to hold the motor for the bit. The L shape is specific because the small part of the L is where it would attach to motor that moves the bracket up and down past the linear scale and the long part of the L pointing down would be where the motor and bit attach. When fully raised the tip of the bit would be above the highest part of the working area.
However, this concept requires 4 motors. One for X, Y and Z axis and one for the bit. Also note that by gearing the motors down from, say 2000 rpm, to a minimum of 50 rpm, it opens up the possibility of carving metal. The lower rpm is especially needed for harder steels. Changing out the bits is up for debate as there are several possibilities to do this, obviously one is to manually change the bits but what fun is that?
A Propeller should be able to handle this without a problem.
Thoughts?
This is the general overview.
Use lead screws for X,Y and Z axis with linear scales and a gear on the output motors shaft to run past a hall sensor for counting ticks. The motor would run through a gear reducer so that a steppers resolution would be greatly increased. The gearing down is important to achieve higher resolution and the lead screw will eliminate some of the problems with using a belt, it will also improve a stepper motors resolution if the motor shaft is used for counting ticks.
For railing, use simple rods with linear ball bearings (two per rail and maybe more), preferable pillow blocks.
Then for the up and down, mount a fixed cut out above the max height with a L shaped bracket to hold the motor for the bit. The L shape is specific because the small part of the L is where it would attach to motor that moves the bracket up and down past the linear scale and the long part of the L pointing down would be where the motor and bit attach. When fully raised the tip of the bit would be above the highest part of the working area.
However, this concept requires 4 motors. One for X, Y and Z axis and one for the bit. Also note that by gearing the motors down from, say 2000 rpm, to a minimum of 50 rpm, it opens up the possibility of carving metal. The lower rpm is especially needed for harder steels. Changing out the bits is up for debate as there are several possibilities to do this, obviously one is to manually change the bits but what fun is that?
A Propeller should be able to handle this without a problem.
Thoughts?
Comments
A fellow machine enthusiast here.
Let me begin by saying that I am a big fan of the Propeller and I am also a big fan of designing and building machinery and/or gadgets.
In my opinion and experience from previous woes, I would not attempt another complex machine, based upon the P1, especially if you are wanting software that has linear and circular interpolation, look ahead planning, etc..... The software gets quite complicated and large, and you may run into the same problems that I have had in the past, which was running out of necessary memory. I am not saying that complex machinery cannot be built with the P1, because I have done it, but if you want bells and whistles, then perhaps you should plan your design around the P2, which will have, I believe.... nearly 5 times the memory.
Additionally, if you plan on building a complex machine and you want bells and whistles, then you should be a decent C or C++ programmer, which would give you the possibility of porting previously written code for CNC, which was never intended to be run on a Propeller, because very little CNC code exists for the Propeller, 1 or 2.
http://obex.parallax.com/object/85
http://forums.parallax.com/discussion/163715/project-homebrew-laser-cutter
Edit: Sorry the examples only show 2 or 3 motor control. Adding control for the bit should be possible though
Yea, Jason is one smart MoFo.... I miss his presence in the forum.
Why bother with steppers?
Real CNC machines use closed-loop servo motors.
There are objects already available for PID and quadrature decode. Everything else could be coded in SPIN where you probably won't have a memory issue.
Personally, I would use the Prop for the real-time stuff and stick something like a Micromite on the front end or even an Android device.
If we are talking about a serious machine here, then we are also talking about serious firmware, something such as GRBL, which will need to be ported to the Propeller. I highly doubt that firmware would fit into the P1.
EDIT: However I am almost certain it would fit in the P2
GRBL Firmware: https://github.com/grbl/grbl/wiki
All is well and good, But then you need decent graphics and Computer Aided Manufacturing (CAM) software to take your idea into some sort of 2D or 3D dimensioned model. I use V.Carve Desktop software, but there are a host of others out there. Hint: Even with all this CNC equipment and software, it REALLY helps if you have shop and machining experience. Knowing feeds and speeds, the different types of cutting tools and metal working experience can make all the difference between a professional job and something hacked together, just sayin'
Yeah, granted that I didn't really study the Teacup(?) stuff but I wonder what can be such a memory hog? At the end of the day, we need to read instructions and translate them in to axis movements. Early CNCs had very little RAM and so the G/M codes were streamed in via paper tape.
I see one cog for all PIDs and one cog for encoder reading...the rest of the P1 is available. Hanno Sander's balancing bot is a HUGE program (although I don't look at much SPIN code)...I fail to see how a command interpreter can be so resource hungry.
Actually, the interpreter can eat up quite a bit of memory by itself, but that is only a small portion of the whole solution. There are many other objects, behind the scene, performing very important tasks, and they all eat up memory.
When looking at firmware, such as Teacup or GRBL, there are literally thousands of man hours behind each of those projects, from various contributors. As you know, and as can be witnessed by the evolution of the P2, when a community of contributors work together on a common goal, something good is bound to result from it. One man trying to do the work of many men, may lead to heart failure.
Perhaps when the P2 has gone through it's testing phases and the kinks have all been worked out, then perhaps I might consider attempting a port of GRBL, but in no way would I ever attempt to write such firmware by myself. It would never get finished, because of the lack of knowledge and ambition.
I just don't see that much to do.
I think I will look at it over the weekend.....Do you have any useful links to where I should start?
The next thing is that ramping and position calculations where done in floating point math, something the propeller does not really shine in.
Some years ago I tried it with Spin and PASM, got somehow stuck on circular interpolation and then the Windows Update against Spectre killed my computer. I still have it, might be possible to boot into some knoppix and recover the files, I just hadn't had the time and energie to do so.
Enjoy!
Mike
The link I gave above is to an old site. I believe this link will give you access to the latest version, which is v1.1.
https://github.com/gnea/grbl
Go to that link above and click on the "Clone or download" button.... After downloading and opening up grbl-master.zip, open the grbl folder and all the source code is in there.
Well that's a turn-off right there....totally unnecessary. I don't know of a high-end motion controller that doesn't work with integers.
Yeah, I've also seen some over-complicated methods of interpolation.
Again....unnecessary.
An X and Y axis each running a PID @2,048Hz (this is where the Arduinos require an interrupt, obviously). I command the X to a position of, say 5 units and the Y to 10 units and I want both axes to arrive at the same time (interpolated). The PIDs divide their respective commands by 2048 and the axes receive those increments for each loop cycle...Voilà...they are synchronised. Path velocity and resolution is dictated by the spacing of the subsequent commands.
Interesting
Right, it can be done with scaled integers, but the existing C code does not. I also was thinking along your path to just normalize the next step to a common time(step) base. But it does not work, really.
I tried. Its horrible for the machine. Constant stop and go, lots of unneeded vibrations, lots of noise. It does not work like that. You need to plan ahead, reading say the next 2-5 needed positions of all axis and calculate the current velocity into the pid loop. The goal is to get the smoothest move. And that has to be done on the 'interpreter' side, the software generating the G-code just tells you where to go and even sometimes with what speed. But the firmware needs to smooth it out to accommodate the hardware.
And here the Propeller did wonders. Since I could split the tasks to different cogs it was working pretty nice until Windows update wrecked my computer.
I am just a CodeMonkey, I did not found any real world project where I could use a micro controller for myself. I just program the propeller because it is fun. Compared to my work environments, either Big Iron in COBOL or C# on WIndows servers, programming the P1 (and now the P2) is extremely relaxing and a lot of joy for me, maybe even because it is completely noncommercial and just - hmm -playing.
I was testing my code on a 3d-printer, not printing anything, just moving 3 axis. But the 2 printheads I was moving where quite heavy and velocity came into the play very soon. I guess that this is also a problem with commercial machinery. You know better than me, I guess.
The P1 was sort of almost there, but the P2 will be able to do that nicely. I am looking forward to play with that,
Mike
approximated the circle by a series of straight line segments spaced at 30 Hz intervals, the maximum error between the straight lines and a true circle would be 0.00028”. So, elsewhere, another cog or a host controller will have ~33ms to calculate/provide the next path-point.
If we switched to 60Hz (~16ms to calculate the new path-point) intervals, the maximum error would drop to 0.000069”. Slowing down the motion or increasing the radius of curvature would further increase the accuracy.
I think you would agree that 16ms is pretty much an eternity for the Prop.
For me, the really cool possibility is to achieve tightly coordinated motion over a relatively slow (115KBAUD) distributed network (RS422/485).
Wireless CNC control is my ultimate objective but I'm sticking 422/485 on there, just in case. :cool:
Great example of why I constantly harp on about closed-loop-servo.
Provide the feedback and the PID will compensate.
However, using FREECAD (3D parametric modeling) or QCAD would solve a lot of problems since both are open source and free. All that needs to be done if using one or both of those is reading the file.
Yes it can be a pain to cross code languages, but it means not having to address with other problems.
Also, why mess with a PID? Why not just code so the problem doesn't exists?
One of the biggest problems when doing manual machining is that the spindle speed is set way to high by the user. Metal needs low speed, and a simple hall sensor for speed control should do the trick.
Good Luck with that!
There is a lot more to it than just reading a file. I can write a Propeller program to read files all day long, but that is not going to get any machining done.
I have started more CNC threads, than probably any other member on this forum, but the interest and support just isn't there to make any serious things happen. I am hopeful that CNC support and interest will change with the P2.
As mentioned, for the type of project you are talking about, you will need some serious firmware to back it up.
If you can write your own firmware to make it all happen, then more power to you, and I wish you success, but for the P1, be careful.
If you search, you will find several threads, pertaining to CNC parsers, interpreters, interpolation, etc.... If you can get something to fit on the P1, it will be very limited in what you can achieve, as per memory, as I indicated, regardless of what others have said.
Exactly...and they're ten-a-penny. All the more reason to come up with something better.
If we are talking servos, how would one avoid PID to control an axis?
This depends on how sophisticated you want to get. Not all spindles simply spin. If you look at Gildemeister, Index, Mupem, lathes, their spindles are fully position controlled. Indexing slides with "live tooling" can perform operations such as milling, drilling, threading on a workpiece that is held/positioned by the spindle. We are talking lathes with 9+ axes, mind.
The feed rate is just as important as the spindle speed since the two combine to determine the MRR or Material Removal Rate.
While there are books and tables for speeds and feeds, these are just reference values since the part and machine setup may or may not work with them.
+1
How big of chucks do these machines have?
EDIT: I know it all depends on the size of the machine
EDIT: Sounds like some very serious machines. I once worked in a shop that had machines that could have probably accomplished all of that, but I believe the chuck size was probably 6~8 inches.
EDIT: I am really becoming attached to small machines, because it definitely eliminates all of the complexities of larger machines. However it all depends on the intended purpose of the machine and the depth of design. Way above my pay grade
Funny you should ask. My last post prompted me to check on Mupem because between 1989 and 1993, they used my 9-axis, PC-based control and then switched to the big name suppliers due to customer preference. At the time, the biggest was 65mm but looking at this video, it appears that they now go all the way to 100mm.
80286 @ 8MHz
9 X LM628 motion processors on 3 ISA cards
DOS
Software, including integrated CAD is MS QuickBASIC and MASM for interrupt handling.
LOL...
C'mon Mickster..... That is your ball park... I am still in the minors