Backlash compensation tests fail

[Eric Norton]

Hi All,

 I was able to get the backlash for X and Y to work with a previous testing version of Open PnP and now it fails. I started Open PnP on 8/27/22 and it asked to update the software and I did. I get this:

What has changed? I modified a version of GRBL for a nine axis control and also has the M204 SXXX acceleration addition plus other Open PnP additions added to the GRBL firmware. Everything worked perfectly before and I can't figure out for the life of me why it isn't working now. I can see the acceleration value change by adding a serial transmit response in the firmware so I know the acceleration is changing as commanded by Open PnP. 

Any thoughts?

I thought about buying the BTT Octopus board and using Marlin because I am done dicking with this but even that board doesn't have the I/O I need for my machine and it also doesn't have the RS-485 comms for the custom feeders I created.

I'm frustrated because everything was working fine and now I'm stuck so any help would be greatly appreciated.

Thanks,

Eric

--

Eric Norton President, Velocitronics Motion Systems, Inc. 352-325-2994 | www.vmstech.net | er...@vmstech.net  3 Hemlock Loop Way, Ocala FL 34472

Create your own email signature

[mark maker]

Hi Eric

please send the machine.xml

_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/CAEfPpXzQ3VRUCVbu-YKUKSkB6CHmWGz7m%3Du_-xxwmJpe429xog%40mail.gmail.com.

[mark maker]

In case I'm offline, this is a rough checklist:

1. Driver must use one of the advanced control types: ConstantAcceleration or better (ModeratedConstantAcceleration recommended).
   https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#motion-control-type
2. Driver must not have a feed-rate limit. Set to 0.
   
3. Axes must all have have feed-rate and acceleration limits defined:
   https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits
   
4. Those axis limits must be smaller or equal to those that are effective on the controller. If you send M204 S2000 but the controller limits that to a configured S1000, it explains all.
   
5. The controller must be a true constant acceleration controller (which Grbl is, AFAIK).
   

>  I was able to get the backlash for X and Y to work with a previous testing version of Open PnP and now it fails.

The speed test was added in one of the later version, after multiple users complained that the calibration did not work right for them. It turned out that they still had the ToolpathFeedRate control set on the driver, which obviously spoils any attempt to calibrate sneak-up distances and backlash compensation moves at reduced speed. Those tiny moves will never be limited by a feed-rate, as they never reach those speeds, they need to be limited by acceleration too. A backlash speed of 25% means a mere 6.25% acceleration.

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#control-of-speed-factors

In general: have you carefully considered Issues & Solutions? Maybe including dismissed ones?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6156fd29-e432-866f-3f6e-80b27affd957%40makr.zone.

[Eric Norton]

Hi Mark,

 Attached is the machine.xml file.

Thanks,

Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6156fd29-e432-866f-3f6e-80b27affd957%40makr.zone.

[mark maker]

Hi Eric

The M204 (set acceleration) directive is missing on your MOVE_TO_COMMAND:

In fact, Issues & Solutions tells you so:

Now I'm just guessing you might have removed it manually, and why: Some controllers don't like multiple commands on one line, i.e. they don't like M204 on the same line as the G1 (even though this should be supported according to NIST RS274NGC, section 3.3.5). I don't know about Grbl.

If this is the case, enter it in two lines:

{Acceleration:M204 S%.2f} ; set acceleration limit
G1 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {A:A%.4f} {B:B%.4f} {FeedRate:F%.2f} ; move to target

If this helps, please report back, I will make it the new Issues & Solutions suggestion for Grbl.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAEfPpXzBX-fFR8D58OMGcBvZhf2XfvV_M%3DFrgSEoKwDDD8bU8w%40mail.gmail.com.

[eric.no...@gmail.com]

Hi Mark,

 

Yes, I removed the M204 for testing purposes to see if that was causing a problem. I had it in place before and it worked fine. For GRBL it is not necessary to have the M204 command because it is not needed. I have it coded like so in the GRBL firmware:

 

case 204: word_bit = NON_MODAL_NO_ACTION; break; // Set Acceleration. Moved to S

 

I can try the two line like you have mentioned but everything worked fine before I did the update so not sure now what broke.

 

Thanks,

 

Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7843fef0-116c-6257-a86e-e4efd436d171%40makr.zone.

[Eric Norton]

Hi Mark,

Here are my answers in bold:

In case I'm offline, this is a rough checklist:

