Geomerative Polygonizer

polygonizer_lengthHave just uploaded a new code bundle, featuring:

  • A bug fix to the polargraph_server_polarshield firmware. The command to set the pen lift height wasn’t working properly. (v1.3.1)
  • New feature in Polargraph Controller, the polygonizer can now be swapped between two styles, ADAPTATIVE (0) and UNIFORMLENGTH (1) by clicking CYCLE POLYGONIZER. The latter one has a parameter too, to actually set the length (POLYGONIZER LENGTH). The pic above is shows changing the length, so you get some pretty tasty effects from it. The polygonizer is part of Geomerative, which is a beautiful library.
  • Also in Polargraph Controller, the zoom works better now. (v2.4.0)

The polygonizer work was prompted by some excellent troubleshooting by Visualbyte and DaniK on two threads in the forum:

I’m not convinced it will point-blank solve your problems, but gives you an extra tool to experiment with.

This bundle (2016-03-29-10-23) contains the updates

(But here’s a link to the most recent release to help this post stay relevant in the future.)

 

Let us try again

Sigh…

Polargraph controller 2.3.0

  • Added: Density preview is now posterized by default, and is linked to the
    pen width setting. So should be able to use this to better visualise the link
    between pen width and grid size.
  • Fixed: Queue preview bug: http://www.polargraph.co.uk/forum/polargraphs-group2/code-software-forum2/updated-controller-thread504.0/#postid-2938
    thanks jbscribble.
  • Fixed: Slight improvement in pixel rendering speed.

Experiments in the controller, and now buildable in Arduino v1.6.6+

Made up a new code bundle, wrapping up a couple of recent changes.

  • Firmwares are now all buildable in Arduino IDE v1.6.6+.
  • The polargraph_server_polarshield firmware now uses the same kind of communications protocol as the _a1 variation. This is a little experimental, so let’s give it a shot.
  • The controller console is back! In a bit of a reduced form anyway. We’ll see if it’s worth anything. Ctrl-C.
  • There’s a posterisation option for the pixel density preview. You might use this to visualise how a compressed dynamic range will affect your drawing. You get a compressed dynamic range when you use very small grid size, or a big pen. It’s not linked to pen size yet, but that’s the obvious thing to do next.

https://github.com/euphy/polargraphcontroller/releases/tag/v2.2.2

Updated firmware for Polarshield v1.2.2

Given recent discoveries, I wonder if the spate of recent touchscreen problems (see http://www.polargraph.co.uk/2015/10/touchscreen-issues/) are to do with the weird startup problem that I described in that post, OR to do with the base stupidity I displayed by including a in-development version of the polargraph_server_polarshield firmware.

It actually had USE_LCD turned off in it.

So that’ll make sense.

I’ve fixed it, rebuilt it and repackaged it and apologise if this made you mad.

https://github.com/euphy/polargraphcontroller/releases/tag/2015-11-10-23-07

An interesting discovery is that the newest version of Arduino IDE (1.6.6 – it’s only a week or two old) CANNOT compile Polargraph firmware. So, thanks Arduino dudes, for breaking everything again – it looks like two can play that game.

So use Arduino IDE v1.6.5. Until I figure out what’s screwed.

 

Touchscreen issues

I’ve had a rash of problems with the touchscreens on bare Polarshields!

Over the last six months or so, I’ve noticed an issue where the touchscreen doesn’t work after booting. It looks ok, and updates fine, just no response to tapping.

I solve this by discharging the static from the device, while it is unplugged. I do it by either leaving it for a couple of minutes, unplugged, or by touching the metal USB socket housing, and rubbing an earthed piece of metal (it’s a wall-mounted shelving rack that I know happens to be screwed into the grounded metal studding in the wall). Handle it carefully, by the edges of the board while you’re plugging it back in.

I didn’t write anything about this until now, because until recently I was hoping this was a problem that only I was having! I think the touch IC must be being blocked during it’s boot process, or something like that.

I have handled hundreds of these, and the screens actually breaking down somehow is very rare. Having them rebel against their touch programming happens every day though, and I always fix it this way.

You can test your screen by using the UTFT and UTouch example sketches, but with these updated lines:

UTFT        myGLCD(TFT01_24_8, 38, 39, 40, 41);   
UTouch      myTouch(11, 12, 18, 19, 2);

Good luck!

Polarshield now compiles in Arduino v1.6

what the hell are you doing?

Well, I’m glad you asked.

The drawing above is by Ben Young. I love it.

Released new code bundle. Only code change is that I’ve mended this line about how the crc_check pre-computed value table is defined in polargraph_server_polarshield.ino. The only purpose for this is to allow it to compile in the newest versions of the Arduino IDE (1.6x). If you aren’t using that version, you don’t need to update anything.

Also updated the UTFT library to v2.81, for the same reason (Arduino IDE 1.6 compatibility).

https://github.com/euphy/polargraphcontroller/releases/latest

Machine Sketches show featuring PolargraphSD

Whitley Bay-based PhD student Carl Gregg has a show opening in a couple of days, featuring elements of his research made material:

Transition5_inviteGregg has used a couple of PolargraphSD machines in his work for the last couple of months, and wrote custom software to drive them over long periods of time, presenting them as performances. I really like this experimental approach, and the materialistic artefacts (like the missing, ghosted names in the drawing above) add depth and resonance to the work.

If you find yourself in Newcastle or Shields in the next couple of weeks you should go along to The Customs House and have a deek! Thanks to Gregg for letting me know about this.

G-Code importing, and a bit of calibration help. Controller v1.2

I am generally filled with forboding about adding features to the Polargraph Controller. I remember it as being a twisted and unstructured wild-west kind of program. However, whenever I actually get into coding in it again, I always regret my fear, because I get something really useful done, in a really short length of time. Last weekend was no different.

Download the result: Polargraph v1.2 code bundle, or read on… If you dare.

G-Code importing

Polargraph exemplar Kongorilla has made a number of not-so-subtle hints about the impediments he runs into in getting stuff prepared for drawing. There’s a workflow that is sometimes fairly tortuous, even if it is logically straightforward. The controller has only been able to import SVG files, so a run through inkscape has always been the last step for most people.

IMG_20150519_172018910

The load vector dialog now allows .gco and .g files too, so anything that emits g-code files is also now a contender. Now, it’s fairly simplistic, understands only G0 and G1 commands, and the Z-axis implementation is rudimentary, but it does mean that it can swallow the output of wonderful things like Dullbits’ beautiful Death-To-Sharpie sketch.

The Z axis automatically makes a choice about when the pen is up or down. The very first Z axis change is ignored, and the second one is used henceforth as the “down” (drawing) position. Any position other than that second position is considered a travel (non-drawing_ position. This is because dullbits has Z1.0 as it’s drawing position and Z0 for travel, whereas inkscape(‘s gcodetools) seems to have Z-0.125000 as it’s drawing position, and moved to Z5.0 for travel. So opposite directions.

Usually the first Z movement is to shift into travel mode, in order to safely get to the start point, and then the second Z movement is to drop the pen / tool. Scripts that have funky stuff going on in their Z movement might need a bit of manual editing to work.

It’s immediately become obvious that .gco is not a standard enough file extension, so I’ll change it to .gcode as well for the next release. For now, just rename the file.

Preview cord offset

A commonly reported problem is that a drawing is short and fat, or tall and thin, or has a curved top or bottom, or it’s sides diverge.

There is a page about this in the Polargraph wiki, but it’s quite hard to diagnose, and hard to explain in words. I added this extra feature to the queue preview that allows me to simulate common calibration errors.

The way I imagine this being used, is:

  1. Draw a shape. Oh no, it’s all wrong!
  2. View the command queue in the controller app. It looks right here!
  3. Adjust the preview cord offset until it the preview matches what happened on the paper.
  4. Look at the value of preview cord offset. If it is:
    1. Positive: Your home point is further from the sprockets than you’ve told the machine. This might mean your home point is actually further down than you’ve measured, or your machine is wider than you’ve measured.
    2. Negative: Your home point is closer to the sprockets than you’ve told it. The home point might be higher up the machine than you have measured, or your machine is actually narrower than you’ve measured.

Firmwares

Polargraph_server_a1 has been updated to v1.2, and while there is no new functionality for UNO owners, I have merged the old MEGA-only features in, and made them configurable at compile time. So you can use polargraph_server_a1 on a MEGA, and get the SD card reading, norwegian pixel, spiral pixel etc. I actually fully expect this to have broken a load of stuff, so please take care, and report bugs.

In other news, I’ve also been working on porting the Controller to Processing 2, but that’s not borne fruit quite yet.

Download the code: Polargraph v1.2 code bundle

Polargraph at the Edinburgh Science Festival 2015

Once again, the Polargraph Pro is featured as part of the Edinburgh Science Festival’s Making It touring exhibit, stationed until the 19th of April 2015 in Ocean Terminal Shopping Centre down the road in Leith.

P1050631_c_p

Tricking the machine with smartphones

I was a bit nervous about having the machine presented in such a uncontrolled environment (it was in the National Museum last year), but it’s been remarkably low-maintenance during it’s first week.

Some better than others

Some better than others

For this year’s outing, there were a very small number of changes to the firmware, mainly to add a feature to support a button and an indicator LED on the circuitboard that is controllable via commands, and used to signal to the Science Communicators that it needs it’s paper changed.

The changes to the Polarweb controller software are a little deeper, and there’s now a visualisation video stream published to a browser so you can see what the machine sees, and what processing it’s doing. Worked pretty well, but taxed the original laptop a bit much (it was an Atom), so the machine has been upgraded.

Other upgrades:

  • Minimum face size, so only people close-up get recognised and drawn
  • Path sorting to make for more efficient drawing (I hope to pull this work into the general Polargraph Controller some time soon)
  • Except for changing the paper, there is no manual intervention required during operation
  • Tracing controls are available in the interface to change posterisation levels, minimum path length, maximum path count and smoothing
  • The pen lift servo wire is routed more neatly, and uses spring-loaded retractable cable spools rather than the coiled cable that got stuck all the time
  • Drawing sequence can now fixed bottom-to-top so that pictures can be cut out and taken home as soon as they are drawn