Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Increase drawing speed #14

Open
jvolker opened this issue Mar 7, 2018 · 1 comment
Open

Increase drawing speed #14

jvolker opened this issue Mar 7, 2018 · 1 comment

Comments

@jvolker
Copy link
Contributor

jvolker commented Mar 7, 2018

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:

I've been tweaking my #axidraw and my motion planning algorithm for optimal performance and less noise.

It seems like Fogleman improved things further in the Axidraw version of his toolkit.

And from his article:

Simplifying Paths
Once we’ve sorted and joined the paths, we should simplify them, again to some specified tolerance. The Ramer–Douglas–Peucker algorithm is an easy way to implement polyline simplification. This reduces the amount of data we need to send to the plotter. But more importantly it improves the results of the motion planning algorithm. (I implemented my own constant-acceleration motion planner, but that deserves an entire article of its own.)

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?

@jvolker
Copy link
Contributor Author

jvolker commented Apr 3, 2018

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: grbl/grbl#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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant