Backlash Test!

[Eric Norton]

To All,

 What is this and how do I fix it? I have a GRBL controller:

Any help would be greatly appreciated :-)!!!!

Thanks,

Eric Norton

[mark maker]

Hi Eric,

Automatic backlash compensation calibration is only available, if the controller can control the acceleration dynamically, typically through a M204 command.

Why is this needed?

In previous versions of OpenPnP, Backlash Compensation worked with the OneSided method. This method is still available and it works as follows: It always moves to a target position from the same side. If a move comes from the wrong side, it goes beyond the target by a certain so-called backlash offset and then retracts from there. With this method, any slack (e.g. in a belt) will always be on the same side and the positioning therefore more consistent. You can configure the backlash offset to be significantly larger than the worst case slack, so you're always on the safe side. This also means you can estimate it manually, there is no need for a sophisticated (automatic) calibration. You can still configure it manually, and this is what you probably need for the moment with Grbl, until it has M204. Note, AFAIK @Ravi is going to implementing M204 for Grbl.

The OneSided method is simple and effective, but this also means that it needs extra moves and direction changes, which makes the motion discontinuous (unfit for good motion planning), i.e. it is less fluid and slower.  Furthermore, by going beyond the target, you might collide with something, so you might need to be aware of that e.g. with the nozzle tip changer motion, or for mechanically actuated feeders. It is not normally a problem for pick & place per se, because the X/Y backlash compensation moves happen at Safe Z, i.e.  "in the air" where it does not matter. To pick and place, only Z moves.

Because of these Cons I created other methods. The Directional methods try to compensate the backlash (e.g. slack in a belt) by going exactly as much further in the original direction i.e. without a direction change. The problem with these methods is that the backlash offset now needs to be accurate, you can no longer just take the worst case, or even more. It soon turned out that this offset is not consistent! It matters how far and therefore how fast the machine moved, before the offset is applied. It seems the differences in peak feed-rate, friction, duration of deceleration (momentum) create differences in the tensions of the machine, e.g. most obviously in the belt. When the gantry or head is heavy, it might even overshoot into the belt (etc.) through momentum, i.e. cancel the backlash on energetic moves (but not others). At least that was observable on my machine (and many others later in testing). Therefore a so-called "sneak-up offset" was introduced. The last bit of a move is performed at a much slower speed, the machine kind of sneaks up to the target position. The idea is that the machine will "relax itself" consistently over that stretch, regardless of whether short/slow or long/fast moves came before.

And that's where the acceleration control is key. When I say "slower speed" I actually mean less deceleration (i.e. less negative acceleration), because physically it is the acceleration that is creating the most obvious differences in tension (the formula is F = ma). The feed-rate is mostly irrelevant as we are speaking of a very short sub-millimeter "sneak-up offset", i.e. very very low feed-rates and therefore negligible friction.

https://github.com/openpnp/openpnp/wiki/Backlash-Compensation#backlash-compensation-methods

The calibration algorithm needs to be able to control the acceleration, to test the various methods against each other. It will determine, how large and how slow the sneak-up offset needs to be to get consistent backlash. On mechanically superb machines it can even decide against using backlash compensation at all (method: None). Or it can decide that backlash is present but always consistent, so it can skip any sneak-up offset (method: DirectionalCompensation). If consistent enough backlash is achieved with sneak-up, it can configure its offset and speed (method: DirectionalSneakUp). Or it will fall back to the one-sided method, if even the slowest and longest sneak-up does not exhibit consistent enough backlash, it will then configure it for the observed worst case backlash and sneak-up, as a "best effort" (method: OneSidedPositioning).

I hope this explains it, and how important acceleration control is for both the auto calibration, and possibly for the backlash compensation itself.

It is also btw. very important for motion that needs to be gentle: e.g. picking large heavy parts, nozzle tip changing, actuating mechanical feeders with tiny parts.

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAEfPpXzk7ttd%3DPTCy-aQSOobCzKJYnM-EqmcLAvzJAXSgo8RzQ%40mail.gmail.com.

[Eric Norton]

Hey Mark, 

 How many new M commands are there now for Open Pnp lol. One thing I am having trouble with is the M115 and can't seem to get Open Pnp to stop sending it. Id like to add it to grbl at some point maybe now would be a good time and also like to add support for M204 if I knew what Open PnP expects from grbl. Can you provide me a list of the commands and the responses Open PnP expects to see and I can add them relatively quickly and then let you know how they work out?

By the way I can now calibrate the bottom camera with ease :-). Thank you so much for making it MUCH easier for all of us!!!

Thanks,

Eric Norton

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cfb166a2-4ae9-b77f-3261-47934fc37741%40makr.zone.

[mark maker]

Hi Eric

There are several initiatives around Grbl+OpenPnP active to my knowledge. There is a "native" Grbl fork for openpnp. @Ravi already has implemented most commands needed for OpenPnP and he is going to implementing M204.

https://github.com/openpnp/grbl/pull/2 (he will need to re-create the PR, so the upstream will be pulled in right)

There is another initiative around a grblHAL for more advanced MCUs:

