Feature Request: Limit carriage position to positive float: Improved software end stop for Deltas?

[MRGiacalone]

Hi,

I am doing a few tests on the delta moves using different Marlin distribution (i.e. Zalm, Cattell, Hercek). I encountered a problem when testing manual moves using both Repetier-Host and Pronterface. As discussed here (http://forums.reprap.org/read.php?267,355792) and here (https://groups.google.com/forum/#!topic/deltabot/tUJ1ty6yebg) the main thing that we are testing is the furthest reach of the delta arms using numeric manual moves. (one of the carriages is at 0.00 or close) The initial problem is that at a certain point (where the delta arm cannot reach according to its length) one of my steppers gets stuck running continuously. It would be better if it stop al together rather than running wild. M114 in both hosts show that after such point one the carriage is sent to a very low position (negative number) causing it to spin continuously. http://forums.reprap.org/file.php?267,file=33256 Repetier-Host: X:0.00Y:0.00Z:0.00E:0.00 Count X: 253.31Y:253.31Z:253.31 X:0.00Y:104.45Z:0.00E:0.00 Count X: 205.79Y:205.79Z:274.00 X:134.30Y:104.45Z:0.00E:0.00 Count X: 3.68Y:220.47Z:238.83 X:134.40Y:104.45Z:0.00E:0.00 Count X: -958.72Y:220.47Z:238.83
Pronterface: X:0.00Y:0.00Z:0.00E:0.00 Count X: 253.31Y:253.31Z:253.31 X:0.00Y:104.45Z:0.00E:0.00 Count X: 205.79Y:205.79Z:274.00 X:134.30Y:104.45Z:0.00E:0.00 Count X: 3.68Y:220.47Z:238.83 X:134.40Y:104.45Z:0.00E:0.00 Count X: -418.61Y:220.47Z:238.83

Would it be possible to limit the position of the carriage to no less than Z + Vertical effector offset?

This would avoid the carriages to try to reach a position lower than the effector. In addition to changing the software end stops to simulate a triangular region rather than a rectangular or circular one, might even be used as an improved software end stop for the Delta's.

[RichCattell]

I did actually implement a fix for this quite a while ago, but i removed it because i thought it was causing issues with glitchy movement. I never really confirmed that it was causing the issue to be honest and the code is still in there but commented out.. if you want to try it ..

open marlin_main.cpp and search for this function:

void calculate_delta(float cartesian[3]) { delta_tmp[X_AXIS] = sqrt(DELTA_DIAGONAL_ROD_2 - sq(delta_tower1_x-cartesian[X_AXIS]) - sq(delta_tower1_y-cartesian[Y_AXIS]) ) + cartesian[Z_AXIS]; delta_tmp[Y_AXIS] = sqrt(DELTA_DIAGONAL_ROD_2 - sq(delta_tower2_x-cartesian[X_AXIS]) - sq(delta_tower2_y-cartesian[Y_AXIS]) ) + cartesian[Z_AXIS]; delta_tmp[Z_AXIS] = sqrt(DELTA_DIAGONAL_ROD_2 - sq(delta_tower3_x-cartesian[X_AXIS]) - sq(delta_tower3_y-cartesian[Y_AXIS]) ) + cartesian[Z_AXIS];

/* SERIAL_ECHOPGM("cartesian x="); SERIAL_ECHO(cartesian[X_AXIS]); SERIAL_ECHOPGM(" y="); SERIAL_ECHO(cartesian[Y_AXIS]); SERIAL_ECHOPGM(" z="); SERIAL_ECHOLN(cartesian[Z_AXIS]);

SERIAL_ECHOPGM("delta x="); SERIAL_ECHO(delta[X_AXIS]); SERIAL_ECHOPGM(" y="); SERIAL_ECHO(delta[Y_AXIS]); SERIAL_ECHOPGM(" z="); SERIAL_ECHOLN(delta[Z_AXIS]); / / <-remove this line if ((delta_tmp[X_AXIS] > 0) and (delta_tmp[Y_AXIS] > 0) and (delta_tmp[Z_AXIS] > 0)) { delta[X_AXIS] = delta_tmp[X_AXIS]; delta[Y_AXIS] = delta_tmp[Y_AXIS]; delta[Z_AXIS] = delta_tmp[Z_AXIS]; } else SERIAL_ECHOLN("ERROR: Invalid delta coordinates!"); */ <-Remove this line }

Remove the two lines as shown to uncomment the code at the end of this function and add the "_tmp" to the three lines at the beginning (to make them Delta_tmp as shown).

[MRGiacalone]

Great. That does solve the biggest issue of having a stepper on the run.

What do you think about the triangular shape? It is comprised of four exact triangles. Marlin would have to know this maximum triangle and set them as software end stops and the rounded edges would be taken care of by the limit set in this code. Would it?

[MRGiacalone]

Also, you said you 'removed it because [you] thought it was causing issues with glitchy movement'. What exactly did you notice? Was it during manual moves or while printing?

[clefranc]

What's the status on this issue? I'm experiencing the same behavior on my delta using the 1.0.2 release.

Thank you!

[RichCattell]

I havnt implemented this "fix" because it at the time when i tried it, it appeared to cause glitching when printing at high speed. The consensus seemed to be that it was eaiser to just not try to print outside of the printable area!

If you want to try it you can add the code back in using my instructions in my previous post..

[clefranc]

OK, will try it. Thank you!

[jose55565]

Hello RichCattell,

I have a question regarding your post on this forum;

delta[X_AXIS] = delta_tmp[X_AXIS]; delta[Y_AXIS] = delta_tmp[Y_AXIS]; delta[Z_AXIS] = delta_tmp[Z_AXIS];

Where in the code is delta_tmp referencing?

Thanks!