I am in need of some ideas, and/or opinions.

TC

Hello all.

I am still in the process of learning SPIN, and the only way I can learn is if I have a project. For weeks I could not find a project that would keep my interest. Well I finally have one, a 3D printer! I have been looking on the web and found there is a lot of information out there, but nothing for the PROP. Now I know, I could just buy the parts like everyone else, but where is the fun in that? The 3D printers out there run on G-code, just like CNC equipment. And most of the products out there use a 16MHz Arduino.

I am compiling a list of things I want/need for my 3D printer. Here is what I have;
~ 80MHz
~ Instead of using stepper motors, using DC motors with encoder feedback (PID)
~ Thermocouple temperature measurement, instead of thermistors. (I have a few of them lying around)
~ Using 1 COG for each coordinate control. (X pos, Y pos, Z pos, and extruder)
~ Using 1 COG to control the temperatures of the hot end, and the print bed.
~ Using a 240x128 monochrome display (been sitting around for years)
~ Using 1 COG to interface with PC, and/or SD card, with buffer.

Now this is just a starting list, and I know more ideas will come along.

Do you think my ideas are bad?
Do you think the PROP can do this?
Do you have any ideas that might be better?
Please any input would be great.

Thanks

LoopyByteloose

Stepper motors are generally the best way to go as they just step and hold position. Other motors perform best when they are spinning at a high rate.

Encoders are expensive, and PID is more microcontroller effort.

Mike G

TC, your ideas are not bad at all. Like any project, the initial design details might not work as expected.

As LB pointed out, a stepper might be better a better choice. The only way to know for sure is to give it a shot. In the process, you'll learn something...

TC

Loopy Byteloose wrote: »

Stepper motors are generally the best way to go as they just step and hold position. Other motors perform best when they are spinning at a high rate.

Encoders are expensive, and PID is more microcontroller effort.

I do agree, encoders are more expensive. But could the feedback offer better quality, even using steppers?

TC

Mike G wrote: »

TC, your ideas are not bad at all. Like any project, the initial design details might not work as expected.

As LB pointed out, a stepper might be better a better choice. The only way to know for sure is to give it a shot. In the process, you'll learn something...

Thank you for encouragement. It is going to be a challenge, but cant learn if I dont push my self.

LoopyByteloose

This link may help you decide.

Both can be used, but stepper motors really perform best at less than 500 RPM, while servomotors have to be geared down to achieve such slow speeds. That gear box and the encoder add to the overall expense.

http://www.cncroutersource.com/stepper-vs-servo.html

TC

Loopy Byteloose wrote: »

This link may help you decide.

Both can be used, but stepper motors really perform best at less than 500 RPM, while servomotors have to be geared down to achieve such slow speeds. That gear box and the encoder add to the overall expense.

http://www.cncroutersource.com/stepper-vs-servo.html

WOW!! that does help, Thanks. I was thinking everyone used steppers because they are easy to use.

frank freedman

Actually, you don't have to have a servo motor turning at any speed. They can actually stand very, very still. In fact, they can be designed to fight any undesired change in position; the harder they are pushed, the harder they fight back. You can use many things as the error source, pots, quadrature encoders etc. A "real world" example is the x-ray collimator. Both Siemens and GE use a servo motor for positioning of the blades when in both auto-collimation or manual mode. In the Siemens model, a quadrature encoder is used to both generate the direction and magnitude of the motor actual signal and the controller then moves the motor to counter this. In a collimator, the FDA spec is that the xray field will line up to the receptor with an error of not more than 2% of the distance of the source to image plane distance. On a 100cm distance this is a fair amount, but it must be accurate and repeatable. So the CPU will see the SID, determine the size of the collimator opening to achieve the actual size. A 14*17" plate may be only a couple of inches at the blades, and you want that to be exact and repeatable. So at cal time, you set the size of the field to the plate, the CPU memorizes that position for each plate size to be used. (GE used to use multi-turn pots for the position reference). Now, the collimator will step to either full open or full closed position to set reference, and then move to the position requested by the technologist. AND HOLD IT. Any attempt to move off of that position will be immediately countered by the motor controller seeing the change start and apply drive to null the change.

As to a servo running a continuous rotation at a fixed speed (I guess to control the rotation speed of your tool) the servo motor used to maintain the speed of a CT gantry constant pretty much does the same thing but rather than maintaining a constant position, it will maintain a constant speed. As to the need to gear down a servo, depends on your motor and what you are trying to push. The CT gantry may be upwards of 800kG and spins at 3RPS. How constant do you need your tool speed and what will you be feeding it? May need gearing. How hard will you need to hold you x/y/z positions? May need gearing. The GE collimator uses some serious gearing to move the blades. Tried to turn by hand, barely moved them just holding them not connected to anything. The motor and gearing was 1.5: dia and 3" long. They were 24V dc motors.

Just some examples by example to think about...... Have fun with the project, I am still off in the ADC/DAC playground......

FF