https://www.grbl.org/what-is-grblhal
https://github.com/grblHAL/Plugin_OpenPNP

I don't know the status of that.

> Can you provide me a list of the commands and the responses Open PnP expects to see and I can add them relatively quickly and then let you know how they work out?

See here. Note the end of that section, for a way to simulate expected behavior:

https://github.com/openpnp/openpnp/wiki/Motion-Controller-Firmwares#key-features

In any case, I hope you guys work together on this instead of creating a zillion forks... 😁

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAEfPpXx97-Jv1JTv9N-2LEJ2gVUzZF92%2BYuXYv7KaPmM71jRtQ%40mail.gmail.com.

[Wayne Black]

There is another initiative around a grblHAL for more advanced MCUs:

https://www.grbl.org/what-is-grblhal
https://github.com/grblHAL/Plugin_OpenPNP

I can say that I use Phils Teensy 4.1   grblHAL BoB Unkit for 2 different CNC's and they work very well. One of them is a 5 axis w rs485 spindle control. Only niggle is the onboard headers are tiny and largest gauge they take are 22awg IIRC. If your familiar w GRBL it's pretty straight forward option using off board motor drivers. My big cnc using sd clearpath servos and the other is small step stick setup and the both run excellent. Ive tried other grblHAL ports around the ESP32 and the seem buggy w comm issues.

I have a 48VB and 36VA. The plan is convert both to Openpnp. My fist step is to flash the 36VA stock board w Marks Smoothie port just to get Openpnp up and running. I confess despite reading all the online info about this Im still daunted by the machine configuration. After I get a feel for things Ill swap the main board w Phil's bob. Im happy to share outcomes.

[Eric Norton]

Hi Mark,

 I have added this to my version of grbl:

M115 firmware detect:

gcode.c file

case 115:
   word_bit = NON_MODAL_NO_ACTION;
   switch(int_value) {
      case 115: report_firmware_detect(); break;
   }
   break;

report.c

// Print M115 Firmware Detect
void report_firmware_detect(void)
{
  printPgmString(PSTR("FIRMWARE_NAME: GRBL"));
  report_util_line_feed();
  printPgmString(PSTR("FIRMWARE_VERSION: 6.0"));
  report_util_line_feed();
  printPgmString(PSTR("FIRMWARE_VERSION_BUILD: 20210901"));
  report_util_line_feed();
}

As you can see it will send FIRMWARE_NAME: GRBL, FIRMWARE_VERSION: X.X and FIRMWARE_VERSION_BUILD: XXXXXXXX

If you can add this support to Open PnP that would be great so that way the minimum can be detected. I can add more to this as time permits.

Now for the M204 command. I see that Marlin uses this:

/**
 * M204: Set Accelerations in units/sec^2 (M204 P1200 R3000 T3000)
 *
 *    P = Printing moves
 *    R = Retract only (no X, Y, Z) moves
 *    T = Travel (non printing) moves
 */
void GcodeSuite::M204() {
  if (!parser.seen("PRST"))
    return M204_report();
  else {
    //planner.synchronize();
    // 'S' for legacy compatibility. Should NOT BE USED for new development
    if (parser.seenval('S')) planner.settings.travel_acceleration = planner.settings.acceleration = parser.value_linear_units();
    if (parser.seenval('P')) planner.settings.acceleration = parser.value_linear_units();
    if (parser.seenval('R')) planner.settings.retract_acceleration = parser.value_linear_units();
    if (parser.seenval('T')) planner.settings.travel_acceleration = parser.value_linear_units();
  }
}

As far as I know the acceleration is updated through a grbl setting while not in motion so this will have to be updated dynamically by calling this:

settings.acceleration = value*60*60; break;

How does Open PnP send the string to the controller? Is it like this:

M204 PXXXX 

Is that it or is there axis information after the P value etc. A little more info would be great or I guess I could snoop the serial line with a logic analyzer and see what it is while the machine is running to find out what it is trying to send...

Any info on this would be great.

Thanks,

Eric Norton

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d7122b78-18f8-d95b-f89f-37e7de53f2cb%40makr.zone.

[mark maker]

Like I said, please work together with Ravi on this. He has already defined the M115 string for Grbl:

https://github.com/openpnp/grbl/blob/9d70549ab533c98941662abb037ede146bf42142/report.c#L702

And I have already added support in the testing version.

https://github.com/openpnp/openpnp/pull/1334

The string needs to contain Grbl (case sensitive).

> this will have to be updated dynamically by calling this:

> settings.acceleration = value*60*60; break;

I'm not sure you should be overwriting the settings. These seem to be per axis limits (an array). The M204 command we use in OpenPnP is a toolpath related acceleration limit.  The controller should always enforce both the axis and the toolpath limits. So define a new variable e.g. toolpath_acceleration, set it in the M204 command and use it in the planner, to initialize the nominal block acceleration. From just a quick look, probably here:

https://github.com/grbl/grbl/blob/9180094b72821ce68e33fdd779278a533a7bf40c/grbl/planner.c#L266

        block->acceleration = SOME_LARGE_VALUE; // Scaled down to maximum acceleration later

