Welcome! Log In Create A New Profile

Advanced

Precision Movement at a Distance

Posted by Wissing 
Precision Movement at a Distance
September 05, 2013 06:42PM
This is a general discussion on precision movement for 3D printers, or related CNC machines as they may lend techniques to the development of 3D printers.

It seems like there are a couple rules of thumb I've come across:
1.) You have to have a stationary ground (rails, guides, dovetail block, etc).
2.) You have to have a moving stage to hold the tool (extruder, spindle, etc.).
3.) The closer your stage is to your ground, the more precise you can be.
4.) The more massive your ground, the less kickback you get from the moving stage.
5.) Screw threads need tension.
6.) Dovetails need gibs.
7.) Set screws slip.

Anyone else have any tips/tricks when it comes to developing machines?

P.S. Feel free to post any foreseeable obstacles to the building of a spherical-coordinate-based 3D printer.
Re: Precision Movement at a Distance
September 06, 2013 07:09AM
Developing a machine has nothing to do with rule of thumb.
If you want a really good machine, everything needs to be calculated.

- You need to have enough rigidity to take into account static deformation of all parts (a cart in the middle of its axis will lower more than in the extremities since the flexion load is higher). You then must embed the rods in their supports (with supports being rigid enough = plain aluminium at least, or even better steel) or fully supported rods.

