Boys and their toys

Technocrat

Boys and their toys

GuyFawkes

Tue Aug 05 04:54:00 -0700 2008

Mechanics

manage

I've been playing around with converting my mill and lathe to CNC operation for a while, slowly, and now it is starting to come together, for those who are interested there is a google video here to watch. (excuse the mess)

I was concious of a very "child at christmas" feeling as the axes started whoosing about under (albeit incomplete and unconfigured and uncalibrated) software control, it is a very "2001" moment where the pre-human primate discovers tool use and proceeds to beat the crap out of his fellows.

And then I nearly (off camera) ran the vice handle into the end of the Z-axis glass scale hard enough to break it (luckily I was watching) and then I was made aware of that other child at christmas feeling when the toy doesn't live up to expectations, and that is always down to a chain of events that all make sense when looked at individually.

CNC control is simple enough for anyone to understand, machine axes are moved by rotating a long threaded bar, and the machine part to be moved is attached to a nut on that bar, rotate the threaded bar and the nut and everything attached moves along the bar.

A typical thread is ten turns to the inch, so turning the threaded bar 3.6 degrees in theory gives a movement of 0.001" excluding backlash and thread errors etc. Attach a stepper motor, which is just a motor that takes one "step" every time it gets a pulse, to this thread and you have the basis of a CNC machine.

A typical stepper has 200 steps per revolution, if we mount it direct coupled to our ten turns to the inch threaded bar, or leadscrew, one step = a theoretical half a thousandth of an inch.

Use a computer, run some software that drives the printer port, connect this to some stepper motor drivers and PSUs and we can see it isn't very difficult to "tell" our stepper motor to rotate clockwise for 20,000 steps at a speed of 1,000 steps per second. Computers excel at this sort of number crunching.

20,000 steps @ 2,000 steps to the inch is 10", so we are telling the computer to tell the stepper motor to rotate the leadscrew enough to move the object 10" over a time of 20 seconds.

Being a computer it will be precise, it will issue commands to the stepper to make 20,000 steps, not 19,999 and not 20,001, and being a computer it will happily shuffle backwards and forwards issuing these commands all day, no lunch break, no toilet break, no telling jokes to the computer next door.

Not only is this simple enough that anyone can understand it, it is also simple enough that each stage can be separated logically as I have done here, and each of these stages also makes perfect logical sense.

But when you chain each stage together that perfectly logical set of individual stages builds into a totally illogical construct that will willingly do something as (human) obviously stupid as running full tilt into a 5 micron (0.005 millimetre) glass scale and destroying it.

Sure, there is a "perfectly logical" lego brick software "solution" to this problem, you can program into the software, relative to the machine table, "no fly" zones, so provided the sofware always has EVERYTHING (from the tooling in the chuck to the coffee cup) that is in the envelope of possible movement programmed into it, it will avoid collisions.

But the fact is that "crashes" like these in CNC machining are remarkably regular occurrences, you'll be hard pushed to find a machinist who has never seen one, so we have a complex series of events, the control signals and sequences operating a CNC machine, built out of lots of smaller, quite logical, quite sensible, quite clever little blocks (at this point the software coders are probably way ahead of me) but nevertheless resulting in a whole that is quite illogical and quite stupid.

Before anyone gets the wrong idea, the CNC Control software is only 150 bucks US, so I'm not expecting NASA shuttle standards, and I don't really mind being the human over-seer for my robotic minions, what I am actually talking about is the way that simple bricks which exhibit excellent internal logic completely and utterly falling over when joined together to make a larger structure, and the point here is that the bricks didn't join themselves together, a human being did.

So it is a human problem, and so putting another human (me) in charge as robotic minion overseer isn't actually addressing the problem, even though it may catch some instances by way of iterative filtering, in actual fact it is simply adding another stage to the problem and actually compounding it.

It is a problem that could largely be solved if we assume, correctly, that most of the things likely to crash into other things are going to be metallic (apart from my coffee cup, which of course should not be on a machine table in the first place...) and so if we separated the machine tool into two parts, the tables and the machine head, and electrically isolated them from each other while maintaining rigidity (no mean trick) we could use capacitance between to two parts to do collision avoidance.

But, there are other approaches.

The Z-axis scale shouldn't be mounted where anything can damage it, mine only is because it is a retrofit, and one that looks like it could do with modification in the light of the subsequent CNC conversion.

But, please note, the above paragraph is another excellent example of a single building block that exhibits excellent internal logic and sense, exactly mimicing the single building block that was retrofitting a glass scale DRO to a manual mill. At that time I made a good job of fitting it is about the right way in about the right place.

