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.

EDIT:

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

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.

Caveat

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!

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.

Changes:

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