Shop OBEX P1 Docs P2 Docs Learn Events
CNC Machine with Propeller? — Parallax Forums

CNC Machine with Propeller?

AImanAIman Posts: 531
edited 2019-01-09 02:57 in Propeller 1
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?
«1

Comments

  • Alman

    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.
  • rosco_pcrosco_pc Posts: 449
    edited 2019-01-09 07:21
    It is possible, some examples:
    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.
  • "Torque", "resolution", etc...
    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.
  • idbruceidbruce Posts: 6,197
    edited 2019-01-09 18:53
    Mickster

    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
  • At the moment I am using a ShapeOKO desktop milling machine, and am very happy with it. You can buy it, or one of the many other brands, for about $1000 ready to go. Some require assembly as they come in kit form, but I have never had any problems. The biggest thing is the GRBL software (lots of protocols and standards, its a book!) used to actually take your GCODE and translate it into stepper motor pulses. You can buy a complete GRBL controller board (ShapeOKO or Micromite) ready to go, for $100 to $200 depending on features.
    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'
  • idbruce wrote: »
    Mickster

    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

    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.
  • idbruceidbruce Posts: 6,197
    edited 2019-01-10 01:12
    Mickster
    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.
  • It can only be that those guys are having to jump through hoops because they don't have the Prop's capabilities (I should really study it before making these comments, I know).

    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?
  • @idbruce has some longer thread here where he tried to port some existing software, but as you said @Mickster the code does not take in account the options a Propeller has. It is written for a single core using tons of interrupt routines.

    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
  • idbruceidbruce Posts: 6,197
    edited 2019-01-10 03:14
    Mickster

    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
  • Okay, I just checked....

    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.
  • msrobots wrote: »

    The next thing is that ramping and position calculations where done in floating point math.

    Mike

    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.
  • 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.

    Interesting
  • Mickster wrote: »
    msrobots wrote: »

    The next thing is that ramping and position calculations where done in floating point math.

    Mike

    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.

    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
  • Well you need to provide a buffer of subsequent command positions so that there is no motion interruption, just a series of blended moves, works beautifully.
  • If we were to move along a 1.0” diameter circle at a speed of 1.0” per second, and we
    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. :lol:

    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:
  • msrobots wrote: »

    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.
    Mike

    Great example of why I constantly harp on about closed-loop-servo.

    Provide the feedback and the PID will compensate.


  • AImanAIman Posts: 531
    edited 2019-01-12 04:54
    I personally don't like steppers for applications like this, but they are fairly common in CNC kits.

    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.
  • Alman
    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.

    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.
  • MicksterMickster Posts: 2,588
    edited 2019-01-12 13:42
    AIman wrote: »
    I personally don't like steppers for applications like this, but they are fairly common in CNC kits.

    Exactly...and they're ten-a-penny. All the more reason to come up with something better.
    Also, why mess with a PID? Why not just code so the problem doesn't exists?

    If we are talking servos, how would one avoid PID to control an axis?
    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.

    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.

  • In theory the resolution or smallest unit of the machine is controlled by software but in the real world it's the physics of the machine itself.

    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.
  • Genetix wrote: »
    In theory the resolution or smallest unit of the machine is controlled by software but in the real world it's the physics of the machine itself.

    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
  • idbruceidbruce Posts: 6,197
    edited 2019-01-12 18:06
    Indexing slides with "live tooling" can perform operations such as milling, drilling, threading on a workpiece that is held/positioned by the spindle.

    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 :)
  • idbruce wrote: »
    Indexing slides with "live tooling" can perform operations such as milling, drilling, threading on a workpiece that is held/positioned by the spindle.

    How big of chucks do these machines have?

    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.

    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.


  • Well then, perhaps I am mistaken about the chuck size, because the the machines I was around were very similar to your pic.
  • I can only imagine what I could accomplish with a machine like that!
  • Can you believe the control specs:

    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:
  • Can you believe the control specs:

    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 :)
  • P1, albeit with a preprocessor on the front end, could easily do all that. This uses the interpolation method previously discussed. The LM628s only close the servo-loops, the actual motion trajectory stuff isn't used. They are set for instant accel/decel. The PC bangs position commands at the rate of 1KHz to each LM628.
Sign In or Register to comment.