New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Limit carriage position to positive float: Improved software end stop for Deltas? #7
Comments
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]) /* SERIAL_ECHOPGM("delta x="); SERIAL_ECHO(delta[X_AXIS]); 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). |
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? |
What's the status on this issue? I'm experiencing the same behavior on my delta using the 1.0.2 release. Thank you! |
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.. |
OK, will try it. |
Hello RichCattell, I have a question regarding your post on this forum; delta[X_AXIS] = delta_tmp[X_AXIS]; Where in the code is delta_tmp referencing? Thanks! |
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.
The text was updated successfully, but these errors were encountered: