I wonder about the voltage now as Robo things 12V where Town thinks 48V would work too. I would like 24V actually as that would drive the steppers for Z and E and allows me to use one 24V power supply.
If you already have a 24v supply you should use it. Literally the only reason I am driving my motors with 12V is that I had a 12V power supply handy when I started my project.
I wonder about the precision of the movements. Robo noticed some problem in the position and solved it by adding some more inertia to the system. I know / read about balancing the inertia of the system and the motor('s). Best being about the same or a bit less for the load. Do you now have a really (position) accurate system Robo? How accurate compared to your encoder (which has how many pulses per rev?).
The purpose of adding the flywheel is to improve the behavior of the motor around the cogging points. With the flywheel attached the motor takes more time to “settle in” to one of the cogging points and the ODrive is able to counteract this. With the flywheel attached I am able to maintain +/- 3 encoder counts of positioning. As towen said this reduces the overall performance of the system, particularly in terms of acceleration and power consumption. A technically better solution would be to add a gearbox, but this requires much more engineering effort . As I mentioned earlier my motors were far more powerful then was necessary to meet my performance benchmarks so this loss of performance was inconsequential for me.
I don’t understand you emphasis on utilizing regenerative braking. My gut feeling is that any energy that you are able to be recover will be irrelevant next to the total energy consumption of your machine. In my laser cutter the brake resistor only barely gets warm during the most extreme possible acceleration/braking cycles. Think about how much power is going to be dissipated in your heated bed alone.
I would like to note that I tried the anti-cogging support before I added the flywheel and I found that it made the issue worse. I would not be expecting a magic bullet.
However, I’d like to reiterate my point from earlier. Step/dir is a bit stupid. How are you supposed to generate an efficient torque profile if you don’t know where your stopping point is? It’s also intolerant of noise or communication issues. It’s designed for stepper motors. If you have a servo motor you should be sending it absolute setpoint values, not relative ones. But I guess I’m ranting now.
Thank you Robo, I’m curious about Towen’s reaction on it but can imagine so myself indeed.
I liked the idea of regenerative as a technology but have abandoned it completely with all of your help. It’s not needed at all and indeed the plate will have 1500W heating element so… .
Your 3 counts is on what encoder? How many cpr does yours have? If it’s like Towen’s that’s amazingly accurate (and load independent) compared to the stepper article…
No I agree completely actually but I see a two stage here like mentioned above. The simple one is the step dir approach and then one can proceed to the next step doing it right with a direct connection to the pi / klipper.
With the step dir approach I think it means one depends on klipper software to compute those profiles (it uses Scurve as far as I understood).
My guess is that as long as there are a lot of small steps sent to the Odrive (with a high frequency) the inertia of the system will allow the Odrive to generate a smooth movement. A bit like Robo mentions to solve his cogging issue.
To give an idea of what can more or less be achieved here since numbers from klipper:
It’s a test so no real case but the SKR I was referring to is the last one. So I think a multi / many kHz step signal is no issue and should give smooth running?
The Step/Dir interface is designed to directly mimic a standard stepper motor driver, so yes, the Klipper software will calculate the trajectories and such just as it would for stepper motors. There is no communication back to the Klipper software from the ODrive. This has no relation to the cogging torque issue, that has to do with the closed loop control that is happening within the ODrive.
That’s interesting when reading I think the Scurve from Kipper is a higher order filter actually. Could it perhaps interfere if the pulse train is high frequent enough with consequently small position steps? For sure it will help when the position steps increase, giving less “jerk” behavior!
Well guys: I’m all enthusiastic about using the Odrive! Gonna buy me one once I’m back from vacation!
I’m really interested to see where this project goes. I wanted to start something similar one year ago and started a discussion here:
In the end I went with Klipper and an SKR Pro Board with TMC5160 drivers running at 48V and Nema 24 steppers. This also gives an incredible performance at much less complexity. Of course, the energy consumption is much higher, but it works fine for me.
The reason I did not go along with odrive, was that Step/Dir was the only method to get the trajectory information out of a trajectory planner like Klipper or any other 3D-printer firmware.
My conclusion was that odrive is great for driving one or several individual axis in real time, but what I needed was a coordinated, pre-planned movement of several coupled axis at the same time which obeyed certain restrictions like speed- and acceleration-limits. 3D printer firmwares were the only things that could do that.
In theory, Klipper would be the perfect software to pre-calculate the trajectory and odrive would be the perfect solution, to drive servos. Both of them together would be able to make much more performance oriented and quieter 3D-printers, but currently there is no good way to transfer the pre-calculated trajectorys from Klipper to odrive, besides the “better than nothing” Step/Dir interface.
Thanks marine from space. I’m getting quite excited about trying. If all were to fail I can always replace with a stepper, so I see only positive things in trying the Odrive with a lot of potential improvement over those steppers
I can get a good deal on Tarot 6S 380KV 4008 4108 motors. They seem perfect for the job (?) and documented on Odrive. But I’m a clear novice and wonder how to:
connect the encoder in the back when it doesn’t have a second shaft sticking out? This is obviously very novice question, but I thought I’d ask anyways.
if it makes sense to mount the motor with a coupling as it doesn’t have a shaft coming out either and I fear misalignment with an adapter with shaft. Does anyone have an example setup perhaps on a Tarot?
I’ve also been thinking about the input filter for the step / dir. I found following on the step / dir interface.
There is also a config variable called <axis>.config.counts_per_step , which specifies how many encoder counts a “step” corresponds to. It can be any floating point value. The maximum step rate is pending tests, but it should handle at least 50kHz. If you want to test it, please be aware that the failure mode on too high step rates is expected to be that the motors shuts down and coasts.
So I wonder at what frequency the Odrive drives the Servos? Probably higher than that, so the input filter makes sense for sure.
So I didn’t give it too much thought at first, but what is really meant with a second order filter? Is the filter meant to upsample the signal to the Odrive control frequency?
I ask as I imagine stepper drivers do something similar with the incomming signal from the controller…
Most definitely, I am using ODrive at 12v for CNC and it doesn’t even remotely get warm. I’m using an Arduino Mega 2560 only and controlling the ODrive over serial, not step/dir.
I did exactly this, I have a bench power supply connected directly to a 12v lead acid battery (75Ah) and this connected to the ODrive (power in port) with its supplied resistor in the brake resistor port. I get around 65000 cps max velocity (with AMT-102, 8192cpr) without the battery and over 300,000 cps with the battery.
Also, without the battery I had a lot of current unstable messages due to low voltage dropout, something I never get on batteries.
Now I have my ODrive CNC machine running off 12v batteries and a 50W Solar Panel ;-D.
You wouldn’t connect it in place of the resistor, you’d connect it as you originally suggested, in parallel with the power supply. You can leave the brake resistor in place, and just set its resistance value to 0 in the config, which means it won’t use it, and will instead send regen energy to the battery.
Using a bench power supply you can adjust the voltage and current limit so that it doesn’t overcharge the battery, although a dedicated lead-acid trickle charger might be better (and cheaper). And a lead-acid battery won’t explode in flames when you overcharge it. (it does give off a bit of Hydrogen gas, though!)
The battery will also prevent the voltage rising too much on regen braking, which would otherwise bork your power supply. So I can see that it does make sense (although a large capacitor would also do fine). 75Ah seems a bit overkill though!
You are right - it can help precision in some cases. I just realised why on this thread:
If you are getting to the point where you need a higher current control bandwith than the controller can provide (i.e. >4kHz) then adding inertia can help, by essentially making the motor more sluggish to move so you don’t need such fast reactions from the controller. But it’s probably an unusual case for ODrive, which runs at low voltages where the inductance is probably the biggest limiting factor for current control bandwidth.
I’m checking your youtube movies Dev, thans for posting. Really interesting and helpful.
So cool to know that as Robo found, inertia can help to keep the motor from cogging and I imagine it can also help to improve the smoothness of operation when the Step / Dir is not really giving a high enough (frequent) pulse train. I’m now trying to find out how many steps I may expect when running an SKR with Klipper. But so easy to find the info though.
Also I’m still very interested in the filter function on the Odrive. Hope @Wetmelon can share more insight if it is indeed an upsampling of the pulse train or if the second order filter has another purpose.
And I hope I can fit an encoder on the Tarot motor?
Ok I did some more homework on my current Duet3 and I can expect to send up 120k pulses per second to the Odrive and even more if I could use the driver output wires (the A B etc) if I put in some kind of logic electronics in to get the step / dir back and eat the current?
But I would think 120k pulses per sec would be enough as it will give me a max speed of about 500mm/s print speed on a 8192 encoder sending a step for each countbwhich is more then enough right?
. As I mentioned earlier my motors were far more powerful then was necessary to meet my performance benchmarks so this loss of performance was inconsequential for me.
.