Side note:
The GE Advantix collimator control took an 12*18" board in a cabinette w/ some pretty sizable analog power supplies, the Siemens now takes a couple small 3"*4" or so boards including the MCU, User interface, system interface (CAN bus) and motor drivers.

Mickster

Loopy Byteloose wrote: »

This link may help you decide.

Both can be used, but stepper motors really perform best at less than 500 RPM, while servomotors have to be geared down to achieve such slow speeds. That gear box and the encoder add to the overall expense.

http://www.cncroutersource.com/stepper-vs-servo.html

With all respect, I think you must be referring to the typical hobby-type encoder with very low resolution. With the resolution that's typical in the industrial world, there is no way that any stepper can compete with the performance of a servo-motor, no matter what the speed. "Serious" CNC machining centers are equipped with servos, not steppers and they typically are coupled directly to ball-screws or roller-screws with no other speed reducer involved. Many cutting/contouring operations require very low but stable motor speeds. Same thing applies to industrial robots.

My desktop simulator features Pittman servomotors fitted with the cheapie HEDS 500-line encoders, providing 2000 quadrature counts/rev. and, thanks to the integrator component of the PID, I can have these motors sit exactly in the same position indefinitely and will fight any external influence with all available amplifier current. The machines that I produce are equipped with 4096 line encoders which result in a resolution of 16384 quadrature counts/rev or 0.022 degrees.

With its ability to read encoders directly and its real-time deterministic performance capability, the Prop makes an ideal closed-loop servo motor controller.

JMO

Mickster

Duane Degn

I know I wasn't the only one surprised to see so many DC motors in the recent printer/scanners I've taken apart. There seems to be a trend in consumer printers to use brushed DC motors with very high resolution optical encoders. I think it was Ron Czapala who posted about this a while back.

Edit: I hadn't seen Mickster's post before posting this. (I had my edit window open a while as I said good bye to a house guest.)

kwinn

Frank and Mickster are right. Industrial servo systems are capable of much higher precision, speed, and torque than any stepper motor. They also tend to be more complex and much more expensive than stepper motor drives.

OTOH, almost every ink jet and dot matrix printer made in the last couple of decades uses stepper motors, and for very good reasons. They are less expensive and simpler to control than servo motors, and their performance is more than adequate for most printing requirements.

A 3D printer may require more torque than a dot matrix or ink jet printer, but due to the nature of 3D printing it can also get by with lower speed and instantaneous precision. For larger movements of course it needs to maintain good absolute precision.

H

Servos can direct drive, but it's usually most efficient to gear them down, the same way steppers usually are geared up. Then again, 3d printers are slow, steppers might suit your needs.

I'll have to agree, for reliability use servos, they are not any more complicated than a stepper. The common solution is to use a driver which accepts step/direction signals for both steppers and servos. The comparison on cncroutersource is biased to steppers. Steppers are good for one thing, they are cheap. Servos are equal or better in any other consideration. Most servo drivers these days come with auto-tuning, even if it's usually a simple calculation of rotor inertia to load inertia to get in the ballpark for setting the the feedback loop. Forget the dc-motors especially if they are brushed, will wear out in no time for the use you propose.

You might want to seek advice for machine building on cnczone.com (forum dedicated to mostly diy cnc machines), if you go for servos, you might find relatively cheap 12bit encoded servos in canada, highly recommended, check dmm-tech.com

I wish you luck. Motion control is not easy to begin with. Adding linear and circular interpolation, gcode interpreting, bit exact step/dir signalling in the 100khz's for 3-4 axis, acceleration profiles and what not, I'd say the prop could do it, I just wouldn't want to be the guy to do it.

prof_braino

more opinion -

The reprap 3D printer support is very well established and well understood. The easiest path to a 3D printer is to copy the existing stuff as close as possible, and limit the project to replicating the Sprinter firmware functionality on the prop, and interfacing tot the established tool chain. A single Arduino is plenty for a 3D printer; a prop is about four time faster than you need and would have about six cores left over. In fact, we looked at the reprap in some detail and decided to just use the existing RAMPS+Sprinter as-is and do something else on the prop. Not to dissuade you from trying it in spin, it would be fun, but it might be reinventing the wheel.

That being said, we do have a project implementing dynamic acceleration and voltage control for an XY table. Its kind of neat, I cranks up the juice for motion, and cranks it back down as it slows. (So it wails and is really smooth but uses minimum power and doesn't burn itself up). This is what reprap does NOT do (AFAIK), and seems to be a good match for the prop.

TC

Thank you everyone for the wonderful opinions. I was second guessing my self if my idea would be good. I was just going to be like everyone else and get a RAMPS board and some steppers. But I have now decided to go for it. I just think it would be cool having a 240x128 display showing what the RepRap is doing, including showing the G-code. And I think the servo/encoder setup might be able to offer better print quality, with faster print speeds.

Just be aware, I am treading on unknown waters for me, So some real simple questions could be coming around.