Not emitting steps at shallow incline.

[lutorm]

I came across a behavior that seems super bad when I was doing some testing the other day. I haven't conclusively debugged it yet, I'll put a scope on the outputs to make sure but I wanted to open an issue in case this is a known problem. I'm using g2/edge from July 13, 2020.

The issue appeared when I was doing short x-moves with a very small delta-z. What happened was that I lowered the z-axis onto a z-axis setter and moved it to zero the z-position. From there, I can do very small moves straight up and down, and they're reflected on the z-axis setter to within 0.02mm (modulo backlash when changing directions.)

However, if I performed a 0.1mm z-axis move while also moving 10-20mm in x, only the x-axis would move, but the g2 position would reflect the commanded position also in z! By doing this back and forth, like:

g1 x10 z0.1
g1 x0 z0.2
g1 x10 z0.3
g1 x0 z0.4
...

I could make the g2 z-axis position change arbitrarily much without the motor ever moving, making the position discrepancy larger and larger. If I made the z-move greater than 0.2 or 0.3mm, then both axes would move.

Like I said, I want to put the scope on the z-axis pulses to make absolutely sure that it's not the z-axis motor, but since it can do the moves with a stationary x-axis perfectly fine, it seems doubtful. (It's a servo and should fault if it for some reason couldn't move.)

I tried searching the issues to see if anything like it had been reported before but couldn't find anything. I can try with the current version but I have to port my settings so I haven't done this yet.

[mhlong10]

Take a look at this #442 (comment) and see if it helps. It looks like you ran into the same thing I did.

Bottom line is change this line

g2/g2core/plan_exec.cpp

Line 941 in 72e49fb

if (fabs(travel_steps[m]) < 0.01) { // truncate very small moves to deal with rounding errors

to this:
if (fp_ZERO(fabs(travel_steps[m]))) { // truncate very small moves to deal with rounding errors

Note - I've been running with the above changes for over a year now without an issue. I think this fix didn't get put in because we were concerned with rounding errors and also the fact the edge-preview push was coming. My bad for not following through.

[lutorm]

@mhlong10 Yeah, that sure sounds like the same issue. I see @giseburt said this would be fixed in the "four-cable-kinematics" branch, but it looks like I'm already using the most recent changes on edge. I can't figure out how to tell if that branch just hasn't been merged yet? That was over a year ago though, so I would have hoped so.

I've been very impressed with g2 over the years I've used it, but not losing track of position is the number one requirement on a motion controller. It's much more important than to move exactly as commanded, or get the acceleration correct, since those would be temporary issues. If it doesn't keep track of position, the error can just accumulate the longer the controller is up, which can get arbitrarily bad.

I'm almost certain this is a regression, because I remember making moves like that a couple years ago and they worked fine.

[mhlong10]

@lutorm The fix is not in g2/edge. I would try changing line 941 in plan_exe.cpp as shown above and give it a try.

[lutorm]

I noted the comment just above the code you pointed out:

    // Very small travels of less than 0.01 step are truncated to zero. This is to correct a condition
    // where a rounding error in kinematics could reverse the direction of a move in the extreme head or tail.
    // Truncating the move contributes to positional error, but this is corrected by encoder feedback should
    // it ever accumulate to more than one step.

The claim that the positional error will be corrected by "encoder feedback" if it accumulates to more than one step seems to be incorrect. t appears that change was made by @aldenhart. What is this "encoder feedback" mentioned?

[giseburt]

Sorry for missing this. The fix is now in the edge-preview branch, which was derived from the four-cable-kinematics branch.

…

On Apr 16, 2021, at 6:46 AM, mhlong10 ***@***.***> wrote: @lutorm <https://github.com/lutorm> The fix is not in g2/edge. I would try changing line 941 in plan_exe.cpp as shown above and give it a try. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#493 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC6HUMQ4B43VSLIVBCSHLTTJAPS5ANCNFSM424UMRBA>.

[lutorm]

@giseburt Thanks for responding. I tried to port my settings to the edge-preview branch but it won't build for me. I'm getting errors like

./board/ArduinoDue/0_hardware.cpp:243:5: error: 'laser_tool' was not declared in this scope
     laser_tool.set_pulse_duration_us(nv->valuetype == TYPE_FLOAT ? nv->value_flt : nv->value_int);

It appears this is code that isn't properly excluded if HAS_LASER is false?

[tomasbubela]

I came across a behavior that seems super bad when I was doing some testing the other day. I haven't conclusively debugged it yet, I'll put a scope on the outputs to make sure but I wanted to open an issue in case this is a known problem. I'm using g2/edge from July 13, 2020.

The issue appeared when I was doing short x-moves with a very small delta-z. What happened was that I lowered the z-axis onto a z-axis setter and moved it to zero the z-position. From there, I can do very small moves straight up and down, and they're reflected on the z-axis setter to within 0.02mm (modulo backlash when changing directions.)

However, if I performed a 0.1mm z-axis move while also moving 10-20mm in x, only the x-axis would move, but the g2 position would reflect the commanded position also in z! By doing this back and forth, like:

g1 x10 z0.1
g1 x0 z0.2
g1 x10 z0.3
g1 x0 z0.4
...

I could make the g2 z-axis position change arbitrarily much without the motor ever moving, making the position discrepancy larger and larger. If I made the z-move greater than 0.2 or 0.3mm, then both axes would move.

Like I said, I want to put the scope on the z-axis pulses to make absolutely sure that it's not the z-axis motor, but since it can do the moves with a stationary x-axis perfectly fine, it seems doubtful. (It's a servo and should fault if it for some reason couldn't move.)

I tried searching the issues to see if anything like it had been reported before but couldn't find anything. I can try with the current version but I have to port my settings so I haven't done this yet.

I had similar behavior, with losing steps in Z axis and sometimes in Y and X also. The cause was the wrong polarity of STEP output signals to stepper drivers. After changing polarity in setting file it is ok. I use DUE board with external drivers.