Monthly Archives: May 2012

Polarshield testing

Posted on by
Reply

A few things came out of my initial tests:

1.  The board, fully populated, is prone to resetting while handling with fingers.  Now this, obviously is pretty disasterous and indicates something operating very close to its reset threshold.  I’m using a transistor in the XBee circuit so that the board can be reset by the XBee – this should allow remote programming / firmware upload, and I _would_ like to have it.  When I take this transistor out, then the board is robust, and doesn’t reset itself.  I will have a closer look at this and hope it is a matter of tweaking component values either side of the transistor.  If not, then I am going to dispense with the transistor entirely.  It has dual footprints, so either a SMT or through-hole part can be mounted, and if you’re happy with the risk, you can solder them in yourself. If it isn’t there, then everything will still work ok, but you’ll need to plug in with a wire to do upload firmware.

2) The voltage divider that handles the SPI interface to the SD card didn’t work.  Seriously.  I can see now that it’s obvious that it won’t work (5v input, 10K resistor between output, and 10K resistor to ground.  I guess the circuit was shooting for 3.3v output?).  I went back to check the source of the circuit to see what was different about that … turns out that doesn’t work either, and never has. Fixed by adding links instead of resistors in half of the divider.

3) Orientation.  The screen mounts onto the top of the board, and orientates the board so that all the cables come out the bottom.  While this looks very neat in a sketchbook, or when hanging up, it is a pain to work with loose .. because there’s no bottom-edge to put it down on.

4) Screen orientation.  The screen can mount directly to the board if the board has female headers attached.  This makes it really neat and handlable but perversely makes the problem above (wires coming out the bottom – oof) more of a stinker.  A solution is to put male pin headers on the board, and have the screen mounted on a short piece of ribbon cable so it can be orientated separately.  Thoughts about this are very welcome as the board can’t easily have both male and female headers, and there’s no going back once they’re soldered.

Currently looking at shipping these initial kits first thing next week.  Four days late, tsk, sorry about that everyone.

PolargraphSD progress

Posted on by
Reply

Progress is good!  Four or five days behind where I was hoping to be, but on balance, good.

Got my polarshield circuit boards through at the end of last week, and extremely relieved (and frankly shocked) that there are no horrible errors on it.  I did forget to order some parts that I need to test the XBee side of things, but those’ll come shortly.

Soldered up the first one without any problems – first time I’ve done anything significant with surface mount stuff.  Slow, but not the big challenge I feared it might be.  A few things that I’d do differently next time round came up but I’ll do a proper hardware review another day.

The real message is: It works!

Now, lets get this software into shape…

 

Spectrum Arts

Posted on by
2

There’s a graffiti supplies shop in town, Spectrum Arts, run by this dude called Mark.  I approached him about putting a machine in his window – he’s got some covetable glass, and is a nice guy.

It’s been there for a while, but I’ve just got the kit to fit a big fat chalk pen in it.  I used this gondola that Stuart Childs designed which did the trick nicely.  Thanks to Stuart for this – very timely, and I think I got some great first results out of it too.  The slow speed of the vector drawing means that gravity can keep the tip supplied with ink.

Am hoping to formulate a sequence of drawings to go in the window, but would love to see something graffiti based, am thinking of a GML-aware system that can accept tags from all over the internet and mark them out on the glass.  For now, it’s just manually controlled, but it communicates using an XBee and has an SD card too, so that’s nice.

 

Eclipse, Arduino 2560 and AVRDude – timeout

Posted on by
4

I’m in the process of restructuring the polargraph firmware, and the first thing I’m doing is moving most of the functions out to a library that can be used by all polargraph firmwares (uno, mega etc).  So that’s easy, you’d think.  I’m a fairly naive c++ programmer so don’t be surprised that I’m trying to get it working in eclipse so as to have a decent overview of things, function names and whathaveyou.  I find it useful when making cross-cutting changes.

So I came across Eclipse/Arduino tutorial page,  which is really good, and got it working on a Duemilanove I have – beautiful!  That said, I can quite see why the Arduino IDE is popular even though it lacks functions.  Eclipse is the archetypal jack of all trades and master of none, and requires a load of configuration to even get started on things.

But the MEGA? Not so much.  I got stuck so went to see how the Arduino IDE does it, and pulled out the AVRDude command it was using (turn verbose output on for the uploading in preferences):

