Shop OBEX P1 Docs P2 Docs Learn Events
Help us develop an open-source motor controller for RepRaps, CNC mils, etc… — Parallax Forums

Help us develop an open-source motor controller for RepRaps, CNC mils, etc…

David CarrierDavid Carrier Posts: 294
edited 2014-05-30 04:06 in Propeller 1
We would like to develop a low-costs motor controller system for RepRaps, CNC mils, laser cutters, pick and place machines, robotic arms, or any other precision computer controlled motor application.

I spoke with Brook Drumm, who is heading the Printrbot campaign, when he came by Parallax right after launching the Printrbot on Kickstarter, and we discussed the future plans and needs for the Printrbot and for RepRap in general. I had previously discussed the direction of other RepRap variations at the Open Hardware Summit where I spoke with Josef Průša, who was demonstrating his variation of the RepRap Mendel, and with a representative from Ultimaker, whose name I cannot recall.

Each new variation of the RepRap hardware seems to focus on one or more of the following goals:
  • Cheaper — lower total costs for kits and assembled units
  • Easier — less work to build, calibrate, maintain, and use
  • Better quality — Higher resolution motors motors for more precise 3D prints
  • Faster — Higher speed motors and other optimizations to decrease print time
It would be a significant help to these goals if the electronics used the Propeller microcontroller, for the following reasons:
  • Resources — The Propeller microcontroller has enough processing power to perform tasks that are offloaded to expensive stepper motor controllers, which currently outweigh the cost of the microcontroller itself.
  • Parallelism — Speaking of stepper motors, they have a high cost for a given speed, resolution, and torque. Other motor options require more feedback capabilities than most 8-bit microcontrollers can handle. The Propeller can perform these tasks while directly controlling these motors, through inexpensive discreet H-bridges.
  • Abstraction — The current electronics hardware is at the limits of its capabilities, and adding new features can hamper existing features, requiring careful testing and coding to ensure that enough processing time remains to perform all of the tasks. With the Propeller, different tasks can run in different cores, known as cogs, so that each task cannot interfere with another.
  • Support — Parallax is willing and able to stand by and support the open-source projects that use its products, including the Propeller Microcontroller. It is rare fore microcontroller manufacturers to acknowledge their open hardware customers, let alone contribute to their projects.
There are other open hardware projects, such as the Lasersaur laser cutter and the OpenPnP SMT pick and place machine, that need similar motor control hardware, that would have similar benefits from an open-source Propeller-based motor controller. The motor controller would also be useful for anything that requires precision motor control, such as CNC mils or robotic arms.

We would like to propose such an open-source motor controller with the following goals:

Inexpensive
The motor controller should have a low total parts cost, and it should be easy to manufacture, so that it can reduce the costs for any of the projects using it

Backward compatible
It should be compatible with the electronics that RepRap projects, such as the Printrbot, are currently using.

Capable
It should match or outperform every feature that current RepRap hardware requires.

Scalable
It should be able to work with different motor types, such as stepper motors, brushless DC servo motors, and brushed DC gear motors, to cater to different designs.

We would like to know who would be interested in using such a board, especially in open hardware projects like Printrbot, and we want feedback on what specific features or specifications would help with specific applications. We would also like to know who would be interested in working on the project. We will not be developing it in house, so we are looking to hire out the design to someone who can create the schematic and layout as well as collect input from the community.

See the following post for the proposed feature set, which we will be updating as we collect feedback. We are also open to suggestions for a name for the board.

— David Carrier
Parallax Inc.
«134

