Close

Now supporting GCODE devices and the problems of GCODE as a protocol

A project log for BowlerStudio: A robotics development platform

Make cooler robots, faster and with less effort.

kevin-harringtonKevin Harrington 05/14/2016 at 15:361 Comment

SO i have all of the basic code in to connect to GCODE devices and use them as bowler devices. I have come across a few problems. The First and biggest is that coordinated motion across more than one axis is possible, but only up to 4 axis (for Marlin) and any more axis than that need "5th axis" and "6th axis" (and so on) machining capabilities. Otherwise, no matter how many steppers your controller can drive, you will be limited to 4 by the GCODE "protocol".

Next issue is how the gcode controllers handle coordinated motion. feed rates are fed in, but used to calculate the linear translation speed of the tip. in non-cartesian situations,such as an arm, this sort of coordination can be tricky to work around. For instance, since the z motor has a much higher steps per mm, any motion that used that stepper gets speed limited to the z's max speed. This isn't a blocking issue, but it is a configuration "gotcha"

Finally, both of the issues are for standard Marlin gcode firmware. If you want to get the most out of a 3d printer controller board, a different command protocol is needed besides GCODE. I will try to put a Bowler Protocol stack into Marlin next to see how well that works.


There are still a few bugs in the gcode bridge (mostly the async position updates) and published for you all to try out in the next week or so.

Discussions

Jonathan Lussier wrote 05/14/2016 at 16:11 point

Great job Kevin, keep it up!

  Are you sure? yes | no