1. Driver must use one of the advanced control types: ConstantAcceleration or better (ModeratedConstantAcceleration recommended).
   

1. https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#motion-control-type I am using ModeratedConstantAcceleration
2. Driver must not have a feed-rate limit. Set to 0. I am a bit confused by this. Do you mean internally in the grbl firmware? I have the feed-rate maximum set to 24000 (400mm/s). Should this be higher? I don't want the machine going too fast.
   

1. Axes must all have have feed-rate and acceleration limits defined:
   

1. https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits I have set the axis limits as defined.
   
2. Those axis limits must be smaller or equal to those that are effective on the controller. If you send M204 S2000 but the controller limits that to a configured S1000, it explains all. The S value updates all axes acceleration values X, Y, Z1, Z2, C1, C2, C3, C4. Should this only change the X and Y axis only and the other axes be left alone or at a default value?
   
3. The controller must be a true constant acceleration controller (which Grbl is, AFAIK). GRBL is.
   

>  I was able to get the backlash for X and Y to work with a previous testing version of Open PnP and now it fails.

The speed test was added in one of the later version, after multiple users complained that the calibration did not work right for them. It turned out that they still had the ToolpathFeedRate control set on the driver, which obviously spoils any attempt to calibrate sneak-up distances and backlash compensation moves at reduced speed. Those tiny moves will never be limited by a feed-rate, as they never reach those speeds, they need to be limited by acceleration too. A backlash speed of 25% means a mere 6.25% acceleration.

Here is what I have:

Thanks,

Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f25ec567-ce6f-cc1d-f091-d01bc38c5fe9%40makr.zone.

[mark maker]

Hi Eric,

Have you read that second mail of mine?

In case I'm offline, this is a rough checklist:

1. Driver must use one of the advanced control types: ConstantAcceleration or better (ModeratedConstantAcceleration recommended).
   https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#motion-control-type
2. Driver must not have a feed-rate limit. Set to 0.
   
3. Axes must all have have feed-rate and acceleration limits defined:
   https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits
   
4. Those axis limits must be smaller or equal to those that are effective on the controller. If you send M204 S2000 but the controller limits that to a configured S1000, it explains all.
   
5. The controller must be a true constant acceleration controller (which Grbl is, AFAIK).
   

I guess 1 thru 3 can be dismissed, but have you checked 4?

Re 5, have you actually tested that M204 works correctly?

> everything worked fine before I did the update so not sure now what broke.

Have you read this section?

>  I was able to get the backlash for X and Y to work with a previous testing version of Open PnP and now it fails.

The speed test was added in one of the later version, after multiple users complained that the calibration did not work right for them. It turned out that they still had the ToolpathFeedRate control set on the driver, which obviously spoils any attempt to calibrate sneak-up distances and backlash compensation moves at reduced speed. Those tiny moves will never be limited by a feed-rate, as they never reach those speeds, they need to be limited by acceleration too. A backlash speed of 25% means a mere 6.25% acceleration.

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#control-of-speed-factors

Maybe everything did not actually work fine before.

Please send a log at trace level of a backlash calibration attempt.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/089301d8c061%24465cfed0%24d316fc70%24%40gmail.com.

[Eric Norton]

Hi Mark,

Here are my answers in bold:

Those axis limits must be smaller or equal to those that are effective on the controller. If you send M204 S2000 but the controller limits that to a configured S1000, it explains all. The firmware addition I did copies the S value and updates the acceleration in the planner 

The controller must be a true constant acceleration controller (which Grbl is, AFAIK).

I guess 1 thru 3 can be dismissed, but have you checked 4?

Re 5, have you actually tested that M204 works correctly? M204 does not do anything in GRBL. I accept the command as I stated before

The log file is attached... I have been away from Open PnP for a while because I was working on building the feeders. I have included a screenshot of the backlash test that was done.

Thanks,

Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0ed2b34c-7ea1-b139-5b80-e34716080d6d%40makr.zone.

[mark maker]

Our mails just crossed each other.

1-3 is ok.

>  I am a bit confused by this.

Primarily, I meant this:

> Do you mean internally in the grbl firmware? I have the feed-rate maximum set to 24000 (400mm/s). Should this be higher?

Yes.

A bit of background: most CNC application "do something" with a tool when moving, liking 3D-printing or milling or laser cutting. Therefore the moving speed along the so-called toolpath is important. It does not matter in which direction we 3D-print/mill/laser cut, we just always want to apply the tool at the same speed.

