Extra guide stuff

I updated the instructable to reflect the new controller, and also the wiki, though some of that just points at the instructable.  In other news, the new controller has now replaced the old in the trunk of the repository.  New updates will be committed to the trunk rather than polargraph_controller_zoom, so those of you who have checked out of the repo directly, then you can switch to this trunk, or just dump the whole folder and start again from the trunk.

Liberty TSP

I’ve done some TSP stuff, based on the Evil Mad Science TSP guide that was written up for preparing artwork for the eggbot. Don’t be put off, it was easy!

Oh, and for extra credit, I will reveal that this drawing was made with a polargraph running …. standalone!  Exciting isn’t it.  I just turned the computer off and walked away, and the machine just kept on scribbling.  It was a seminal moment.

I exported the queue to a .txt file on a microSD card linked to an arduino mega, and did it that way.  I’ve started a new branch for this in the embedded code repo.

v1.0.4 – Image loading fixes and serial port selector

Hello, another wee update to the controller.  Main thing is a serial port selector.  I have only tested this on my machine here, with a couple of ports, so am a bit anxious about how well it’ll work on others, particularly macs.

So now every bit of configuration can be done from inside the app rather than needing to edit the properties files.  That’s good news.

I fixed a couple of other little pesky things, and hopefully the issues with selecting areas that aren’t there, or fall off the edge of the machine.


There’s still an issue with loading images when there’s no page.  So before you load an image, make a page using the setup tab->page width, page height, page y pos and then centre page. Don’t think the size matters.

Then load your image, then move image to the middle of the page, _then_ do some resizing etc.

Image resizing is now done with a numberspinner rather than with the “fit to box” method.  I think this is a bit more sensible.

Binaries:  http://code.google.com/p/polargraph/downloads/list

And code: http://code.google.com/p/polargraph/source/browse/#svn%2Fcontroller%2Fbranches%2Fpolargraphcontroller_zoom


Version numbers, subversion, compiled binaries

Hello, I’ve had a think about my version numbers, and decided to revert to a 1.x system.  I never had a system before, so imagine the old version was in beta.  I will henceforth refer to the old version as “The Old Version”.

The new version is what is currently in development under the http://code.google.com/p/polargraph/source/browse/#svn%2Fcontroller%2Fbranches%2Fpolargraphcontroller_zoom branch.  I have a version number embedded in it, and I’ll update it when I remember to.  Once this version is stable enough, I’ll move it to the development trunk, replacing The Old Version.

A word about Subversion:

I don’t know how much folks know about software development and things like that, but most software that is developed is stored in a code repository along the way.  This is a centralised storage area that keeps track of the current code, but also all the previous versions that have ever been made.  So it keeps a full history.

What I do is check the code out of the repository, make my changes, and then commit the changes back into the repository.  Then if I realise that code is terrible, I can just roll back to a previous version.  There’s a few different kinds of Concurrent Version Systems (CVS), which is the generic term for this kind of code store.  I use Subversion (SVN) for no reason other than it’s what I’m used to, but GIT is another, and Mercurial is another.

Now, I’m saying this because this project is rapidly changing, and is no longer just a simple single-file program.  Compiling binaries, uploading and naming them is a pain since it has to be done manually for windows and mac every time there’s a change.  I hate doing it, so there’s a good chance I won’t always update the binaries every time I make a change.

If you want to keep absolutely up to date, then you should check the source out from the repository directly.  I use TortoiseSVN to do this.  It’s a shell extension for windows explorer that adds subversion tools to your folder.  Make an empty folder called polargraphcontroller_zoom, and right-click in it and choose “SVN Checkout”, and in the URL, enter the URL of the particular branch of the repository you want, in this case: https://polargraph.googlecode.com/svn/controller/branches/polargraphcontroller_zoom and hit OK.  It will download the complete repository branch into your folder, and what’s more, you can pull down the latest updates just by right-clicking on the folder and going to “SVN Update”.  This is a good way of keeping yourself in sync with the newest code.


Remember sometimes I break things instead of fix them.  This is just to keep you on your toes.  No, really, I’m just a spanner.  So if you happen to update and something’s broke, that’s unlucky.  Either let me know, or wait until I notice myself.  I would prefer the former.

Branches and trunks

The code repository has files and folders just like a regular file system, but it is a convention (amongst SVN/CVS anyway) that each project has a trunk, where the main development occurs, and branches, where experimental stuff happens.  Things are trialled on branches, and eventually, if they work ok, they get merged into the trunk.  While things are still in branches, they are considered experimental, or unreliable.

On our project here, the trunk contains The Old Version.  Eventually I will merge the changes in the zoom branch into the trunk.  It will be a sad day.

Why I’m being tardy about this

I feel there’s still some changes to be done in the new branch, so I’m reluctant to go and update all my instructions everywhere if I’m just going to have to do it again in a week.  I’ve still got a couple of features I want to add, but I was also aware that the limitations of The Old Version were making things very difficult for some people, so that’s why I pushed the new code out.  BUT, if I’m honest, it’s still got some issues that need looking at, in terms of usability and efficiency.  I’ll add some new instructions and things once things have settled down a bit – in the meantime hopefully it’s not too much of a difficult beast to grasp, and you’ll let me know if something doesn’t work.

