Open jvolker opened 6 years ago
A friend of mine thinks that the serial connection can be a significant bottleneck as well. He believes this is why arcs and circles should be calculated on the microcontroller instead to avoid sending all of those vertices via serial.
He also pointed me to GRBL.
Grbl is a no-compromise, high performance, low cost alternative to parallel-port-based motion control for CNC milling. This version of Grbl runs on an Arduino with a 328p processor (Uno, Duemilanove, Nano, Micro, etc).
Running this as firmware could probably improve things a lot and take away much of our guessing how to do it properly. For example look at the speed of this DIY plotter running GRBL.
And again @fogleman looked into this a couple of years ago already: https://github.com/grbl/grbl/issues/872 Eventually he went a different direction though and came up with his own firmware, which this project is based on.
Some people in this conversation say it would be worth replacing the Me Orion for a regular Arduino with GRBL shield. But for this project, it would mean every user would have to get different hardware first and rewire everything. I would love to see GRBL working on the Me Orion board instead. But apart from using the Makeblock, I have no previous experience with CNC machines. So I'm not sure if and how I could help with this.
Would like to continue the conversation about increasing the drawing speed started in #10 in a fresh thread as it goes beyond the subject of the original issue.
Just found some more insights from @fogleman.
From his tweet:
It seems like Fogleman improved things further in the Axidraw version of his toolkit.
And from his article:
Maybe it's better to use a general path simplification before sending the job to the plotter instead of trying to write efficient functions for every shape, as discussed in #10?