PnP is different, we just want to move as fast as possible. It is only the axes that are limiting us, steppers would lose steps or something if we went any faster. However, if we travel in a diagonal, we can move two axes at full speed, so we get a faster diagonal top speed than the single axis top speed. We absolutely want to exploit this!!

The toolpath limit must be larger than or equal to the Euclidean sum of the axis limits, i.e. it must not limit the axes moving in a diagonal, e.g. you have 333.33mm/s on X, Y and Z (from your machine.xml), so you get (3*333.332)\sqrt(3 * 333.33^2) = 577.35mms-1 as the maximum diagonal toolpath feed-rate. This should be the minimum limit to set on the controller.

Alas, this does not explain the backlash speed problem, because that moves only one axis at a time. You should still fix it.

> The S value updates all axes acceleration values X, Y, Z1, Z2, C1, C2, C3, C4. Should this only change the X and Y axis only and the other axes be left alone or at a default value?

Yes, the S value is the toolpath acceleration, i.e. the Euclidean sum of all the axes' accelerations. OpenPnP automatically calculates it based on the individual axis limits and the vector components of the move, multiplied with the speed factor squared. So it is still the individual axes' limits that count.

Some controllers have individual axis acceleration limits, some controllers only have toolpath acceleration limits, some have both. Smoothieware even has a third type, the actuator limits (which is only different for special robot solutions such as on a Delta robot).

I don't know about GRBL. Just make sure that the limits set in OpenPnP are always smaller than ALL the ones set on the controller, both the individual axis limits AND converted to toolpath (Euclidean sum) limits.

> Here is what I have:

That's fine from the OpenPnP side.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAEfPpXw9RQvkYzz1NKxm-4iy-jyJVZ%2BtCCqXNTr9q%3DUnVnfqFg%40mail.gmail.com.

[Eric Norton]

Hi Mark,

 Here is what I have:

With the maximum limit set to 24000 mm/min (400mm/s) is that too low for the GRBL limit? Here are the MAX settings for GRBL:

$110=24000.000 (X-Axis Max Rate (mm/min))

$111=24000.000 (Y1&Y2-Axis Max Rate (mm/min))

$112=24000.000 (Z1-Axis Max Rate (mm/min))

$113=24000.000 (C1-Axis Max Rate (mm/min))

$114=24000.000 (C2-Axis Max Rate (mm/min))

$115=24000.000 (Z2-Axis Max Rate (mm/min))

$116=24000.000 (C3-Axis Max Rate (mm/min))

$117=24000.000 (C4-Axis Max Rate (mm/min))

Should these values above be higher?

Right now I am just copying the S value to all of the accelerations for all axes and it does not have a limit set at the moment in the firmware. I did a temporary test and I can see the acceleration value changing and I can also enter for example S400 and I can hear and see the acceleration change. 

I have spent a lot of time on this GRBL controller and would hate to just kick it to the curb. I'm just tired of it not working correctly and it isn't your fault. I don't know where the problem is and I am too frustrated to want to work on it.

Thanks,

Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b61e7631-3668-d4be-0efa-e85cbb7a16a3%40makr.zone.

[mark maker]

Hi Eric

OK, all is suddenly clear. Should have asked for the log earlier.

G4 P0.5

Turns out Grbl takes the dwell P word in seconds, not milliseconds, which is actually correct. All the other Open Source controllers got it wrong and take milliseconds.

https://github.com/gnea/grbl/issues/172#issuecomment-294228802

https://reprap.org/wiki/G-code#G4:_Dwell

So you are waiting a whopping 0.5 seconds after each move which completely screws up the speed measurement done by backlash calibration.

Issues & Solutions actually proposes

G4 P0

Why did you change it? Does this mean that zero does not work? The Grbl source does look like this should work (but maybe P0 is filtered out earlier):

https://github.com/gnea/grbl/blob/bfb67f0c7963fe3ce4aaf8a97f9009ea5a8db36e/grbl/motion_control.c#L194-L200

Please report back, so I can make I&S propose the right thing.

https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl#synchronization

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b61e7631-3668-d4be-0efa-e85cbb7a16a3%40makr.zone.

[mark maker]

Forgot to comment the last link:

They say here that the P value must in deed be larger than 0:

https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl#synchronization

