Forum

Welcome Guest 

Show/Hide Header

Welcome Guest, posting in this forum requires registration.





Pages: [1]
Author Topic: Is look-ahead planned?
Televio
Newbie
Posts: 3
Permalink
Post Is look-ahead planned?
on: March 25, 2013, 08:52
Quote

Hi,
I now have finished my self build polargraph and play around with the software. Is it planned to improve the speed by adding a look ahead algorithm? I drive my stepper motors with Pololu drivers and I use accelaration. The problem is that the machine accelerates at each starting point of a line and slows down to the end of each line. Regardless at which angle they are connected. So if you have a lot of lines connected which point in the same direction the machine will always slow down at each connection point.

I modified the source to work with this shield:
http://www.watterott.com/en/Arduino-FabScan-Shield

and I improved the pen up/down methods.

If you want I can send you the code.

Best Regards,
Andreas

sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: Is look-ahead planned?
on: March 25, 2013, 10:44
Quote

Hi Andreas! Neat looking shield - I'd be interested in seeing your penlift improvements too. I have just added changes that allow the up and down positions to be changed, but other than that I'm sure there's work to be done. I've shifted development work into github (https://github.com/euphy).

I have no plans at all for look ahead - it is beyond me, technically. You will have noticed that the code is fairly unsophisticated.

sandy noble

Televio
Newbie
Posts: 3
Permalink
Post Re: Is look-ahead planned?
on: March 31, 2013, 16:26
Quote

Hi sandy,

sorry for the late reply. Here is my code for lifting the pen. It also works if the up position is negative. I added penlift_movePenUpHome for moving the pen up regardless in which position it was before.

Andreas

/**
*  Polargraph Server. - CORE
*  Written by Sandy Noble
*  Released under GNU License version 3.
*  http://www.polargraph.co.uk
*  http://code.google.com/p/polargraph/

Penlift.

This is one of the core files for the polargraph server program.  
This file contains the servo calls that raise or lower the pen from
the page.

*/

void penlift_movePen(int start, int end, int delay_ms)
{
	penHeight.attach(PEN_HEIGHT_SERVO_PIN);
	if(start < end)
	{
  		for (int i=start; i<=end; i++) 
		{
    		penHeight.write(i);
    		delay(delay_ms);
  		}
	}
	else
	{
  		for (int i=start; i>=end; i--) 
		{
    		penHeight.write(i);
    		delay(delay_ms);
  		}
	}
	penHeight.detach();
}

void penlift_movePenUpHome()
{
  penHeight.attach(PEN_HEIGHT_SERVO_PIN);
  penHeight.write(UP_POSITION);
  delay(500);
  penHeight.detach();
  isPenUp = true;
}

void penlift_penUp()
{
  	if (isPenUp == false)
	{
    penlift_movePen(DOWN_POSITION, UP_POSITION, 10);
		isPenUp = true;
	}
}

void penlift_penDown()
{
  	if (isPenUp == true)
	{
	   penlift_movePen(UP_POSITION, DOWN_POSITION, 15);
		 isPenUp = false;
	}
}

void penlift_testServoRange()
{
  penHeight.attach(PEN_HEIGHT_SERVO_PIN);
  for (int i=0; i<200; i++) {
    Serial.println(i);
    penHeight.write(i);
    delay(15);
  }
  penHeight.detach();
}
sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: Is look-ahead planned?
on: April 1, 2013, 20:52
Quote

Thanks Andreas, that's a more sensible approach, you're right. I've rolled your penlift_movePen method into the polarshield code, appearing in a new release soon!

(Currently in the background_comms branch of polargraph_server_polarshield - https://github.com/euphy/polargraph_server_polarshield/tree/background-comms)

Cheers!

Chojins
Newbie
Posts: 19
Permalink
Chojins
Post Re: Is look-ahead planned?
on: April 22, 2013, 09:54
Quote

Andreas I am also really keen to get some look ahead function into the firmware. I think vector drawing would really benefit from a constant feed with less bleeding, increased speed and line smoothness. Also it would allow for large scale painting with an airbrush or similar, and that's what i'm really interested in.

I guess the first thing to do would be have two commands in memory at once. once you know where the machine is headed after the 1st move you can decelerate each of the motors to the speeds required at the start of the 2nd move. Then you need to read the 3rd command asap while moving to point 2. Might run into issues here if the moves can't be read in time while the controller is moving

Also because the motors aren't moving at constant velocities while drawing a straight line there will probably be implications to positioning during the deceleration - ie the motors would need to maintain their velocity ratio while decelerating to the speeds needed at the start of the next move... Pretty confusing but I think this is worth the effort to get rid of the stop start motion. What do you think Sandy?

sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: Is look-ahead planned?
on: April 22, 2013, 12:41
Quote

This solution to buffering while moving is one that is already fairly well baked for general machine control stuff - GRBL is the gold standard for this, it's an arduino based CNC firmware, does all kinds of clever business, proper geometry, arcs, lookahead, buffering. It's what most hobbyist 3d printer firmwares are based on (sprinter, marlin), and I personally believe the hype. It's also rather beautifully written, reading it is a very pleasant experience.

However, in terms of event processing, it is pretty radically different to the current polargraph configuration. I do agree that lookahead would be nice (for at least a couple of reasons), but to be honest, not only is it not currently a problem for me, it actually produces an artefact that I like and find very appealing.

I did branch the current code into a background-comms, to have a hack around, and successfully speeded up the comms by a significant margin by removing stupids, so that was a nice outcome, but I didn't immediately see a simple way to merge the comms / command pipeline into the background processes. And it no matter how fast the actual comms, there's still a deceleration and a re-acceleration either side of it.

I don't think it's insurmountable, but it does mean a fairly significant rewrite and restructure. I do think it will happen one day, but unless someone else does it, it'll be later rather than sooner.

Personally, I suspect polargraph may be the wrong tool for the job for you Andreas - at this point in time at least. You could have a look at Dan Royer's (marginallyclever) drawbot code. It is a more stripped down and elegant piece of work than polargraph as it is purely for a plotter type device running from gcode, and I believe it uses the timer-interrupt based approach that means it'll do command buffering. I haven't used it myself.

sn

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