Project Logs

Collapse

• Preparing to prototype

  Sci • 08/21/2014 at 02:09 • 0 comments

  A concept is a thing of sublime fantasy. It is a dream with no flaws. Reality isn't like that, so when you start to bring it to life, you start having to make changes to get it to work.

  The control panel

  The original idea was simple; three rows of 4-digit 8-segment displays, each row with a matching 2-bit greycode dial. Easy as pie until you start counting available pins on the microcontroller. I have some Atmega168's left over from another project, so we're going to try for a pure Arduino core.

  I want to keep the parts count and cost down, so while I could use a multiplexer and a dedicated 8-segment driver, the segment drivers are about 5 times the cost of the Atmega. Plus if I use a dedicated driver, while I only need 4 lines to drive it, I only get the hex digit range at best.

  I'd rather have complete control over what the display shows, as it would allow the display of error codes.

  So what's the spec? Fantasy says twelve 8-segment displays, total. If you multiplex the display selector with a 4-to-16 line decoder, that's still 12 (8+4) output pins taken up right away. There's still 9 input pins required for the greycode switches (2-bit + button). So we're at 21 pins required and haven't even talked about the current sensor, MOSFET PWM, sounder, serial data, or RPM sensors.

  The Atmega168 only has 28 pins, and they're not all usable. So let's start paring it down.

  Do I need 8-segments? The decimal point is only of conceivable use for tool sizes, but throwing some imaginary numbers at the RPM formulae ( (m/min * 318.057)/dia ) says the mill won't be capable of reaching the speeds where fractions of a millimetre between tooling size are noted. A 1mm tool at 15m/min cutting speed (very slow) needs a speed of 4770rpm.

  Practical considerations. You're never going to be using a tool that fine in a machine this big. We can forget the decimal points and go with whole numbers only without loosing anything.

  One pin down.

  Cutting speed examples (http://en.wikipedia.org/wiki/Speeds_and_feeds#Cutting_speed) range from a low of 15 up to 210m/min. (Thought I suspect machining waxes would be best with high, I can't find any cutting speed numbers for them, only RPMs)

  In any case the cutting speed display only needs 3 digits. And if we limit the tool diameter to a very generous 99mm, then we only need 9 digits total.

  So 7 pins for the displays and 9 to multiplex them. Still a bit hight. So let's get the 4-to-16 line decoder back in play. We can have all the original displays at this point if we like, but let's save costs where we can.

  And you know what? Here's another saving. The multiplexing's happening faster than we can see, so our clumsy monkey fingers aren't going to outrun it. Let's turn the greycoder buttons into a 3x3 matrix and run the inputs from the end of the same decoder.

  So now that's 7+4 outputs and 3 inputs to cover all the displays and manual controls. Much better!

  It means using some of what are usually considered the analogue input pins as general IO, but the datasheet says it's fine. It also means there are sufficient pins left for the other functions. The standard serial pins are there, current gets an analogue input, MOSFET control gets a PWM pin, RPM sensor gets a digital input and we even have one PWM left for a small alert sounder!

  I think that uses up every single pin, only requiring the addition of one cheap line decoder IC. Like a glove!

  I'm still favouring a classic look with red 7-segment displays showing through a translucent black plastic fascia, laser engraved with the various labels.

  Interfacing

  Now let's start with something close to my wallet. However you cut it I'm going to be hooking a microcontroller up to a 9A mains supply and frequently modifying the code from my computer.

  Every time I get something wrong, I do not want to have to replace my computer because the USB port took a 230v hit.

  I looked up off-the-shelf possibilities for isolation of the USB connection, in case something goes wrong. Turns out USB isolators are very...

  Read more »

• Spec'ing out

  Sci • 07/14/2014 at 17:05 • 0 comments

  What I have to work with will define the initial build, so let's press on with that.

  My mill is a Chester Machinetools Eagle 25. The standard induction motor is 3/4HP and the two-belt gearing set gives it a standard range of 100-2150rpm. I've already stripped it down though.

  To fit the DC treadmill motor I fabricated a simple bracket to mount the treadmill belt-tensioning arm on. An aluminium bushing fits the motor pulley to the M12 treadmill spindle fitting. The positioning looks odd but works. With the middle pulley removed, the highest gear ratio is about 1.7:1, so the upper limit using a 4800rpm motor should be around the 2800rpm mark. The lower end will depend on the motors stall speed plus whatever feels like a good safety margin. At 5% it'll be about 240rpm at that ratio. The low-end belt ratio is about 1:7.69 though, so at 5% it'll give 31rpm. A potential improvement in range in both directions!

  Auto-calibration will be nessesary any time the pulley ratio is changed. A POST operation is probably a good idea.
  

  The motor in question comes from a Roger Black "Gold" treadmill the owner threw out because it "caught fire". Which meant it made a lot of smoke. This turned out to be from the plastic output pulley coming loose on it's shaft and rubbing against the running platform until it melted. The motor was fine.

  The motor is a Greenmaster GMD118-1, and as you can see from the sticker it's spec is a bit odd. 230V DC. At 50/60Hz. Umm...

  Shops selling them give them a "compatible" voltage range of 180-230v. It's one of the better brands but of still generic chinese DC motor stock, so I'm putting the AC frequency mentions down to bad translation.

  Online shops also list the spec's as being 1.5HP and anywhere from 4000 to a crazy 5600rpm! On the old controller though 10% power put out 471rpm, so I'm inclined to beleive the motors own label. I'll still be very cautious running it up to full power in testing.

  So, 230VDC is the aim. The cont. duty of 1.75HP comes out at around 1305Watts. However the apparent peak power I've seen on (physically identical) motors from other generic manufacterers has been 2.75HP, which comes in at 2050Watts.

  It's an important note to make that some treadmill motor manufacturers seem to list peak motor power and some list the continuous duty power in their specs without defining which it is. Watch out for this when sourcing your own treadmill motors.
  

  The current sensing is going to come in very handy for testing the motor specs against reality.

  To accomodate the gulf of mystery, the initial build is going to be spec'd for a 2Kw power supply.

  I'm looking to use the Texas Intruments UCC28019. I'll freely admit I don't know a terrible amount about PFC controllers, but I was recommended this one and it's power and voltage specs seem to be suitable.

  The example circuit design for it in the datasheet relies on their design calculator spreadsheet, which is very thorough but only has settings for boost converter configurations. To take rectified UK mains and drop it to 230VDC it would need to be a buck converter. Or, to allow the circuit to operate on a wider range of inputs and outputs, it would need to be a buck-boost converter.

  TI's Power Stage Designer tool takes care of providing the specs for the major power componants (Inductor, diode, MOSFET) for a variety of configurations. The UCC28019's configuration options will need to be calculated from the datasheet formulea.

  Of course the fact that they need individual configuration too means a universal PCB is probably off the table, at least until I've tested the waters some more. The path of least resistance to a working prototype is a buck-converter, so let's get that calculated next.

• Two design concerns

  Sci • 07/11/2014 at 21:56 • 0 comments

  Concern one;

  A friend asked me how this project will meet the "connectivity" requirement of the Hackaday Prize. I'm not sure I liked the phrasing; it sounded like they were suggesting I was just going to cobble something on at the last minute.

  I don't think anything needs cobbling on. What will be used for debugging and control in the prototype will become a data-logging output. Tying control into existing CNC control methods hardly seems pointing out.

  Data-logging isn't anything fancy, but it's extremely useful. Being able to plot current use and RPM for certain cutting speeds and tools could help you find the optimum feedrates you can handle, or watch for worn tools. Or you could simply keep an eye on how much power you're using, or even just general machine health (free-spinning current is higher than it was last month for the same speed? That doesn't sound good).

  That's all just software though, this just gives an all-in-one way of accessing it. With a simple serial output, I expect there'll be many more ways found of using it all than I can imagine alone.

  Obviously I'll have the microcontroler opto-isolated from any high voltage stuff. USB ports are better not on fire.

  Concern two;

  Is it really nessesary to have the special power supply? Couldn't I make do with just using better fuses as a safety?

  Maybe.

  It may be overkill to have it arranged this way. And if you want to do it "treadmill style", you should be able to just replace the whole PFC power board with a rectifier and set the apropriate range limits in software (Id: that's a good idea actually, I'll put it in as a redundant config option).

  Personally though I don't like it. Just doing PWM off straight rectified mains is going to be electrically noisy for one. I also have a suspicion that even though a limited PWM duty keeps motor speed down, the high-voltage peaks that still go through the motor are what causes the most common failure; overheating.

  If using a properly regulated power supply from the start solves the issue of motor-overheating, I may be able to remove the temperature interlock from the design completely. But this is again entering into the "black magic" area of motor control, so we'll just see if behaves well enough when the time comes.

• Progress through proper planning

  Sci • 07/11/2014 at 00:48 • 0 comments

  First things first. If I want to get this done properly, I need to plan properly. To that end I've started using some "mind map" software (a fancy way of saying "spider-diagram") to lay out the various notes about this project. I've only discovered this method recently, but I'm finding it a lot more natural and adaptable than linear lists.

  Version 1.0 of the list is uploaded as a graphic. Green items are the basics to cover in the prototype, yellow in the next version (an extension of the prototype really), and the third will likely need to be a wholey fresh build, built on what's learnt from the first two iterations.

  A fourth version isn't mentioned, but will likely be required to tidy up the layout of adding in the additional sensors.

  First stage though is finding someone with an up-to-date version of MS Word so I can use the PFC design calculator. The macros don't seem to like Open Office.

View all 4 project logs