Multi-directional pixel drawing and configurable sprocket sizes

I have a couple of minor updates to the controller and the embedded code, but there are a couple of things to be aware of if you’re updating.

Thing 1:
This might be a gotcha if you’re updating your embedded code.  The value for mmPerRev (essentially the amount of string that gets extended in one revolution of the sprocket) has previously been hard-coded. That is, the arduinos you all got from me already had a program installed that said the mmPerRev was 84, and it couldn’t be changed without reloading the firmware.
That value can now be modified from the controller, using the properties file key
machine.motors.mmPerRev=84.0
and restarting and clicking “upload machine spec” on F3-Details page.
The rub is that for those of you who ordered the machine from me, this value should be explicitly set to 84.0 if it isn’t already.  The default value is actually 95mm because that’s the mmPerRev on my main home one here.  The difference is because although the sprockets are the exact same size everywhere, the cord I supplied with your machines had a slightly different bead pitch, so what we’re really measuring is the length of 8 beads-worth of cord.  It might even change over time if it’s hanging up for ages, who knows.
The other thing:
The old embedded code had this concept of row direction.  So I’d use a command to set rows to go from left-to-right, then all the pixels I drew would be drawn in that direction, regardless of whether that fit the sequence of the pixels.  When I got to the end of the row, I’d send a command to say “now switch to right-to-left mode”, and start sending the pixels for the opposite direction.  What sometimes happened is that the first row was drawn backwards because its initial direction setting had been missed.  Particularly if you’re stopping and starting the drawing, or do some practice drawings first.
So I’ve got rid of this global row direction setting, and the embedded code is now “smart”, ha ha.  This means it will try to figure out the best direction to draw a pixel in, based on where the pen currently is.  So if the pen is up in the top right corner, and you ask it to draw  a pixel down at the bottom right of the page, it’ll start drawing on the north-east (top-left) edge of the pixel, and draw in a south-westerly direction.
I think this seems to work, but I haven’t exhaustively tested it.  I think if there are differences, then it will probably be on the ends of rows, when the direction needs to change.
Please let me know if it’s going mental and it needs more work.
Get the updated code at

Polargraph build tutorial entered into Instructables contest

Once again I’m chancing my arm with Instructables laser cutter competition.  I’ve written up a guide to building a polargraph machine, that actually is probably a bit better in many ways that the various pieces of instructions I have left scattered in my wake during this project so far.

Please take a look, and if you like it, consider voting for me in the contest.  I don’t know if I’ve got half a chance of winning, but just think what extra shenanigans I’d get up to with a laser cutter!  I mean, after I got thrown out the flat for making bad smells. I MEANT BURNING SMELLS.

I’m also on the front page! (sell-out or proud, I can’t tell the difference any more.)

Instructables Polargraph Drawing Machine

Thanks everyone!

 

 

 

Resize images!

Just committed a couple of changes to the controller, the most significant is that you can now select an area (using the box1/box2) and then click “Resize image” and your loaded bitmap will stretch or squash to fit horizontally into your selection box. Don’t forget to save to properties after you’ve done it though, if you want to keep it.

Other little changes:

  • Names of buttons.  Box1 / Box2 is now Select TopLeft / Select BotRight.
  • New outlines.  Not actually new, but haven’t had their own button for a while.  Bottom section of the buttons panel on F1.  I put these back in because I’ve been battling with a new pixel direction choosing algorithm on the embedded side and they were going all over the place. Draw grid of box draws an empty grid over the area you’ve selected. Draw outline box isn’t new, but it’s been moved.  It just draws to all four points of the selection box.  You can use this to test if you have good geometry on your machine.  Draw outline rows draws a line around each row you have in your selection area.  Draw outline pixels draws a line around each pixel you have in your drawing area.
  • Fixed problem where it would crash if the top-left corner of the image was to the right, or further down of the selection box top-left.
As usual, this code is available from the Polargraph code repository.

Test textures

I was curious to see how these generated images

Would come out of a polargraph machine. It’s just a section from the middle, on A3 paper. I rotated it so that the main horizontal flow was aligned with the symmetrical axis of the drawing machine’s pattern.

Row size is 45 steps, and tip size 0.2mm, using a 0.1mm UNIpin pen. Bears little resemblence to the original, but not unpleasant. Rather undisciplined pattern though, could benefit from a bit more weight on the gondola.

Controller updates

I’ve just committed a couple of little updates to the controller software that will make things easier for you all.

  1. IMAGE LOADER!!  Finally, don’t know why I didn’t do it ages ago.  It was easy.
  2. Import / export command queue.  This is so that you can edit your command queue by hand if you want do do something funky.  Combine portions of a drawing, that kind of thing
  3. Picture frame is now useful.  Those four coloured circles you see are the picture frame.  I use them as a guide to where to click when I want to be able to select the same area lots of time.  Well, now there’s two buttons, one that sets the picture frame to be the same as the current selected box (save selection), and the other that just draws a selection box, based on the picture frame (select frame).  Useful.
  4. The information overlay can be toggled on or off with the “I” key.
  5. The pixels are now automatically recalculated after moving the image.  Don’t have to re-select the box to prompt it.
  6. mmPerRev and stepsPerRev are now stored in the properties file rather than hardcoded.  They are NOT uploaded to the machine though.
Download it at the repository.

Power supplies, spare parts, and double-sided sticky tape

Two double-sided sticky tapes malfunctions in one week!  These motors are a bit heavy, so they come down with a bang if they fall off, and break their plywood mounts.

I have (one or two) spares, but that’s literally it for a couple of weeks, so please do be careful and use something very adhesive to mount your motor brackets.

I think it’s important to use some adhesive with a bit of “give”, because the bracket face, and usually your surface are not completely flat and it’s subject to a bit of vibration in use.

I usually use this double-sided sticky foam tape which is very tenacious indeed, but I have also used some temporary “no more nails” tape strips with great success.

Just be careful, I have a few spares, but that’s it!

Power supplies

I just want to remind everyone who hasn’t already got past this bit that it’s very important that you fit the tip for the power supply the right way round.  It should be centre-positive.  Because the motorshield power supply can, if required, supply the power for the arduino too, there isn’t any reverse voltage protection on the power input, so if it goes in the wrong way round, it might damage either the shield, the arduino, or both.

good luck!

 

Updated software guide

Now many of you have received your machines, and are bolding setting about destroying decorating your walls with them, I’ve made a couple of updates to the software guide, namely mentioning the extremely key point of how to get your machine size settings from the UI into the arduino itself. I’m positive I have written this somewhere already, but I can’t find it, so maybe I just imagined it:

Save machine size into hardware (IMPORTANT!)

The hardware (arduino) needs to know the size of the machine too, so once you’ve got your proper machine size into your properties file, and your processing controller running, go to F3-Details page and click both change machine buttons. This puts the machine values into EEPROM on the board, and it’ll be saved until next time.

from Polargraph Software Guide v2

I’ve chatted with a fair few of you on email and things, but I’d also like to remind anybody that there’s a forum on this site too, and it might be useful for other polargraphers to share the questions there.  That could be a good resource of information, particularly for new users.

Machine size is too big for your screen issue

Those bold fellows amongst us striving for very large machines (or those with very small screens) will have noticed that the UI doesn’t play nice with them.  The problem is that the machine size and image size is coupled directly to the pixel size on-screen.  So a 1800mm wide machine will be 1800 pixels wide onscreen, and that doesn’t leave a lot of room for much else.

I am working to decouple these things, and that should also make it a lot easier to zoom, and to resize the image to fit the page, that kind of thing.

Thanks for your feedback everyone, this is fun!