c:\Dev\arduino-1.0\hardware\tools\avr\bin>avrdude -CC:\Dev\arduino-1.0\hardware/
tools/avr/etc/avrdude.conf -v -v -v -v -patmega2560 -cstk500v2 -P\\.\COM55 -b115
200 -D -Uflash:w:C:\Users\sandy\AppData\Local\Temp\build4894098567197191708.tmp\
Blink.cpp.hex:i

That’s what it emits, but when I put that same text in at the command line, I am faced with

avrdude: stk500v2_ReceiveMessage(): timeout

Which is the same problem I was bumping into in Eclipse.  Well.

The fix

Turns out using the arduino or stk500v2 programmer, the board doesn’t get reset before programming.  I could get around this just by pressing the reset button and then uploading that same instant, mostly, but it’s not very clever.  Then I came across a better solution at this page discussing the error in avrdude 5.10 (I’m using 5.11 that comes with the Arduino IDE so I guess it’s still an issue), and that solution is just to use the Wiring programmer instead of the Arduino programmer that works fine on the Duemilanove, or the stk500v2 programmer that the Arduino IDE uses.

That worked fine.

Homing

Posted on by
3

Came across this brilliantly pragmatic solution to the homing problem.

And his site, and a useful forum post.

This comes as a lesson to me in the value of just getting it done vs trying to engineer the “best” way forward.  I’ve worried and sketched and wondered about the best way to do automatic homing/calibration for ages, since this project started in fact.  Never  got around to doing it though, and it’s something that would take half an hour to test.

This is the opposite problem that manifested at the beginning of the project, and that problem was that I rushed in and just got stuff working without much thought to maintainability.  Which did the job, but left the code in a pretty desperate state, from which it is yet to fully recover.

There must be a middle ground.

Polargraphs in the gallery

Posted on by
Reply

I got wind of this set of polargraph drawings in a recent show in Belfast.  Richard Forrest is the fellow behind them.

 

I like this exploration of the intrinsic nature of the digital, or quantised, sampled or rasterised forms – the pixelation is a big part of my own work, and I see it here too.  Richard revels a little more in the flaws of the machine, with some great effects, the distorted face is ace, but I like the abstract portraits the best.

I’m not clear if this last show is still on, but Richard tells me he has an upcoming show in Cork next month that will hopefully be featuring a live machine in situ.  I love to see a live machine.

 

PCBs ahead full steam

Posted on by
7

I’m getting the hang of Eagle, and the design for the first Polarshield is close to being complete.  Matt Venn is charitably helping me by gently pointing out the stupid stuff I’m doing.  Luckily for me, the board is electrically very simple, being an aggregation of other designs rather than something truly original.

The polarshield is be the key piece of the PolargraphSD machine.  It’s a shield with:

  • 2x Stepstick / Pololu A4988 sockets.
  • ITDB02 2×20 pin LCD touchscreen header w/ SD slot.
  • XBee socket.
  • 2x Servo motor connections
  • 4x Endstop connections

Connected to a MEGA, then you can use everything all at once, on-board.  If you don’t have stepsticks yet, then you can stack your existing Adafruit motorshield on the top, and it’ll work.  This includes the touch-screen that will allow fully untethered drawing, and potentially some really nice things eventually.

Connected to an UNO, you can use your old Adafruit shield, or upgrade to use stepsticks.  Using stepsticks frees up the SPI pins on your UNO, so it could, in theory, read an SD card too.  (SD reading isn’t likely to become part of the UNO build for the foreseeable future, but it could be hacked to do it for someone who is determined.)  You definitely can’t use the LCD screen though with the UNO.

The XBee port is accessible to both UNO and MEGA, so if nothing else, this can be used as an XBee breakout that will cooperate with a motorshield.

There are connectors for endstop sensors that will eventually provide for automatic calibration, but there’s no hardware to go with that quite yet.  I’m currently thinking of little magnets attached to the cords and some reed switches or hall effect sensors positioned just above the sprockets.  This needs to be built and thoroughly tested, but I don’t actually think there’s much to it.  It was never planned to be part of the PolargraphSD design, so I’m not rushing into it with only a couple of weeks to go.

The board is largely based on the RAMPS board that folk use in their Repraps, so there’s a handful of other pins broken out by default.  I have tried to be good and group pins together, and the board does have a slight general purpose quality to it for that reason.  Hopefully it should be open to extension without too much hacking.  Pics and plans soon.