The same series of scribble pixel commands:
Look closely, exact same pixel shapes for each one. I know random numbers are hard to come by in the digital world, but I did expect the arduino random() function to be slightly less deterministic. Funny.
I think the differences in the line shapes can be put down to different motor speeds / accelerations.
When I use my array of scalpels and box cutters, they get blunt. I don’t notice so much, but slowly, I’m applying more pressure to get the same cut done, I’m tolerating sub optimal performance.
It’s such a good feeling when I put a new blade in, cutting like butter, and every time I do (every time) I reflect that I mustn’t leave it so long next time – the benefits of having the right tool for the job outweighs any notional benefit of being a cheapskate.
As with soldering. I can do the surface mount stuff easily and quickly en masse, but I dread the through-hole stuff, the pin headers and sockets. It just seems to take forever, and is a battle.
I looked at the iron tip, which has slowly been getting narrower and narrower. It was initially thin to do 0804-scale surface mount soldering, but I now use hot air for that. It’s no longer the right tool for the job, and it’s terrible corrosion makes it even worse. I looked for a replacement, but remembered I had got a multipack of tips last time, containing a mixture of sizes. Grumbling, I put the next smallest one I had on, and after the first joint, wished I’d done it months ago.
Bigger tip = more heat = quicker joints. Obvious.
As an amateur, economy plays a large part in my reluctance to snap off a blade segment, or unwrap a new blade, and also storage and access (trying to remember where I put the spares months ago).
As a professional (which I suppose I am) I have to balance cost with speed and quality. And as an employer (employing myself albeit) I have to balance cost with quality of life.
Right tool for the job.
I got a new batch of stepper drivers, Pololu ones. They run hot and angry, and so benefit from a bit of tuning to soothe them:
Takeaway: Twiddle with the trimpot on the board until you find the sweet spot between gentle microstepping, and a good grip. That spot seems much smaller on these drivers.
The location of the motor terminals on the polarshield is a bit awkward. One of them is fine, but the other is directly above the USB socket on the arduino board underneath. So that’s fine for the PolargraphSDs I make because they use arduino boards with micro-USB connectors.
But for anything else, the pins from the connector will come into the contact with the big USB-B shell on the arduino below, and that’ll short, and that’s not cool. I always almost always do the following to a Polarshield to get around it:
First snip off the protruding pins and file then down almost flat. I make extra sure there plenty of solder lining the holes for these ones.
Stick a couple of pieces of electrical tape over the little nubs that are left.
So now it fits flush, that’s good.
I saw this mentioned on Julio Terra’s blog where he mentioned putting a bit of tape over the USB shell to insulate it. I scratched my head because I always do the above operation for the polarshields I sell as part of vitamin kits. Except obviously I missed this one! Tsk! I know, shameful.
Today I am very pleased to report on a great looking and useful setup guide by forum member Gontiki. He’s had lots of challenging questions and useful suggestions on the forum, and has written up and illustrated his experiences with a PolargraphSD vitamin kit.
Great, clear photographs (they make the kit look rather pro!), and good descriptions. I know it’s shameful to be pointing people to other sites instead of updating my own documentation and things, but there it is.
What’s that? Another setup blog?! Yes, Julio Terra has a couple of great posts on his blog too:
He’s setting up a drawing machine at The Lab (an interaction design team, part of a big architecture firm) in New York. Great to see his thoughts, and I am dead keen to see what kind of stuff they get up to with it.
I’m actually really pleased (and relieved) that Gontiki and Julio are having good experiences with their kits. It’s easy for me to send machines off into the wild in their boxes and fear the worst – that they sit half-assembled in a drawer, amongst the dust of other disappointments and failed projects. So this kind of positive feedback does me so much good, as well as being great for the project – the more people there are showing exactly how simple (and exactly how complicated) it is to set up a machine, the better.
So thank you for the therapy.
Of course it does. Long time Polargraph supporter Wes Nijssen let me know about a project where he used his Polargraph machine as a large format plotter for drawing out the parts for a giant piece of papercraft (cardboardcraft) for his agency’s office.
Here’s the link to the blog post about it.
I often thought large format papercraft would be a great use of the machine, and I’m impressed that it was precise enough to do the job. Great stuff, thanks Wes!
I haven’t really explained anything about how the polarshield works, except that it does.
Having a close look, you’ll notice there are very few active components. The Polarshield is largely just an interface board that lets a bunch of regular-shaped things plug into an arduino, so it’s mostly pin headers and passives.
The XBee port switch (top left, next to the servo pins) bears a mention: The up (or right, in this pic) position disconnects the XBee port and allows programming and comms via the USB port. Switching down (left in this pic) connects the XBee port that allows serial comms from that module. If there is an XBee plugged in then having it switched in prevents reprogramming via the USB.
I’ve detailed the connectors on here too, most interestingly (I bet) is the END STOP connectors. These are input pins for four switches that would be used as limit switches for self-calibration, or for emergency stops. The code doesn’t really use them yet, but it will soon, I’m working on it!
The good news is, those pins are available on all polarshields, so it’ll be pretty easy to add retrofit the self-calibration / limit switches to any vintage of board.
Kongorilla let me know about this great new bot, or rather a great new service / business – it’s a Dutch company called Black Stripes, who offer a poster / drawing production service that offers a very handsome web-based input and preview system (go to “shop”) and output the artwork using a very covetable hanging-v plotter machine
Beautiful results and a really nice, industrial-quality setup. Big steppers, big drivers. They seem to be using a Raspberry Pi + arduino combo with discrete CNC style stepper drivers, and toothed belts for suspension. A solenoid raised or lowers the pen.
It’s great to see an actual product based on this process, and some degree of automation going on too, in the image upload process. I like best that the form of the output, the direction of the lines is a succinct expression of the form of the machine – the drawings could only come out of a machine like this, and the angles at the intersections and the and centre points of the arcs are all fingerprints tied to this particular machine too.
They have their counterweights running on little tracks too! That’s a good idea.
Most people think that Jurg Lehni’s Hektor was the original hanging-v drawbot. I know I owe my excitement about drawing machines to seeing that video ten years ago, but I also remember being pretty frustrated at the time that there was no instructions on how it was done, no software, no hardware. That’s always been the bit that interested me.
Though the mechanical setup of the hanging plotter machine seemed obvious enough to me that I was sure that it must have been done before Hektor, I never saw any evidence of it until this video:
That shows a hanging-v plotter in action, at the SIGGRAPH show in 1988 made out of Technic Lego, drawing more-or-less the same test patterns I was working with this time last year. This confirms Hektor as only the most famous (and messiest) example in a long line of revisions stretching back at least 25 years. It’s good to kill your gods every now and then.
I am excited to see so much interest in the last year or two in drawing machines, and am pretty thrilled to be involved in that surge of interest – I am vain enough to like to think I have done something to help it along, and I have met lots of great new people along the way – thank you for being interested enough to harass me into doing it better!
Happy holidays to you all!
Hello, thank you to the couple of you who have been waiting a long time for your machines, and are very patient. I’m behind, for a couple of reasons: 1) New job means less flexibility in the short-term (don’t want to give a bad impression you know). 2) Worrying problem with the touch-screens. They weren’t working. Touches being registered, but position mangled, and then locking up the whole machine. Not good.
Thanks to dc42 on the arduino forum, I think I have a solution. Now, the real question that I am going to shy away from asking myself is “why did this only start happening now”. I thought the lines that I find were causing the issue were inserted as a response to this problem in the first place. But I could be wrong, lost in the mists of time now. I wonder if slightly different manufacturing tolerances on the LCDs or the megas have led to a slightly different behaviour. I have moved to using the new UTouch libraries instead of the ITDB02_Touch ones (more or less the same). As ever, the updated code is in the code repo. I haven’t packaged it up, because I’m not clear that the code in the current release zip is causing any problems. At any rate, it’s only the touch-screen stuff that’s the issue.
Anyway, so that’s 3) The solution. And big news: 4) I have a workshop now! I’ve rented a studio in Art’s Complex in Edinburgh – this should give me better separation of business and pleasure and lead to routine stuff (kitting) being done faster – or at least at a more reliable pace. Thanks!