Forum

Welcome Guest 

Show/Hide Header

Welcome Guest, posting in this forum requires registration.





Pages: [1]
Author Topic: Problem with "Move Direct" and vectors
Chojins
Newbie
Posts: 19
Permalink
Chojins
Post Problem with "Move Direct" and vectors
on: April 15, 2013, 03:32
Quote

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..

Chojins
Newbie
Posts: 19
Permalink
Chojins
Post Re: Problem with "Move Direct" and vectors
on: April 15, 2013, 08:46
Quote

I am running the machine on 12V rather than the recommended 7.5V.. But like I said there is no problem with doing the pen test pattern or render type drawings.

Aren't steppers supposed to be driven at higher than spec voltage anyway? What is the advantage of using the lower 7.5V?

sandy
Administrator
Posts: 1229
Permalink
sandy
Post Re: Problem with "Move Direct" and vectors
on: April 15, 2013, 11:37
Quote

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

Chojins
Newbie
Posts: 19
Permalink
Chojins
Post Re: Problem with "Move Direct" and vectors
on: April 15, 2013, 12:19
Quote

Yea its weird. If I do a direct move (real slow and strange ramping accelerations) and then do a move pen to point (which normally works fine) I get the weird motion in the pen to point move too. but it will snap out of it partially on the way ie one motor will speed up and the other will sometimes ramp up speed really slowly until finally it gets to position. Then the next pen to point move will be as normal.. Have never seen a normal vector move on my machine no matter what I try

I am using the 1.25 zip release and have also tried the 1.24 with the same results. Polarshield with Mega 2560 with motor drivers etc as per the vitamin kit.

sandy
Administrator
Posts: 1229
Permalink
sandy
Post Re: Problem with "Move Direct" and vectors
on: April 15, 2013, 15:26
Quote

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

sandy
Administrator
Posts: 1229
Permalink
sandy
Post Re: Problem with "Move Direct" and vectors
on: April 16, 2013, 00:12
Quote

Tonights excavations have uncovered one significant issue that I am positive has caused it's fair share of head scratching, but I don't think it'll have made any difference this one. I seem to have arsed up the github clone for my polarshield firmware, but I'll push a new firmware update out when I've figured out what I've done there.

There is also a few new accelstepper versions out since the last firmware, so that might help too.

cheers
sn

Chojins
Newbie
Posts: 19
Permalink
Chojins
Post Re: Problem with "Move Direct" and vectors
on: April 17, 2013, 11:20
Quote

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..
Image

Chojins
Newbie
Posts: 19
Permalink
Chojins
Post Re: Problem with "Move Direct" and vectors
on: April 17, 2013, 11:56
Quote

It looks to me like the speed() is getting updated correctly at the high points (curved profile makes sense) but in between it gets set low somehow. The high valued points in in the data are all whole numbered values and the low points all include decimals, which also indicates that they are being set by a different unrelated process..

sandy
Administrator
Posts: 1229
Permalink
sandy
Post Re: Problem with "Move Direct" and vectors
on: April 17, 2013, 14:40
Quote

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

Chojins
Newbie
Posts: 19
Permalink
Chojins
Post Re: Problem with "Move Direct" and vectors
on: April 18, 2013, 00:36
Quote

Yeah the three moves short - medium - long is what i'm seeing (can see in the graphs above). I'm compiling from the source and have included the newest AccelStepper. Will try the hex tonight and see if it makes a difference.

Chojins
Newbie
Posts: 19
Permalink
Chojins
Post Re: Problem with "Move Direct" and vectors
on: April 18, 2013, 08:52
Quote

Just loaded the hex and its working now!

sandy
Administrator
Posts: 1229
Permalink
sandy
Post Re: Problem with "Move Direct" and vectors
on: April 18, 2013, 09:47
Quote

Oh that's even worse. Well, it's good that it works, but it's bad because why!?

Right I didn't have a chance to play last night, but might try to go through a few accelstepper versions to see if that has anything to do with it. It rings a bell that there were a couple of fixes in accelstepper around behaviour to do with speed/accel set to 0.0, so I wonder if I was relying on bad behaviour to make it work how I intended, and that's since been fixed. The whole vector acceleration thing _was_ pretty smudgily put together.

I also have a nagging feeling that the randomness of this, and the random fixability of it indicate a "state"ful kind of issue though. A setting or value that seems completely unrelated.

The hex files will have been compiled with an older version of accelstepper.

Thanks for digging into this - I appreciate it.
sn

sandy
Administrator
Posts: 1229
Permalink
sandy
Post Re: Problem with "Move Direct" and vectors
on: April 19, 2013, 01:25
Quote

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

sandy
Administrator
Posts: 1229
Permalink
sandy
Post Re: Problem with "Move Direct" and vectors
on: April 20, 2013, 01:22
Quote

I have built a new archive with v1.5 of firmware and v1.4 of controller - https://code.google.com/p/polargraph/downloads/detail?name=Polargraph1.5.zip.

This includes the fix for the vector drawing and faster comms amongst other things. I'll be writing up a blog post about it shortly, but thought it was worth mentioning here.

sn

sandy
Administrator
Posts: 1229
Permalink
sandy
Post Re: Problem with "Move Direct" and vectors
on: April 21, 2013, 01:01
Quote

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

sandy
Administrator
Posts: 1229
Permalink
sandy
Post Re: Problem with "Move Direct" and vectors
on: April 21, 2013, 23:36
Quote

Well, maybe it is. Give it a shot! http://www.polargraph.co.uk/2013/04/a-flurry-of-activity/

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