Cheers folks!

Polargraph Controller v2.0, I mean 1.0.

To install:

It’s a bit more complicated than it used to be, sorry about that.

1. Check out this branch of the project: http://code.google.com/p/polargraph/source/browse/#svn%2Fcontroller%2Fbranches%2Fpolargraphcontroller_zoom

You need all of the files.

2. You need these libraries also installed:

Geomerative for SVG import and polygonalisation.

ControlP5 for the GUI.  I’ve tested with 0.5.4 which is the last stable release.

3. Alternatively, get some precompiled binaries.  These are a pain to make, and I can only test the windows versions myself, so there’s a good chance they won’t get updated very often, but they are here.


  • SVG import and vector graphics output.  In conjunction with the latest version of the server code, this is now a pleasant reality.  It’s a bit slow, and a little inflexible right now, but I anticipate it’ll get better.  The SVG file is placed at the top-left of the machine, so I’ve been making a file in inkscape that’s the same size as the machine (in px), and drawing my layouts on that.   It is aware of lines only (no fills), and ignores all styles in the SVG.
    I’ve discovered that there is something like an incompatibility between the way inkscape exports text outlines and the way geomerative imports them though, that results in some of the centres of the letters being offset a bit.  Not sure why, but if I break the object into its constituent paths, (Path->Break Apart) then it’s solved.  Go figure.
  • Zooming and panning on the machine.  Use the mouse wheel to zoom the machine, and a middle button drag to move the machine.  This should let it be usable for most screens.
  • Adaptable button panels. They’ll stack to fit on the screen.
  • New GUI library.  I’m using ControlP5 to handle the buttons and tabs, and there’s a few nice things in that like the number spinners too.  It’s pretty good.
  • More sensible controls.  How to select an area is more obvious.  Buttons are disabled when not usable, buttons can toggle on and off too.
  • Machine designer.  The setup tab lets you define machine sizes, page sizes, page positions and pen width test settings.  You should save your properties and restart if you change the mmPerRev and stepsPerRev settings. The only thing you need to edit manually now is the serial port.  I’ll fix that shortly.
  • Queue path preview.  This looks for C01 (move pen) and C17 (move pen in straight line) commands in the queue and draws them on the machine.
  • Row size is now grid size.
  • Pixel threshold.  Use the bright pixel and dark pixel number spinners to ignore pixels at either end of the spectrum.  Chroma keying is reinstated (mask with bright green).

Please have a go and see what you reckon.

Almost forgot – AccelStepper has been officially upgraded to work with Arduino 1.0.  Don’t use my branch.

Vector drawing almost there

Vector graphics importer was much easier than I anticipated.  I’ve used the geomerative library for dealing with the SVGs, but I don’t really know if I need it.  I tried it because Alex Weber recommended it in his writeup about Der Kritzler, and if it’s good enough for him, it’s good enough for me.

Initially this will work like the bitmap image imported used to – no cropping, scaling, moving etc, plain import.  I’ve done this by making a new document in inkscape, the same size in pixels as my machine is in mm.  As time goes on I’ll add moving and scaling if it becomes necessary.

I think what is more likely is that for vector graphics, I’d prefer a plugin for inkscape, like eggbot has.  I wonder if anyone reading this is into python and would care to point me in the right direction, or give it a crack themselves?

You’ll also notice that the letter centres are offset.  That’s a problem.  Not sure where, or why, but it’s my first go, come on.

Very pleased.  Will be in subversion once the centres are fixed and the loading is a bit more elegant.  Next stop, TSP!!!


New zoomier controller software preview

If you think I’ve been quiet for a while, it’s because I’ve been busy rewriting the controller.  Almost done.  In fact, I think I’ve got it back to the functionality that it had before.  Have a look: 

The reason for this all is primarily to decouple the machine size from the display size.  It was previously fixed at 1mm = 1 pixel, which is fine for people with small machines and big screens, but not really for anyone else.  So the major innovation here is a zoomable / draggable machine. Use the scroll wheel or pgup / pgdn to zoom, and middle button drag (or arrow keys) to move the machine around.  This changable machine, alongside the buttons panel that adjusts to the screen size means this will even squeeze onto little diddy screens like netbooks.

While I was getting my drag on, I also changed the select topleft/botright to be a plain drag to select.  Row size is now grid size, and there’s a number spinner thing to change it with the mouse.

I’ve used the ControlP5 GUI library to make it easier to write and script, and it’s really good, I’m impressed.  The downside to this is that you need to download that library and put it into your Processing libraries folder.  I might start making a binaries distribution of this, for this reason.

This code is currently in a branch in SVN called polargraphcontroller_zoom and you’ll notice it’s now a bunch of files, not just one.  You need them all.  There’s been a fair bit of extra code written to support these new features, and splitting them up this way makes it much easier to read and maintain, given the limitations of the Processing IDE.

I’m holding off merging the branch into the development trunk until I’ve got the SVG importing cracked.  Now I’ve got straight lines working nicely, SVG is worth doing.  Oh, that and support for multiple properties files with a save as/load feature.

If you have a chance, please have a shot with this new code, see what you think and let me know if there’s things that it get’s wrong – particularly if you’re using a huge machine, or a tiny screen.  Your regular polargraph properties file should work in it.

Happy scribbling!