This solution to buffering while moving is one that is already fairly well baked for general machine control stuff - GRBL is the gold standard for this, it's an arduino based CNC firmware, does all kinds of clever business, proper geometry, arcs, lookahead, buffering. It's what most hobbyist 3d printer firmwares are based on (sprinter, marlin), and I personally believe the hype. It's also rather beautifully written, reading it is a very pleasant experience.
However, in terms of event processing, it is pretty radically different to the current polargraph configuration. I do agree that lookahead would be nice (for at least a couple of reasons), but to be honest, not only is it not currently a problem for me, it actually produces an artefact that I like and find very appealing.
I did branch the current code into a background-comms, to have a hack around, and successfully speeded up the comms by a significant margin by removing stupids, so that was a nice outcome, but I didn't immediately see a simple way to merge the comms / command pipeline into the background processes. And it no matter how fast the actual comms, there's still a deceleration and a re-acceleration either side of it.
I don't think it's insurmountable, but it does mean a fairly significant rewrite and restructure. I do think it will happen one day, but unless someone else does it, it'll be later rather than sooner.
Personally, I suspect polargraph may be the wrong tool for the job for you Andreas - at this point in time at least. You could have a look at Dan Royer's (marginallyclever) drawbot code. It is a more stripped down and elegant piece of work than polargraph as it is purely for a plotter type device running from gcode, and I believe it uses the timer-interrupt based approach that means it'll do command buffering. I haven't used it myself.
sn
|