Should I be using normal gcode senders that are familiar with GRBL?

[akzmonster]

First of all, love your stuff. I only built this because I had the parts sitting around and saw that you had started a V-plotter fork of GRBL. So I have it assembled and setup. I'm certainly not a GRBL superuser. I'm fairly comfortable with Marlin but GRBL has always been much more "jerky" so I just haven't found my stride with it.

That said, as usual with my GRBL attempts, hooking it up using 1/16th microstepping and quintuple checking all config settings yeilded just no functionality and noisy steppers on bCNC. So, I removed to jumpers to full steps and updated the settings: 5 steps/mm, 2000 mm/min (your wiki says mm/s but I figured it out), 250 mm/s^2, and perfectly measured X max travel.

But when I jog using bCNC, no matter which direction or length that I jog in, only the right motor does anything and it just runs constantly. The right motor is connected to Y on the ramps and the left to X. I'm not sure if that is correct or not. but the left motor does nothing other than hold during moves and then releasing (if I have idle time set).

Should I be using a different sender? I'll be fiddling either way. THanks!!

[jasonwebb]

Hi akzmonster! Unfortunately, I don't think this repo is not yet ready for use. I'm not even sure yet how to do what I'm hoping to do (user sends X,Y coordinates, GRBL converts to A,B and handles the rest). I don't have a plotter set up yet, so the commits I've made so far are untested. I also haven't had much time to spend on this project as of late :(

My intent with this project is to enable the use of any normal GRBL sender (I was looking at Candle, for example) to send standard GRBL commands with X,Y coordinates. I've also been wanting to integrate support for a pen-lift servo, which has been super difficult for me because I am not an embedded C programmer and the AVR documentation is a nightmare, haha.

I would definitely welcome any contributions if you're interested in moving this project forward a bit!

[terjeio]

@jasonwebb : I have just started playing with your code, with a debugger only, and I believe there is a bug or two.

In system.c:

  int32_t system_convert_wall_plotter_to_y_axis_steps(int32_t *steps)
  {
    return( sqrt( square(settings.max_travel[A_MOTOR] - steps[A_MOTOR]) + steps[B_MOTOR]*steps[B_MOTOR] ) );
  }

settings.max_travel[A_MOTOR] is in mm, steps[...] are in steps, max_travel needs to be converted to steps before use. Perhaps a good idea to precalculate this somewhere to save some processor cycles?

Also, the real-time position report is not correct - inverse transform is needed? Perhaps @akzmonster has some input for how to do that?

[terjeio]

The transformation has to be moved from step to mm domain in order to avoid overflows (unless the Arduino compiler does some magic behind the scenes - my ARM copiler does not). This seems to be working:

typedef struct {
    float a;
    float b;
} coord_t;

static machine_t machine = {0};

// Returns machine position in mm converted from system position steps.
// TODO: perhaps change to double precision here - float calculation results in errors of a couple of micrometers.
static void wp_convert_array_steps_to_mpos (float *position, int32_t *steps)
{
    coord_t len;

    len.a = (float)steps[A_MOTOR] / settings.steps_per_mm[A_MOTOR];
    len.b = (float)steps[B_MOTOR] / settings.steps_per_mm[B_MOTOR];

    position[X_AXIS] = (machine.width_pow + powf(len.a, 2.0f) - powf(len.b, 2.0f)) / (2.0f * machine.width_mm);
    len.a = machine.width_mm - position[X_AXIS];
    position[Y_AXIS] = sqrtf(len.b * len.b - len.a * len.a );
    position[Z_AXIS] = steps[Z_AXIS] / settings.steps_per_mm[Z_AXIS];
}

// Wall plotter calculation only. Returns x or y-axis "steps" based on wall plotter motor steps.
// A length = sqrt( X^2 + Y^2 )
// B length = sqrt( (MACHINE_WIDTH - X)^2 + Y^2 )
inline static int32_t wp_convert_to_x_axis_steps (float *target)
{
    return (int32_t)(sqrtf(target[A_MOTOR] * target[A_MOTOR] + target[B_MOTOR] * target[B_MOTOR]) * settings.steps_per_mm[A_MOTOR]);
}

inline static int32_t wp_convert_to_y_axis_steps (float *target)
{
    float xpos = machine.width_mm - target[A_MOTOR];
    return (int32_t)(sqrtf(xpos * xpos + target[B_MOTOR] * target[B_MOTOR]) * settings.steps_per_mm[B_MOTOR]);
}

[akzmonster]

I was looking through your code. I've been trying to wrap my head around how GRBL works for the past month or two and I'm just not getting anywhere. How should I implement your code? I don't know which file you are referring to. Thanks! I want to find a way to get this to work so bad! I would love to help but there is just no reference for learning GRBL. I understand C, Cpp, and some C# but embedded is new territory. I can learn really fast if I have a resource.

[terjeio]

@akzmonster An simple overwiev of the grbl architecture can be found here.

For the rest I assume the above comment was aimed at @jasonwebb, but it may be of interest to you that I have ported grbl to a number of 32-bit processors and added wall plotter kinematics including the reverse transform for reporting. Please note as of now this implementation is not tested yet, but hopefully some of it may be useful input for completing this port.

[akzmonster]

Oh thanks so much, I was responding to you. Sorry for not making that clear. I'm new to this. Looking at your link now. I've started refreshing myself on C again to start getting a hang of this!