Welcome Guest 

Show/Hide Header

Welcome Guest, posting in this forum requires registration.

Pages: [1]
Author Topic: Communication Protocols
Posts: 1
Post Communication Protocols
on: November 5, 2011, 17:32

I'm assuming there are some standard commands that the OOTB processing application is sending to the arduino for the drawing.

Are these documented anywhere?

I'm keen to start playing around with the software side, and I'm planning on trying a few things out in Max/msp, i was hoping there was maybe an API of sorts so I can just dump out commands from max and the arduino will do it's thang.

Really I'm hoping it's as simple as some sort of move(0,100) command that will move the pen to position 0x100 in it's current field. Fingers crossed 🙂

Also are there any gotchas that you know about from already having built the controller software that you would share with would be controller hackers.

Posts: 1449
Post Re: Communication Protocols
on: November 5, 2011, 20:03

Hey Jon, good to see you here.

Bad news:
It's all non-standard. It's a custom command set, and it's grown up quite organically, which means most of it works, but there's a few commands that don't do anything yet, or don't do anything any more. Or just do something unexpected.

Good news:
Everything is pretty simple. You can probably guess what the commands do as you see them being issued / generated in the command queue. And look at the command names in the code itself.

All units for positioning are measured in motor steps.
All coordinates are measured using the triangulation system: distance from the top corners.

There isn't any documentation beyond the code itself, and what I'm typing here. To that end:

Command structure:
C01 means move to [coordinates]
5408 is the distance from the left motor,
5528 is the distance from the right motor.

C14, END
C14 means raise the pen off the drawing surface

C05, 4620, 2460, 120, 127, END
C05 means shade a pixel using a square wave hatching pattern
4620, 2460 are the coordinates of the centre of the pixel
120 is the size of the pixel (in motor steps). Pixels always have sides of equal lengths.
127 is the brightness, from 0 (solid ink) to 255 (empty - single line through the centre).

Looking at the list of commands in the polargraphcontroller code, you'll see:

static final String CMD_CHANGELENGTH = "C01,";
static final String CMD_CHANGEPENWIDTH = "C02,";
static final String CMD_CHANGEMOTORSPEED = "C03,";
static final String CMD_CHANGEMOTORACCEL = "C04,";
static final String CMD_DRAWPIXEL = "C05,";
static final String CMD_DRAWSCRIBBLEPIXEL = "C06,";
static final String CMD_DRAWRECT = "C07,";
static final String CMD_CHANGEDRAWINGDIRECTION = "C08,";
static final String CMD_SETPOSITION = "C09,";
static final String CMD_TESTPATTERN = "C10,";
static final String CMD_TESTPENWIDTHSQUARE = "C11,";
static final String CMD_TESTPENWIDTHSCRIBBLE = "C12,";
static final String CMD_PENDOWN = "C13,";
static final String CMD_PENUP = "C14,";
static final String CMD_DRAWSAWPIXEL = "C15,";
static final String CMD_DRAWROUNDPIXEL = "C16,";
static final String CMD_GOTOCOORDS = "C17,";
static final String CMD_TXIMAGEBLOCK = "C18";
static final String CMD_STARTROVE = "C19";
static final String CMD_STOPROVE = "C20";
static final String CMD_SETROVEAREA = "C21";
static final String CMD_LOADMAGEFILE = "C23";
static final String CMD_CHANGEMACHINESIZE = "C24";
static final String CMD_CHANGEMACHINENAME = "C25";
static final String CMD_REQUESTMACHINESIZE = "C26";
static final String CMD_RESETMACHINE = "C27";

Not all of these are properly working, you'll need to have a look in the arduino code to see exactly what they do.

Anything to do with SD, image files, roving is not working.

I will do some more documentation at some point. But not now 🙂 More than happy to help with anything that doesn't seem to make sense though.

Gotchas. Not too many actually. Er, everything's a curve. Draw a straight line between two points you will get a curve on the page. As far as the machine's concerned, that _is_ a straight line. There's a pause between each command while the next one gets squeezed down the pipe. The controller will assume that the machine is busy until it received a READY notice. The machine sends out little SYNC,[a-coord],[b-coord],END messages every now and again, and also reports on how much memory it has left. That's debugging stuff really.

Sending a command:
1. Controller issues it.
2. Arduino confirms it by prepending "ACK," on the front of it and sends it back.
3. If it matches what just got sent, then the controller sends "EXEC".
(if it doesn't match, the last command gets resent)
4. Arduino received EXEC and executes on it's last received command.

Dispatching command: C01,5408,5528,END
incoming: ACK,C01,5408,5528,END
Dispatching confirmation command: EXEC

This back and forth is because I was getting mangled messages when I first started that meant dropped pixels every now and then. Not sure why, and never really got to the bottom of it. I'm sure there's a smarter way to deal with it with CRCs or whathaveyou, but I'm not smart enough for that. Besides this worked. The polargraph was always intended to be just enough tech to work.

You probably will have seen that there's a new update today that lets you load commands from a txt file. Might be useful

Posts: 17
Post Re: Communication Protocols
on: August 2, 2012, 23:11

should i be able to send commands by hand using the arduino serial console ?

I can't have to polargraph to react to commands ... :s

Posts: 17
Post Re: Communication Protocols
on: August 2, 2012, 23:48

ok i can 🙂

that's a good starting point to debug things

i'll continue my troubleshooting in another post 😀

Pages: [1]
Mingle Forum by cartpauj
Version: 1.0.34 ; Page loaded in: 0.013 seconds.