Where can I change this density? The purple dot seems to be at the right position all the time, with vectors, the lines disappear eventhough the purple dot does not follow them.

The density is the density of the pixel you're currently drawing. So if it's a dark pixel, then it'll be high, and will use lots of lines to try and fill the pixel in. If it's a light pixel, then it'll only use a few lines to fill it in.

If you have specified a very very thin pen, then it will need more lines to fill it in to the same darkness as if you'd specified a thick pen. This is why telling it you have a very thick pen gets it to put down less ink for each pixel.

Tell me, have you uploaded your machine spec to the board? (Setup tab -> "upload spec")? This tells it what size machine you have, how many steps per rev and how many mm extension per rev your motors have.

I think vectors are being sent, but ignored because the machine thinks they are outside of it's area.

sn

thumbs up!

Hello, it is normal for the motor's behaviour to change when the pot is touched - that's why lots of the drivers come with a special ceramic schraubendreher for adjusting them.

What bit of Polargraph code are you using?

I can't really see anything wrong with your circuit diagram. It is not a polargraph circuit (no enable pin connected), but that should not prevent it from working - only from turning off. I don't think that the vibrating is normal, but it could simply indicate a floating "step" pin, that isn't connected, or that hasn't been initialised and is waving about, randomly triggering steps.

You will probably have modified the source code (which version? from where?) to have something like:

const byte motoraStepPin = 30;
const byte motoraDirPin = 32;

const byte motorbStepPin = 36;
const byte motorbDirPin = 38;

If you think there is something wrong in the physical circuit, I'm afraid a diagram will not help. Only a good, clear photograph will.

(Secondly, you have resurrected a 24 month old thread - it would be better to create a new thread - I'll leave it up to you to do that in future - as I'm not clear if you have used lanthan's firmware or not.)

sn

You could have a look at http://www.polargraph.co.uk/2014/05/running-polargraph-on-ramps/ and http://www.polargraph.co.uk/forum/polargraphs-group2/building-hardware-forum3/arduino-mega-2560r3-with-ramps-1-4-thread286.0/ to see the more recent details about running on other hardware.

I've recently made a few big changes to polargraph_server_polarshield, so one thing you'd like to do to the most recent version is comment out

#define USE_LCD

in polargraph_server_polarshield.ino

sandy noble

https://github.com/euphy/polargraph_server_a1 is the current code that is supported for serial stepper drivers. I've only just made a stack of structural changes to it though, so I expect there to be a few problems. It'd be great if you could give it a try.

Also, bundled with the libraries: https://github.com/euphy/polargraphcontroller/releases/latest

sn

IT depends on the driver Sembot, and how you want to be able to control it. I prefer to use the enable pins when I can, because it allows me to, well... disable or enable the driver completely.

On a stepstick, the driver is enabled by pulling this pin low. So if you want them always to be on, yes, just pull them to ground. Your datasheet will tell you whether it is active high, or active low. Actually, all the ones I've seen have been active low, but you'd better check.

sn