You see the problem here, it isn't a computer problem, it isn't an engineering problem, it isn't a Guy Fawkes is an idiot problem, it isn't technically actually even a problem. What it is, is a hardwired evolutionary response of the human animal... from my christmas toy when I was 7 through Kubrick's opening sequence in 2001 through everything you out there do every day, it is all Nature's short cut solution to the cost/benefit analysis of species survival.

What the grainy (quality reduced by Goggle, sic) video referred to above doesn't show you is that the glass scales for the DRO aren't actually mounted "properly"... it is good enough to work, and work well, but when I bought them I knew I was going to go CNC at some point in the future, and my engineering apprenticeship was good enough to teach me that that meant avoiding making too many of those building blocks permanent.

In the video I make a comment about "You have to make one, (in order to learn how) to make one."

The younger engineers poo-pooh this, whip out AutoCAD and proceed to design and solid model and maybe even FEMS analyse the thing to death, and churn out a production design, no physical engineering prototypes, no physical production prototypes based on the engineering prototpes, but straight to the production design.

And it will work.

But, it will inevitably, having had a human being involved in the design stage, also incorporate that human "It is good enough for government work and Nature" hardwired internally logical building blocks, and sooner or later the lack of external logic will meet the hardware and it all falls apart, and at that point a rather complex and integrated and what was a "final" solution is what falls apart, not an engineering prototype.

So my "you have to make one, to make one" apprenticeship was actually all about acknowledging that you cannot take the human being and his nature out of the engineering equation, so the only possible EXTERNAL logical response to that was to fudge it, don't assume any answers or solutions are final, and don't lock out any future logic path changes unless you can help it.

Again, some of the software coders out there will be ahead of me, and muttering about "versioning", and maybe we can get very Zen and start talking about things all being journeys rather than destinations.

But, if you want to be a Zen Master, you have to remember one thing, include yourself as a bunch of internally logical but externally illogical building blocks into the equation.

While it is true that my Mill and Lathe are undergoing a versioning, dynamic, evolutionary sort of transformation from mundane manual machines that I served, into semi-automated robotic minions that will serve me, it is also true and equally important to remember that I myself am evolving from a "carbon life form unit" that served my machines into an overlord of robotic minions.

I am not the same person as I was when all my machines were 100% manual and old fashioned, and I will not be the same when the transformation is complete, always assuming it will ever be complete, incidentally the initial assumption was that it would never be complete, hence going down the path of DIY conversion rather than simply buying ready made CNC kit (that and the money)

And so I and you also have to be aware that having gotten to this stage, for those of you out there contemplating the same undertaking for yourselves, perhaps the best thing I have to offer is not in fact my uber leet engineering skillz and peerless CNC experience, because you are not me, even though we may have vastly more in common than we have in difference, the difference is what counts, so perhaps the best thing I have to offer is my experience of the changes in myself.

Human beings are some 90% visual creatures, last night I listened to that video rather than watching it, and it was quite different, while the video portrays someone trying to show you some of the engineering points of relevance, the audio track sans video portrays someone talking about the human approach.

The "child at christmas" feeling is still there, and it is important, it is what we call "fun" and "enjoyment" and "fulfillment" and all that jazz that "makes like worth living", and it all comes from that opening sequence of 2001 where you pick up a tool and feel empowered and better, as a person, than you were before.

Servo controllers

wowbagger

Tue Aug 05 06:49:50 -0700 2008
manage

While this is probably right out of your price range, I'll raise a point from my own experience designing industrial robotics.

You might want to think about servo controllers (microstepping controllers). They are a basic stepper motor, with a high resolution encoder attached directly to the motor. You now have a very accurate idea of where the motor shaft is, irrespective of what you have commanded it to do.
You then have a controller which can:

read the encoder

precisely control the voltage and current delivered to each of the phases of the stepper motor

and most importantly, compare the commanded position of the stepper with the actual position in real time

This allows you to step your control up to a higher level: you no longer stay "take a step. one-mississippi. take a step.", you say "Take 10000 steps, with a maximum velocity of 1000 steps/second, an acceleration of 100 steps/second², and a deceleration of 200 steps/second². Let me know when you're done."

But even better, since the torque a stepper supplies is proportional to the difference between the commanded position and the actual position, the controller can do torque limiting: if the Δposition grows larger than X, the system will immediately cut power to the motor. We used that to prevent a system from over-torquing an assembly and breaking it.

The other thing is that you gain even more precision on the stepping, as you can get about 256 micro-steps per motor step (which, in your case, is probably meaningless - you likely have more backlash than that).

