XY Wall Plotter Problem - Y axis is angled

January 26, 2019 2:55 PM

So for my daughters science fair project she built an XY wall plotter but having a bit of a problem with the software side in that the Y axis isn't plotting a straight line, it's a line that points towards the center of the machine. Any ideas?

We are using grbl-polar which I thought would handle the conversion of the cartesian co-ordinates into polar but something is awry.

This is the change they made to handle the polar co-ordinates. Not quite sure what's up.

#ifdef POLAR

//Change from cartessian to polar coordinates
float target_polar[N_AXIS];
float x= settings.distance-target[X_AXIS];
target_polar[X_AXIS]=sqrt(labs(target[X_AXIS]*target[X_AXIS]+target[Y_AXIS]*target[Y_AXIS]));
target_polar[Y_AXIS]=sqrt(labs(x*x+target[Y_AXIS]*target[Y_AXIS]));
target_polar[Z_AXIS]=0.0;
plan_buffer_line(target_polar, feed_rate, invert_feed_rate);

gc_state.position[X_AXIS]=target[X_AXIS];
gc_state.position[Y_AXIS]=target[Y_AXIS];

#else

Any ideas? Thanks!

posted by zeoslap to Science & Nature (21 answers total)

Sorry, I should have looked at the link for grbl-polar first - despite the name, it is doing the right coordinates. Did you set the distance between the two motors using grbl-polar's $27 command or the GUI? Is it possible you have the left and right motors mixed up?
posted by moonmilk at 3:40 PM on January 26, 2019

Response by poster: So motors seem correct, I think... Question though is y500 - y600 supposed to go up or down? The distance has been set yet.
posted by zeoslap at 3:56 PM on January 26, 2019

If the distance hasn't been set, the software has no way of doing the math to put the pen in the correct place. Eyeball it and run that command.
posted by Alterscape at 4:10 PM on January 26, 2019

A curved line or a straight line at an angle? Does it draw a horizontal line?
posted by sammyo at 4:26 PM on January 26, 2019

Response by poster: Horizontal line is perfect, and it's a straight angled line pointing towards the center point of the two steppers.
posted by zeoslap at 4:30 PM on January 26, 2019

Response by poster: @alterscape The distance has been correctly set.
posted by zeoslap at 4:30 PM on January 26, 2019

Why do you want polar coordinates? Why not stick with cartesian?

Your link mentions a simulator; does your file print correctly in the simulator?

You say "the change they made...", but that code looks to be unchanged. Look at line 42 in config.h to see if polar is enabled or not. The leading hashtag ('#', octothorp, pound sign) isn't a comment character as in python, but is part of the CPP C language pre-processor, so leading slashes ('//') would mean commented out.
posted by at at 4:30 PM on January 26, 2019

Response by poster: Also it draws a nice straight line in the center. So it's a bit like / | \ for x300 x500 x800. 500mm is the center.
posted by zeoslap at 4:31 PM on January 26, 2019

Response by poster: @at - standard grbl doesn't translate to polar which is necessary for these types of machines because you are taking the x y and converting it to string lengths. The file is fine and yes it looks as expected in the simulator.
posted by zeoslap at 5:17 PM on January 26, 2019

Response by poster: Hmm so after another test the horizontal lines aren't straight either. They are arcs centered on the middle of the machine
posted by zeoslap at 5:50 PM on January 26, 2019

Are you quite sure this isn't a mechanical issue, like chain sag, gear backlash, etc?
posted by aramaic at 6:04 PM on January 26, 2019

My trig is beyond rusty but looking at these equations the first matches but the second seems wonky, but the tan may be calculated that way but well, grr algebra.

r = √ ( x^2 + y^2 )
θ = tan^-1 ( y / x )

target_polar[X_AXIS]=sqrt(labs(target[X_AXIS]*target[X_AXIS]+target[Y_AXIS]*target[Y_AXIS]));
target_polar[Y_AXIS]=sqrt(labs(x*x+target[Y_AXIS]*target[Y_AXIS]));
posted by sammyo at 6:06 PM on January 26, 2019

But again it may be to transform a coord to two stepper motors, and that is a bit more complex than a basic arc and length. Very cool project though!!!
posted by sammyo at 6:12 PM on January 26, 2019

Response by poster: They calculate R for both strings - the R for left motor is the first equation. And then the R for the right motor is machine width - target X.

So X = 750 and a machine width of 1000 we get
R for 750 and R for 250.

At least I think that's what is going on... My math is hopeless.
posted by zeoslap at 6:38 PM on January 26, 2019

I am also wondering if this is a mechanical issue, like maybe the motors aren't sized to properly handle the weight of the plotter head on the far sides of the board (where one motor has to do the bulk of the heavy lifting, literally). Does the problem get worse if you weigh down the head, or better if you make it lighter?
posted by btfreek at 6:39 PM on January 26, 2019 [1 favorite]

Response by poster: So a little progress. I reversed the direction of one of the steppers and that corrected the y slant. However it did flip the image upside down (not a big deal).

The next issue is that while the start and stop points are translated correctly the intermediate steps are clearly not polar so it uses an arc to get from point to point. Will dig deeper. Thanks for your thoughts.
posted by zeoslap at 8:03 PM on January 26, 2019

How big are the rotors and how thick is your string? If the effective radius of the rotors is noticeably increased as more string gets wound onto them, that's going to screw up the assumptions underlying the x-y to string length calculations.
posted by flabdablet at 12:27 AM on January 27, 2019

the intermediate steps are clearly not polar so it uses an arc to get from point to point

If you're drawing from SVG files or the like, you could load them into illustrator or Inkscape to subdivide long straight lines into sequences of many short lines to minimize that arc effect. For example, in illustrator you could use the Object > Path > Add Anchor Points command several times, or choose the Add Anchor Point tool and click along the lines you want to subdivide. Although the machine will still draw arcs between the new anchor points, if they are close enough together the result will be nearly indistinguishable from a straight line.
posted by moonmilk at 6:43 AM on January 27, 2019

Why aren't you using the Stringent driver code? Most grbl-based wall plotters have the motors at the top of the board, but Stringent has them at the pen end so the kinematics will be completely different.
posted by scruss at 12:37 PM on January 27, 2019

could we see a video of it running?
posted by at at 8:52 PM on January 27, 2019

Response by poster: So think we have everything sorted out - after digging into the code I could see that G0 was navigating through cartesian space and this expected the pen to be raised. Start and end points were correct but it goes from A to B in an arc which is fine. G1 is used for pen down moves and it splits long lines into 2mm segments in order to plot nice flat lines in polar space like @moonmilk suggested.

The final issue was the image was printed upside down but a quick change to the gcode generator to flip the Y axis fixed that. So we are all set :)

@scruss - Hadn't heard of the Stringent driver, our plotter has the motors at the top.

Here's a pic of the contraption - it's plotting an upside down picture of my daughter :)
posted by zeoslap at 12:51 PM on January 28, 2019 [2 favorites]