should now be

       block->acceleration = toolpath_acceleration; // From M204 S, scaled down to axis maximum acceleration later

But like I said: Ravi is already on it, so you two should coordinate.

> How does Open PnP send the string to the controller?

When your controller responds with Grbl in M115, OpenPnP testing version will recognize it and Issues & Solutions will propose the right MOVE_TO_COMMAND for you, including the M204. So no guesswork.

For Grbl M204 is sent with the S word.

The other words mentioned in the Marlin source code you cite (P R T) are clearly for 3D printing, Marlin deprecating S seems a bit narrow-minded, I guess it will stay for other NC applications after all.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAEfPpXykewvJHxz-aF%3D%2Br4rVNvxzQaVZjb7AM10kP7sA9r3U6A%40mail.gmail.com.

[Eric Norton]

Ah ok ill use that then and coordinate with him.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e952abb7-68bb-e3b5-1768-8d00cc3f23b1%40makr.zone.

[Eric Norton]

Hi Mark,

 How do I get a hold of Ravi? Is he a part of this group and does he see the back and forth emails? I'd like to get with him to discuss the M204 stuff in more detail. 

I have implemented the M115 command as per Ravi's code. I will download the GRBL testing version and play around with it.

As far as my system goes it is a lot different than the standard grbl. I have modified it heavily to work with a PSOC 5 and it has nine axis control, Z offset adjustment, dual axis drive for dual Y configuration and so on. This will not be a released version of grbl but can share code snippets if it helps others.

Now as far as the M204 with S command will this value need to be saved to eeprom or is this just for calibration purposes? I know you said it is a toolpath acceleration. Is this command sent every time the controller is enabled in Open PnP? Is it sent every time the toolpath acceleration needs to be updated? How does this work exactly?

In my planner.c file I have this:

block->acceleration = limit_value_by_axis_maximum(settings.acceleration, unit_vec);

which calls this:

float limit_value_by_axis_maximum(float *max_value, float *unit_vec)
{
  uint8_t idx;
  float limit_value = SOME_LARGE_VALUE;
  for (idx=0; idx<N_AXIS; idx++) {
    if (unit_vec[idx] != 0) {  // Avoid divide by zero.
      limit_value = min(limit_value, fabs(max_value[idx]/unit_vec[idx]));
    }
  }
  return(limit_value);
}

I could put the toolpath_acceleration like so:

float limit_value_by_axis_maximum(float *max_value, float *unit_vec)
{
  uint8_t idx;
  float limit_value = toolpath_acceleration;       // SOME_LARGE_VALUE;
  for (idx=0; idx<N_AXIS; idx++) {
    if (unit_vec[idx] != 0) {  // Avoid divide by zero.
      limit_value = min(limit_value, fabs(max_value[idx]/unit_vec[idx]));
    }
  }
  return(limit_value);
}

I just want something to work with so I can get my machine running and get it building boards as efficiently as possible. If Ravi can chime in, I'd be happy to get with him so we can sort this out.

Thanks,

Eric Norton

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e952abb7-68bb-e3b5-1768-8d00cc3f23b1%40makr.zone.

[mark maker]

>  How do I get a hold of Ravi?

The link of Ravi I gave you before is all I have.

> Now as far as the M204 with S command will this value need to be saved to eeprom or is this just for calibration purposes?

No, it is permanently used for OpenPnP. It is used as a transient setting, like the F word for feed-rate in G0/G1. So do not save it in the eeprom. It would burn it out and AFAIK it would also not work on the fly i.e. the stepper signal driver interrupts must be disabled during eeprom writing.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAEfPpXx6sVa_3GeYP0XUwa1kw0qxXv%2Bubo2oaz4qzWd3v0RHxA%40mail.gmail.com.

[Eric Norton]

Thank you Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/fd8924a8-204f-2fb7-834d-116a647fd3db%40makr.zone.

[Eric Norton]

Hi Mark, 

 Do you have the new grbl stuff in the test release as an executable so I can update my version of Open PnP? If not, how do I update it to use this?

Thanks,

Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e952abb7-68bb-e3b5-1768-8d00cc3f23b1%40makr.zone.

[mark maker]

It is in the testing version.

https://openpnp.org/test-downloads/

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAEfPpXydqdgGx7GF8gBGGQte1UPhxDsMFp5zhCXk4vZ83btVGw%40mail.gmail.com.

[Eric Norton]

Ok thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/66e88809-36a6-3f3f-9361-4cde6666f861%40makr.zone.

[Eric Norton]

Hi Mark,

 Just wanted to let you know I was able to get the backlash compensation stuff to work. The move to command cannot be G0 moves and had to change to G1. 

I was able to place components but still having some weird issues with the reference auto feeder and the location gets out of sync position wise and I wonder if it has something to do with the nozzle tip calibration for the up looking camera or not. I will continue to play with it but so far I am further than I thought I would be which is nice. Pretty crazy I built this thing with 3d printed parts and the accuracy is better than I thought it would be but there is still work to be done to make it more accurate. 

Thanks for all your help thus far :-)

Thanks,

Eric Norton

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/66e88809-36a6-3f3f-9361-4cde6666f861%40makr.zone.