And what is REALLY cool is that, when there is no load on the motor, the motor gets no current to the coils - saving power and heat. But, start trying to torque the motor by hand, and the system will start to resist (using a PID loop controller).

OT: the damn HTML tidy-er won't let me put a non-LI element in the middle of an OL, which is what I wanted to do with the italicized text.

Servo controllers

GuyFawkes

Tue Aug 05 07:21:32 -0700 2008
manage

Ah yes, the classic servo / stepper dilemma.

While I agree that where a stepper can "jump" a step and not know it a servo will know it, however, for less than the price differential between a servo and a stepper it is possible to fit an encoder to a stepper.

The other big advantage of the servo is RPM, torque really starts to fall off a stepper while the servo is fairly flat up to 3,000 RPM and beyond.

Where I am going to diagree is the following points.

Knowing the relative position of the leadscrew via servo encoder still doesn't give you an accurate indication of table position, which I have with the glass scales and DRO, which the Mach3 software will accept electronic input from (for additional cost and complexity) and become a "closed loop" system.

The high servo RPM potential is a waste on a home machine, lower rapid speeds do not cost me production time and therefore money, having said that, my 3 Nm direct coupled steppers can do quite astonishing (compared to manual) rapid speeds, in testing it went up to 100" per minute with no ill effects, but for me I'm limiting rapid speeds to 48" per minute with a 1 second acceleration and decelleration at each end.

As far as the ability to over torque an assembly and break it, leaving aside for a moment the temporary location of the relatively feeble Z axis glass scale, I deliberately specified my steppers at 3 Nm because I figured 1 Nm to overcome friction and stiction, 1 Nm to maintain adequate chip load, and 1 Nm spare to avoid stepper "jumping", but while 3 Nm on a 10 turns to the inch leadscrew is certainly enough to snap off an end mill, it isn't enough to damage the mill itself although I would of course tramline everything (particularly with a universal mill) back square after a collision of any import.

As it is I can do 256 microsteps per step, and the motors are 200 step per rev, and I have set it to 32 microsteps, so 32 x 200 x 10 = 64,000 steps per inch, so I have to "jump" 64 steps (*very* audible, I tried it, even 4 steps jumped was quite noticeable over spindle noise etc) to "lose" a theoretical thou, even without manually referencing the DRO or physically closing the loop and connecting the DRO to the CNC software.

So we're left with the remaining big "disadvantage" of the stepper system which is power consumed to lock in place, which again, given 3 Nm steppers isn't a lot, they run stone cold with a decent stepper controller hardware as fitted, even after locking for a couple of hours, and they only get moderately warm to the touch in use, again, my workshop is not a production environment where I have to push everything to make a profit.

So, given NOT A PRODUCTION ENVIRONMENT, I actually feel that the (evolving) solution I have is physically superior to a "pukka" closed loop industrial servo job, most of the abilities of which would have been wasted, and instead I can spend that cash and therefore effort where it will actually make a difference, and compensate for the relative inadequacies of the theoretically technically inferior stepper solution.

Here is a link to the stepper controller datasheet. pdf.

Servo controllers

John Dalton

Tue Aug 05 07:52:33 -0700 2008
manage

Out of curiosity, does anyone make machine tool systems which actually measure the shape of the work in real time? (Maybe using an interferometer or similar?) This measurement is then put into the feedback loop. That way every source of error is inside the feedback loop and the tool is inherently accurate. Of course you don't want any overshoot, otherwise you get divots all over the work!

Servo controllers

GuyFawkes

Tue Aug 05 07:54:57 -0700 2008
manage

Not to my knowledge, normally physical measurement is a separate process in a CMM (co-ordinate measuring machine)

Boys and their toys

D. Hensley

Tue Aug 05 07:05:03 -0700 2008
manage

I have a question --now first I'm not a machinist, or much of a programmer, so if the question seems dumb, it's just from ignorance, not stupidity (ignorance being a curable condition and stupidity being ignorance that does not want to be cured).

I don't quite understand why the CNC device could hit any part of it's self --possibly it could do great damage if it had some material to be worked in it, but why would it not have rather simple limit switches physically on the max point of travel in any axis? (either direction of course).

It would seem that such a simple set of micro switches that cut power to any stepper motor driving that particular threaded rod would be set to never allow the stepper motor to have a degree of travel large enough to hit a part of the machine it's self.

So OK, I'm ready to have my ignorance cured --it will not surprise me at all if I missed something here. (uhh... I am assuming that whatever a Z-axis glass scale is, it is a part of the machine).

Boys and their toys

GuyFawkes

Tue Aug 05 07:33:30 -0700 2008
manage

