For nerds only: Raspberry Pi for EMC2 controller? - Page 3

Page 3 of 8 FirstFirst 123456 ... LastLast
Results 41 to 60 of 159

Thread: For nerds only: Raspberry Pi for EMC2 controller?

  1. #41
    Registered
    Join Date
    Apr 2010
    Location
    USA
    Posts
    363
    Downloads
    0
    Uploads
    0

    Default

    I think better definition is needed. Most of us use our PC to create the code (CAD, CAM, etc) AND run the code (Mach3, EMC2, etc) Maybe some use different PC's for coding and running but it's usually for comfort reason. For example I create my files in my office, and then go to my machine and run them there. The only reason I don't create the files at the machine is I don't like standing while I work at a computer. I can, and often do quick changes and additions to my model there at the machine PC.

    What I am referring to when I started this thread was using RPI to be the motion controller with EMC2. CAD/CAM functions may or may come in that package.

    From what I have experienced, parallel is more reliable then USB.



  2. #42
    Member
    Join Date
    Jun 2007
    Location
    canada
    Posts
    3891
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by mpack View Post
    Maybe I came across too aggressive in that last post. I don't want to get involved in some pointless flame war.

    My objective would be to get the PC out of the workshop, not eliminate it from my life entirely. I don't want to buy a full PC dedicated to that one thing, I also don't want to have to cart a PC back and fore, and PCs are no good in the job anyway, especially if they don't have parallel ports any more (which modern ones mostly don't). Laptops while portable would of course be especially no good.

    Now imagine that I have a little box in the workshop next to the mill. When I want to make something I pop an SDcard into that box and click the on switch. The program on the card is created in the comfort of my home using a PC.

    That's the role I have in mind for the RPi.
    the raspberry pi IS a pc. adding it to yet another pc would just be totally redundant as it offers only a limited set of what the pc can already do but nothing more.

    right now a typical scenario is:

    PC -> Drive.

    a usb scenario is typically:

    PC -> USB converter -> Drive.

    a high end motion controller scenario is:

    PC -> Motion Controller -> Drive.

    what you seem to be proposing is:

    PC -> Raspberry Pi -> Drive Interfacre -> Drive.

    it just seems like youre adding devices that dont actually add anything very useful.

    what i would like is:

    Raspberry Pi -> USB converter -> Drive.

    the above yeilds something thats different than whats available now, and with several advantages, like cost and size and simplicity.



  3. #43
    Registered
    Join Date
    Apr 2007
    Location
    America
    Posts
    663
    Downloads
    0
    Uploads
    0

    Default

    crane550 stated: "The only reason I don't create the files at the machine [running CNC] is I don't like standing while I work at a computer. I can, and often do quick changes and additions to my model there at the machine PC."

    Like crane550, I have a separate computer for each of my two CNC routers, and have design computers in the studio and one in my home office. I use a portable hard drive to transport the design files, and a thumb drive to move g-code from the studio design computer to the CNC computer.

    And like crane550, I do not care to stand while designing and generating g-code. Concrete floors are too too hard on my back and legs. Gravity's adverse effects have increased as I have "matured".

    Neither of my CNC computers cost anything [helped friends clean out their houses!!]; each runs Windows 2000 and MACH3 is quite happy.

    A bit of research into parallel ports and USB will easily show that a parallel port is a much more robust interface, especially for CNC controller usage.

    However, RPI is a phenomenal little device. Its size, lost cost, and ease of coding certainly make it seem to be a "democratic" step to bring many benefits far beyond the CNC world.

    I hope all that have started with ideas of using it for a CNC controller will keep pushing forward, though I suggest that everyone not get quite so strident in their analysis of each others ideas.

    A more cooperative approach will move the idea forward much much faster. Hence this suggestion: When someone posts an idea or comment that seems to countervail the physical or electronic or coding norms, try to analyze the logic of the statement; i.e., follow the posters thought process from their initial statement, through their conclusions. Most assuredly, everyone will be much wiser using this method of critiquing each others contributions.

    A method to accomplish this is to write the response on a word processor, then proof-read the response, then reread the other person's original post, then reread your response, then get a good nights sleep, then reread the original post and your response.

    When you arise, reread the original post, then reread your response. Rewrite your response as needed paying attention to assure that your response is about the logic of the original posting and addresses the issues raised.

    The real power of written communication is in the rewrite.

    When writing, do not use words that convey emotionality. Stick with the logic of the matter at hand.

    Also: If the original posting is unclear or ambiguous, then ask the original poster to clarify the issues that you do not understand.

    Email may be instant, but human though still moves at the same slow speed.

    ps. I wrote consulting reports for over 30-years, and for the last 10 or so it was all for Court where written or spoken errors or uncivilized behaviour were the spell of doom!.



  4. #44
    Member Tkamsker's Avatar
    Join Date
    Oct 2010
    Location
    Austria
    Posts
    1189
    Downloads
    0
    Uploads
    0

    Default

    Hi
    I dont agree.
    I use win nc pc and emc2 ..
    I use alot cam Programms. Cut2d DeskProto bobcad ...
    So my toolchain is drawing turbocad or eagle then gcode on the stick to the machine.
    Seldom i do gcode on the machine.
    Verry verry seldom. Nothing what you couldnt do by handwheel /)-
    But i lost several millers due to win dows ....
    So i will First Update the small pcb Mill and then we see.
    I was thinking of an Port of emc2 to an ti3530 board ...
    May be an better soluzion have a beagle board Keep
    All pro of unix and emc2 and leave the cons of pc s
    Just
    My
    Point of view Thomas



  5. #45
    Member BanduraMaker's Avatar
    Join Date
    Dec 2010
    Location
    USA
    Posts
    634
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by mpack View Post
    I would point out that all the hard stuff can be done on a PC and stored on the SDcard as a data file - a kind of script to follow. All the RPi would have to do is read and write a few PIOs. I would have thought the application should be relatively trivial, doable in a few hundred bytes! Of course we'll need bootstrap and sdcard code on top of that - so call it a few thousand bytes. 512MB? And you think that won't be enough? Sheesh!
    mpack,

    I think that you might not understand fully what the process is. The problem with your idea is that as far as I know, there are no PC apps that would create the "script to follow" today. It would probably be possible to do so using a plug in to Mach 3 (or EMC but I have no experience with that) that could export a script but the file size could be quite ginormous - at least in CNC file size terms.

    Normally, CAM apps spit out G-code. The controller app then interprets the G-code, plans the coordinated motion using a trajectory planner and then spits out the pulse trains to control the motors. Implementation of a trajectory planner and other machine controls is non-trivial and it would certainly take more than a few hundred bytes!

    Something like the "Smooth Stepper" grabs the pulse data using a plug in to Mach 3 and then sends it to the smooth stepper via USB or Ethernet. The smooth stepper then generates the pulse streams with very accurate timing - this I think is what you've got in mind.

    It also stands to reason that a similar plug in could be made to "record" the pulse stream data to a file for "playback" on a stand alone controller as well but, the file size will be in the GB size for longer jobs as opposed to kB to MB range with G-code.

    If one truly wants to ditch the PC in the shop for machine control, I think that the best bet would be to make an embedded G-code interpreter with direct hardware control over I/O...a non trivial task that will probably take a bit more than a few hundred bytes!

    -Andy B.
    http://www.birkonium.com CNC for Luthiers and Industry http://banduramaker.blogspot.com


  6. #46
    Registered
    Join Date
    Apr 2010
    Location
    USA
    Posts
    363
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by BanduraMaker View Post
    mpack,

    I think that you might not understand fully what the process is. The problem with your idea is that as far as I know, there are no PC apps that would create the "script to follow" today. It would probably be possible to do so using a plug in to Mach 3 (or EMC but I have no experience with that) that could export a script but the file size could be quite ginormous - at least in CNC file size terms.

    Normally, CAM apps spit out G-code. The controller app then interprets the G-code, plans the coordinated motion using a trajectory planner and then spits out the pulse trains to control the motors. Implementation of a trajectory planner and other machine controls is non-trivial and it would certainly take more than a few hundred bytes!

    Something like the "Smooth Stepper" grabs the pulse data using a plug in to Mach 3 and then sends it to the smooth stepper via USB or Ethernet. The smooth stepper then generates the pulse streams with very accurate timing - this I think is what you've got in mind.

    It also stands to reason that a similar plug in could be made to "record" the pulse stream data to a file for "playback" on a stand alone controller as well but, the file size will be in the GB size for longer jobs as opposed to kB to MB range with G-code.

    If one truly wants to ditch the PC in the shop for machine control, I think that the best bet would be to make an embedded G-code interpreter with direct hardware control over I/O...a non trivial task that will probably take a bit more than a few hundred bytes!
    I agree- storing the data as a pulse stream would be a really really really big file. Probably in the gigabytes. When I proposed this project, I kind of had existing software already in mind.

    The RPI IS a small computer. Not a super powerful one, but when you compare it with the power of the early CNC controllers you will quickly realize it is not a matter of processing power that is lacking, but rather getting software to run on it.

    There already is a lot of CNC control software out there- some of it open source. The task here is to find a way to port that software to work with the RPI. Keep in mind, if a custom linux distro could be compiled which was stripped down (more so then the Ubuntu based EMC2 package) to a bare bones setup I think the hardware would be more then sufficient. That is the first task, getting the open source software we already have to work with it.

    Next step is hardware interface.

    EMC2 manually generates pulses to send to the motors directly as-is. The challenge here is to get those pulses to the motors the easiest and most efficient way possible. So now we need to look at our options- the physical outputs on the PRI.

    First is USB. While known to have some issues on PC's, it has still been a viable option for many people. Moving away from the broad PC market to the RPI would potentially change things, as it is no longer generic hardware we need to code our drivers for, but specific. The problem as I understand it with USB is irregularities with the pulse stream and latency due to sharing this bus with a lot of the other hardware on the system. Move it over to a propitiatory unit (the RPI) and much of that interference could be controlled. Remember, the idea is to strip down the software to bare bones. Only input from mouse/keyboard and the smoothstepper would have access to the interrupts. Proprietary drivers would be a must, but this is certainly not unheard of. It is EXACTLY what Mach3 does with its own parallel port driver that you must use when installing mach.

    Come to think of it, this case could be made for the Ethernet controller as well. Personally I think the 10/100 would be an easier use providing that drivers could be ported. As far as I know the Ethernet smooth stepper communicates over standard TCP/IP, a protocol not hard at all to harness.

    These are just thoughts. If I knew more about I would be working on it myself. I'm not much for coding, but what I AM good at is figuring out what it takes to make something work, and as far as I can tell the main hurdles are listed out right here.



  7. #47
    Member Tkamsker's Avatar
    Join Date
    Oct 2010
    Location
    Austria
    Posts
    1189
    Downloads
    0
    Uploads
    0

    Default Some Thoughts

    Hi
    for a project i was playing around with one of these
    Embest DevKit8000 OMAP3530 Evaluation Kit, TI OMAP3530, ARM Cortex-A8, 256MB DDR SDRAM, VGA, Camera, 3G, GPS, GPRS, WiFi, OMAP3530 Board
    they even have an Touchscreen
    i think also sufficient i/o there we could do the ethernet stuff.

    For my 3d printer ( shapercube ) the chain is reprap source
    where they use an http://reprap.org/wiki/RAMPS_1.4 als hart.
    There is different software out like merlin or sprinter to drive it.

    https://github.com/ErikZalm/Marlin

    And i think with am hand wheel we have an solution
    I am about to adjust this hand wheel for emc2
    (sorry for the german english will follow)
    EMC2 (linuxcnc) Handrad Arduino basierend - Aktivitaeten - tkamsker

    and this you could adjust to and hardware based controller.

    what dog you think ?
    thomas



  8. #48
    Registered
    Join Date
    Mar 2012
    Location
    UK
    Posts
    22
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by BanduraMaker View Post
    I think that you might not understand fully what the process is.
    That is undoubtedly true. I am in the position of considering what I would like in a CNC mill - I do not yet own one.

    I have heard of G-code, that is exactly what I had in mind as the script, though undoubtedly there will be other options. An ARM processor is easily capable of implementing a g-code interpreter that works in real time.

    [edit] It may also be worth pointing out that a data file measured in GB would not be a major obstacle - cheap SDHC sdcards I'm using for current embedded projects at work have a capacity of 8GB - bigger and more expensive ones are available. We must not confuse the memory capacity with the data capacity. Still, we wouldn't go for GB size data files if we didn't have to.

    The only objection that occurred to me overnight is - I didn't envisage the RPi having a display. Do people need a display in the workshop to tell you what the CNC widget is up to? It isn't an insurmountable obstacle if you do (I've recently written code to control and LCD display using an HDMI driver chip), however the display itself is not going to fit inside the box, and it's a bit of equipment I would be happier to eliminate.

    Last edited by mpack; 04-01-2012 at 06:49 AM.


  9. #49
    Registered
    Join Date
    Mar 2012
    Location
    UK
    Posts
    22
    Downloads
    0
    Uploads
    0

    Default

    Hi Thomas,
    When I first heard of the RPi it did sound remarkably similar to the processor and devtool evaluation kits I've used for years. For example the old EB30 Atmel ARM7 eval board I played with in... 1997?

    The problem with eval boards is that they are often available only in limited numbers, especially per person, and as the name implies they are sold at big discounts (maybe below cost) to encourage adoption of some processor in hw designs. The people who make them would be less than happy if they were disappearing off the shelves with no prospect of processor sales: and not enough sales of the boards themselves to offset mfring costs.

    The RPi is as cheap or cheaper and should not have these political problems. My only concern is that I don't know how they can make the RPi this cheap!

    ps. Got a big shock yesterday. Was Googling for info on the RPi and discovered that one of it's leading lights - Pete Lomas - is someone I know. My company owns shares in his company, we use them to design our boards, but sadly the RPi is a separate charitable hobby of his, so I get no shares from that... bummer :-)



  10. #50
    Registered
    Join Date
    Mar 2012
    Location
    UK
    Posts
    22
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by crane550 View Post
    Keep in mind, if a custom linux distro could be compiled which was stripped down (more so then the Ubuntu based EMC2 package) to a bare bones setup I think the hardware would be more then sufficient.
    I would be wary of that approach. First, it would require a lot of Linux expertise to decide what can go and what needs to stay. Second, if you start with a working OS and take bits out, chances are you'll have a non-working OS.

    What I had in mind was working from the opposite direction. Start with the CNC app: lets assume it's EMC for arguments sake. We take the source code and find out where all the OS calls are - and it's possible that the devs already isolated these in a few modules (I would). In which case we implement those calls more or less directly on the RPi hardware - we would have no OS to speak of at all.

    Each unnecessary frill would complicate the task. For example TCP networking would require a full network stack and drivers for the Ethernet chip. Ditto USB. So, we need to think carefully before adding these on some whim. If the RPi can control the motors perfectly using simple PIOs then there is absolutely no need to introduce something more complicated.



  11. #51
    Member BanduraMaker's Avatar
    Join Date
    Dec 2010
    Location
    USA
    Posts
    634
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by mpack View Post
    I have heard of G-code, that is exactly what I had in mind as the script, though undoubtedly there will be other options. An ARM processor is easily capable of implementing a g-code interpreter that works in real time.
    I'm sure it can, I'm just pointing out that the g-code interpreter/trajectory planner implementation is a non-trivial task.

    Do people need a display in the workshop to tell you what the CNC widget is up to?
    Absolutely. You might be able to get away with a few lines of text but a full blast display would be much better.

    Quote Originally Posted by mpack View Post
    What I had in mind was working from the opposite direction. Start with the CNC app: lets assume it's EMC for arguments sake. We take the source code and find out where all the OS calls are - and it's possible that the devs already isolated these in a few modules (I would). In which case we implement those calls more or less directly on the RPi hardware - we would have no OS to speak of at all.

    If the RPi can control the motors perfectly using simple PIOs then there is absolutely no need to introduce something more complicated.
    Now this sounds like a pretty good approach. There's definitely no reason to include a smooth stepper in this processes if there's already adequate I/O on the board....but, that has yet to be proven.

    You might check out the Dynomotion (kflop) site to get some ideas.

    -Andy B.
    http://www.birkonium.com CNC for Luthiers and Industry http://banduramaker.blogspot.com


  12. #52
    Member Tkamsker's Avatar
    Join Date
    Oct 2010
    Location
    Austria
    Posts
    1189
    Downloads
    0
    Uploads
    0

    Default

    Mpack:
    As i wrote if you want avoid the OS even if it is already ported. Then have a look at the ramps 1.4 stuff
    I think adding a little screen to see orientation does the Job.

    The ti. 3530 is also base of beagle board so i expect this boards to Stay.
    Thomas



  13. #53
    Member
    Join Date
    Jun 2007
    Location
    canada
    Posts
    3891
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by BanduraMaker View Post


    Now this sounds like a pretty good approach. There's definitely no reason to include a smooth stepper in this processes if there's already adequate I/O on the board....but, that has yet to be proven.

    You might check out the Dynomotion (kflop) site to get some ideas.
    the pi has 4 gpio pins. 1 will be used for a real time clock. so your left with 3.

    that is not adequate for cnc, unless you use them as a serial connection to an external board which would need development. at that point though to me youve defeated the purpose by making a complicated expensive system out of an underpowered PC.

    the only things the rpi has going for it are size and cost. if you eliminate one of those factors, you may as well buy a more fully functional system.

    alternatively you can go the other way, and use an arduino, which is better suited to be the "middle man" between a pc and a drive.



  14. #54
    Registered
    Join Date
    Sep 2006
    Location
    USA
    Posts
    10
    Downloads
    0
    Uploads
    0

    Default

    No offense, but I think some of you have no idea what are you taking about. Or you are simply insane

    Gcode was invented long time ago. In 1950s. First machine was running from vacuum tubes and relays!

    16mhz 8 bit AVR microcontroller with 2 kilobytes of ram can run gcode interpreter for a CNC machine. It has 2 kilobytes of ram.
    Grbl Gcode Interpreter - Contraptor
    http://www.youtube.com/watch?v=mHmDhi2u2BE]GRBLshield CNC Milling Machine Conversion - YouTube
    http://www.youtube.com/watch?v=QDKlZyB5RpE]Zen Toolworks CNC Controlled by Arduino/GRBL - YouTube

    We are talking about 700 MHz 32 bit ARM chip with 256 megabytes of ram. 300mhz Pentium equivalent. Turbo CNC can run on 66mhz 486 and 4 megs of ram.

    Parallel port must die for CNC the same way it died for printers. It is unreliable, it requires big old junk PC. It was great, but it starts to be outdated technology. Currently it exists pretty much only on second hand market. It is like floppy drive in some older industrial machines. Still works, but is it good? We can replace big, unreliable, noisy, delicate (dust and vibration) computers with something nice and small that won't require maintenance to keep it running.

    Raspberry Pi has 8 GPIO pins, SPI, I2C and serial port on the header pins.
    RPi Low-level peripherals - eLinux.org

    It is enough for 3 axis machine. With extra I/O port expanders on SPI or I2C you can have a lot more pins for spindle/coolant power, buttons, safety features, probes, MPGs, tool changers, LCD screens for DRO, etc...

    I think Raspberry PI has great potential for hobby CNC controllers. Because it is cheap there is great interest and there will be thousands of them. CNC controllers will grow on this platform the same way they did on Arduino.

    Arduino is the controller for RepRap. 3 axis stepper driven machine.

    In my opinion Raspberry will take place of PC and smoothstepper type cards for complete solution. It has enough power to run gcode interpreter and user interface and it has GPIO to run motor drivers and other electronics pretty much directly.

    Linux is not good for real time? I bet it is a matter of time to port changes and extensions they have for EMC (LinuxCNC) on PC Linux to Linux running on Raspberry.

    There are real time OSes for ARM chips.
    FreeRTOS - Wikipedia, the free encyclopedia

    Imagine something like this for your CNC machine:
    Introducing the MakerBot Gen 4 Interface Board Kit v1.1! « MakerBot Industries
    $100 seems about right. A lot cheaper and a lot more portable than a PC.

    But I think Raspberry PI will be able to do a lot more. This hardware has a lot more power than even higher end CNC requires.

    "Industry standard" Mach 3 requires 1GHz CPU and 512 megs of ram. Remember that it is running on Windows, so we have networking, multimedia and a lot of other crap eating those resources.

    Even if I'm wrong in the end we can always just add FPGA (smoothstepper equivalent) to those GPIO pins on Raspberry. It still will be cheaper and better solution than any x86 PC. I will invest my time and money to work on it.

    Last edited by KuchateK; 04-02-2012 at 08:28 AM.


  15. #55
    Member Tkamsker's Avatar
    Join Date
    Oct 2010
    Location
    Austria
    Posts
    1189
    Downloads
    0
    Uploads
    0

    Default

    Kuchatek :
    I was exactely referring to Kind of makerbot.
    As i work with cnc and now own a 3d printer i think you need an little Controller for the steppers servos relais toolchanger what ever so a Lot of gpio are required
    but fancy screen on an Mill in the basement whatfor.
    I can Control my printer even wireless from an android phone ...
    So i will Investor my time there lets see where i get till june
    Cu
    Thomas



  16. #56
    Member Tkamsker's Avatar
    Join Date
    Oct 2010
    Location
    Austria
    Posts
    1189
    Downloads
    0
    Uploads
    0

    Default

    Kuchatek :
    I was exactely referring to Kind of makerbot.
    As i work with cnc and now own a 3d printer i think you need an little Controller for the steppers servos relais toolchanger what ever so a Lot of gpio are required
    but fancy screen on an Mill in the basement whatfor.
    I can Control my printer even wireless from an android phone ...
    So i will Investor my time there lets see where i get till june
    Cu
    Thomas



  17. #57
    Member
    Join Date
    Jun 2007
    Location
    canada
    Posts
    3891
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by KuchateK View Post
    Raspberry Pi has 8 GPIO pins, SPI, I2C and serial port on the header pins.
    8?

    why was i thinking 4? its actually up to 17 it seems, if you dont need uart, spi, etc. one pin even supports pwm which could possibly run a spindle (not sure if it mees he needs of a vfd).

    with all that in mind, then yes, screw the external board. treat the gpio as if it was the pc's parallel, and youll probably have as just a much power as any other pc setup, for $30. the speed of the gpio seems adequate as well.

    now if only i could GET one of these boards!



  18. #58
    Member BanduraMaker's Avatar
    Join Date
    Dec 2010
    Location
    USA
    Posts
    634
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by KuchateK View Post
    No offense, but I think some of you have no idea what are you taking about. Or you are simply insane
    If you don't mean to offend, don't use offensive terms.

    Conceptually, a stand alone replacement for Mach 3 and/or EMC2 at a cheaper price is truly an appealing thing. However, if it's a step backwards in terms of features and possibly performance, much of its appeal is lost, at least for users such as myself.

    I'm a Mach 3 user and while it leaves many things to desire, it does have a very rich feature set and is quite flexible.

    Consider that a SmoothStepper is about $150, A 1GHz laptop is about $100 and Mach 3 is about $150. If you can out perform Mach 3 in terms of outright performance and feature set (including display) for <$400, you've got something that would be of interest to me.

    If on the other hand, you make something for $100 that has a crippled and poorly implemented G-code interpreter, lack of flexibility and a lack of features (e.g. spindle control, macros etc.) then you may have something of interest to some but certainly not to advanced users.

    -Andy B.
    http://www.birkonium.com CNC for Luthiers and Industry http://banduramaker.blogspot.com


  19. #59
    Member
    Join Date
    Jun 2007
    Location
    canada
    Posts
    3891
    Downloads
    0
    Uploads
    0

    Default

    i think what he was trying to say is the rpi is actually quite powerful enough on its own.

    after a little more refreshed reading, im inclined to thing hes right. for some reason i confused it with another board is was looking at with only 4gpio, 2 in 2 out. the rpi sees configurable enough to come close to matching the io on the traditional par port, with a theoretical clock speed that would not be a downgrade vs mach3's 100khz.

    so, a rpi, a realtime clock and a break out board in a tiny box for $100-$200 would be quite viable.

    the hitch now is someone needs to get software that works with it... whether its emc, mach3, or something from the ground up.

    maybe its time to implement one of my ancient ideas... a web browser based UI that talks back to a nice simple motion planner and pulse generator.

    couple that with xzeros new tiny low cost stepper drives and you might have something awesome and under $400 all in.



  20. #60
    Member BanduraMaker's Avatar
    Join Date
    Dec 2010
    Location
    USA
    Posts
    634
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by ihavenofish View Post
    i think what he was trying to say is the rpi is actually quite powerful enough on its own.
    Was anyone really disagreeing?

    -Andy B.
    http://www.birkonium.com CNC for Luthiers and Industry http://banduramaker.blogspot.com


Page 3 of 8 FirstFirst 123456 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


About CNCzone.com

    We are the largest and most active discussion forum for manufacturing industry. The site is 100% free to join and use, so join today!

Follow us on


Our Brands

For nerds only: Raspberry Pi for EMC2 controller?

For nerds only: Raspberry Pi for EMC2 controller?