Hi there !

First of all thank's for your great project and thank's for sharing your code !

To make a long story short, It has been a while since I wanted to build an hecktor machine, but I've been discouraged by the fact the source code wasn't available (afaik)

So when I discovered your polargraph project It gave me the push to get back on rails.

So first thing first, here is my setup

- one mac with polargraph controller running
- two bipolar steppers
- two timing belts
- one 5kg servo
- two L298N Dual H Bridge
- one arduino uno
- and one spray can !

For this project I'm only interested in vector graphics drawing and as you can guess speed and accuracy are of great importance. (I like drips but I like them more when they are desired)

I started to draw a straight line "abecedaire" which rendered not exactly as expected but with a certain "hand style" though.

Then I figured a fact (that might have been covered in several other topics) which is to draw a straight line, the two motors start together, run the same speed but don't end together. This seems quite normal since they don't have the same ground to cover. If I'm right I think you avoided this problem by subcutting a line into small segments making this discordance insignificant.

You might have considered this other option, which is to set two different speeds for each motors allowing them to start and arrive at the same time, no matter the distance they have to run.

I rewrote the exec_drawBetweenPoint implementing that feature with satisfying results

void exec_drawBetweenPoints2(float p1a, float p1b, float p2a, float p2b, int maxSegmentLength)
{
  // ok, we're going to plot some dots between p1 and p2.  Using maths. I know! Brave new world etc.
  
  // First, convert these values to cartesian coordinates
  // We're going to figure out how many segments the line
  // needs chopping into.
  float c1x = getCartesianXFP(p1a, p1b);
  float c1y = getCartesianYFP(c1x, p1a);
  
  float c2x = getCartesianXFP(p2a, p2b);
  float c2y = getCartesianYFP(c2x, p2a);
  
  // test to see if it's on the page
  // AND ALSO TO see if the current position is on the page.
  // Remember, the native system can easily specify points that can't exist,
  // particularly up at the top.
  if (c2x > 20 
    && c2x<pageWidth-20 
    && c2y > 20 
    && c2y <pageHeight-20
    && c1x > 20 
    && c1x<pageWidth-20 
    && c1y > 20 
    && c1y <pageHeight-20 
    )
    {
    reportingPosition = false;
    float deltaA = p2a - p1a;    
    float deltaB = p2b - p1b;
    
    float speedA;
    float speedB;
    
    if (abs(deltaA) > abs(deltaB))
    {
      speedA = currentMaxSpeed;
      speedB = currentMaxSpeed*deltaB/deltaA;
    }
    else if(abs(deltaA) < abs(deltaB))
    {
      speedB = currentMaxSpeed;
      speedA = currentMaxSpeed*deltaA/deltaB;
      
    }else{
      speedA = speedB = currentMaxSpeed;
    }
  
    usingAcceleration = false;
    
    motorA.setSpeed(speedA);
    motorB.setSpeed(speedB);
    
    changeLength(p2a, p2b);
      
    // reset back to "normal" operation
    reportingPosition = true;
    usingAcceleration = true;
    reportPosition();
  }
  else
  {
    Serial.println("Line is not on the page. Skipping it.");
  }
//  outputAvailableMemory();
}

Well, apart from quite brutals accelerations (no acceleration means "infinite" acceleration right ?) my "abecedaire" looked better.

I think I'll compensate the accelerations with looping path (the hecktor solution) or with some sort of mechanical cushion system.

Anyway, I still have a problem, and that time I'm quite stuck with it at the moment.

When I started to draw curves I had a bigger acceleration issue AND a speed issue related to the fact that sending a long queue of C17 commands made the motors stop and go quite repetitively while I ideally would like them to run the full path smoothly.

I had good results with circle drawing (curves_drawCircle) since one command make the drawing of a complete path (even if it is still subcut into small segments of course). So I assumed I had to make a new command sending all the points of a path (already sampled into small segments) at once and then boom, THE big problem : memory

Here is an example of the command I'm sending

C61,8485.6316-8454.6336-8348.6397-8288.6436-,END

And AFAIK this is the longest command my arduino UNO can swallow with its goldfish SRAM.

So maybe my approach is not the good one but I can't figure a way of having the motors not stopping on every point (or at least not more than a few ms) with that setup. The motors could stop at the end of a path (when the spay can tip is released) and the biggest path won't have a thousand points but a maximum of four points is quite limitating.

After all what I'm trying to achieve is to :
- draw a svg with inkscape (that's ok)
- sample it into small segments (polargraph controller does it quite well even tough a small inkscape extension could do it too)
- send that to the machine and have a "smooth" movement while drawing a path (this is where I'm stuck)

If you or anyone have any idea I'd love to hear them !

Thanks

Alain