I'd love to do something like that - it kind of begs for it eh. Will have to come up with a continuous inking or marking solution too, but that can't be too difficult.

My ideal controller would have
50K+ program space
Two reasonably powerful stepper drivers
A third stepper driver or PWM pins for servo for pen lift, spray on/off
Integrated microSD card for buffering / standalone prints
Integrated Bee port (for wireless comms)
Spare interrupts and input pins for endstops (self calibration/limits)
Spare pins for a hardware interface (controls, or other sensors)

Anybody else got anything they'd like to see in a new hardware platform?
Anything you'd want to see in the software in fact?

Oh nothing mathsey please! All that stuff just makes me feel inadequate!

I thought I'd have massive problems with the noise, but in fact I didn't have any at all - I think because I stuck the brackets on with foam tape rather than screws or something harder, it just never materialised. Also of course, not using squealey microsteps either, hee hee.

sn

I think you'll come up against that limit with the speed with accelstepper to be honest. 2000 is super fast for me, because I only have 800 steps per rev, and my big sprockets a higher mmPerRev too, but you have much more steps, and less mmPerRev, so it'll be a fraction of my speed. I never thought top speed would be a problem to be honest, so didn't worry about that. You would need to do some tests to see how quick you can go before you start dropping steps. Maybe try some square wave pixels so you can see the differences.

I put acceleration up to 6000 for C17, effectively turns it off. The newest code does this automatically, but try it, see if it makes a difference (do it while you're drawing, it'll go to the front of the queue) if you don't already have that version.

Setspeed() get's used in conjunction with runSpeed(). At the moment I do

motor.targetPosition(12345);
while (motor.distanceToGo() != 0)
{
     motor.run();
}

Doing it without acceleration should be something like:

long newPosition= 12345;
motor.targetPosition(newPosition);
if ((motor.currentPosition - newPosition) < 0) // motor needs to go backwards
{
     // make negative speed if motor is to go backwards
     motor.setSpeed(0-newPosition);
}
while (motor.distanceToGo() != 0)
{
     // run speed doesn't implement acceleration
     motor.runSpeed();
}

but in practice I couldn't get that to work. Not sure why, and very possibly was just being a dimwit.

The reason that C17 will always be slower than C01 is because it's made up of lots of tiny moves with a pause for recalculation in between each move. It chops the line up into segments. There is a setting "maxSegmentLength" (or something) that controls how big each segment is. If you're in the controller and press "i" you'll see a little overlay that shows some useful debugging stuff, and one of the values at the bottom is this maxSegmentLength. It might be called something slightly different at the moment. But it can be changed with "<" and ">". A value of 1 will make the machine pause to recalculate after every single step, so it is the most accurate, but the slowest. As you increase the values then you will begin to get a less and less straight line on the page. Each segment will start and end on the axis of the line, but it will deviate from the line during each segment.

This value is also visible in the C17 command, it's the last number in the command. Because your steps are so tiny, you might find that you can increase this to quite a high value before you start getting zigzag lines, and actually, if there's no acceleration curves, you might find less zigzag anyway.

Ah, once the commands are loaded, changing the max seg length won't make any difference. The max seg length is fixed in the commands.

runsSpeedToPosition() (afaicr) is blocking so it can't run the two motors together in a loop. That linux CNC is good eh. I think kinematics is the way to do this "properly", this line-chopping system I use seems like a fairly inelegant way to do it. But of course, at a higher or a lower level, any lines that deviate from the true axes of the machine have to be made up a combination of smaller lines, and all curves are approximated with straight lines too, not a way around that. And any time there's extra calculation required it'll take longer. However, I think the way I'm using accelstepper for these moves probably isn't that clever.

I used the sequence of commands in this post http://www.polargraph.co.uk/2011/12/more-arduino-1-0/ to do my initial testing, just manually changing the last value in the commands and moving my bit of paper along after each one.

Brilliant, good to see you here Matt! Am I right in thinking this would use a pair of transmitters/receivers, one of them on the host PC with a USB connection, and the other wired to the SPI interface on the microprocessor?