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.
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
I’m not sprooking what I’m doing.
And I’m sure like every one else I’m going to have issues on implementation of my system.
I’m working on two systems at the moment.
First one is linear tubular motor bldc.
Ironless.
No cogging.
Second is a bldc motor ironless.
But not your normal set up.
I had the brainwave the other day after seeing a knew motor come on the market for robotics.
It would be very easy to convert to ironless.
But no time as of yet to get on it
Wetmelon mentioned that it’s not saved between reboots yet.
.