Aha, well, a few things came about. The main one is that at the time I knew _of_ g-code, but didn't really know much about it. I deliberately steered clear of it because I didn't want to make a half-arsed version that looked superficially like g-code but didn't behave properly.

In particular, the polargraphs native coordinates system is very non-cartesian, and every other g-code application I'd seen used cartesian coordinates, and I didn't want them to get mixed up.

Since that time I've learned a lot more about what kind of features I need but I'm still not clear how I aught to implement them in g-code. The "move" type functions are easy, but the other stuff (pen lift, execute from file, define boundaries etc) could be done badly, and I wonder if it's worth having a system that doesn't have much integrity or is going to change rapidly as soon as it's made. Given that the point of g-code is to allow the interconnection of machines and software from different folk, having such a brittle or fragile, or inconsistent interface seems like it could cause a problem.

Is it just curiousity or do you have an application / setup in mind?

sn

Hey TTUSA, I did some slic3r drawings last year - example:

The only challenge I hadn't completely overcome was how to deal with "back face" (for lack of a better term) lines. I did some drawings of nuts and bolts that looked interesting "see through", but for the head I didn't want to draw the slices from the back of the head. I tried two things. One was just loading the sliced vectors into Inkscape and, via the xml editor, selecting and deleting a great number of the first listed vectors, stopping when then the lines I wanted to keep started to disappear. Another technique was rendering a depth map in Blender (Z pass), and using the resulting map as a displacement map on a very high-poly plane. The resulting model is a high relief sculpture kind of thing, which doesn't have back faces. These slice nicely, but there are many redundant lines along the perimeter of forms that need to be deleted manually in Inkscape. If you look closely at the head drawing, near the back of the head, you'll see some smudged ink. That's because I was too lazy to delete the redundant lines, so the outer contour of the head got drawn ~30-40 times. Much icky ink buildup.

I'm looking forward to seeing whatever you come up with, TTUSA!

Hi, no almost all the coordinates that are sent use the native coordinates system because the controller speaks that native system. If it spoke cartesian, then the commands would make sense to a cartesian bot - there's nothing inherently native-ish about most of the operations. The exception is the direct move (straight line move) and that could be a lot simplified, because that's actually converting from native to cartesian, then back again every move.

Something like GRBL is the best option if you want a g-code reading arduino solution, but I'm sure theres a bunch of others too.

sn

GRBL is a really nice piece of work - realtime stuff, and beautifully written. Inspired by Dan Royer (whose drawbot firmware started off loosely based on GRBL, I think), I started a rewrite of polargraph based on the same timing mechanism as GRBL, but didn't get very far, and then noticed that Dan had stripped most of the clever-clever GRBL stuff out of his software too, so I didn't feel so bad about quitting with it. You might want to give his software a shot - I would certainly be interested in a comparison. Worth noting that his software is driven by g-code already.

sn