Hackit: A Better Homebrew Control Interface?

I’ve built a few CNC controllers, and I’ve been a bit disappointed by the state of the control interfaces. Most diy systems rely on a parallel port interface, while a few use a serial connection. Just one that I’ve seen has an actual USB interface, but it’s limited to use with the fab@home software for now.
So what’s the hackit of the day? I think that the hardware hacking, home fabrication community could really benefit from a standardized I/O interface for driving CNC machines, robotics or anything else along those lines. For CNC work, it’ll need a serial or parallel port emulation scheme to allow existing software to take advantage of it. For quicker home development, some simple API’s for controlling the device would be excellent. Imagine using perl to develop robot logic with just a few easy function calls…

Hackit is really your show, so lets hear your ideas.

15 thoughts on “Hackit: A Better Homebrew Control Interface?

  1. I’m a fan of the PIC series with USB (I use the 18f4550 extensively, though I’ve used the 2550 for its smaller form-factor). When configured right, you can use a relatively small and simple circuit, run it off USB (with serial port emulation or full-speed), and even use a boot-loader to program it (no more needing that programmer after you get it going). There have been people experimenting with the boot-loader in non-windows environments, I know, but I haven’t really explored these.
    This is what I’ve been using to run most of my projects lately — especially with their samples program, it’s a fairly cheap option. Plenty of I/O ports, libraries for PWM, a decent amount of memory, wide operating voltage and the student version of their C18 compiler (with MPLab IDE integration) is fairly full-featured (completely full-featured for the first 90 days, if I recall correctly, then there are certain limitations). I’m actually already looking at using it for a CNC interface — I’ll tell you how it goes.

  2. Woops, forgot links :P

    ^^^18f wiki, it’s pretty good… the barebones schematic on the homepage is what I used to start. I’m pretty sure it’s compatible with their (Microchip’s) boot-loader from the get-go, but I decided to go the ICSP route to free up the input and memory limitations.

    ^^^Create USB Interface, another good design. Same basic idea, and a good read even if you don’t go with it.

    There’s more out there, but that’s a good start.

  3. i’m a sucker when it comes to cnc mills so excuse me if it’s an ignorant comment; how do you think usb protocol will benefit systems control?
    do they really need the extra bandwith? there are people out there who can (and probably to some extent did) write usb routines to control sensors, robotic arms and whatnot.. but i fail to see the shortcomings of a system which operates on fully optimized parallel port (or at least rs232) i/o interface..

  4. I prefer rs-232 for controlling embedded stuff. The drivers are simpler. This is good since my experience is that, given complicated protocols, many manufacturers will screw them up or (worse yet) roll their own.

    I also like serial because I can use hyperterminal (or z-term or kermit) to talk to the device when I need to test something. No (invariably broken) special tools that won’t install under my OS, no (usually insufficient and/or brain-damaged) APIs written in Visual Ada.NET.

    I use a laptop that has no serial port, but the usb-to-serial adapters work really well. If you insist on USB, the USB Bit Wacker seems to have things basically right. It presents itself to the computer as a standard modem device which you then talk to with normal serial using normal serial tools. Works on my mac, works on my pc. Folks running Linux seem to be able to use it fine.

    9600 8,N,1 please. No flow control. If you’re doing something that 9600 baud won’t keep up with then by all means, go faster. If not, please don’t. If you’re doing something that 115k won’t keep up with, then there is a really good case to use USB along with all of its associated nasty issues.

    Okay, I feel better now. Thanks for listening.

  5. as note of interest, an attempt at a cnc usb interface has been made by gecko drive using a rabbit micro, called the g-rex g100. there was/is a lot of discussion on the mach1mach2cnc yahoo group on the problems encountered using usb for cnc. it seems that latency is a big problem, and not throughput

  6. USB future-proofs the i/o interface. Parallel is history on new laptops and desktops, and parallel PCI cards are getting fewer and farther between. RS232 serial is quickly headed that way.

  7. as for the gecko usb board (grex) it also has a nic interface on it so throughput should not be an issue. i could be wrong on this part but i thought it also had somewhat of a buffer to get around any lag problems that might happen.

    #4 you are curious if mills need the extra bandwidth. absolutely 110% yes. the more steps per second (if you are using steppers) or the finer you can tune your encoders if you are using servos the better the output you will get will be. think of it kinda like this, if you were to draw a circle on an etch a sketch you would get lots of steps everywhere to make the circle, with the extra bandwidth you will be able to smooth those edges out somewhat. ok so that example is a bit exaggerated but stands true.

    what i would like to see someone do is write a driver for phidgets usb servo controllers to work with something like mach3 that is used often on hobby mills

  8. I got one of these to control a parabolic dish im using. it can only do .5a for steppers and you would have to wright software to have it take cnc commands easy. right now you send through HT “(WM1F100)” that moves stepper 1 forward 100 steps. i love it and am so happy to have it.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.