Hi Jaromir, yes there's a lot of stuff, and bits of it are only relevant to certain designs, can get confusing!

The polarshield is an add on for an arduino mega. It uses pololu motor drivers, and a screen and sd card.

The adafruit motorshield can be used on an uno or a mega.

The instructable is probably the most "complete" guide, so that is building a machine based on an arduino uno, with an adafruit motorshield. I use beaded cord in my machines because I use a hanging counterweight so that the motors do not take the full weight of the gondola at all times, and that needs the sprockets to have a good "grip" on the cord - because the contact area is small. The same reason that der kritzler (and harvey moon's machine) uses toothed belts.

If you use regular bobbins instead of sprockets on your motor, you can use thin thread and just wind it up onto the bobbin. Pretty much every other hanging-v plotter uses this system. It certainly makes for an easier and cheaper build, because there are no unusual parts. The drawback is you can never turn it off without the gondola coming crashing down, and setup is a bit more awkward - the polargraph software doesn't have a "fast wind in" or jog feature. You could have a look at dan royer (marginallyclever.com)'s system for that - that's the model he uses on his machines.

Servo pen lift is necessary (well, sensible) if you are doing any vector plotting, but the machine will work perfectly fine without it - it just won't lift the pen.

The polargraph controller doesn't need to have anything connected. But once you've loaded your image, you need to use "select area" to choose the area that you want to convert to pixels, that will give you your preview.

Sometimes the software _does_ go mad, yes, I think it's a feature of controlp5 (which is the gui library I'm using) that it allows you to drag and drop the buttons around. It happens to me too. I can usually use the button correctly by holding down ctrl, or shift, or alt while clicking, but it never really gets back to normal. I have never figured out what triggers it.

good luck!
sn

Oh, great, thank you much for your detailed answer. I'll dive into it once again and come back with questions or results. I have most of the needed parts in my junkbox, so I'm eager to build it 🙂

Thumbs up your support.

Oh, how stupid. Nevermind.
I found out how to start rendering two minutes after I submitted the post above 😕

Now the motors are humming, moving as expected, queue is getting shorter and purple dot on image moves through pixels. Fantastic!

Well, I got further.
I built first iteration of drawing board, mounted motors and gears and after a bit of playing with it, it started to draw pictures!
However, the process freezes very often. I'm running linux32 version. It works and executes commands and then it simply stops, indicating being busy with a command - see attachment. At this point, application is completely unresponsive - I can't click on anything.
When I close and reopen application, I can normally start from zero (with another wasted paper) - but it will freeze sooner or later. In fact, I didn't draw a single complete A4 sheet.

Any ides what's going wrong here?

It is pretty inefficient, so I'm not surprised, especially with that fine a grid. Java is a pig, and therefore Processing is too, unfortunately. That said, it isn't written very well either, so I am to blame too.

I haven't ever run it on linux before, so I don't have any experience of any foibles around it. I would suggest moving to the "queue" tab once you're running though, that is the least CPU intensive view, I know it makes everything go a little faster for me in that view. More noticeable now that comms is a bit quicker.

sn

The closest the dump comes to helping find a cause is mentioning Java2D, which (I understand) pretty much everything else runs under anyway. So it might be that the failure is at a higher level than the polargraph code itself, or it could just be being hidden. I suspect the Processing code for that is a couple of years old, and I get the impression that staying on the cutting edge has never been a priority for the project, so I wouldn't be surprised to find it was not great. And as I say, the polargraph code itself isn't very clever in a few places.

The CRC stuff is from java.util.zip.CRC32;

Checksum crc = new CRC32();
crc.update(lastCommand.getBytes(), 0, lastCommand.length());
lastCommand = lastCommand+":"+crc.getValue();

(in the polargraphcontroller.pde dispatchCommandQueue() method)

I guess you could write something shelly like you suggest, or adapt the export queue routine to append the checksums as part of the export

sn

Good luck!

Ha yes no that's reasonable - it's a monolithic thing, and I suspect that the sugar that Processing adds to java does not help at all.

The polargraph machine will return a message READY (for arduino uno) READY_100 for arduino mega with adafruit shield and READY_200 for mega with polarshield, when it is ready to accept the next command.

It will also issue a RESEND message if the checksum fails.

sn

Cool stuff!