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

• source code
• precompiled binaries (bundle)

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