Maybe that's true, maybe that's outdated (I haven't studied the whole source calling path).

Please test this when your back at the machine (using Pronterface or something):

G1 X100 
G1 X200 F1000
G4 P0

Test if the third  "ok" only appears after that slow move is really finished, i.e. it should be delayed by about 6 seconds.

If P0 does not work, I hope you can set less than the example P0.01, which is still 10ms.

_Mark

On 04.09.22 18:08, mark maker wrote:

Hi Eric

OK, all is suddenly clear. Should have asked for the log earlier.

G4 P0.5

Turns out Grbl takes the dwell P word in seconds, not milliseconds, which is actually correct. All the other Open Source controllers got it wrong and take milliseconds.

https://github.com/gnea/grbl/issues/172#issuecomment-294228802

https://reprap.org/wiki/G-code#G4:_Dwell

So you are waiting a whopping 0.5 seconds after each move which completely screws up the speed measurement done by backlash calibration.

Issues & Solutions actually proposes

G4 P0

Why did you change it? Does this mean that zero does not work? The Grbl source does look like this should work (but maybe P0 is filtered out earlier):

https://github.com/gnea/grbl/blob/bfb67f0c7963fe3ce4aaf8a97f9009ea5a8db36e/grbl/motion_control.c#L194-L200

Please report back, so I can make I&S propose the right thing.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/62dcd55e-3220-fbdf-5260-f71f4da07ffc%40makr.zone.

[Eric Norton]

Hi Mark,

 I changed it to P0.5 because it gave the board some time to react to the commands and also made Open Pnp wait a little bit so the commands finished processing. I will try the P0.01 as you suggest and report back.

Thanks,

Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9f092208-5c5d-60e0-df5b-844661cb33a3%40makr.zone.

[Eric Norton]

Hi Mark, 

 I have tried G4 P0.01 and it started doing the backlash test but I get the timeout error while doing the test. I will increase the dwell time to see if it will complete the backlash test. 

Thanks,

Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9f092208-5c5d-60e0-df5b-844661cb33a3%40makr.zone.

[Litterio Andrea Guainella]

Hi Eric, Mark,

according with this or this (based you use) for obtain G4 P0 seems possible use: G4 P0.0001 because:

>  delay_ms(floor(1000*seconds-i*DWELL_TIME_STEP)); // Delay millisecond remainder.

this would be delay_ms(0)

Maybe works but if G4 P0.01 raise timeout I think not works.

It is also important to know the version of grbl you use for investigate

LAG

[Eric Norton]

Hi Mark,

 I keep getting timeout errors now and also says it "Subject not found". Not sure what is causing it.

Thanks,

Eric

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9f092208-5c5d-60e0-df5b-844661cb33a3%40makr.zone.

[mark maker]

>  I changed it to P0.5 because it gave the board some time to react to the commands

No need for that. Grbl must support flow control, and it will automatically back up commands if they arrive too quick.

> and also made Open Pnp wait a little bit so the commands finished processing.

No need. The very semantics of G4 is to wait for the commands to finish, even before it starts the dwell time.

> I will try the P0.01 as you suggest

Please reread both my answers carefully and ask if unclear. I did not suggest P0.01, in fact I still hope P0 will work. You'll need to perform the tests I laid out.

While at it (and per the suggestion of Litterio), please also confirm that the P values are in-deed seconds. You might have a different Grbl version.

G4 P5

should wait 5 seconds until the "ok" appears.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAEfPpXwXZP3HqFKFdT%2BEmvxYyb_ShuSnj3-1fU1ZkoNz-NFYoQ%40mail.gmail.com.

[eric.no...@gmail.com]

Hi Litterio,

 

I have modified grbl version 1.1f and this is my mc_dwell function:

 

// Execute dwell in seconds.

void mc_dwell(float seconds)

{

  if (sys.state == STATE_CHECK_MODE) { return; }

  protocol_buffer_synchronize();

  delay_sec(seconds, DELAY_MODE_DWELL);

}

 

Thanks,

 

Eric

 

From: ope...@googlegroups.com <ope...@googlegroups.com> On Behalf Of Litterio Andrea Guainella
Sent: Sunday, September 4, 2022 1:04 PM
To: OpenPnP <ope...@googlegroups.com>
Subject: Re: [OpenPnP] Backlash compensation tests fail

 

Hi Eric, Mark,

1.       Driver must use one of the advanced control types: ConstantAcceleration or better (ModeratedConstantAcceleration recommended).

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#motion-control-type I am using ModeratedConstantAcceleration

2.       Driver must not have a feed-rate limit. Set to 0. I am a bit confused by this. Do you mean internally in the grbl firmware? I have the feed-rate maximum set to 24000 (400mm/s). Should this be higher? I don't want the machine going too fast.

3.       Axes must all have have feed-rate and acceleration limits defined:

https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits I have set the axis limits as defined.

4.       Those axis limits must be smaller or equal to those that are effective on the controller. If you send M204 S2000 but the controller limits that to a configured S1000, it explains all. The S value updates all axes acceleration values X, Y, Z1, Z2, C1, C2, C3, C4. Should this only change the X and Y axis only and the other axes be left alone or at a default value?

5.       The controller must be a true constant acceleration controller (which Grbl is, AFAIK). GRBL is.

>  I was able to get the backlash for X and Y to work with a previous testing version of Open PnP and now it fails.

The speed test was added in one of the later version, after multiple users complained that the calibration did not work right for them. It turned out that they still had the ToolpathFeedRate control set on the driver, which obviously spoils any attempt to calibrate sneak-up distances and backlash compensation moves at reduced speed. Those tiny moves will never be limited by a feed-rate, as they never reach those speeds, they need to be limited by acceleration too. A backlash speed of 25% means a mere 6.25% acceleration.

Here is what I have:

 

Thanks,

 

Eric

 

 

On Sat, Sep 3, 2022 at 1:14 PM mark maker <ma...@makr.zone> wrote:

In case I'm offline, this is a rough checklist:

1. Driver must use one of the advanced control types: ConstantAcceleration or better (ModeratedConstantAcceleration recommended).
   https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#motion-control-type
2. Driver must not have a feed-rate limit. Set to 0.
3. Axes must all have have feed-rate and acceleration limits defined:
   https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits
4. Those axis limits must be smaller or equal to those that are effective on the controller. If you send M204 S2000 but the controller limits that to a configured S1000, it explains all.
5. The controller must be a true constant acceleration controller (which Grbl is, AFAIK).

>  I was able to get the backlash for X and Y to work with a previous testing version of Open PnP and now it fails.

The speed test was added in one of the later version, after multiple users complained that the calibration did not work right for them. It turned out that they still had the ToolpathFeedRate control set on the driver, which obviously spoils any attempt to calibrate sneak-up distances and backlash compensation moves at reduced speed. Those tiny moves will never be limited by a feed-rate, as they never reach those speeds, they need to be limited by acceleration too. A backlash speed of 25% means a mere 6.25% acceleration.

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#control-of-speed-factors

In general: have you carefully considered Issues & Solutions? Maybe including dismissed ones?

_Mark

On 03.09.22 18:50, mark maker wrote:

Hi Eric

please send the machine.xml

_Mark

 

On 03.09.22 18:08, Eric Norton wrote:

Hi All,

 

 I was able to get the backlash for X and Y to work with a previous testing version of Open PnP and now it fails. I started Open PnP on 8/27/22 and it asked to update the software and I did. I get this:

 

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f7403201-63b7-47ca-bfec-95a1f0b9d5fdn%40googlegroups.com.

[eric.no...@gmail.com]

Hi Mark,

 

I do not have flow control functionality on the board. Grbl does not have flow control. Only RX and TX is available.

 

I was assuming here:

 

If P0 does not work, I hope you can set less than the example P0.01, which is still 10ms.

 

Thanks,

 

Eric

 

From: ope...@googlegroups.com <ope...@googlegroups.com> On Behalf Of mark maker
Sent: Sunday, September 4, 2022 1:16 PM
To: ope...@googlegroups.com
Subject: Re: [OpenPnP] Backlash compensation tests fail

 

>  I changed it to P0.5 because it gave the board some time to react to the commands

1.       Driver must use one of the advanced control types: ConstantAcceleration or better (ModeratedConstantAcceleration recommended).

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#motion-control-type I am using ModeratedConstantAcceleration

2.       Driver must not have a feed-rate limit. Set to 0. I am a bit confused by this. Do you mean internally in the grbl firmware? I have the feed-rate maximum set to 24000 (400mm/s). Should this be higher? I don't want the machine going too fast.

3.       Axes must all have have feed-rate and acceleration limits defined:

https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits I have set the axis limits as defined.

4.       Those axis limits must be smaller or equal to those that are effective on the controller. If you send M204 S2000 but the controller limits that to a configured S1000, it explains all. The S value updates all axes acceleration values X, Y, Z1, Z2, C1, C2, C3, C4. Should this only change the X and Y axis only and the other axes be left alone or at a default value?

5.       The controller must be a true constant acceleration controller (which Grbl is, AFAIK). GRBL is.

>  I was able to get the backlash for X and Y to work with a previous testing version of Open PnP and now it fails.

The speed test was added in one of the later version, after multiple users complained that the calibration did not work right for them. It turned out that they still had the ToolpathFeedRate control set on the driver, which obviously spoils any attempt to calibrate sneak-up distances and backlash compensation moves at reduced speed. Those tiny moves will never be limited by a feed-rate, as they never reach those speeds, they need to be limited by acceleration too. A backlash speed of 25% means a mere 6.25% acceleration.

Here is what I have:

 

Thanks,

 

Eric

 

 

On Sat, Sep 3, 2022 at 1:14 PM mark maker <ma...@makr.zone> wrote:

In case I'm offline, this is a rough checklist:

1. Driver must use one of the advanced control types: ConstantAcceleration or better (ModeratedConstantAcceleration recommended).
   https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#motion-control-type
2. Driver must not have a feed-rate limit. Set to 0.
3. Axes must all have have feed-rate and acceleration limits defined:
   https://github.com/openpnp/openpnp/wiki/Machine-Axes#kinematic-settings--rate-limits
4. Those axis limits must be smaller or equal to those that are effective on the controller. If you send M204 S2000 but the controller limits that to a configured S1000, it explains all.
5. The controller must be a true constant acceleration controller (which Grbl is, AFAIK).

>  I was able to get the backlash for X and Y to work with a previous testing version of Open PnP and now it fails.

The speed test was added in one of the later version, after multiple users complained that the calibration did not work right for them. It turned out that they still had the ToolpathFeedRate control set on the driver, which obviously spoils any attempt to calibrate sneak-up distances and backlash compensation moves at reduced speed. Those tiny moves will never be limited by a feed-rate, as they never reach those speeds, they need to be limited by acceleration too. A backlash speed of 25% means a mere 6.25% acceleration.

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#control-of-speed-factors

In general: have you carefully considered Issues & Solutions? Maybe including dismissed ones?

_Mark

On 03.09.22 18:50, mark maker wrote:

Hi Eric

please send the machine.xml

_Mark

 

On 03.09.22 18:08, Eric Norton wrote:

Hi All,

 

 I was able to get the backlash for X and Y to work with a previous testing version of Open PnP and now it fails. I started Open PnP on 8/27/22 and it asked to update the software and I did. I get this:

 

.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0340f1cc-6d82-15d3-4b1f-4a590853fd61%40makr.zone.

[mark maker]

> I do not have flow control functionality on the board.

Yes, but you are using Confirmation Flow control, i.e. OpenPnP is waiting for the "ok" after each command was sent (GcodeDriver) or before the next command is sent (GcodeAsyncDriver).

Grbl itself is using an internal buffer where it collects pending (motion) commands. If this buffer is full, it will "hang" in the motion execution until a new buffer slot becomes available. As a consequence, the response with "ok" will be delayed until then. Hence it is using flow control, not serial flow control, but on a higher application level.

https://github.com/gnea/grbl/blob/bfb67f0c7963fe3ce4aaf8a97f9009ea5a8db36e/grbl/motion_control.c#L59-L65

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/09dc01d8c08a%24bb4ff930%2431efeb90%24%40gmail.com.

[Litterio Andrea Guainella]

Hi Eric,

according with this (1.1f build 20170801) G4 P0 should be works because not seems check for 0 limit value but:

G4 P0.1 will waiting 2ms

G4 P0.001 will waiting 1ms

G4 P0.0001  will waiting 1ms

because with new  delay_sec use ceil  function ==>  uint16_t i = ceil(1000/DWELL_TIME_STEP*seconds);

LAG

[Litterio Andrea Guainella]

Sorry for wrong report. I mean:

G4 P0.1 will waiting 100ms

G4 P0.001 will waiting 50ms

G4 P0.0001  will waiting 50ms

LAG

[eric.no...@gmail.com]

Hi Mark,

 

Ok that makes sense. So how do I keep it from hanging? I was adjusting the G4 P0.5 thing to make it slow down a bit so that Grbl could catch up or at least that’s what I thought was happening… Im not exactly sure why it loses comms if that is what is happening.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6429ecdb-93d7-adfa-c5da-07343ab12ebe%40makr.zone.

[eric.no...@gmail.com]

Ok thank you Litterio. So do I play with the value until I get something that works reliably?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/51c476bb-ce04-4135-9410-5bd9244c42d7n%40googlegroups.com.

[eric.no...@gmail.com]

Hi Mark,

 

I just thought about adding RTS and CTS to the hardware side of things. The UART module has the RTS and CTS in hardware so it would be transparent in the grbl firmware. I’d have to do some hardware mods but that won’t take too long to do. Is this something that’s worth looking into? The board has already been modified with jumpers so a few more won’t hurt right lol…

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6429ecdb-93d7-adfa-c5da-07343ab12ebe%40makr.zone.

[Litterio Andrea Guainella]

>  So do I play with the value until I get something that works reliably?

At this point I think so

LAG

[mark maker]

>  I just thought about adding RTS and CTS to the hardware side of things.

If you can do that, it will of course be much better. But I'm curious, what MCU do you run this on? You still have spare IOs after adding nine axis control??!

However, note that RTS/CTS should not be necessary on a plain GcodeDriver, i.e., do not expect this to solve the problem.

Serial flow control is only required on a GcodeAsyncDriver with Confirmation Flow Control switched off.

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#advanced-settings

Eric, I'm still waiting for you to do these tests on the controller, using Pronterface or similar.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0a3801d8c094%24853ed550%248fbc7ff0%24%40gmail.com.

[mark maker]

In your log I saw you have double "ok"s. Then I  found this:

https://github.com/grbl/grbl/issues/1024

That could explain the whole thing!

So please set the line-endings to LF only:

Then please try again with

G4 P0

If this works, please report back. I will make Issues & Solutions propose all this correctly for Grbl.

@Other Grbl users on the list: you never had any of these issues?

If you found the LF issue yourselves, please consider reporting such a find back to the community, next time. Thanks.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/15eda946-3a84-417a-a60c-62056a4b8c05%40makr.zone.

[eric.no...@gmail.com]

Hi Mark,

 

Thank you for this and I will make the change and report back my findings.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c7ecd042-8aa5-1694-98c4-f674495d23ef%40makr.zone.

[eric.no...@gmail.com]

Hi Mark,

 

Please see my response in Bold:

 

>  I just thought about adding RTS and CTS to the hardware side of things.

If you can do that, it will of course be much better. But I'm curious, what MCU do you run this on? You still have spare IOs after adding nine axis control??! I use the PSOC 5 100 pin chip and have IO’s left to implement this. I have to make some code and hardware changes but should be relatively straight forward

However, note that RTS/CTS should not be necessary on a plain GcodeDriver, i.e., do not expect this to solve the problem. I know. I want to be able to use the GcodeAsyncDriver as explained below.

Serial flow control is only required on a GcodeAsyncDriver with Confirmation Flow Control switched off.

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#advanced-settings

Eric, I'm still waiting for you to do these tests on the controller, using Pronterface or similar. I have been extremely busy with my main company duties. I will run the tests and get back to you with the results soon.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/15eda946-3a84-417a-a60c-62056a4b8c05%40makr.zone.

[eric.no...@gmail.com]

Hi Mark and Litterio,

 

I finally fixed my issues. It turns out when I left the firmware a while back, I wasn’t done making modifications. The ADC and the feeder RS-485 UART interrupts was causing the CPU to go and service those causing the chip and communication with Open PnP to freeze up and throw the timeout exceptions. I had to get creative with those components to make sure they work without interrupts. Now everything works great with no issues at all. I set G4 P0 with no dwell time and all works as expected. Just wanted to give you a heads up.

 

Thanks,

 

Eric Norton Velocitronics Motion Systems,Inc.   Phone: (352) 325-2994  Email: er...@vmstech.net   3 Hemlock Loop Way Ocala, FL 34472   www.vmstech.net

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6429ecdb-93d7-adfa-c5da-07343ab12ebe%40makr.zone.

[Litterio Andrea Guainella]

Hi Eric,

good job :-)

LAG

[Eric Norton]

Thanks :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3c0f4e76-1ce2-4a96-8cea-f72d3999ed13n%40googlegroups.com.