Closed-loop for Steppers ?

Controllers Smoothie
1

I have a couple desktop CNC tools which utilize Nema 17’s with integrated optical encoders to provide closed-loop functionality. The control system is MaxNC, which is proprietary … but it screams, the motion’s about 5x faster than what was possible with Nema 23’s in open-loop configuration on the same machines. Does a great job of thread cutting on lathe … And no worries about lost steps.
I’d like the same capability for the printer I’m building using Smoothieboard … It seems most folks feel that closed loop only deserves expensive DC servos, that a stepper with an encoder attached is a bastard setup. I’m having trouble buying that argument, since the stepper/encoder marriage seems to work very well and the cost of step loss can be high.
Is there any effort afoot to provide closed-loop for stepper control ?

Thanks,
MTG

Imported from wikidot

2

Hey.

There is currently no effort going into adding encoder support into Smoothie ( though that’s something that will probably be worked on with Smoothieboard v2 ).

I think your only option at the moment, would be to use external drivers with stepper drivers and encoder inputs ( there are a few, but they are expensive ).

Cheers.

3

Just out of curiosity, are there any limitations barring this from being implemented on the current version of the smoothieboard? It looks like the idea of putting them into a clsoed loop isn’t seen as beneficial, but is still something I might like to try if I could.

4

Your question is actually more involved than you might realize because there are several different degrees to which a stepper motor can be integrated with an encoder.

Adding encoder support to the smoothieboard would only allow the most basic level of integration, which would be detection of lost steps. I use the word detection because compensating for missed steps is generally not a great idea for several reasons.1 You are still using the exact same electronics and electrical configuration, so performance is not altered.

If you use the encoder for commutation, the resulting system is effectively a low RPM brushless servo. Such systems are sometimes described as “hybrid servos”. If you really dig into their construction, they have almost no similarities to a stepper motor (aside from the high pole count) and are true servos.

It is likely that MAXNC uses the latter system as they describe them as servo steppers. Encoder support on the smoothie will not provide hybrid servo performance. If your interest is purely fault detection and not performance2, then using the new generation of single-chip stepper drivers with stall detection would be the best way to go. They monitor the speed of the stepper motor using back-emf, which requires no additional components or wiring.

You are absolutely right that using expensive DC servos is not ideal in a 3d printer. You are paying for huge RPM, and then you have to pay even more for zero-backlash reduction to reduce the motors speed. A hybrid servo was designed precisely for this application and provides all the advantages of a servo combined with the torque and low speed performance of a stepper.

1The usefulness of closed loop position control for reliability tends to be overstated. Detecting a fault implies that it has already occurred - your part is already ruined. When a motor has lost position there is always some underlying mechanical cause which will not disappear if ignored. In many cases overcompensating will only make the problem worse (ex: loose encoder wiring or genuine collisions). For these reasons a servo drive will generally fault and kill the axis if abnormal conditions are detected.

2Existing stepper systems are more than sufficient for 3d printing, at least with the current generation of desktop printers. Frame rigidity and alignment are the major limiting factors.

5

Yeah there are different levels of doing this. I still think the best way of getting this to work is to use external drivers, wether you are doing error correction, hybrid servo, or true DC servo. If the driver has a step/dir interface, it makes no difference to the Smoothieboard anyway :slight_smile:

6

Wow, detailed answer, many thanks …
My preconceptions on usefulness of closed loop were largely based on observed experience, not theory. On my machine tools it was a huge performance boost over open-loop. If a stepper loses a step for a few milliseconds and then controller corrects position, it may be considered a catastrophic error by some, but in practice you’re talking about a minute defect that’s barely detectable. As far as the printer application goes, I’m butting my head against the upper practical limit of open-loop stepper performance currently with printers I have. The highest safe speed that I can achieve is about 130mm/sec ( this isn’t with smoothieboard though, it’s 8-bit Arduino ). I’m in the process of swapping out boards now to introduce the smoothie and see if that helps performance, I’m betting it will. My big printer has a 12" x 36" build area, so print speed is a key element. As is not losing steps.
The description of hybrid steppers is interesting… doesn’t sound like the stepper+encoder units being widely sold. My MaxNC motors certainly look like plain old Nema17’s with encoder applied to the back axle. Can’t see what’s inside though.
I’ll look into external stepper controllers if lost steps continue to haunt me.

