hello guys, now embarrassingly I’ve just looked at the last time I posted on this forum, and it was almost 12 months ago… and the reason it’s embarrassing is because I’ve not really spent anytime tinkering with my o drive so if I’m outcast from the group I understand…
But ok… the reason I’ve started this post is because I’ve got a desire to update the electronics on my 3d printer, I want to use the o drive for the main motion control,
But I’ve got no controller I’m wedded 2, so the question is, what should I go with… my main objective is speed and precision, I’ve got some boards and a smoothie plus the usual ramps gubbins…
But as i never seem too do anything the easy way, and well if anyone can save me months of time wasting that’ll be amazing
Thanks
Pb
Anything that does step/dir will work, but it’s limited in pulse rate.
Strictly speaking, an industrial controller with CAN would be best
that’s very interesting you mention the limited pulse rate… I’ve been on the quest to build a fast (ish) 3d printer, and It always boiled down to being able to not only handle the mechanical aspects… (it not just falling apart from the forces… ) but the speed you can process the Gcode, when researching this quest yesterday I found the Klipper firmware which does feel like it fits the bill nicely for processing performance… as you could actually run it on a modern SBC like a Pi4, or other… but if that’s not enough horsepower then it can run on a full on PC…
but then… and this was almost knocked me off the sofa, its possible you can have klipper control more than one “board” to drive the printer…
Soooooooooooooooo… this made me think… can the Pi command the Odrive via Can, and then use the USB or SPI or something for the other hardware interfacing, like the Z axis, temperature feedback, Mosfet control of hotend etc…
now the Klipper forums don’t have anything quite like I’m thinking of (well not where i could find it… ) there was a few honourable mentions of Odrive, but oddly it seemed to be saying that it wasn’t really suitable, but my thinking is it’s likely to be better than your nema 17 steppers,
so … (and this is me on my knees at the end of the bed wishing to the tooth fairy here… )
if someone can advise me
- if this is a good idea
B) if its already been done
III) where the github repo of the Pi image and the pdf of the instructions are… 
now i know this is an Odrive kinda place… and 3d printing is more than just motors, but kilpper looks to be a good set of tools for all things 3d printing… and if Odrive can be the V8 (or Tesla drive train) of the 3d printer world… I’m all for cruising about slowly in my very powerful car, just because i can … so what I’m saying is… tweeking and tuning systems like this is like tuning a car… its endless, you get more power you need better tyres, you get more grip you need bigger brakes,
currently, my 3d printer is sat on the driveway on bricks, and the neighbours are starting to whisper about how I’m lowering the tone…
anyway … good idea??
Pb
Hi mate.
I’m doing a 3d printer as well.
Stuck on the same issue.
I was looking at duet 2wifi.clone.
With expansion board to get me started.
Maybe we can link up.
Hello Manematician
the more the merrier…
i’ve got a pile of old 3d printer boards… ramps… smoothie, MKS and the board that came with a tronxy 5 which is the printer I’m working on …
with the klipper firmware doing all the heavy lifting on the motion control side… and then just using the boards as slaves, it strikes me that Odrive is kinda ideal for that… use a PI and send it commands…
now I’ve not done a lot of Odriving… and the original plan i had for odrive was connecting it to a PLC for a very simple conversion on a Huge surface grinder… that project was done in the end a different way using more traditional ethercat AC servos, but when i was thinking of using odrive i had the idea i would get the PLC (which was running on a PI, under Codesys) to just send commands to the odrive via a bit of python code (which i could have integrated into the PLC software… (which i did in ladder))
so I’m going to start playing with Klipper… .and see how it bolted together… and hopefully, i can direct the commands for the X,Y motion to the odrive… and the other stuff say a ramps board… and well … just think how cool that would be.
I’m excited…
off to see some klipper i think…
Pb…
There is some YouTube videos on odrive 3d printers.
But not many.
Until now I haven’t done any programming.
I’m mechanically minded.
Electric motor rewinder by trade.
I’m doing a bldc linear motor conversion.
I’ve so far designed and built my motor.
Purchased a magnetic linear encoder.
And started to set up a y axis frame (Cartesian style) just for testing.
Hunting around for shielded cable on alliexpress.
Very hard to find anything that’s what they advertise as.
We’ve talked about this a lot on the forum / discord server. A Klipper implementation would be dope
I connected up on discord.
Couldn’t find how to connect up and talk about this stuff.
I’m very interested for a linear motor implementation.
I was reading on another post that duet is hard to implement.
Is that just the can side or the board in general.
I’ve taken a look at the klipper codebase before to see how much work this would require. Klipper (and other stepper motor trajectory planners) usually have variable data rate and constant position steps, whereas servo amplifiers like ODrive expect a constant data rate and variable position steps.
For example, if Klipper knows that you need to move the x axis 100 steps in 10 seconds, it precisely calculates the time between step pulses and sends that to the motion controller. This is because a step is a fixed size, so multi-axis accuracy comes from timing.
ODrive (and other servo amplifiers), on the other hand, can handle variable steps, so it’s easier to send commands at a constant rate like 1000 commands per second and let the difference between positions be whatever it is.
A good amount of the “special sauce” in Klipper has to do with how it calculates and packages the time between steps into commands for the stepper driving board. The ideal case for Klipper->ODrive would be to hijack the trajectory planning after it calculates position and velocity equations and before it samples it into <time between steps>. Once you have a set of equations describing position over time (not quantized into steps), just slice it 1000 times a second to get position setpoints for ODrive. It would also be strongly beneficial to sample velocity vs time and send that to ODrive as a feed-forward command for better tracking.
Depending on the rate that Klipper sends timestamp messages, it might also work just fine to modify ODrive to accept native Klipper command messages.
2 Likes
So has anyone done this yet
this feels like a project that would be well worth doing… (but then i’m stood in my world… so i would say that… ) now looking at the dev notes on the klipper code_overview page it’s organised, and it looks like a module could be swapped in to do more Odrive’y things… but that’s me looking at the 10,000 ft view… and oh … i know nothing about how to go about tweaking it… but that said… i want to help… and if someone wants to hold my hand i’ll give it a try… (but maybe this will be a slow burner… and not a 2 hour cut and shut… ) but that said… I’d be happy if it was done this afternoon…
Pb
now you know what happens when you dont read all the overview… you end up with silly ideas…
but
so klipper does some clever stuff to get the timings for the steppers… (like Pjohnson said) its all about when to tell the stepper to step, as the stepper just moves when its told… we don’t want 2 do that… we want to tell the Odrive every fraction of a second to move xx amount… which is a different challenge. … this looks like its going to involve setting up some printer config files… and hopefully just a buit of manipulation of the move commands out to the odrive… (the bit i cant quite figure out is how to process both on a fixed time schedule, but also not ) ahhhhhrgh my head is hurting already…
but only for the X & Y motors… (in my case… ) I was planning on keeping the z axis and the extruder on steppers…
ok, I’m gonna get Klipper up and running on a PI and start having a poke at the code that makes it all work… you never know… it might just be easy…
Pb
1 Like
I’ve been looking at using a fork of Grbl called Grbl HAL. It’s a fork of Grbl for ARM microcontrollers. Supposedly it was designed to be pretty easy to add extensions for new types of controllers/kinematics but I haven’t done any of the necessary coding yet.
For a while I was writing my own firmware that communicated of the UART interface and was getting pretty reasonable results though that eventually died off and I’m now looking at building onto an existing firmware instead.
We’ve setup our printer with Duet 2 Wifi & Odrive. It is true, that you can’t use the CAN-bus currently, as Duet supports only CAN-FD and Odrive only CAN. Theoretically one could implement CAN on Duet, but it’s a lot of work.
More promising is the outlook for Odrive 4 with CAN-FD.
Anyway, we are working for now with the step/dir interface, which works flawless. We haven’t had the issue yet of missed steps, even at speeds of 1800 mm/s with +10 kg payload. And that isn’t the end of line, we’ll just need to take safety precautions before going any higher.
On Duet side I can’t come up with complains. Maybe here and there some ideas for the DWC UI, but nothing really important.
1 Like
Thats amazing! I have been looking for more info on this for a bit now but this is the first time I’ve seen someone say “yes, its working for us and working well”.
FYI, I also found the resource/blog post from the Hangprinter project were he talks about wiring up two Odrive controllers for step/dir AND connecting them over Uart as well! very helpful diagrams too. You may find more interesting stuff on his gitlab page as well.
Hangprinter Blog
Gitlab Page for V4 dev
Hi I’ve just ordered duet 2wifi with expansion board hoping this would be the way to go.
Am I able to contact you for advice.
Thanks in advance
Tobben has helped us a lot during our development. In fact, our printer originates from the Hangprinter. We added one additional axis to expand the print volume. The Hangprinter has a print volume in a shape of a trumpet, where as ours has mainly a cylindrical volume. The top most part is reduced in diameter, so effectively the volume has a shape of a bullet (more or less).
Tobben’s dev blog has lots of crucial information, but there is a lot of info scattered over different forums, websites etc. Maybe the most comprehensive source is Project Trikarus About Trikarus Project (Hangprinter) - Trikarus Project Overview - Stadtfabrikanten e.V.
Our Bloft Mk2 will be available at some point in future (late '21/'22), also as an open source kit. We will start with the documentation after summer, I think.
Please be warned, that building a solid Hangprinter based on Duet/Odrive is quite an endeavour. You will need time and patience. And once you figured out that FDM won’t do the trick, it will get also really expensive.
1 Like
Sure, hit me with your question 
1 Like
Did you use a differential line receiver to help with noise and if so what did you use.
I saw a blog called everything bends.
He used one he assembled him self.