Slightly crazy idea to obtain very high precision

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.

  1. 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.

  2. 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