Thanks,
MTG

7

Yep, 130mm/s is definitely way bellow what you can achieve with open-loop steppers.
1000mm/s shouldn’t be a problem at all ( and Smoothieboard will help a lot in getting closer to that ).
Really if you are 3D printing, above about 200mm/s your main problem is going to be to melt filament fast enough in your hotend.

8

Hybrid servos are more common than you might think. There is really almost no reason to put an encoder onto the back of a stepper motor and not perform commutation - every product on the first two pages of a google search of “Closed loop stepper” is a hybrid servo.

The performance boost you saw was a reflection of the jump in performance between a stepper motor and a servo. A servo motor is capable of short bursts of extreme power because it can detect when additional torque is necessary, and avoid overheating by using less power when not under load. As stepper motor has no idea of whether it is under load and must therefore apply constant torque at all times.

Under intermittent loads you can therefore compare the peak torque rating of a servo to the continuous/stall rating of a stepper motor. Peak torque ratings are generally 3-5x higher than continuous ratings, so in certain applications a servo can be much more efficient (in terms of size, weight and power consumption. Not necessarily cost).

A servo may correct minute deviations from commanded position, but in practice those events are unlikely to cause a properly sized stepper motor to fail. Assuming you are comparing a stepper and a servo of equivalent torque, any situation that stalls the stepper motor should also cause a servo to fault. (Of course a servo and a stepper of equivalent torque do not exist in practice).

The point is that a properly sized servo is not inherently more resistant to failure than a properly sized stepper. They have numerous advantages, but they are mostly performance related. Misumi just released an article comparing stepper motors and servos which did not even contain the words open or closed loop.

9

Hi,

I’ve seen that Logxen was working on a Stepper driver http_//smoothieware_org/smoothiedriver.
Is he still working on this project!? Maybe its a good idea to make it a Closed Loop system (could be optional)

10

if i may add my pennerth worth? (spelling unaplicabable btw…its rated under dyslexic missed stepps…)

the basic problem is missed steps … cauzes, the motors inadiquate/had to much exspecred…or the belt slipped, leadscrew travel, or in the case of two motors on two screws, one runs fractionaly different that the other and the Z plain gets a little twisted out…

leading to my point…

we then put the encoder/readers on the motor, this says to me we’ve half way approached the problem…because the belt, or the teeath or whatever (i.e. the axis on the screw bars) runs out…

my sugestion is the old long strip of bars effert, like the pc printers have in them, would actualy cover just about every easpect going for missed steps, as the counter would not reach that ‘150 bars’ on the ticker tape, or the the two seperate screws would always reach point zero no matter how bad they were…

in hinde sight, a bag uh nails moter and those screw bars we could afford would now be of much much more use and far more accessable.

the downside being…we then get charged the diference plus some because we are su-special….

the software needs to be applicable or used by the exsisting systems so as to not price out the window yet again. (i think thats why the smoothie chap sais use the external drivers…that sorts one end out amicably’ish…but the actual integrasion is the final step, which in truth is out of the reach of some 80 percent of printer users…hint hint lol)

the bread and butters in the 80 percent of users is it not?..80 is much bigger than 20…lol.(yes that was sarky…reason…all i keep reading is some old twarp shouting ‘my voise is bigga than your need’…the image that flashs to mind with these stigmatics izzz ‘‘this is the voise of the mysterons’’, you tube it to get the full affect…coment iz not direcred at any one here btw)

the only arguement against it all is…ermmm? ermmmmm? oh yeah the cost! other than that every one tries their damdessst to side trak it and ultimatly it goes no where.
the obly reason we arnt as yet is? software and the board to do it…or, the cost of such maybe?

the methodic logic…

1…my prints out yet again and in the bin

2… how to solve it?

3… the merry go round…(majic roundabout now playing in the back round).

4…final analogy…throw in the bin, throw in the bin throw in the bin…(see any patterns forming…?)

  1. answer….closed loop feedback, at worst a blobb-uh plasrit to file off/drill out…problem solved, wayyyyyyyyyyyyyyyy less crap in the bin narr int there?

is there another option? (without needing to sell orgons and small children??? or requiring 10 year programming exsperience and a small chip dot factory…du dahhhhhh)
….yeh tighten the belts till they stretch-n-slip/snap…yeah spend more on presision, but, sooner or later we skip to the bin again…feeeeed it back please??