Problem with g132 with high micro stepping and slow acceleration

[derwassi]

I've got a delta printer which needs currently pretty slow acceleration (~25mm/s^2). After I have switched to 128 micro stepping (raps128 chips) the g132 command always reported 0 as offsets (although this is not true). after digging around in the code I found the reason: due to slow acceleration (and deceleration) and probably 128 microstepping the endstops are still moving a few steps and so the according lines in DeltaSegment::checkEndstops get called multiple times overwriting the initially correct value. As a workaround I've set stepsRemainingAtYHit = 0 in g132, and set it only, if it equals 0 (so it will be only set once). I didn't fork and make a pull request, as I don't know what impact this might have (especially on cartesian printers)

[kyrreaa]

128 microstepping is a waste of time. The slight varainces in load on the steppers will make the position skew so bad that even 1/64 and 1/32 is on the edge of pointless.

Kyrre

From: derwassi Sent: Saturday, June 06, 2015 11:17 PM To: repetier/Repetier-Firmware Subject: [Repetier-Firmware] Problem with g132 with high micro stepping and slow acceleration (#405)

I've got a delta printer which needs currently pretty slow acceleration (~25mm/s^2). After I have switched to 128 micro stepping (raps128 chips) the g132 command always reported 0 as offsets (although this is not true). after digging around in the code I found the reason: due to slow acceleration (and deceleration) and probably 128 microstepping the endstops are still moving a few steps and so the according lines in DeltaSegment::checkEndstops get called multiple times overwriting the initially correct value. As a workaround I've set stepsRemainingAtYHit = 0 in g132, and set it only, if it equals 0 (so it will be only set once). I didn't fork and make a pull request, as I don't know what impact this might have (especially on cartesian printers)

— Reply to this email directly or view it on GitHub.

[repetier]

I guess a better way to not interfere with existing other code would be this correction:

     if(isXPositiveMove() && Endstops::xMax())
        {
#if DRIVE_SYSTEM == DELTA
            if(cur->isXMove())
                Printer::stepsRemainingAtXHit = cur->stepsRemaining;
#endif
            setXMoveFinished();
            cur->setXMoveFinished();
        }

This uses the fact that cur move in direction gets finished afterwards so it does not need such tricks.

What I do not understand is why it should otherwise return 0. cur->stepsRemaining is still not 0 for the next step- The move is twice as high as the delta. You would only measure the last time a signal occurs instead of the first time as I see it. Also I guess the first might be more useful since that axis stopped moving at that point.

[derwassi]

@kyrre: its not about precision it's about loudness. Microsteps never has good rpeatability accuracy. Besides that, the code should still be robust enough.

@repetier: sorry for being inaccurate:stepsRemainingAtXHit is not zero, but they read the same for all axis a few More times => g32 reports zero offset. i will try your suggestion later today.

[repetier]

I see what you mean. So it is not the first stepsRemaining and if it updates all three on last step the difference is zero. Yes, that should be avoided. Will test my update later, also did not have that problem before it could in deed occur. Please let me know if it worked for you.

[derwassi]

I just tested your code, g132 still reports zero for all towers (probably setMoveOfAxis get's called from anywhere else during further movement?) BTW: it worked without any problems with 1/16 microstepping

[repetier]

It might be a problem if you get more then one move command. Delta splits longer moves. cur is the longer move I used for testing, but if the line itself gets split into more then 1 line due to step limits a later cur would have move reset and could trigger again. But this is a pure z move so each subsegment has 65535 steps. Even with only 10 subsegments per line these are 655350 steps with lets say 1280 steps per mm it would suffice for 512mm. Could be a bit low since it moves 1.5 * zHeight and some deltas are higher. So if your size is >341 mm with that resultion and you hit endstop in the first 512 we get your problem. I guess your 128 bit lies somewhere in that area. So setting them to -1 as flag would be the only safe solution.

[repetier]

Ok have pushed pushed now my final solution based on pre initializing. Should work as long as you start high enough now.