Developer Wanted: Open Source Motor Control Board
Jessica Uelmen
Posts: 490
You may remember David Carrier's forum post from a couple weeks ago, looking for input on an open-source motor controller. We appreciate everyone's input and have taken them into consideration when defining our final specifications.
Due to the current stack of internal projects and timeline required for this product, we are looking for an outside developer to design this board. The specifications are attached to this post; if you or anyone you know is interested, please send an email to me: juelmen@parallax.com.
We are looking for an enthusiastic & experienced developer, and look forward to hearing from you!
Cheers,
Jessica
Due to the current stack of internal projects and timeline required for this product, we are looking for an outside developer to design this board. The specifications are attached to this post; if you or anyone you know is interested, please send an email to me: juelmen@parallax.com.
We are looking for an enthusiastic & experienced developer, and look forward to hearing from you!
Cheers,
Jessica
Comments
IMHO the spec seems like an overkill for the RepRap market.
What is the input voltage range the switching converter should deal with?
What voltage range should the H bridges handle? I assume this is the same as above?
How much output current do the H bridges need to drive?
How fast do the H bridges need to switch?
I also think that it should have encoders for all motors not just 3, so that should be bumped to 5. The extruders can benefit greatly from it. If you put the encoders on a shift register (which I think would be fine) that would reduce the pin count for them and open up pins for the 5th motor. The encoder shift register should be on its own pins, I think, to facilitate their being read independently from the other I/Os.
Also, I would consider having each stepper driver be easy to replace. On these machines burning out a single driver happens. A common thing done for RepRap and others is to have them be on little daughter boards, and they tend to use pololu ones. Like this: http://reprap.org/wiki/Sanguinololu Or like the RepRap that has different larger boards for each motor. I realize it can cost more to produce, but I think it would go over better.
Also, doesn't the number of pins needed go down if you only have one or the other? Maybe I don't understand everything involved?
I'm using the Maxim MAX7311 in a project right now, it's their version of the same part.
The problem with using I/O expanders for encoder is speed. Encoders can generate fairly high frequencies. You would need a low resolution encoder to get away with an I/O expander.
If you have 100 count, 400ppr encoders, that is really low resolution for a 1/8th microstep driver. You need at least 2x the motor resolution, so a 400 step motor is 3200 ppr. The closest encoder to this would be a standard 8000 ppr or 2000 line encoder. These are standard on most CNC machines, some CNCs have higher resolution (Okuma absolute encoders are very high resolution).
Most 30 year old CNC controls are rated at 1Mhz encoder input. 8000ppr at 6000rpm is 800Khz. I2C is 400Khz/1.7Mhz, then there is 10Mhz SPI. You will very quickly run up against limitations in the Propeller trying to multiplex over serial expanders.
I have done work with the Propeller to generate software commutation sequences for stepper motor microstepping. I'm using 2 counters to generate the sin/cosine PWM values, which limits the number of phases you can drive to 2 phases per COG. It may be possible to generate PWM sine waves using a tight loop, but I think it would be tricky with the necessary closed loop current control that is needed.
I'm not an EE or an expert in electronics, however I have some hands on with these problems and have faced some of these types of issues in EFI and data acquisition, and I know I could write the software. Making all of this fit into a single Propeller (I/O needs for synchronous devices) would be a challenge and would certainly use up all of the Prop's resources.
I had not considered such high ppr encoders being needed, but you make a good argument. I guess we need all the encoders to be directly connected.
I still think my other comments are valid. I'd really like to see this be able to drive 5 steppers and have 5 encoder inputs.
Also, on the firmware side, why wouldn't it use everything and also read gcode from the SD card and drive the motors / heaters / etc. to run the machine. The Prop is more than capable of it. Might need a bigger eeprom though.
Roy
I purchased a bunch of 65A MOSFETS that are intended for PC motherboard power supplies, at 53 cents each. If a high side MOSFET driver is used, this would be a lot better. The MOSFETs have the freewheeling diode builtin and are designed for driving inductive loads.
You could do many encoders in 1 COG, but that would require 1 COG. The steppers might require 1 COG per motor. Using the typical PWM method, you can only get 2 channels per COG. However, I will look into doing it all in 1 COG with software to do the PWM. The tricky part of this is the current control, right now I lengthen the off time period to control current. I may have to change the way this is done.
So, as it is now:
4 COGs -- 4 steppers
1 COG -- 4 encoders
1 COG -- ADC
1 COG -- SD card
1 COG -- Manage the multiplexers, user interface.
I was planning on making the stepper COG do encoders too, since it spends a lot of time just waiting for the counters to expire. That would give room for 1 more COG for a 5th axis. The management COG would need to do motion control, reading the ADC current sense values and passing those to the stepper drivers -- presently I would expect a LUT with 4 bins that translate step rate to current, for current reduction and current boost to accommodate torque and boosting field saturation at higher frequencies.
You also need 4 outputs per stepper to drive the 4 half h-bridges per motor, at least I haven't seen a way to make it work with just 2 outputs yet. 5x4 = 20 I/O Then 5x2 = 10 I/O for encoders, that leaves nothing for anything else.
I would propose having 2 propellers and boot load the 2nd from the first, then use the 30/31 for high speed comms. That would work nicely to have 1 Prop doing motor and encoder, then take commands from the other prop that does GPIO and ADC. You could get rid of the MUXes and reduce the part count and complexity to just using Propeller I/O directly.
Unless those MOSFETs have four terminals, it's not a true freewheeling diode. It may be a zener, though.
-Phil
Jessica is looking for an engineer she could hire for doing the design.
Ken Gracey
Will there be similar offers from Parallax's in the future?
Have a look at the Datasheet and tell me what you think: http://www.irf.com/product-info/datasheets/data/irlr8721pbf.pdf
EDIT: I have a tube of these sitting on my desk and was thinking of making a stepper driver from them, so it just happens by coincidence that this subject came up.
-Phil
My intended use is with a High side Bridge driver (IRS2302), so I will be using the same part for the high and low side. In High side the internal schottky body diode will be biased so that a voltage potential 1v higher than the supply voltage will be shunted to the supply voltage. This would serve the function of a flyback schottky diode, correct?
EDIT: My understanding of your original objection is that the body diode is on the low side in a typical MOSFET driver circuit, which precludes using it as a flyback diode.
I'm in the process of designing a 150 amp 80 volt brushless motor controller with regenerative braking right now. This opportunity just appeared.
The body diode in THIS part are schottky diodes with a 17-26ns recovery time. What say you? I'm not trying to be contrary, but until someone explains WHY you can't do something, I ask the question. I wouldn't be asking if IRF didn't suggest, but not outright provide an app note for this application. The part mentioned above is specifically for inductive loads.
What I would like to see is some kind of visual display and buttons and the ability to print straight from the SD card without a computer hooked up. Will the Propeller have enough resources left after all the encoder stuff? Anyway I am for the Propeller controlling anything I use it's the only uController I somewhat understand. I cant be of much help technically but I would be happy to donate a machine frame (Prusa Mendel frame all the plastic and hardware no electronics) or two, to Parallax if they need one for testing and the individual who signs on for this task.
I started a 3D Printer Group here on the forum. Groups don't get much use here on the forums but well see what happens I am curios how many people here have 3D printers. So if you have one or are just interested join the group.
Ron
I do have some questions though... Why not use the Toshiba stepper motor driver chip (or equivalent)?
Implementing your own bridge out of discrete parts seems like re-inventing the wheel to me...
Also, why do you want encoders for the motors? I could be wrong, but I think most of these systems are open-loop...
With a stepper, I think you know where it is because you're telling it how many steps to take.
Not sure where this aversion came from as hundreds of other driver circuits were not mentioned. The circuit in question was published for educational purposes and the main advantage of this circuit is that the output follows a digital input in all 3 states. Dead time is controlled by using the third state (tristate). Use it as you wish, or don't use it. As for placement costs being higher than specialized chip cost I find that extremely hard to believe.
Regarding high-side n chanel drivers there is one great problem (of many) in that the gate is rather sensitive to fault conditions where the high side nch source appears to be grounded or even worse at a negative potential. With a gate breakdown of around 20 volts this means instant and cataclysmic destruction unless the gate source is properly clamped. Motors are mischievous things.
For steppers, encoders would be overkill for many applications. A 3D printer does not have a large dynamic range of torque requirements, and it would be easy to run the system at higher speeds until a predictable range of missed steps starts to occur to determine the Max speed. Even a CNC with a greater dynamic range of torque on the motors will have a predictable point of failure. Setting a Max speed usually solves this problem. Incorporating error correction into the code may not guarantee that the part being machined is salvage-able if there is a serious step error, although it could stop the machine to avoid damaging the part, and allow the user to choose how to proceed. I would suggest that instead of taking up 10 i/o's for 5 encoders(I2C would be too slow IMO), dedicate 2 i/o's, include a header, and offer a daughter board with a second Prop that is the encoder manager, with feedback to the main board in the event of errors. The daughter board would receive a mult of the step/dir pins (5 step, 5 dir), and a feedback pin to notify the main board of an error. The main Prop in this scenario only needs 2 pins assigned to the daughterboard. One for a response from the encoder manager, and one input to the manager to reset encoders a la carte(serial input). The extra board, Prop, terminal block, passives, would be an insignificant cost for an application with stringent requirements such as closed loop feedback for steppers. It may be possible to use the same scheme for brushless motors.
I think that there are stepper drivers that are better suited to steppers, and BLDC drivers that are better suited to the those motors(hall sensor inputs built in). I would recommend this to be a modular system, with a main board and optional output driver boards depending on the motor type.
Personally, a standalone motion controller (that's what this is, no just a "motor controller") has been an itch I wanted to scratch for a long time. Ever since I had to debug and babysit my Hardinge CHNC with Siemens 810 control. I got a lot of insight into controls when repairing that basket case of a machine. I had thought about doing this with an Atmel ARM in 2006, but didn't.
I've been pursuing some of this project on my own. I'm afraid to raise my hand on this project because a) I'm not an EE b) I don't know their timeframe fits mine c) criticism from qualified EE types
The last thing I want to do is raise my hand and make something that has a critical flaw or is lambasted on the forums for some design decision.
I'm a pretty good coder, but my electronic skills are a mashup of what I have learned from what I've been exposed to.
Yes. For developers who get familiar with our system, manufacturing capabilities and demonstrate an ease of working together the opportunities are very good.
We've just hired out a few sensor designs, for example. These jobs often go straight to the person we have in mind to do them, but we're trying to expand the team a bit by posting on the forums.
Another reason for the encoders is that the board could other kinds of motors, since, I think, the intention is for the board to be able to be used in other applications.
All the gate drivers I've seen drive the high-side gate off of a charge pump referenced to the high-side-source voltage, so that isn't a problem.
My question came out of surprise that my circuiit was even mentioned at all as it was not being discussed as far as I'm aware. Anyway I designed this circuit for a 24V system and motor loads of around 6A which is also why I used complementary output stages as it led to a very compact design at the time.
High-side N channel drive:
Now I stumped by your remark that the just because the charge pump is referenced off the high-side-source voltage (as they are) that it isn't a problem. In stall conditions and also if motor direction is reversed instantly (sink to source) the Nch source's "source" will be at close to 0V or even negative which means that if you are using a high-side drive voltage of 34V in a 24V system then the gate-source will see 34V or more and yet the gate-source will normally breakdown at 20V. So this juncture needs to be protected adequately or else the destruction is sudden and catastrophic.