The biggest reason is cost, at least for accurate ones that work over longer ranges (up to 1m or so).
This is a great idea!
The past couple of days I worked on a prototype:
[attachment file=122466]
I bought a cheap tape measure and removed the housing. I put it on an axle with bearings and attached the GT2 belt. It pulls around 230 grams, and that seems to be enough to keep the belt straight.
The belt then passes around a 16T GT2 pulley with a CUI AMT102 encoder attached to the shaft (also on bearings). The encoder counts 8192 steps per revolution, which means one step per 3.9 micron.
The whole assembly rotates around a vertical axis (again, with bearings).
I made a small test setup: [attachment file=122467]
I put a weight on the end of the belt to make sure it wouldn’t be retracted when the stepper (on the right side) is off. I command the stepper to move 5 full revolutions of the 16T GT2 pulley that is attached to it (so 5 * 200 * 32 microsteps in total). While it’s moving, I log the actual position of the stepper, and I log the position of the encoder, together with a millisecond timestamp from the Teensy 3.5 MCU.
When I plot the difference between the position of the stepper and the position of the encoder (all converted to microns), I get the following plot: [attachment file=122468]
I know for sure that the pulley on the axle with the encoder is off-center. That’s because it’s actually mounted to a 4.8mm diameter threaded rod with a grub screw. (I ordered a 5mm smooth rod, still waiting for it). I think that explains the sine wave pattern.
The stepper is moving at around 8mm/s, and uses acceleration and deceleration at the beginning and end. I think that’s why the peaks are a little lower the beginning and end.
There is also a non-zero slope. Not sure what’s causing that. The encoder also has 8 index pulses per revolution, I’m going to check that so see whether I’m missing encoder steps.
Finally, there is some noise in the readings. Not sure where that is coming from. The axle with the encoder has no play but does have some resistance. Maybe that should be smoother (or the tape measure mechanism stronger).
But all in all, I’m very happy with the results so far! Looks like it might actually work!
3 Likes
Nuts! How freaking interesting.
1 Like
Interesting.
What happens if you put another one on the other end? So they are both reading what should be the same thing?
You may have the perfect rig to test another mystery. 1/16th vs 1/32 microstepping! It would be really interesting to get this under some fixed load, and be able to measure the error in 1/32 or 1/16th microstepping.
Good idea! I only have one so far, so that test will have to wait a little while though.
This page (under ‘Holding Torque’) seems pretty clear. I intend to try to measure the lag angle. I already built the hardware, I just need to write a small program to do the measurements and analyze them. I’ll also test with 1/16th!
In a nutshell, I plan to attach one end of a load cell to the stepper and I attach a weight to the other end. At first, the load cell will hang down vertically, so the stepper initially barely has to lift any weight. But the more the stepper rotates, the more torque it will have to use, so the higher the lag angle should become. I then compare the measured distances with and without the weight, and that should give me a “lag angle vs torque” chart. Strictly speaking I don’t need a load cell, anything would do. But now I can also measure the exact force and torque.
1 Like
WOW that page is a gold mine of facts! Better than most stepper manufactures trying to explain the same thing. I am very exited to see your numbers.
1 Like
Wow. Great work, can’t wait to see more.
2 Likes
Duet guys are great. Their reprafirmware.org has a full featured EMF calculator that will crunch all the important numbers for you to see if your power supply voltage is enough to drive your steppers at the speed you want.
I’ve never tried anything like this, but my understanding of these sensors is that it’s just a laser diode + a lens + a CMOS chip in the same housing. Basically a laser pointer and a camera. High resolution CMOS sensors are really cheap nowadays. RPI camera costs like what, $20?
Interesting work! However are you sure about the encoder resolution? When I look at AMT102 product page, the highest resolution encoder they offer is 2048 PPR which would be around 15.6 microns.
Laser pointer or a mirror attached to a shaft is a better rig for measuring how accurate the position is. The optical magnification that can be obtained by projecting to a wall a few meters away enables a very high resolution. Conclusions are driver and motor model specific and not as broadly applicable as one might hope.
Here’s a fairly good test from three years ago: https://hackaday.com/2016/08/29/how-accurate-is-microstepping-really/
To improve microstep accuracy, TMC2130 and TMC5130 drivers have a programmable microstep table. Prusa firmware contains code that will populate this table with values specific to the LDO motors that ship with their MK3 printer.
Unfortunately TMC2130s can only push out 1.2A of current and stepsticks with TMC5130 drivers are hard to come by. The latest TMC2209 and TMC5160 chips do not have this feature nor is it in present in older TMC2660 that were/are used in Duet2 boards. I don’t know why it was removed, maybe the gains were not worth the complexity.
Here’s a link to a Trinamic application note that describes how these tables can be optimized to improve microstep accuracy and it even has a few pictures about recommended rigs.
1 Like
Found another microstepping accuracy test from Hackaday: https://hackaday.com/2016/08/29/how-accurate-is-microstepping-really/
Would be interesting to rerun this with latest trinamics.
EDIT:
One fascinating formula from the linked resources is TN = TH x sin ((90 x N)/µS)) where N is number of microsteps taken and µS is the number of microsteps per full step. E.g. incremental torque to move 2/32 steps (0.01mm) would be ~ 9.8% of full step holding torque however to move 10/32 (0.05mm) it’s already 47% of full step holding torque.
1 Like
That’s my understanding too. But to get high accuracy at both smaller and larger distances, you need the resolution to be extremely high. Or you need optics that can focus at different distances or something.
Yes, it outputs 8192 steps per revolution with 2048 PPR, because it’s a quadrature encoder. This also allows you to know which way it is rotating.
Plenty of food for thought regarding the TMC steppers and accuracy, thanks Anttix! That formula is also a very nice find. I’ll see if that fits my results.
However, I’m not too worried about little deviations in the microstepping accuracy. A deviation of 100% of a certain microstep only means 5 microns of position inaccuracy. Maybe the lag angle is relevant if it turns out to be substantial. In the end, I’m more interested in absolute positioning of the gantry/end mill, regardless of the source of inaccuracy.
I’ve also been thinking about how to actually use the measurements to correct the position of the end mill. It will be pretty complicated to correct the position in real time. Implementing that in firmware will take a lot of work.
So, inspired by the quote above, I came up with another plan. First, I’m going to calibrate as well as I can, which takes care of “static” inaccuracies like squareness. A gcode preprocessor can then incorporate corrections for this. Then, I’m just going to let the MPCNC do its cuts as usual, and just log all the measurements without correcting anything in realtime.
By taking the original gcode and the measurements, it shouldn’t be too hard to compute where there is too much material left. A new gcode can then be created which essentially does another finishing pass, just taking off the excess material where needed. This loop could even be done multiple times to slowly hone in on perfect dimensions. (This approach assumes that the accuracy of the initial cut is high enough to ensure that nothing comes out underdimensioned. Shouldn’t be too hard with the calibration and some tolerance in the gcode.)
So it would work like the sculptor, but fully automated!
This could work but there are a few things to keep in mind.
-
Surface finish - you do not want to increase the number of times the cutter enters/leaves the material. Probably need to leave enough stock so all finishing passes will follow the entire contour.
-
Chip thinning - Taking very light passes too slowly can result in the cutter rubbing instead of cutting thus subsequent passes may need to increase the feed to compensate for low radial DOC. This can also increase the positional error of the machine which may undo the benefits.
I guess a lot of careful planning and testing is required to do this in a way that will actually improve the resulting parts and it may be hard to come up with a method that works well for all kinds of cuts.
1 Like
Klipper still doesn’t do closed-loop. I’ve built a couple of large closed-loop DC servo 3D printers using Marlin and inspiration from Miguel Sanchez’s dcservo which grabs step/dir and does the motor driving. Most recently I did an XYZ closed-loop using STM32 bluepill hardware timers to read encoders which was very convenient. The main issue I ran into was that all the motors have planetary gears with a lot of backlash and all my encoders are on the backs of the motor shafts.
2 Likes
But, writing the controller software for klipper to do closed loop seems easier than intercepting step and dir pins. Especially because there is an ability to see into the planner’s future. The klipper firmware that ends up on the boards is trivial.
1 Like
A quick update on this project. I have built all three encoders now, and mounted them on a make-shift frame, and I connected the belt ends to the router. I wrote a small Python script that sends gcode to Marlin, and reads the encoders via a separate Teensy microcontroller.
At first I thought I would only need the three distances between the encoders, but in addition to that I also need all three belt lengths to one specific point, for example the home location. Measuring those things with a ruler or tape measure only gets within a millimeter or so, and I would like (much) higher accuracy than that.
So I started thinking about a way to automatically calibrate it by having the router probe something. My plan is to string a bunch of thin wires in various orientations, and have the router probe those. Each line gives rise to some constraints. Given a model of the system with some parameters, those constraints can be used to estimate these parameters. I think, though I haven’t done it yet, that it will be possible to get very good calibration this way, without needing any known size of something (!).
I then got side tracked with this little project to calibrate the router itself. The approach in that thread does not work (yet), but I’m still working on it and it looks very promising.
1 Like
Yes, they are both reading the same thing. The difference is typically within 1 or 2 steps of the encoders (so just 5-10 microns) if you make sure the belt is straight after you move it. However, sometimes the difference is bigger, and I think that’s because the belts are sagging a little after moving it and the tape measure mechanism isn’t always strong enough to pull them completely straight again.
1 Like
I’d argue that since all firmwares are currently using step/dir, it is actually easier to capture those than writing a new motion control system for klipper. Since you probably won’t have servos on all axes, you can end up with a mixed motion control system. I totally agree klipper would probably be best for this, but still not trivial to implement (I’d guess; don’t really know). I’d love to see it done since it would give me a reason to get back to improving my closed-loop machines.
Check out their developer docs. They are very good, and worth a read. The protocol is designed very well:
If you had one arduino that was only responsible for reading messages from klipper and controlling the motors, and reading feedback, all the other stuff, like any standard axis, or extruders, probes, etc, can all be on the regular arduino. Klipper can be configured to send X and Y commands to the new board, and everything else to a regular board.
The whole acceleration profile gets sent to the motors, so you’d basically know the speed to travel, the distance, and how long to do it. That kind of info would really help your control loop. Plus, the communication from klipper is already done for you, so it would be pretty robust when you finished.
1 Like