Closed loop for X and Y
-
@iamturbo1978 I'm planning on using uStepper external drivers to achievejust this. I'd imagine the processing overhead for going integrated closed loop would be significant and the complexity of the real time code would be overbearing.
Saying that it'd be a great addition and definitely a defining market differentiation feature for the Duet3D!
-
Isn't the main limitation at the moment squirting hot plastic out in a controllable manner, rather than maximum head speed? You could run simulations with the duet setup with superfast speeds in the config file to justify the effort?
-
It could justify itself if the drivers were fast enough to kill ghosting wobbles after sharp cornera.
-
have a look at
https://www.thingiverse.com/thing:2929869 -
@doctrucker I'm not worried about the print speeds. I normally print at 60mm/s. I'm more worried about the final print quality
-
@doctrucker good point. Hopefully, by putting the encoders as close to the print head as I can, a good majority of the "slop" in the system could be filtered out. In theory, the closed loop should notice the wobble of the head, and make corrections.
-
@veti I currently have a hypercube. I might do that as an upgrade. Thanks
-
@iamturbo1978 fair enough. Just feeling the aims need to be a little tighter. Appreciate cost isn't as much of an issue, but all the same if you're throwing hundreds at the drive it would be nice for you to be able to have a little confidence in what you hope to achieve.
But on the other hand, I would have better precision, accuracy, no missed steps, faster travel speeds (non printing).
No missed steps aren't much of a thing. If you miss steps in a build with the extruder things can get a little messy. If you miss steps on the axis then you are going to be out of position by at least 2 physical steps. In other words, generally game over. A well set up machine won't do that unless something else has gone wrong, which is likely to be looking poop anyway.
Precision and accuracy are however valid aims. Stepper motor manufacturers have a state accuracy of step size in the order of a few percent of the step size. While the error will be repeatable there is currently no way to tune for and dial out these errors. encoders on the rails effectively ignore these errors. Microstep sizes when running at highest resolution for the duet2 are likely to be a fraction of the positional error of the major step.
Take this one: http://motechmotor.com/productDetail-0104-40.html A 200 step motor with a 5% accuracy in step position. So positioning the stepper at 1.8deg is 1.8 +/- 0.09deg. The step size of a 256 microstep is 0.007, meaning that your positional accuracy of a single microstep is within about 12 microsteps. Splitting one rotation of the motor into 12.8 microstep lumps gives 4000 steps per full rev. So, to match the level of control you have from a stepper you'd likely need in the order of 40000 pulses per rev at the motor.
...but this is probably overkill when you look at the other uncontrolled errors that we have already hinted at. The wobble and surface patterns on parts can get significant before missed steps because the stepper can lag (or advance) target position by upto 2 whole steps before it snaps back or forth. So, taking that into consideration an encoder measuring the actual final axis position may only need to have the equivalent resolution of 1000 steps per revolution of the motor in order to hope to achieve better control than the current stepper systems. With a GT2 16 pulley axis on a simple machine that would be 1000 steps per 32mm.
Finally I think the encoder + motor system has the potential to be far more energy efficient.
-
The stepper is only likely to lag or advance on it's actual position when you are pushing the steppers hard in terms of acceleration or max speed. So, if you were looking at guarding from missing steps then around 800 pulses per inch maybe plenty. if you are looking to be better resolution than a 256 microstep stepper system that isn't heavily loaded you'd need to get as many as you can handle, somewhere between 16,000 - 32,000.
Edit: Gut feeling is I'm guessing that a system based around your 8k encoder will be easier to setup than a stepper based system and generally very nice. However, there is potential for someone to tune a stepper based system to make higher detail parts.
-
I think it's probably needless overkill for a Voron2. Quality steppers driven to spec and print settings tuned to the printer will be as good as the Voron frame design can provide anyway.
-
Thank you everyone for your insight. Because of your input, I think I am going to go forward with doing a closed loop system for a couple reasons... One, to add one more example of using a closed loop system on a FFF printer. Two, move out of my personal comfort zone doing the designing and planning.
-
@iamturbo1978 keep us updated. I'm interested to see how it goes.
-
@iamturbo1978 Those are two eminently sound reasons for going ahead. Even if the end result shows no advantages, you will have gained knowledge along the way, which is never a bad thing. As @Phaedrux said, keep us posted.
-
Other thing is the torque characteristics of BLDC motors, and perhaps lower inertia may be beneficial to the systems.
Don't get me wrong, I'm not trying to put you off the idea, merely trying to help develop it and ensure your idea of how the system will perform is not at a level that is setting yourself up for a fall.
Keep an eye on inertia ratios to give yourself an easier ride to begin with. It's taken me a while to start getting my head around them but it is definately not just can the motor deliver the required torque.
-
@iamturbo1978 You could check out this:
SimplexMotion
They use Out-runners and Hall sensors to read the magnetic field instead of encoders. Contact them directly with a project description if you are interested. I do not think they support linear encoders for position feedback.One advantage with a servo is that you can use a stiffer Polyurethane belt to get a stiffer system with better response and accuracy. The downside is the tuning of the servo that can be time consuming.
In my experience from industrial servo application with linear encoders, the inner loop is the encoder in the rotating servo and the outer loop is from the linear encoder. I think it would be difficult to control a servo with only the linear encoder.
I have build a screw based system that can go fast (1m/s) and accurate and the limiting factor I found was the extruder (with gear) that has difficulties providing a smooth flow during accelerations, specially with pressure advance that creates higher pressure. The effect is similar to ghosting, so it took a while to figure out the cause. I print at 150mm/s (limited by the melting of plastic) and with conservative values for acceleration.
-
@urban said in Closed loop for X and Y:
In my experience from industrial servo application with linear encoders, the inner loop is the encoder in the rotating servo and the outer loop is from the linear encoder. I think it would be difficult to control a servo with only the linear encoder.
BLDC motors can run sensor less, however yes, I think it is far easier to get the timing of energising the coils correct and at an appropriate advance or retard with an encoder on the motor.
-
Thank you for the encouragement, and the additional advice. I did a quick check into SimplexMotion, there are no distributors in the US at this time. I will contact them to see what options they can do.
-
@doctrucker said in Closed loop for X and Y:
BLDC motors can run sensor less, however yes, I think it is far easier to get the timing of energising the coils correct and at an appropriate advance or retard with an encoder on the motor.
The keyword being "run". Sensorless is based on back EMF from the un-energized phase. No motion, no back EMF. Small motion, not enough EMF to (properly) sense. Not a great thing for start/stop tracking of rotor position. Very un-suitable for stepper alternative, regardless of "closed" or "open" tracking of position over time.
-
This project looks interesting:
...and it's statement about most industrial motion being done by brushless servos.
Neatly it looks like this is likely to have CAN support soon, which will mean not masses of work to get it to play ball with duet3, or maybe with earleir duets with a bit more hardware since CAN is on Arduino Due.
@danal more-or-less an expansion of what I said? Hence 'can run'.
The rotor position encoder doesn't have to be particually high resolution to achieve decent start control. You could also send signals through one of the coils which won't move the rotor, but allow you to locate it.
The sensorless techniques result in a vague knowledge of true rotor position when in use, much like only knowing a stepper rotors position is within two physical steps of that assumed. This is acceleration/instant speed tuning come in. Essentially a patch on open loop control.
The downside of using BLDC like this is a 'lost step' would result in a larger angular displacement, but equally you'd need a greater torque to cause this. You could also slap an encoder on a stepper, but by that point you've lost most of the cost benefits of a stepper system.
-
@danal said in Closed loop for X and Y:
@doctrucker said in Closed loop for X and Y:
BLDC motors can run sensor less, however yes, I think it is far easier to get the timing of energising the coils correct and at an appropriate advance or retard with an encoder on the motor.
The keyword being "run". Sensorless is based on back EMF from the un-energized phase. No motion, no back EMF. Small motion, not enough EMF to (properly) sense. Not a great thing for start/stop tracking of rotor position. Very un-suitable for stepper alternative, regardless of "closed" or "open" tracking of position over time.
Exactly. Running BLDC motor sensorless is great in drones and similar applications where the motors always run fast, but in 3D printers and similar applications you must have a position sensor that works at speeds down to zero. You could possibly use a combination of a BLDC using sensorless commutation, gearbox (because BLDCs are suited to higher speeds than we need in 3D printers), and an encoder after the gearbox.