Comments

  • David CarrierDavid Carrier Posts: 294
    edited 2011-12-15 16:53
    Current feature list:
    • Compatible, using GCC, with current RepRap firmware written in Wiring
    • USB connection to a computer
    • Logic powered from USB port or from motor power supply
    • Can load firmware and G code programs to and from a microSD card socket
    • Eight full H-bridges with current limiting, for use with up to four stepper motors, or up to eight brushed DC motors. Six of the full H-bridges will be pairs of half H-bridges, which could be used to control brushless servo motors.
    • Many I/O pins for limit switches, encoders, and other devices. Some may use shift registers on slow signals.
    • Several low-side FETs for the hot end, a heated bed, and other devices (probably four)
    • Analog inputs for thermistors and other sensors (probably four or eight)
    • I2C and serial buses for further expansion
    A stepper motor takes two H-bridges, a DC geared motor takes one H-bridge and an encoder, and a brushless servo motor takes three half H-bridges and an encoder. Propeller I/O pins will be a limited resource on this board, but if we make efficient use of them we will have more than enough. If the board only had half H-bridges, it would take sixteen I/O pins to run four stepper motors. If it only used full H-bridges, it would only take eight I/O pins, but couldn't run brushless servo motors. A combination of twelve half H-bridges and two full H-bridges will require 14 I/O pins and will be able to run up to four brushless servo motors or up to four stepper motors.

    So far, I have only seen RepRaps using stepper motors, but Brook Drumm at Printrbot is interested in reduce the costs for future higher volume runs, which may necessitate different motors. He is on board with using this board on future designs, so we will be coordinating our feature set to make sure that the board performs all of the functions that he needs. We won't know what full advantages and disadvantages of other types of motors until some makes a prototype and tries it out.

    — David Carrier
    Parallax Inc.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-12-15 17:19
    David,

    My MakerBot has several boards in it, rather than just one. Four of them are stepper controllers: one for each stepper. I'm wondering if this is not a more desirable approach than one monolithic do-all board. For one, it will give users the opportunity to pick and choose the features they want or need. Plus, there may be economies of scale from having multiple, identical, but smaller boards, rather than one big one. A host platform into which smaller boards can be plugged, rather like the current MoBo, but on a bigger scale might be one option. (In the MakerBot, the boards are connected by ribbon cables, which is an added expense.) A bussed system in which all boards are connected in parallel but which, unlike AppMod-style busses, includes dedicated address and data lines is another possible way to achieve modularity.

    Is this an approach that your feature list could accommodate?

    -Phil
  • David CarrierDavid Carrier Posts: 294
    edited 2011-12-15 18:14
    Phil,
    I didn't mention it in the post, but the cost cutting aim is for high production quantities. At low quantities it makes more sense to have separate boards for each motor, because the central controller can be the same across different feature sets, and the quantity of the motor control boards will be much higher than the quantity of the central control boards. As the total quantity increases, the costs of building separate boards for each motor outweighs the cost savings from building a high quantity. The cost of the connectors also becomes significant. Since the Propeller could directly drive a discreet H-bridge, the cost per H-bridge will be very small, probably tens of cents each. Even at high quantities a pair of IDC connectors and a ribbon cable will cost much more.

    RepRap does seem to show some interest in through-hole boards that could milled on a modified RepRap. I like the idea of publishing a designing for a through-hole variation of the board, and in that case having a discrete H-Bridge PCB for each motor may simplify manufacturing and debugging. We wouldn't be building them though, it would be a design for those who are building a RepRap using as few Vitamins as possible. They seem to be pushing for through-hole PCBs for those assembling their own boards, but if someone designs a pick and place nozzle for the RepRap, SMT boards would be easier to build.

    — David Carrier
    Parallax Inc.
  • pedwardpedward Posts: 1,642
    edited 2011-12-15 18:19
    I have started on the software end of this. I think it's silly to buy ~expensive driver chips for stepper control when the Prop has a lot of horsepower. If you look in my profile, you'll see some microstepping posts.

    I am already on the way to developing a microstepping object for the Prop. I expect this could be modified to do direct DC control and ultimately, 3 phase control.

    I don't know how involved I'm going to get in the microstepping. I've pushed it to about 50K steps per second with open loop current control and high-er voltage.

    I have a variety of steppers to play with and I need to build a driver board to get outside of the baby category. I've run the motor from a head assy in an optical drive using the L293 in the PPDB. I'm probably going to make a dual h-bridge out of discretes, since I have them. I also want to do some current sampling to see if adjusting the chopping or advancing the waveform might help.
  • frank freedmanfrank freedman Posts: 1,983
    edited 2011-12-15 18:58
    David,

    My MakerBot has several boards in it, rather than just one. Four of them are stepper controllers: one for each stepper. I'm wondering if this is not a more desirable approach than one monolithic do-all board. For one, it will give users the opportunity to pick and choose the features they want or need. Plus, there may be economies of scale from having multiple, identical, but smaller boards, rather than one big one. A host platform into which smaller boards can be plugged, rather like the current MoBo, but on a bigger scale might be one option. (In the MakerBot, the boards are connected by ribbon cables, which is an added expense.) A bussed system in which all boards are connected in parallel but which, unlike AppMod-style busses, includes dedicated address and data lines is another possible way to achieve modularity.

    Is this an approach that your feature list could accommodate?

    -Phil

    Phil,

    I like your idea of multiple smaller boards. My original project, the curve tracer has been back burnered for the moment as I am running down the A/D, D/A path with ADD (no H in my ADD diag.) abandon. My implementation of the single channel MCP3201 was expressly for the purpose of capture in parallel with no time skew between channel samples. The initial as OBEX'd design will let me put up to 6 of these in parallel with the same prop chip, and leave enough time to store and/or transfer the samples in near real time. Now we get C into the mix and I am trying to integrate that into my mix of stuff. So what does this have to do with multiple boards?

    Just this, another branch from the curve tracer. I am sure there are others out there with far more understanding of audio processing and equipment than I. Specifically as regards music and recording systems. Picture an extensible sound board, only a few channels such as a garage band could afford. Put a prop on a board with one channel on it and enable multiple boards worth of expansion. That leaves five cores unused. Rip a page out of digital medical image acquisition and processing. It is all realtime. No computers involved beyond say control of the system and perhaps look-up table generation and loading. The image stream proceeds through a pipeline structure with each effect being done sequentially as the stream passes through a specific circuit for processing. With five cogs, one could conceivably set up a different effect in each cog and pass the audio stream through each cog sequentially. All on one single (very) small board for each channel. Expandable at will. The Caxton Foster book on Real Time Programing barely touched the surface of this subject..

    Stepper boards with an individual prop on an Arcnet/token-ring or CAN loop, each self contained. Need two for just x/y, good start. Add another including input position sensing as would be existing on x/y now you have basic three dimensions. What about a fourth module for table rotation or jaw offset travel? Stepper controlled drill/mill head? Sure!! Modules all the way, and if a module looses its magic smoke, replace it and have the master controller download the modules specific software and parameters over the CAN net. And if carefully designed, the modules should be similar enough to make most of them interchangeable differing in software only for the majority of them.

    About to go random, not enough time to do all the ideas that start diverging from here..............


    Frank
  • idbruceidbruce Posts: 6,197
    edited 2011-12-15 19:16
    It should be able to work with different motor types, such as stepper motors, brushless DC servo motors, and brushed DC gear motors, to cater to different designs.

    Sounds like a very tall order :)
    So far, I have only seen RepRaps using stepper motors

    Steppers will give the accuracy needed for this type of application

    If you want to design a discrete board, perhaps a design of two full h-bridges that utilize mosfets with a current limiting scheme for PWM would be a good choice.

    Bruce

    EDIT: There has been some talk about controling HEXFETs IRF3708 from the Propeller within the forum, perhaps this might be a good choice for h-bridge construction. 30 volts for a reprap sounds pretty good.

    For circuit diagram, go here: http://machinedesign.com/content/chopper-controlled-current-limiting-1209-0

    For those that want to read the whole article, go here: http://machinedesign.com/article/limit-current-to-boost-stepper-motor-torque-1209

    On the other hand, should you decide to go with an IC solution, I personally like the attributes of the L6208.
  • ElectricAyeElectricAye Posts: 4,561
    edited 2011-12-15 19:59
    ...

    My MakerBot has several boards in it, rather than just one. Four of them are stepper controllers: one for each stepper. I'm wondering if this is not a more desirable approach than one monolithic do-all board. ...

    Speaking as a perpetual noob, I, too, would suggest keeping things modular. I once built a single PCB that could control 3 steppers and was thrilled I could get the Propeller to work everything at once, but my poor soldering skills caused a chip to get fried on a board that I had nearly completed, and because the board was so loaded with other components, it was hell trying to fix the problem and salvage the thing. Nowadays, I keep things modular just so it's easier to handle when things go wrong. So if these boards are meant to be DIY, then I wouldn't go with SMT or monolithic PCBs.

    my 2 euros worth.
  • pedwardpedward Posts: 1,642
    edited 2011-12-15 21:17
    My microstepping driver will drive 1 motor per COG. I just ordered some L298 samples from ST to build a driver board. If you are doing a typical 4 motor system, you would only need 4 COGs for stepper control,. That leaves 4 COGs for communication, motion control, G-code interpreter, and user interface. That's just the simple of it, I'm sure a determined developer could cram a lot more into that.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2011-12-15 21:38
    Just on the subject of stepper motors specifically I have to say that I am very happy indeed with the L6470 micro-stepper chip. It's only a tiny little HTSSOP28 pack and yet I'm driving large stepper motors very efficiently and using only the pcb copper as heatsink. I have a customer who has used L298s and L6203s etc in these same applications with the same motors yet they needed big heatsinks and didn't do microstepping etc. Plus the motors used to get hot. He can't believe that something so small can drive these steppers with 128-step microstepping and I have made these motors fly faster and smoother than other expensive $$$ stepper controllers units he uses for the big jobs. In terms of Prop resources it doesn't require real-time control and monitoring so you can drive it straight from the application code using up to 8 pins yet only 4 are required and 2 of these I share with the EEPROM's I2C bus pins. How simple is that?
  • 4x5n4x5n Posts: 745
    edited 2011-12-15 22:00
    Is there any thought to how much current this driver is to be able to supply? The reason I ask is that I have an application that will need to be able to deliver 2.5+amp to a bipolar stepper motor. Off the shelf drivers are expensive. :-)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2011-12-15 22:15
    A discrete design should have no problems handling 5 amps or more. As for steppers the L6470 I mentioned handles 3A RMS per winding with 7A peak. Some of the other stepper drivers quote figures which are misleading as they combine the current from both windings and quote peaks. The L298 for instance is only 2A per channel and although it's easy to solder it still needs a heatsink and 8 suitable schottky diodes as well as a couple of large current sense resistors. Also, the L298 is only a bridge with very basic gating logic so it requires more again to make it a proper phase-chopper let alone a microstepper.
  • bsnutbsnut Posts: 521
    edited 2011-12-15 22:46
    I2C and serial buses for further expansion
    I love to see RS485 for communication between the boards and the cool thing is that you will use only 4 I/O to do this.

    Overall the whole idea for this motor controller is a good and many uses such as props.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2011-12-16 03:36
    Not sure if you are saying the Prop only requires 4 I/O for RS485 or 4 I/O for both RS485 and I2C, however RS485 only requires 2 Prop I/O. The 485 chip is either in transmit or receive so therefore the RX and TX pins are tied together back to a single Prop I/O with the other Prop I/O controlling the combination of /RE an TE. Ideally a pulldown would used on the TE line to ensure that the 485 chip was never placed into transmit mode during reset etc. The I2C lines can be the same as the EEPROM's I2C, there is no need to have separate buses as it is indeed a "bus".
  • GadgetmanGadgetman Posts: 2,436
    edited 2011-12-16 03:41
    One point...

    Many(if not all) RepRap board designs now have room for 5 stepper motorcontrollers.
    X, Y, Z, Extruder and Extruder2...

    It must be able to handle heaters(extruder hot-end, optional heated printed, possibly a second hot-end) and the same number of thermistors(have to make certain you don't overheat something), fan control... (For cooldown. Sometimes used when printing tall items with small cross-sections)
    You also need at least 3 endstops, but some want 6.
  • Mark_TMark_T Posts: 1,981
    edited 2011-12-16 03:49
    MOSFETs are not necessarily needed for discrete H-bridges BTW - For instance recently I've built some little DC motor H-bridges using NPN/PNP dual high-performance transistors PBSS4032SPN.

    These are 8-SOIC package 30V 5.7/4.8A, low Vce (150mV/ 210mV at 2A), high gain 450/250 typ at 2A (NPN/PNP values). Having two devices in one package reduces the footprint (although external flywheel diodes are needed (which can be schottky though). And cheap.

    Suspect the hard part is fast current sensing for bipolar stepper driving - 4 channel comparator LM339 looks a useful device.
  • idbruceidbruce Posts: 6,197
    edited 2011-12-16 04:10
    MOSFETs are not necessarily needed for discrete H-bridges BTW

    I never said they were, and I think most of us realize this.

    **************************************************************************************************

    Here are some more of my thoughts:

    I believe the design should be dmos compatible

    I believe the design should follow the basic industry standard that is being set. Each driver should only require three IO pins: Direction, Step, and Enable.

    I believe the design should also follow another industry standard of having a means to adapt a current set resistor.

    And once again, I also believe that the design should be able to handle much higher voltages (so perhaps the mosfets that I previously mentioned are not worthy), something to the order of 50-60VDC 3-5A should do the trick for a wide range of steppers.
  • idbruceidbruce Posts: 6,197
    edited 2011-12-16 05:01
    As a side note, being a little off topic, this was going to be the subject of my next thread, but I will post it here instead. Everyone cannot afford a nice power supply. When I really started getting into stepper motors, I began using a PC power supply as my power source. There are plenty of internet articles pertaining to the conversion of a PC power supply into a bench top power supply, however, although not very complicated, it is time consuming. So lately I have been thinking about adding an ATX PC power supply connector to a Propeller Proto Board, to have the Prop chip control the power supply.

    I am not to sure where I am going with this just yet, but for low speed, small steppers, this might be a low cost alternative to the high dollar power supplies, and furthermore, we are talking Propeller controlled.

    Bruce

    EDIT: In an ideal situation, it would be nice if a PC power supply had a constant output of 6-9VDC for feeding power to the Propeller chip. But then I am dreaming...
  • GadgetmanGadgetman Posts: 2,436
    edited 2011-12-16 05:17
    Problem with using an 'ATX' plug is... which bl**dy one!?

    Most who want a 'cheap' PSU recycle older PSUs, they don't buy a new one. and the ATX standard seems to be changing more often than I change socks...
    Stick with screw terminals. They work fine with just about any PSU...
  • idbruceidbruce Posts: 6,197
    edited 2011-12-16 06:01
    @Gadgetman

    Lets assume that this thread goes in the direction of designing a chopper drive.

    Providing that you will use this PSU to power stepper motors, just try to find a psu with the output you need with a little headroom. Of course, we want to use the highest voltage possible to power our steppers, in the case of a PC psu, this will be 12V. Some of the ATX power supplies have up to four seperate 12V rails, which is perfectly acceptable.

    Let's assume that you have a known setup with 5 motors wired in bipolar fashion,that each consume 2 amps. Naturally you want a little headroom for the power supply, how much headroom is up to you, but play it safe. I would double my need. So for 5 motors @ 2 amps, the bare minimum would be the availibility of 10 amps on the 12V rails, but I would shoot for 15-20 amps, just to be safe.

    There should be a wide variety of PC psu(s) that will accommodate this demand for current, even older salvaged ones. Simply read the output of the 12V rails on the label, and if it suits your needs for current, then use it.

    Bruce

    EDIT: But do not expect high speed from your stepper motors if you are only supplying 12V.
    EDIT: Gadgetman, I missed the word "plug" on your post, sorry.
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2011-12-16 08:51
    In terms of cost reduction a lot of typical inkjet printers use DC servo motors along with printed encoders either linear or rotary. You can make high res rotary encoders cheaply by just making them big (see inside a cheap Epson). The drive electronics for a servo are nothing too terrible it is all about the software, it is possible to emulate step and direction controls as used by stepper motors as well if you want to.

    I started working on some servo motor position control a while back, implementing a PID controller, it worked, my issue was my encoder (not high enough resolution for my needs). The propeller certainly has the guts for it, You could do two motors in one cog, two because you would be using the timers for the PWM signals.

    Cheers,

    Graham

    p.s. I once had a canon printer with the neatest little magnetic linear encoder, was just like a metal rod through a little plastic doo hicky with some wires coming out, these would be supremely awesome. I wonder if one could record an encoder a bit like a cassette tape? Or perhaps it is a tube full of balls like some encoders use.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-12-16 09:04
    Since the controller would implement encoder feedback for servomotors, it might as well use them for steppers as well. On my CNC, which uses steppers, if something jams up the software doesn't know about it. That means an operator has to be there constantly, just in case. At the very least, a miscount between steps and encoder could shut down the motors and ring an alarm.

    Or, in the case of using higher steps rates for faster acceleration, use the encoder to prevent the problem of misstepping. The big issue with steppers is always their top *reliable* step speed, even with proper acceleration. Having to limit the top speed to some conservative value makes them slower over their servomotor brethren.

    -- Gordon
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2011-12-16 09:07
    Adding encoders to a machine using steppers does not make economic sense. Not even our commercial machine which uses steppers does that. But you have the option if you feel the need I suppose.

    Graham
  • dwaltondwalton Posts: 11
    edited 2011-12-16 10:36
    I have a home built CNC machine and use the following:

    1) 4 axis chopper stepper motor driver (based on TB6560HQ PWM Chopper-Type Bipolar stepper motor drivers)
    2) A Warp9 Smoothstepper board (USB to 2 parallel ports)
    3) Mach 3 CNC control software
    4) Vectric Aspire CAM
    5) KiCad and/or Google Sketchup

    I rely on Mach3 to work around problems when I mill things. I can set tool offsets, override feed rates, re-run a tool path that didn't cut deeply enough. I would not want something I plug a flash card into and hope for the best.

    I would be very interested in helping develop a board that works with PC-based CNC control software such as Mach 3 or EMC (open source). The key would be to take g-code as the main input since most CAM software generates it.

    We would also need limit and homing inputs as well as an emergency stop input.

    The control board should control at least 4 axis to be useful and I would also want either a relay to control the spindle or a PWM motor controller. I like the TB6560HQ based controller since it can control a very broad range of steppers using a single power supply.

    I hope this works out. I was wishing there was a propeller-based solution as I built my machine and did not have time to do it by myself.

    Drew
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-12-16 10:50
    Adding encoders to a machine using steppers does not make economic sense.

    It's actually cheaper to add three $50-100 encoders than to have an operator sit or stand at the machine all the time in case of a jam. An open loop system is always at the mercy of "jumped" parts, even with vacuum hold down (small parts that miss a vacuum port). So "economy" is where you want to spend the money. Labor is pretty expensive. Many of the commercial CNCs that use steppers have an option to add encoders. The basic package is just to stay competitive.

    -- Gordon
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-12-16 10:57
    (I should point out that I'm talking about CNC routers. A CNC mill or lathe isn't going to have the same problems of smaller parts jamming the bit, spindle, or router.)

    -- Gordon
  • idbruceidbruce Posts: 6,197
    edited 2011-12-16 11:03
    Not that I use encoders, but encoders are also useful for finding home positions.

    Encoders have their uses in stepper applications.
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2011-12-16 11:03
    But it sounds like the objective is low cost machine control for 3d printers rather than for machines making parts for money. So for a low cost machine encoders with steppers don't make sense.

    Graham
  • idbruceidbruce Posts: 6,197
    edited 2011-12-16 11:06
    I am not saying I would use encoders in this situation. I am just saying they have their purpose like home pos after estop.

    However, I think the focus should be on the driver instead of the end use.
  • Graham StablerGraham Stabler Posts: 2,510
    edited 2011-12-16 11:07
    I was replying to Gordon's comments.

    Graham
  • RobotWorkshopRobotWorkshop Posts: 2,307
    edited 2011-12-16 11:31
    There is a ton of information about motor control as part of the OSMC (Open Source Motor Control) project. I've used several of those controllers and they work out well for large motors. I helped write some of the assembly docs for them.

    http://tech.groups.yahoo.com/group/osmc/

    Robert
Sign In or Register to comment.