Marlin I2C? #43
Comments
|
I am not sure what could be the best way of integrating the servo drive in
Marlin. I2C or just a serial port (Arduino Mega has four and only uses one
or two). Going forward to implementing the trapezoidal motion pattern on
the motor controller frees resources on Marlin side and makes its code less
time-sensitive. The planner could just queue the motion command and wait
till it is done (all of it through a serial connection).
However, if using an ARM processor maybe all of it can be under the control
of the same processor, making it simpler and cheaper (though software would
be more complex and time-sensitive). I am working towards a controller that
can handle at least four motors to test the waters.
…On Mon, Mar 12, 2018 at 1:56 AM, paukstelis ***@***.***> wrote:
It seems like Marlin now has included quite a bit of I2C code for some of
these Aus3D encoder/steppers. This got me thinking that it might be better
moving forward for DC motors to do I2C to set/get encoder positions
directly from the firmware with feedback from the motor control module to
let the firmware know that each axis has completed its move. Is this
ultimately the idea of the trapezoidal system?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#43>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAccyJ8S56YamRGGgmQe1coUuYkGpYh2ks5tdcfSgaJpZM4Sl8Qb>
.
|
|
misan, any progress on your multiaxis controller? I have "finished" my previous project and it prints quite nicely given the mechanical limitations of the design I was building off of. I just picked up a frame with X and Y motors for something new and trying to consider which route to take (multiple pro micro or single controller) as I plan the next steps. |
|
@paukstelis Life gets in the way and I have made not much practical progress as I keep on reading. A multi-axis controller is not yet in the near future. |
|
I understand how that goes. I did recently see this that seems to indicate that thinkyhead was using i2c to control a second board for z-axis. He's sending gcode so that probably means there weren't many modifications to the planner, but it does suggest that this could be done without too much trouble. |
|
@paukstelis, in order to keep multiple axes in synch (needed to draw lines) Marlin/GRBL and others, use Bresenham algorithm. GRBL adds AMASS to prevent slave steppers to be triggered at odd moments. Alternatively, each axis could have its own timebase and trigger motion at appropriated times (more computing resources but better physical modeling). That is precisely the case when each motor has its own controller. Planner forwards each motor the next move parameters (vin,vout, accel,decel, cruise speed, total steps) and then there is a common GO command for all the controllers to start a at a similar time reference (motion synch happens as a consequence of each one of them having been properly planned). I've used I2C to read a couple of bytes of a magnetic encoder (at default speed takes hundreds of microseconds). That is not much time if that processor is not tasked to pulse the steppers but a pain otherwise. |
|
I showed off my printer that uses dcservo at ERRF2018 this last weekend. Seemed like people really liked it and I got a lot of great expressions when I would grab an axis and it would move back to position. I was able to talk to thinkyhead a little bit about getting some feedback into Marlin. My brain was a bit fried by that time, but he seemed to think that doing something similar to how backlash correction is being handled would be the easiest first way to start supporting DC motors with encoders. I suggested he talk to you about what approach to take, though I'll help test whenever I can. |
|
Hi @paukstelis, I would happily share my views with thinkyhead. I have been thinking on how to do it all by myself for quite a while so I have some ideas on how it could be done. However, I see it may mean a bit of a radical departure from the way the stepper-oriented code is built. Anyway, the more people that work towards including DC motors with encoders, the faster/better we will have a working firmware. |
|
I'll open a feature request on the Marlin github and perhaps take the discussion there... |
It seems like Marlin now has included quite a bit of I2C code for some of these Aus3D encoder/steppers. This got me thinking that it might be better moving forward for DC motors to do I2C to set/get encoder positions directly from the firmware with feedback from the motor control module to let the firmware know that each axis has completed its move. Is this ultimately the idea of the trapezoidal system?
The text was updated successfully, but these errors were encountered: