I have just set up my vitamin kit and have done a few test drawings from .jpg images - these all work fine so I am happy that the connections and machine setup is good. But I have problems when I use the 'Move Direct' function or try and draw the outline box of a picture (vector method?) or draw a vector directly.

What happens is that the motors move to the correct position but very slowly. And they move in a stop start way, fast at first then slowing down with several steps like this over any given line. It seems like the machine is chunking up the line its drawing and decelerating (very slowly) until it reaches one of these intermediate points and repeat until it reaches is final position.

I have tried reloading the latest firmware and fiddling with the acceleration and max speed settings but with no success. I am pretty stumped on this one, has anyone else seen this before? It seems like there are a few people that have had problems with the vector drawing but none that I can see that are the same and resolved..

Hi, I tend to run as low as possible, for no reason other than managing the amount of work the voltage regulator on the arduino has to do. I think it reduces the heat that the bits and pieces generate too.

Like you, I've never got to the bottom of this mysterious slowdown issue, if it's the same as other similar reports. I've had it sporadically myself, but not been in a position to isolate and test it, and it's "fixed itself" after lots of reloads, reboots etc. I assume the folk who have reported it have had the same experience.

I'm hoping to have a closer look at the code this week, and I have a new release coming up shortly that rolls up the live webcam drawing in the controller (that I was using at the maker faire last weekend), and the configurable pen lift height that has been requested. I need to test that code on some other machines before it's good.

I don't think any of the current changes will fix the issues, because they are nowhere near that stuff, but if I (or anyone else) comes across a solution, I'll try to get it out to everyone.

One thing to note is that unless you tell me (us) what hardware and firmware combination you're using, I (we) can't really help. There's a few platforms out there, and while in principle, the parts of the code that do this basic stuff are shared between all platforms, sensible debugging is only really made possible by replicating the faulty situation in as many ways as possible.

sn

There's been one obvious thing that I've observed plenty of times, but never tracked down, and that an odd occasion where a motor appears to decelerate from a standstill - so it is not moving, then suddenly zips to top speed and starts decelerating down. Makes a mildly cool peeeowwwm noise, and I can't honestly see that there's a symptom on-the-page (which is why I've never pursued it), but I think it indicates there's the capacity for something a bit peculiar going on with accelerations.

sn

I added a bit of code so I could look at the speed of the motors during a direct move

void changeLength(float tA, float tB)
{
// Serial.println("changeLenth-float");
  lastOperationTime = millis();

  transform(tA,tB);
  motorA.moveTo(tA);
  motorB.moveTo(tB);
  
  long int j = 0;
  float oldspeedA;
  while (motorA.distanceToGo() != 0 || motorB.distanceToGo() != 0)
  {
    impl_runBackgroundProcesses();
    if (currentlyRunning)
    {
      if (usingAcceleration)
      {
        motorA.run();
        motorB.run();
        Serial.print("A");
        Serial.println(motorA.distanceToGo());
        Serial.print("B");
        Serial.println(motorB.distanceToGo());
      }
      else
      {
        motorA.runSpeedToPosition();
        
        motorB.runSpeedToPosition();
        if (motorA.speed() != oldspeedA) {
          j++;
        Serial.print(j);
        Serial.print(",A,");
        Serial.println(motorA.speed());
        Serial.print(j);
        Serial.print(",B,");
        Serial.println(motorB.speed());
         }
         oldspeedA = motorA.speed();
        }
    }
  }
  
  reportPosition();
}

I get some really strange numbers here.
I am going to try and attach an image of the plots..

Hey cool graphs. I was hacking around and tidying up for a new version last night, but then discovered a peculiar behaviour on "move direct" that looks very much like what you describe. Very slow motion, and around three "batches" of move, each one longer than the last.

Good news and bad news I suppose. Good news is its replicated, so that's going to lead to a fix. Bad news is that all my most recent fixes obviously didn't have anything to do with it, bah.

Are you compiling from source, or using the hex files?

sn

Just loaded the hex and its working now!

Hello, right, I think I've got to the bottom of this. The newer versions of accelstepper (I suspect since 1.22 or 1.23) precompute a speed when setting a target with .moveTo(...).

So what the vector line algorithm did was split the line into lots of smaller lines, and for each of those, figure out the speed that the motors should be moving in that line. For each small line, acceleration is disabled and both motors move at a constant speed. So I was working out the speed, and setting the speed of the motors, then issuing the moveTo(..) command to set the actual target, and then running runSpeedToPosition() to get it to move.

That doesn't work any more, because issuing the moveTo() changes my pre-set speed to the speed that would be required for the first step, moving from a standstill (so it's usually something really low - hence the very very slow movement).

So my fix for it is a bit of number gymnastics which is a little bit childish, but gets the job done. I'm sure there's a smarter way to do it.

I have not properly tested it out in all three platforms, but the polarshield version is currently up to date in the github repo: https://github.com/euphy/polargraph_server_polarshield, I updated the util.ino and the exec.ino files. Those files will eventually be the same in all platforms (mega, uno, polarshield) anyway.

I haven't yet tested it with old versions of accelstepper, but this appears to work with 1.31.

huzzah!
sn

Nuts, that's not it at all. Well, partly is fixed, but has created another problem along the way... Keep watching.