It does have limit switches (you can see one on the video) for XYZ travel, essentially we are specifying the boundaries of a theoretical box.

We can also define, in software, the bottom of the quill / collect chuck assembly (think drill chuck for a pillar drill) so this is our reference point moving around inside our theoretical box.

So far, so good, no problems.

Now, I can stick a 16 mm diameter end mill that protrudes down 25 mm from that quill.

Again, in software I should in theory have these parameters loaded and referenced for "Tool #1" etc, so still, no problems.

Again, in software, I can define the say 150 mm deep by 175 mm long by 10 mm thich alloy plate that I am going to work on, and by "jogging" (manual movement) I can reference the end of "Tool #1" with say the rear left upper corner of the "work"

Again, so far, no problems.

In practice, how did I hold down that piece of work securely to the machine table? If I used clamps of a vice they _I_ can see them but the "stupid" software doesn't know of their existence, and trying to tell it is where it gets really complex.

The other issue is being a manual mill I can tell the machine various parameters, then rotate the quill around the Z axis so it is pointing sideways at 45 degrees, the end of "Tool #1" is no longer where the machine "Thinks" it is, and telling it is again quite complex.

HTH etc

Boys and their toys

D. Hensley

Tue Aug 05 07:59:01 -0700 2008
manage

Thanks, that cured the problem up I think --it's just the old AI problem of after inputting all parameters everyone could think of, when 'told' to stack some boxes the computer tried to 'set' the top box first... Obviously a parameter (and a difficult one to program for in all possible axises --gravity) was left out... (I hope that's not to far off the mark for an analogy).

Boys and their toys

GuyFawkes

Tue Aug 05 08:02:47 -0700 2008
manage

That or Mr Hensley was sat eating his sandwiched where the robot tried to stack the bottom box... and nobody told the robot, you scrambled out the way in time, your lunchbox didn't.

Boys and their toys

GuyFawkes

Tue Aug 05 08:03:55 -0700 2008
manage

it's just the old AI problem of after inputting all parameters everyone could think of

This is really the gist of my tale, the parameter that almost nobody ever things to input are all the human ones.

Pinball Wizard

wowbagger

Tue Aug 05 08:05:40 -0700 2008
manage

That was always one of my big problems when I did that for a living: people couldn't understand why the machine couldn't tell there was a problem: "But it's OBVIOUS! Can't you see it?" "Yes, *I* can see it, but how is the machine supposed to see it? The machine has no eyes, and there are no sensors there."

Compared to us, the best industrial robots are still very much Tommy the Pinball Wizard: deaf, dumb, and blind, and yet expected to keep the pinball moving.

Pinball Wizard

GuyFawkes

Tue Aug 05 08:14:37 -0700 2008
manage

Mmmm, there was an early kiosk touchscreen thing I worked on, it fell over because the programmers never anticipated anyone starting the process and then just walking away after making the first menu selection.

They fixed that and then there was a word wrap screen width problem, and no user interface to scroll and bring the "button" back on screen.

From there it turned in to whack a mole.

How about a retracting blade/mill guard?

mengel

Tue Aug 05 09:06:32 -0700 2008
manage

It seems to me that one could rig a blade/mill guard that was retractable to a given depth for cutting, and acts as a limit switch on all 3 axes when bumped. You would physically adjust this guard to just cover the business end of the mill/blade whenever you change cutters. Then when programming the milling machine, you would retract the guard the depth of cut that you wanted on this cutting pass (plus epsilon), and if there was anything there higher than the surface you're expecting to cut (i.e. a clamp, a passed-out person, etc.), it would just stop and alarm. If you mis-estimate the depth of your cuts, it would be pretty annoying, but it could save you a lot in damage...

How about a retracting blade/mill guard?

GuyFawkes

Tue Aug 05 10:50:39 -0700 2008
manage

Yeah, that and a couple of other features are on the pie-in-the-sky drawing table, but, that wouldn't have prevented the upright undone mill vice handle from smashing into the inappropriately mounted Z axis glass scale.

And that's the thing, wherever human being are involved each time you take another factor into consideration you may have covered another base, but you are in fact no nearer in practical terms to the theoretical perfect solution.

This is the point of the article, no "advance" actually advances you position in truth one iota.

reminds me - chewing arm off

rubycodez

Tue Aug 05 08:52:40 -0700 2008
manage

my father's tool and die company pioneered a robotic arm system for moving parts from one station on a die to the next for stamping presses. There was no question of a limit switch to stop the press if robot arm got out of sync and in the way, presses with thousands of tons of force won't stop on a dime just because you want them to, haha. yep, they sometimes smashed the arms.