I’ve been playing around with magnetic encoders a lot lately in the hopes of getting some sort of error-detection system up and running. I think I’ve finally made some headway on it.
I’ll start off with the video of where I’ve gotten too. It’s not much, but I think this system is worth exploring further.
Apologies for the rather poor quality! I was planning on recording a better video (using a tripod and all!) but I ended up tearing things apart to tweak before I remembered to – doh! I’ll get another video recorded soon.
In the video, you can see me being rather abusive towards my printer – shoving the X-axis around pretty heavily. You can also see that the printer knows the axis has been moved and fixes the problem. It doesn’t fix it instantly, it takes a little while to move back into place – but this happens while the print continues, without interrupting operation.
Sure, there’s still a defect present in the print from when I moved the axis, but the printer pretty quickly gets past this defect and the print returns to normal from there on. Without this system, you’d have a pretty permanent layer-shift – something that would have ruined the entire print!
Of course, people usually don’t grab moving parts of their printer (I hope), so the example in the video is not a problem most printers would face. Still, there are a number of things that could go wrong that would cause similar behaviour:
Overheating stepper drivers. I’m curious to test this one – obviously, a really severe case of overheating would probably cause too many problems to overcome, but I think this system could correct a lot of borderline cases – when there are only one or two layer shifts in a print, for instance.
Nozzle getting snagged on print. It doesn’t happen often, but I know I’ve had prints before where there’s just a little bit of curling and the nozzle decides to move right through the curled area, causing an axis to miss a few steps. This is the problem I see being most easily addressed by this system.
Any other (momentarily) insufficient torque cases. Overly-aggressive accelerations / axis moves, insufficient motor current, and so on.
Belt stretch or slip. If the belt starts to slip mid-print, this system should handle that. Depends on the severity – if the belt is loose and not moving the axis at all, then we’re out of luck.
At the moment, I’m using a linear magnetic encoder IC from AMS (the AS5311) on a small PCB I’ve designed, along with an ATmega328 to track the axis motion and implement I2C communication (also on the same IC).
This seems to be a relatively robust solution, and the encoder can track axis motions up to about 350mm/s – which I think covers speeds reached by most 3D printers.
Printer firmware is Marlin, with a few new bits I’ve thrown in to get this working. It’s still pretty messy, but you can find the code on GitHub here.
Unfortunately, AMS has discontinued the AS5311, so I’m reworking things at the moment with a new IC. I’ll have another update once I’ve got that IC running and tested.
On the printer firmware side, I still have a lot of tweaking to do. I want to get the correction process moving quicker, but that shouldn’t be too tricky – I arbitrarily picked a fairly low correction rate to start with to play it safe, and there should be headroom to take it higher. I also need to do a lot more testing, preferably with some larger prints.
Edit: Follow up post is here.
Superb research. Great. I had the same interrogation but do not have the knowledge to implement such a sensor.
May want to consider this one?
From this series
Good work! Congrats!!!
Really interesting work!
Could this be used in combination with threadless ballscrews?
It’s definitely possible. I take it the main drawback with threadless ballscrews is that they tend to slip over time, causing drift over the course of a print?
If that’s the case, they could work rather nicely with this system. I’ll have to see if I can test something when I can.
Actually also the solution to pause a print, go to bed and next day to resume the print from cold start something we cannot do today.
Maybe we should just be using servos instead of steppers? On paper the cheap Dynamixel XL-320 seems to have the same stall-torque as a NEMA 17 at a comparable price.
Actually scratch that, I was comparing it to a particularly weak NEMA 17. A comparable Dynamixel servo would be 2-3x the price of a stepper.
Awesome work ! , Looking forward for your enhanced version. This could be a one of the kind open source enhancement for a 3D printer I had come across.
Thanks! I’m hoping to start playing around with the next version in a week or so, all going well I should have an update on here.
We did something similar about a year ago, implementing closed-loop control of a printer gantry using AMS encoders, an I2C interface, and hacked Marlin. Details here: https://sites.google.com/site/benweisspublic/projects/imc-closed-loop-control
Your thesis was a big part of the inspiration behind me trying this project – the work you did was fantastic! The system I have here is a lot more basic than what you were experimenting with, and long term I think your approach – full closed-loop motor control – will be the way to go. I’m hopeful my solution can provide a stepping stone between open-loop and full closed-loop, and hopefully kick up some community interest.
I am experimenting with something similar – I am using an optical encoder strip from salvaged inkjet and DC motor instead of stepper. The position accuracy is quite good (I get >7500 input readings over 250mm movement, therefore the resolution is close to 0.033mm).
However, I am struggling a bit with repetier-firmware and its implementation of the feedback look for now. However, using the mican’s approach (github search for DCservo) works OK for me.