jstevewhite, which motor from Anaheim automation are you using?
EDIT: is that print using a direct drive or bowden? (looks like RailCore is using direct drive by default?)
The picture shows areas where afaict “no (or very little)” oscillations appears - is that correct ? What was wrong with the tuning there ?
I would start to tune without printing and i would use the liveplotter. This way should be much faster and easier to compare.
In addition every change of speed will trigger different frequencies, most important is the change of speed (acceleration setting e.g. trapezoidal), jerk and how long the acceleration phase last (size of speed step). Depending on these factors different PID setting will work or not. So your PID-tune test setting has to include different speed steps in different directions for a given acceleration and jerk setting. Otherwise it might work for a certain print and destroy another… To make it more complex, at a corner your will get different results compared to the middle of the print bed. So in the end you will have to choose a robust tuning, which is of course somehow sluggish (and might show tiny oscillations which can be seen e.g. everywhere on your picture).
I have also a fast fdm printer (with normal steppers, i use 20 g for travel moves and 3-5 g when printing, speed is limited to 500 mm/s because of dropping torque, there i saw big potential) and my plan was to pimp it with odrive. Unfortunately tests (on a test rig) last year showed, that in my opinion at that point in time, Odrive was not able to outperform steppers for this application. Anti cogging was even more experimental, i didn´t try long.
Because Odrive has a lot of power and no missing steps can occur, you could also increase friction (damping), this will reduce the ringing further, but also smear out small features.
As you have shown, fdm is not forgiving for small oscillations…
I am looking forward to see a success here, best wishes !
I’m using the BLY172D-24V-2000 from anaheim automation. And yes, the RailCore2 uses direct extruder by default. You can convert it in a few minutes, but direct is the base config.
Well, the smoothest bits in that picture are the best I can get out of the servos right now. The suggestion is that it’s due to cogging, which seems to make sense because the frequency of the small oscillation is constant at every angle and speed. Unfortunately, those small waves are not even in the same class as what I get from steppers right now.
I plan on testing anticogging as soon as I get another motor - I torched on with a mechanical jam that I didn’t EPO quickly enough. Those motors are a hundred bucks, so it’ll be a couple of weeks before I get a chance to revisit.
The big problem as I see it is that the 3d printer controllers available all use step-dir, so the odrive’s only optimization is from one step to the next. We’ll see how it shakes down.
My concern is less about speed - I can already lay down plastic faster than I can cool it - but wall stacking consistency. Typical 3d printers have layer stacking errors > 0.06mm; RC2, properly tuned, delivers variance < 0.03mm; my goal is < 0.01mm of variance from layer to layer - which is down in the noise floor for the physical system.
Thank you for sharing. I want to upgrade my printer at some point to ODrive and wasn’t sure what I can expect. Hope to see you achieve desired results soon! I’ll be following along your posts so keep us updated.
… that is also what i recognized on my test rig. In my opinion, a part of the problem might also come this topic -> Increase Odrive torque stiffness?. But adding a base current (as described in the link) might make the cogging problem even worse.
It seems that the torque stiffness of a well chosen stepper is already quite big because of the higher number of poles, reasonable high kt values and PID-loops add oscillations you don’t have without them. So adding a PID loop adds micro scale problems you have to overcome afterwards with efforts.
500 mm/s is my travel speed limit, cooling is definitely the barrier when printing.
Independently from dynamic problems, If you aim for < 0.01 mm you have to measure it multiple times better (encoder resolution & pulley teeth number vs. steps frequency) this might get really tricky. As long as the variance is stochastic you won´t notice 0.03 mm anyhow. The static and dynamic extrusion rate error is plenty times bigger.
Best Wishes.
This seems quite possible. Empirical testing is king, though. I’d love to test anticogging and see if it’s the solution to that specific problem. The fact that the ‘waves’ remained pretty constant regardless of orientation and speed of travel lends some credence to the assertion that it’s cogging, but you could be right, insurmountable problems might lurk behind that resolution.
A couple of things here. The measurement is in the final print; I’m not trying to measure the motion stage dynamically. The nice thing about 3d printing is that it leaves a physical object behind wherever we might care about its motion.
Variance in x/y along z of > 0.03 is easily visible in a print you’re holding in your hand. 0.03 is easily visible with slightly oblique light. After considerable time spent looking at prints from … tens of printers (at MRRF and at Maker Faire and the like) I’d say typical prints are ~ 0.06-0.1.
Variance due to filament diameter should be < .01 (at e.g. .5 line width, .2 layer height) for quality brands (Atomic and the like). I’m taking that as my theoretical noise floor, though I understand your point. It’s possible that < 0.03 is ‘as good as it gets’, though I’ve got some evidence that I can reduce it by 30% or so by increasing torque or decreasing friction.
Remember that I’m not talking about absolute accuracy, but precision from layer to layer at point x,y.
An easy way to reduce errors from cogging (or in general) is to simply use a higher resolution encoder. Then you can simply squash the error torque with a higher bandwidth feedback.
Of course, cost may be a concern. Still, have a look at the ODrive encoder guide.
I was using the 8192 ppr encoder in a 3:1 reduction, for roughly 600 pulses per mm. I thought the discussion I read on the anticogging showed the encoders tracking the error? Or am I not understanding what you mean? What encoder would you suggest here?
I mean a higher res encoder will be able to hold a better control tolerance in the face of any disturbances (cogging or otherwise). This is separate from anti-cogging. Actually the anti-cogging feature is just a proof of concept and not very usable yet.
Ah, I see. So you’re suggesting, e.g. the 40k ppr encoder in place of the 8192ppr ones? Sounds like something that’d be ok for a prototype, but from your comment about money, might push it out of the range of reasonable implementation for most RailCore users.
Yeah, I was reading about the fact that the anti-cogging code is still POC, but presumed that it might be developed into a real feature in the future. Testing it is also the only way I can think of to verify that it’s actually cogging and not some other variable 
Wetmelon mentioned that it’s not saved between reboots yet.
I suspect these sorts of issues are the reason I see … many … posts in the #reprap forums and on reddit where folks announce their intention to build a servo driven 3d printer and they get about to the point I’m at and then there are no more posts. I suspect this is partly because there are no 3d printer firmwares (that I’ve found) that can control servos directly, but only step/dir.
To be fair, I know someone who implemented ClearPath SK series on a 3d printer and even with the help of their support couldn’t eliminate a couple of artifacts. I know I’m fighting an uphill battle here , and I appreciate everyone’s help.
Yes the intention is to finish the anti-cogging feature at some point. I will take your experience as a strong vote for us to try to finish it sooner rather than later 
.
It would be interesting to see the performance with the 40k encoder, as a demonstration of what is possible if nothing else.
Maybe you could try to increase your steps per unit. I think i read that you were using 1. You could increase on both sides IE printer firmware and Odrive firmware. Speaking of printer firmware I wonder if the Marlin or Sailfish guys could come up with a direct connection and bypass the step dir interface which is not optimal. Just a guess.
There was no visible difference between 1 and 2 (counts per step) other than the fact that I had to (of course) double the steps/mm on the firmware. The waves remained constant, though I didn’t try e.g. 3 counts per step.
It’s not clear to me what having multiple counts per step describes in behavior of the odrive. If I have it set to, say, 5 counts per step, and I issue 2 steps, does it move 6<>10 counts, or does it move 10 counts deterministically? I guess I’m asking does it use “5 counts” as the “range” the encoder should be in, or does it just start counting by fives?
That matters particularly with the 40k ppr encoder; my steprate isn’t high anough to achieve very high speeds with that high an encoder count at 1 count = 1 step.
I don’t know either. I appreciate you trying it out though. One more thing eliminated.
The internal position setpoint is simply updated like:
pos_setpoint += counts_per_step * direction;
So if it was 3, and counts_per_step is 5, the next position is 8.
1 Like
Ah, thanks, Oskar. That clears that up nicely. So with the 40k encoder I could increase that number without introducing error; I’d just be counting by fives. Thanks!
I still need to look up how much those encoders are…
Any update on this? I am too trying to make this work with a corexy and I have the exact same issue with artifact like that. They dissapear at certain speed. Like 50mm/s is fine… then from 80 to 150mm its terrible…then its fine again again arround 200mm/s. Im using a 20t pulley direclty on the motor. So thats 40mm per turn. At 3200 step per turn. I tried several other settings with no luck. There is always certain speed that will cause vertical artifacts
2 Likes
Plus 1. Seems like a good thing to know.
Look up vez 3d tutorial on odrive.