Category Archives: machine

Faster vector drawing

Posted on by
2

Have just committed a few firmware updates that make vector drawing much faster.  It runs at your maximum speed now, so you might want to tone it down a little – big moves can get quite violent.

I have implemented some very rudimentary braking / acceleration to make it a bit smoother.  Beforehand, small moves especially were very jerky.

That update is firmware only, and for polargraph_server_a1 as well as polargraph_server_polarshield, get the source code or the precompiled hex:

PolargraphSD users will also find that their touchscreens go blank after half an hour. Don’t worry, it’s just a screensaver, and it’ll come back on when you touch it or send a command.

 

More updating firmware without using Arduino

Posted on by
6

I realised that the Arduino Uploader (featured here earlier) doesn’t work for Mega2560s.  Easy enough to fix, but I wanted something that’d work out the box so I’m recommending XLoader instead.  Works much the same way.  In fact, I’m just going to leave you with this screenshot and a couple of links.

Download XLoader from the XLoader site.

And download the precompiled firmware you want to update to (do right-click-> save target as…):

Start XLoader, load the hex file you downloaded into it, select your device (Mega(ATMEGA2560) for PolargraphSD machines, Duemilanove/Nano (ATMEGA328) for older Polargraph machines), select your COM port and press UPLOAD.
UPDATE- [minor] WARNING WILL ROBINSON.
Kongorilla points out to me that XLoader is a little unforthcoming in the event of a problem – If you load a file that isn’t a hex file, then it still goes through the charade of loading it, but then quietly announces at the end “0 bytes uploaded“.  So keep an eye on the status line to make sure it actually does what you think it’s doing.

Some interesting stuff that you probably aren’t interested in:

Note that I’m going to start uploading the compiled hex files to the SVN repository so I don’t have to faff on with updating zips and things.  The problem with this is that the hex file will not automatically be the compiled version of the code that is next to it in the repo.  I’ve still got to do that bit manually so it’ll probably be out-of-sync much of the time.

The way to check to see if the source code has been updated since the hex file has been compiled is to look at the revision numbers:

In this case, the source code (the .ino file) has been updated in the same revision as the compiled file (the .hex file).  This means that there hasn’t been any updates to the source code since the hex file was compiled.

If the source code has a higher revision number than the hex file, then the hex file is an older version and won’t reflect the changes in the source code.  You should compile it yourself (the regular way, through Arduino IDE).

Uploading firmware without Arduino

Posted on by
1

EDIT! – Use XLoader instead of this – it’s just as good and works on more boards.

Hello, a few people have had problems getting their programs uploaded to their arduinos.  I haven’t.  Not rubbing your faces in it, but if I can’t replicate it, I can’t fix it.  I think it might be something to do with bootloaders, but who knows.

EDIT! Looks like it is to do with bootloaders – Matt’s adventures confirm that.  I think it’s restricted to UNOs of a certain age.  The only UNO I ever owned I blew up literally hours after getting it, so can’t test.  And I don’t think this way of uploading will get around the issue – you might just have to reprogram your bootloader.

A second problem is that you need a couple of libraries installed, and not everybody want’s to harass themselves with that.  So I’ve made a precompiled hex file that you can load onto your arduino to save you that hassle.  You don’t even need to have arduino installed anymore.

What you need:

  1. The hex file is here.
  2. ARP-Uploader.  This is the thing that uploads the hex.  Get it from here.

And that’s it.  Unzip and startup ARP-Uploader, load up your hex file that you downloaded.

Choose the COM port that your arduino is on, and m328p as the microcontroller.

Change the baud rate from 19200 to 57600 where I’ve highlighted in the pic.

Press upload!

I’d be interested in knowing if this helps anybody who is having sketch size issues too.

OK, this hex file is good for Arduino UNO, Duemilanove, or any ATMEGA328-based arduinos.

Fistful of polargraphs

Posted on by
2

The Polargraph factory (my living room) is in full swing today.  I had a bit of downtime when my 3d printer decided to start acting the goat, but I stripped down the heated print bed and rebuilt it, and it’s going gangbusters again.  I’m printing in ABS.  It doesn’t look that nice, but it’ll be better at taking the heat that these more powerful stepper drivers can pump into the motors.

I’m hoping to have this first handful of PolargraphSD kits on their way to their owners during next week, and at that point I’ll take a little stock to figure out how much they really cost all-in.  The boards themselves are really cheap, but they use all SMT (surface mount) components and I know a lot of folk are wary of that – so will probably offer an assembled shield as part of an upgraded vitamins kit.  I’m getting the hang of it.  Don’t know what all the fuss was about!

Also, doing lots of drawings.  These micro-stepping step-stick drivers are wonderfully civilised, so quiet and gentle.  I miss the L293D’s singing a little though.

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.

 

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.

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.