His code looks like it could be more efficient and elegant than mine, and its clarity is refreshing, so I’m interested in either adapting it, or just using it outright. Prompting me to think about moving to a g-code based language too – it kind of does make sense. Just not sure how to deal with the dual coordinates system (native and cartesian).
No impressive results in terms of actual drawings on the site, but have a dig around and there’s some really nice stuff.
Just came across this brilliant drawing machine on Norwegian Creation’s blog.
What a handsome gondola! And the quality of the drawing is beautiful – would love to have a peep at their software. The enviable sharpness, I guess, is a product of the big brass weight that keeps the whole thing very tight. It uses a variable-width line – but doesn’t seem to have identifiable “pixels” as such, I wonder how it does it.
In response to Kongorilla’s request for cleverer pixel skipping routines, I’ve just uploaded some new code.
Note, if you’re going to use the controller, you also need to update the firmware too.
1. Pixel skipping.
Skipped pixels are ones that are masked, or that are outside of the brightest/darkest thresholds. Normally skipped pixels are simply omitted from the command queue – they just aren’t transmitted, and this is fine for ones around the outside of an image. It does mean though, that skipped pixels that are in the centre of an image get drawn as blanks – a line through them as the pen trundles towards the next drawable pixel.
So this is changed now: The default behaviour is now to lift the pen while moving over skipped pixels. For one reason or another, it does mean that even skipped pixels get transmitted so it might take longer, but the pen will be up during that time. You can still go back to the old continuous-line way by choosing the other option in the dialog. I believe this still works as before.
This works best if you use it in conjunction with masking and reducing the brightest pixel threshold a bit to weed out the false positives that are not completely blank, but are nevertheless too bright to be expressed by the machine as anything other than a straight line.
2. Faster communication
With this release (v1.1.6) I have switched over to using a CRC-based system to verify the integrity of the command. Each command has a checksum appended to it when it’s transmitted, and when the machine receives it it recalculates the sum and if it matches what’s on the end then hurray, the command was not corrupted. If it doesn’t match, then it will signal to the controller to resend the last command. This is twice as fast as before, so that’s good. But it’s not compatible with the old way of doing it. Well, it might work, but it probably won’t.
How it used to work: Basically the controller used to send a command, then the machine would acknowledge it by sending it back, and the controller would check to see if it came back unchanged, and if it did then it’d conclude the message was properly transmitted and send a final execute command. It was fairly safe, but it was slow because there are three messages exchanged for every command.
I put it in as a response to some dropped pixels I was having back in the day, where every couple of hundred commands, one would get truncated or mangled for some reason.
I’m off on holiday for a few days from tomorrow, so if it all goes wrong, goes on fire or destroys your drawings, please wait until next weekend to be cross with me.
I jumped on the bandwagon with my mooning and it came out really nice – the coarse resolution of the polargraph suits this kind of half-toning very well.
Read the whole thread for some interesting experiments. Thanks to all involved.
Kongorilla did make the point that running this in a tethered mode (as opposed to from an SD card) is deadly slow, and that’s made me look again at implementing a native circular pixel style, so look for that some time soon, hopefully for UNO-sized arduinos.
I always had a terrible fear of Eagle, the PCB design software. It’s been written by and for engineers, which is great if you are one, but as a beginner to PCB layout and design it’s horrifically opaque and counter-intuitive.
But it’s gotta be done, so I soldiered on and successfully produced a suite of gerber files for a little breakout board that I need for the motors.
And I think it actually worked! It’s off to the PCB makers anyway, so that’s exciting. Actually it turned out to be – like most things – pretty easy when you know how. I am positive I have done something wrong, and these will come back twice as big as expected, or with the text reversed or something.
This is a tiny board that will accept the 2mm pitch ELCO 8283 connectors that are on the end of my motors, and present a set of 2.54mm pitch pins which is a much more useful kind of connector to have. Current plans are to use this 22AWG ribbon cable with these IDC connectors on the ends to produce the motor wires.
Didn’t really need a pic for that, but it’s so adorable I couldn’t resist it. That shouldn’t be too onerous, and the mess and faff crimping the motor cables was always the main source of sore fingertips and misdirected rage for me in the past. And they are a bonny colour too.
I plan to produce a variant of the motorshield that has 2.54mm pitch connectors instead of (as well as) the screw terminals currently on there, so I won’t need to make funky breakouts for the connectors on the motorshield end. This is A Good Thing. I’m gradually moving to a “designed” machine rather than a cobbled-together one.
I’ve made up a couple of Polargraph SD prototypes following this same kind of pattern. They are very simple.
It uses a Mega protoshield (a cheap source of which I am yet to find), an Adafruit micro-sd breakout board, and the motor driver shield of your choice.