- Cart must be the lightest possible to have a large bandwidth (dynamic behavior) in order to print really fast with precision (if you print at resonnance frequency, you get a mess by overshooting all displacement. If you try printing at higher speed the cart won't move accordingly to the order sent and displacement will be reduced so that you part is just a small tangled mess.)

- Bearing tolerances must be accurate. Chinese LM8 have so much play that the carts can rotate lightly. This can be overcome by having the biggest distance possible between the two guiding rods to limit angular misplacement.

- Belts shall be attached on the cart between the two guiding rod and not on the exterior side unless you want your cart to pivot when you change displacement direction (linked to the bad bearing problem so if you use precision bearings and precision ground hardened shafts you can dismiss this problem)
- Coming to the rods, you need stainless steel with enough hardness to not be damaged by the balls in the bearings. Indeed, under load it creates a Hertz contact pressure problem which will create grooves in the rod if they are in a soft material. Also, stainless is better if you don’t want to have a rusty printer which would jam the mechanisms.
What do you call a spherical-coordinate 3D printer ? Is it a robotic arm printer ? In this case, the conception is totally different and inertia change continuously when moving the joints. It is far more complicated to design than a Cartesian printer and you can’t expect the same precision unless you spend many more hours to design and program it (and more money too). To make a straight part, you will always be more precise with a straight path tool than with an arc calculated from trigonometric approximation (it requires much more calculation power).
Delta printers are already more difficult to tune but easier in manufacturing. Maybe a cylindrical coordinate printer could be an interesting challenge, built the same way as a construction crane with the main beam going up and down if you want something original and not too difficult for an amateur project.
Re: Precision Movement at a Distance
September 06, 2013 07:26AM
Quote

stainless steel with enough hardness

No need for stainless. Stainless steel usually can't be hardened and the exceptions are pretty expensive. You need some grease or oil anyways, because the bearing balls aren't stainless, either. And running steel on steel entirely dry is "eeeek", anyways ...


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Precision Movement at a Distance
September 06, 2013 08:22AM
Yes, my mistake, the one I use are not in stainless steel. I started with simple steel rod from a local furniture distributor and they were really bad steel. They rusted in 2-3 months even with a lot of oil and being kept at 20°C in my bedroom. Also, they were damaged by the load exerted by the bearings.
I changed them since they were only used to make a proof of concept (at 6$/m) and I'm now using chinese "precision" shafts made in "bearing steel" with a hardness of "58 HRC" (as advertised by them, so no real information on the alloy but definetely not stainless steel).
I've been using them for more than 6 months and they have no sign of rust (they are lubricated only by a thin film of oil) or degradation by the ball bearings. The downside, they were priced at 20 euro/m (without shipping cost) but they are really worth the money (it's a shame I can't find them on the web anymore, like if their factory vanished).
Re: Precision Movement at a Distance
September 07, 2013 10:11AM
Thanks for the input!

Yeah, I meant a robot arm, I guess. The appeal is precisely that - more complicated math, but less hardware. I see it as more efficient. Although I don't see why calculation power diminishes precision.
Re: Precision Movement at a Distance
September 09, 2013 03:48AM
Simply because calculating a sine/cosine (etc) requires an algorithm which will try to reach the real mathematical value without being able to do so. Also, the precision depends on the type of variable used to store the value (e.g a 16-bit variable is 256 times more precise than a 8-bit variable).
Currently on the Delta like Rostock, the calculation is done onboard and consumes a lot of time but I think that on reprap, when doing a circle (which is also time consuming) it only reads the commands sent by the computer and doesn't do any calculation on board (all displacements are pre-processed by the slicing software). The way to go would ask to make a software translating cartesian gcode to spherical gcode (or use an onboard lookup table with sine/cosine value precalculated).

The next step would be a fully customized slicing software working in more axis (a robotic arm could print things way more crazy than what a cartesian printer can).

My only experience with robotic arms is working with an ABB industrial robot. It was really painful to make it write my name with a pencil on a piece of paper ... the damn thing was always destroying both the paper and the pencil (and BTW also the table ...)
Joke apart, most robotic arms work with inverse kinematic which requires to solve optimal path matrix to reach the space coordinates you want it to reach and sometimes it gets stuck in a singular position because he can't find a proper solution to the mathematical problem (and then it starts lagging like hell because each point requires a lot of calculation).
Reprap's are working in a open-loop fashion, only initializing its home position at startup (and so in case of step losing, your print is a mess) whereas a robotic arm would have a closed-loop positioning on each joint. I don't know if you can make a robotic arm with stepper motors (maybe by using gears to boost the torque and using more massive motors at the base and lighter ones the closer you get to the hotend) since you have to support the whole weight of the arm on the first joint.
Re: Precision Movement at a Distance
September 09, 2013 09:18PM
No, I have no intention of using steppers. Servos will be my first attempt.

I'm actually foregoing the plastic and using aluminum cross-links in a sort of accordion style motion (like a scissor lift on its side, more or less). That will give me a radial displacement, and hopefully a good ratio between moment of inertia and weight.

I've realized I'll have to actually introduce at least 1 extra degree of freedom; not only do I have to have a radial mover and 2 angles, but I need to pivot the head to compensate for angle changes.

As for the software, I was hoping to maybe find someone else to help on that... I can do the math all day, but I'm not so good with syntax, for lack of experience. Maybe I'll give a college kid a free sandwich or something to help out.
Re: Precision Movement at a Distance
September 15, 2013 01:41PM
What do you mean by an accordion cross-link or scissor lift? Where would that be?
Re: Precision Movement at a Distance
October 07, 2013 05:19PM
nice stepper robot
[youtu.be]


Random Precision
Re: Precision Movement at a Distance
October 11, 2013 06:45AM
Servos are a bad idea unless you're buying (expensive) industrial ones. Stepper motors are used for a few very good reasons.
  1. Stepper motors can be run "open loop." This means you don't need feedback. Microstepping allows you to divide the precision down to very small increments. With 1/32 microstepping, you can get 0.06 degree resolution. To get something equivalent from a servo, you need a shaft encoder that gives 6400 pulses per revolution. That's not obtainable for a sensible price.
  2. Servo motors require speed and position controllers, while stepper motors simply require a step/direction control. Software does much less work when it's just step/direction.
  3. Low cost servo motors are just DC motors. But low cost DC motors are high RPM and low torque. That means they have to be geared down. That introduces backlash.

None of this means that servos aren't a better long-term solution. They're just much more complex to work with.

Polar bots can be just as precise as cartesian ones. Even with the controller doing the inverse kinematics. It's a question of the resolution you're working in. If you have a numerical accuracy more than 10x the print resolution, any numerical error will be invisible. If you're worried about the inverse kinematics being done in realtime, use a better microcontroller. There are MCUs on the market, for a reasonable price, that provide 168MHz cores with FPUs.

It all comes down to tradeoffs. If you mandate that your design must use a controller with all through-hole parts, you're limited to low capability microcontrollers and you're stuck with cartesian or simple delta geometries. Otherwise, there's lots of processing power available.
Re: Precision Movement at a Distance
October 13, 2013 11:30AM
Something I've noticed by looking at the pics on this site, some of the holes for the shafting look like they were just drilled.

For a good sliding fit, all the holes should be reamed.
Re: Precision Movement at a Distance
October 14, 2013 12:57PM
I got a servo to work off an Arduino... it didn't seem that complicated, and it was pretty cheap. Now, the higher-torque ones will probably be more expensive.

Would it be feasible to use a regular 1-RPM DC gearmotor, and attach an encoder, or would that cause too much backlash? Would it be feasible to make my own encoder by mounting a laser pointer to reflect into a photocell?

My goal is to stick with the Arduino for all controlling. Is that possible?
Re: Precision Movement at a Distance
October 15, 2013 05:19AM
Wissing Wrote:
-------------------------------------------------------
> I got a servo to work off an Arduino... it didn't
> seem that complicated, and it was pretty cheap.
> Now, the higher-torque ones will probably be more
> expensive.

Driving the servo isn't the problem... it's controlling the servo that's the problem.

> Would it be feasible to use a regular 1-RPM DC
> gearmotor, and attach an encoder, or would that
> cause too much backlash? Would it be feasible to
> make my own encoder by mounting a laser pointer to
> reflect into a photocell?

Backlash before the encoder is irrelevant. That can be compensated for. Also, if you can measure the backlash after the encoder, that doesn't matter either. Both of these can be compensated for in software, provided that your motor is fast enough. I would worry about a 1RPM motor being able to do retraction. I would suggest that you look at printable quadrature encoders.

> My goal is to stick with the Arduino for all
> controlling. Is that possible?

Arduino will work provided that: 1) you have enough pins, and peripherals (e.g. ADC's) to accomplish the job, 2) your software is simple enough to fit in a 16MHz 8-bit CPU.

If you're using a geometry other than cartesian, you need to check if there's any firmware that supports it. There's good support in some firmware for some of the non-cartesian varieties (e.g. Rostock, Kossel), but others (e.g. Simpson, Wally) don't have support and rely on gcode preprocessing.

Edited 1 time(s). Last edit at 10/15/2013 05:20AM by Annirak.
Re: Precision Movement at a Distance
October 16, 2013 12:45PM
When you say retraction, are you referring to 'retracting filament', or do you mean 'retracting' back to a set point after, say, an x-axis motor overshoots its mark? I guess the hard part is going to be balancing power and RPM. What about a 10-RPM motor?

Finally, a context for the second meaning of 'quadrature'. So yeah, that shouldn't be too hard. I think I may try it with gearmotors and use a printed encoder. That's more in the spirit of the self-replicating machine concept anyway.
Re: Precision Movement at a Distance
October 18, 2013 07:05AM
I'm referring to retracting the filament.

I don't know what is "enough." You'll need to determine what your maximum desired print speed is and work backwards from that.
Sorry, only registered users may post in this forum.

Click here to login