Huge Portland Design Week project

It’s great to hear from polargraph people from around the world, and I was especially pleased when it turns out they’ve had zero problems, and have added their own features to the standard kit.

IMG_1725You can see this is a big machine (12ft wide, 8ft tall), drawing some promo stuff for for an agency in Portland. Notice the extra pulleys that have been added to reduce the drop of the counterweights – liking that.

This isn’t merely a really big machine though: The makers, Olivier and Evan spend 55 hours drawing the motorbike above and decided they could do better, and came up with a very sweet little script that will read your optimise the saved command queue and … make it efficient!

motorcycle_originalAbove is what the original pen path looks like. No surprise it took 55 hours really. The path planning has never been efficient, and just draws the file as it reads it, from top to bottom.

Running an exported command queue (previewed above) through this Polargraph Optimizer results in:

motorcycle_optimized

Which I think we can agree is much more sane. Evan reckons this is 3 1/2 times faster, and I don’t doubt it. Brilliant!

Thank you to Olivier, Evan and Squishymedia for supporting the project, and for giving back too. I’m going to try and pull those algorithms into the Polargraph controller at some point, but until then, I’d recommend that anyone doing really complex drawings should have a look at this.

Most of the things I end up talking with folks about about are troubleshooting and helping get things working, and I feel endlessly guilty about putting you through all that. It’s really gratifying and refreshing to hear success stories – and when someone cares enough to contribute, it means a lot. Even if it is embarrassing because it shows up all the bits I never got around to finishing…

Source: Polargraph Optimizer on github

 

Significant changes to UNO firmware – please help test!

Update 19th Sept 2014!

Thanks to billc and rincey12 on the forum for finding that penlift commands without height parameters didn’t work (https://github.com/euphy/polargraph_server_a1/issues/2). This was a leftover bug from the switch from Strings to char-arrays.

Code updated, and software bundle re-bundled.

My country is voting for independence, or not, right now. Quite exciting.

Update 18th Sept 2014!

There was a silly bug in the controller that broke vector drawing for most of you. Silly bug! Quickly fixed, sorry about that. (forum link)

Hello, after chatting on the forum, and working with jhndrx, I have made a fairly minor but important change to the UNO version of the Polargraph server firmware.

Short version:

The Adafruit Motorshield v2 is now usable in a sensible way, you don’t have to sacrifice features, or chop bits of the code out to use it. If you have a motorshield v2 (AFMS2), then please try the new polarshield_a1 code and see how it works out for you. I have tested that it compiles and runs, but I don’t currently have an UNO with a AFMS2 on it.

There is a very small change in the controller to support this minor change in the comms protocol (more on that later), so grab that too

(This is significant ONLY for folks who are using Adafruit Motorshield v2 on UNO. It all already worked for you other guys. The stylistic changes will eventually filter through to the polarshield branch too.)

What’s changed

It is more memory efficient

It uses and reuses one char array for the incoming command instead of a load of Strings scattered throughout the program. This means less SRAM (the volatile run-time memory) is needed and wasted.

No more checksums

Funny story. The checksum is a number added to the end of each polargraph command by the controller. It was added back in the day because commands were getting mangled during transmission, and I needed a way to make sure the command had finished properly. Totally did that, and made the system pretty robust, but in the process it gobbled up a lump of memory.

Well, looking back at this code, with the benefit of great troubleshooting and some pointers by jhndrx from offof the forum (thank you so much), there was one critical problem: The firmware looped through the incoming chars in the serial buffer, adding each character into it’s command buffer, and considered the command complete when when it got either 1) a termination character (10 / 13) OR 2) the buffer was empty. Well, this made the timing of the buffer pretty critical because if I took characters off the buffer faster than the controller could load them on, then the command was prematurely ended, and so I added a 1ms delay into the loop to make sure the queue never starved. I never really understood why it was necessary until now, and it means the reading is slower than it needs to be too.

Ah, turns out the controller NEVER actually sent a termination character, and the queue running dry was the ONLY way a command ever actually got terminated. I had assumed that a Serialport.writeln(…) did it. Maybe it does. But I was using a write(..) in the controller. Maximum Duh. So this has been a serious flaw for as long as there has been Polargraph, and I’m really happy to have found it. A bit embarrassed, but hey ho. The fix to the controller has been pushed to the controller repo.

What else

Learned a load of new stuff about the built in C functions for dealing with strings (lower-case “s”).

Feedback in the controller

The Polargraph machine has always given useful responses, if you know where to look for them.

This last update (v1.10 polarshield, v1.9 _a1, v1.9 of the controller) introduces a machine message log that sits alongside the command queue:

feedback-line-not-on-pageErrors show up in pink. Above is an example of what could otherwise be a pretty opaque piece of non-cooperation if you didn’t know to check the debug console.

The main reason for this is to debug pixel drawing though. The relationship between pixel size, pen size and density is ultimately simple, but it is easy to find yourself in a situation where you expect a wiggle and get a straight line.

So now, when you change pen size, the machine itself replies suggesting the smallest grid you can usefully work with with this pen:
feedback-set-penwidthAnd if you try a smaller grid than recommended (or the exact size – because of rounding that happens during display, this is a bit hit-and-miss), then it draws a simple empty line on your page, and normally you’d scratch your head and wonder where your wiggle went, but now the helpful message is exposed (highlighted at the top of the message log below):

feedback-bad-sized-grid

Trying one grid increment larger (9), and the complaint goes away because the pixel is now big enough to hold a wiggle:
feedback-good-sized-gridThere are three kinds of message, DEBUG, INFO and ERROR. Debug (black) should normally be hidden unless you have a verbose/debug switch turned on in your firmware. Or I’ve forgotten to turn it back off before doing the release.

Info (white) are the standard ‘might be useful’ messages. Error (pink) means specifically that something you wanted to happen didn’t happen.

I have not yet added the message prefixes to all the functions in the firmwares, but I will get around to them as required.

The examples above (vector location and pixel debugging) are now in polargraph_server_polarshield and also polargraph_server_a1 in a limited way. Polargraph_server_a1 is too pushed pushed for space to be able to sacrifice much for this, so it will never be as helpful as wasteful old polarshield can be.

Give it a shot by getting the newest code bundle.

3rd August 2014: Little update!

To clarify: This firmware IS suitable for ALL PolargraphSDs and Polarshields, new and old. The source code is configured to run on the most recent version, with the most recent version of the LCD screen.

If you’ve got an older model and you want to compile from source, pay attention to the screen type configuration settings in the main polargraph_server_polarshield.ino file. There are three possible options, the comments there should explain what’s what.

 

 

New pixel preview styles

Polargraph Controller v1.8 adds a more representative pixel density preview style to the controller app:

native-pixel-size-preview

Edit your properties.txt file and set controller.density.preview.style=5

native-pixel-density-preview

 

or set controller.density.preview.style=2

These new modes are designed to give a better idea of whether pixels are going to fall off the page. That’s really annoying when it happens.

I’ve also taken out a couple of buttons that didn’t really do anything sensible any more.

It’s available here on the github page.

Also included in that bundle is v1.9 of the polargraph_server_polarshield firmware. This is really only intended for the new v2 polarshield, but should do no harm if you want to play with it. Well, I hope it doesn’t do any harm anyway.

The only new feature is that the pen-lift height (at up or down points) can be adjusted through the touch UI now, rather than just through the controller app.

 

Finally introducing… PolargraphSD v2!

I wondered if I would ever get here to be honest. It was only the thought of dozens of angry Polargraphers chasing me into the town square with pitchforks that gave me fear hope.

PolargraphSD v2

I have stock! The first couple of machines will be being posted or collected during this week.

PolargraphSD v2

To the folks who have so far only paid a deposit: I’ll be sending you an email out when your machine is ready, and asking you to go and pay the balance. To those kind, generous trusting souls who already paid up front during the pre-order period: Thank you. Without that we wouldn’t have even got this far. I will drop you an email to confirm your delivery address (in case it has changed in the meantime), but unless I hear back in the next few days, your machine will be winging it’s way to you as soon as it’s built.

PolargraphSD v2

 

Seriously, thanks for being so patient. This machine is a much better product because of it, I have much more faith in it now than if I’d had to rush it out the door two months ago (eek, when I said I would). I really hope you’ll enjoy using it.

I’ll do a bit more of an “unboxing” guide in the future. There is a still a long waiting list for this machine, but now stock actually exists, it’ll be moving fast at least. It can be bought along at The Polargraph Shop.

 

Slow going

Slow going, but … going!

IMG_20140630_130446635

The hardware is working fine now, working with all kinds of SD cards, all servo motors and all power supplies, but I’m waiting for the full set of the new cases to be cut and sent.

The case is funny. Probably the ugliest thing I’ve ever made, but I quite like it.

IMG_20140630_130513459

Choice between clear acrylic and MDF – any thoughts? The clear looks shows fingerprints but looks pretty snazzy.

 

PolargraphSD progress

The PCB v2 testing is still ongoing, the end is closer and I’m expecting the final boards late next week. This extra round of board testing was always accounted for in the schedule, but what I didn’t account for is the last set of PCBs taking three weeks instead of one week to arrive. So although I feel this is disastrous, and the project is crashing down around me, actually it’s only literally two weeks behind, and I just need to get a grip.

I know that’s not much consolation to those of you who have been waiting since February, and I am really sorry about that, and that’s the bad news.

IMG_20140608_170052266

Why

I’ll do a proper introduction when it’s done, but in short, the Polarshield v2 has an integrated switch-mode step-down power supply so that the arduino can be run safely from a single higher-voltage power supply, without overworking the arduino’s on-board voltage regulator. That’s all gone fairly smoothly. This makes the system much more tolerant of working with cheap, basic arduino clones.

The second feature is fixing the circuit that converts the arduino’s 5v signals to the 3.3v signals that the screen and SD card expect. Previously this used resistor networks, but I’m using logic buffer chips now. This should make SD cards from different manufacturers much more reliable. BUT, it is new to me, and that’s why I’m determined to make a mess of it.

For those who are interested, the PCB files, and the gerbers that go to the PCB house are in the repo at https://github.com/euphy/polarshield_hardware.

Parts are slowly rolling in

A big lovely batch of shiney stepper motors arrived today. My electronics parts came last week (£650 of ICs and connectors – that is always so disappointing to receive). I’ve got a pile of touchscreens, and stepper motor drivers, and a big bag of drive sprockets. A big box of MEGA2560 R3s. Red ones.

The first version of the Polarshield v2 was tested and found wanting, so I’m expecting the samples of the final version at the beginning of next week. The first batch of PCBs took a week to arrive, this batch has taken three weeks so far. I am looking for a new supplier.

So unfortunately, that has eaten up all of my contingency, and then some, and so I’m already behind before I’ve even started. Great!

sn

Running Polargraph on RAMPS

There’s been a bit of discussion on the forum about the adaptations required to run the Polargraph firmware on RAMPS. The good news is it’s easy. I’ve just committed some changes to the polargraph_server_polarshield firmware that should make it easier to run on different hardware other than the Polarshield.

There is a little chunk of code like this in the main polargraph_server_polarshield.ino file:

#ifndef MOTHERBOARD
#define MOTHERBOARD POLARSHIELD
//#define MOTHERBOARD RAMPS14
#endif

Comment out the POLARSHIELD line and comment in the RAMPS14 line, and your machine will be rigged for RAMPS. See this Polargraph wiki article wot I wrote up.

 

Polargraph Server for Adafruit Motorshield v2

There’s been a bit of ongoing investigation about getting the polargraph firmware running with the new Adafruit Motorshield (v2). I have just got one of these shields recently, so have only just had a chance to work on it tonight.

https://github.com/euphy/polargraph_server_a1

The new Adafruit library is slightly bigger than the old one, and the polargraph_server_a1 firmware was super tight on space already, so I’ve split up the code into a set of features that can be easily enabled or disabled at compile time to save space:

  • PIXEL_DRAWING – This is pixel shading.
  • PENLIFT – Controlling a servo to lift the pen.
  • VECTOR_LINES – Drawing straight lines, aka vector plotting.

So to get this to fit on, you need to disable either PIXEL_DRAWING or VECTOR_LINES – can’t have both anymore, not with Motorshield v2.

For convenience, I’ve pre-compiled two binaries, one for Motorshield v1 (using AFMotor), and the other for Motorshield v2 (using Adafruit_MotorShield). The firmware for Motorshield v2 has pixel drawing disabled.

This is a bit of a pain, but I don’t see an acceptable alternative.

I haven’t tried this for actual drawing yet, because I haven’t got a machine made up that uses this system, but at least the motors move! Please let me know if there is any success – or otherwise.

Happy scribbling!

See also http://www.polargraph.co.uk/forum/polargraphs-group2/troubleshooting-forum5/motors-not-working-when-i-compile-but-hex-works-thread324/

This knowledge transferred to: https://github.com/euphy/polargraph/wiki/Polargraph-Server-for-Adafruit-Motorshield-v2