Norwegian pixel preview

Didn’t get around to making up a numbered release this weekend, entirely restructured the server code instead to separate the basic polargraph stuff from the advanced polargraphSD stuff.  This will make it much easier to keep multiple versions in sync, but needs a bit more testing to make sure I haven’t broken something in the mean time.

However, also added a couple of new features, one of which is the much-asked for norwegian pixel style (above).  This is named after the Norwegian Creations drawbot that I featured on this blog before, and looks quite like it, but is remarkable because it draws directly from a bitmap file on the SD card itself, rather than interpreting commands from the controller.

10 Bullets, working to code

I forgot to mention, Viet Anh Cao used a Polargraph machine to great effect in his graphic and media design graduation show.

I really like the crisp and clean quality of this work – looks very nice, and especially love the joining lines done without the pen lift.  Those kinds of character marks are my favourite parts about this machine, how it shows the process and sequence.

Link to the Creative Review page about the show.

Vector sprites – aka WRITING

A major new feature sprang up over the weekend, and it’s actually one of the things that was immediately desirable when this project started over a year ago. 

PolargraphSD can now draw vector sprites.  These are little fragments of vector art saved into their own files, they are executed by a new command (C39) that specifies where on the machine they should be drawn and at what size.  It works as a kind of macro.  The first application is writing:

In this case I’ve made up 26 files, each with a letter form in it.  I specify the active area using the controller and a starting point where to draw the first letter, then feed in a load of text.  Lines wrap until the active area is full.

This uses the rove area as the demarcation for it’s operations.  The rove area is not entirely a new thing, but it’s never really worked before.  It’s really nothing more than a safe, cartesian area to behave in and it’s specified as simply as dragging a box in the controller and sending it to the machine. It’s going to be important for future standalone functions where the machine will be given free rein to draw or scribble or otherwise fill in this rove area.  It’s called a rove area because the machine is free to rove anywhere in it.

I’ve committed the code I’ve done already, but there’s still a little bit of work to do before putting out a full new compiled version, so that’ll happen later in the week.

Faster vector drawing

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

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).

Quick controller update for those whose problems are hanging

I’ve just uploaded a new version of the controller.  It has one new feature, and that’s a built-in java console.  If you press “C” in the controller, the console will pop up, and start echoing out all the internal messages and things that are useful while debugging.

This is really aimed at Kongorilla and Gensior who have been bumping into a problem that makes their machine lock up.  It will also be useful with general debugging, reporting faults etc.  The firmware is actually fairly verbose, so often gives some insight into what it thinks you’ve asked it to do – should you care to look.  Normally this is visible in the console if you run the app from the Processing IDE, but if you run from the binaries, all this juicy goodness gets lost.

If you aren’t having any issues, then it’s not important that you update.  The only other fix in this is to remove escape as a key that will close the app.  That’s just a little too close for comfort.

EDIT- I have just incorporated a minor firmware fix into the zip that fixes this hanging problem in some cases.  I will continue to work on getting a proper fix.  Thanks to Kongorilla and Gensior for working with me on testing this. (details).

Mac downloadWindows download

or update direct from the SVN.