Skip to content
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

Current Delta Auto Level Issues ? #2302

Closed
BuzzBumbleBee opened this issue Jun 16, 2015 · 14 comments
Closed

Current Delta Auto Level Issues ? #2302

BuzzBumbleBee opened this issue Jun 16, 2015 · 14 comments
Labels

Comments

@BuzzBumbleBee
Copy link
Contributor

All,

What are the current issues with the current auto bed level code when using deltas ? Iv looked through the milestones and issues, but its hard to tell whats current. For a test I used my 3DR with FSR probe after #2281 was merged into marlin. Everything seemed to work fine when the commands went in the order G28 --> G29 --> Print see video below as how the printer behaved.

https://www.youtube.com/watch?v=iZxeP_71bXk

If someone could link me to the current standing issues id be happy to take a look at them.

Regards,

@giutrec
Copy link

giutrec commented Jun 16, 2015

I have the same problem in marlin and marlin4due, i think is a knowed problem

@BuzzBumbleBee
Copy link
Contributor Author

@giutrec "same problem" ? I see no problem with how mine auto levels itself. I was looking for confirmation on what is the list of bugs currently, or maybe someone top point out in my video what the issues are :P

@giutrec
Copy link

giutrec commented Jun 16, 2015

No excuse me, i have look your video and i've observe the convex movement to goto each new line of the grid, the probe works correctly but is a little bug.
I've understand tour issue...

@BuzzBumbleBee
Copy link
Contributor Author

@giutrec ahhh, see i didn't notice that.

Ill see if I can track down that bug :)

@Wackerbarth
Copy link
Contributor

I think that the problem is that the motion is in the actuator domain and not in the cartesian domain.

By that, I mean that if you look at the end points of the motion and find that one of the actuators is in the same place for both ends, then the movement does not change the position of that actuator. This leads to a curved motion in the cartesian domain. To obtain linear motion, it is necessary to move the actuator away from its initial position and then return it to that position as a part of the coordinated movements which make up the action. I addressed this on my machine by raising the effector at the end of each probing far enough to keep the "sag" from causing a problem.

@Wurstnase
Copy link
Contributor

With the new zigzag (V<3) this should be not a big problem.

@thinkyhead
Copy link
Member

the motion is in the actuator domain and not in the cartesian domain

It would be great to have a patch to make the probe movements go through the delta interpolation. I've looked at the problem and it slightly intimidated me due to unfamiliarity.

@Wackerbarth
Copy link
Contributor

Rather that attempting to approximate linear motion during these moves (you can only approximate it because to the kinematics) and the fact that there is no value in having "zero" sag in the path, I would suggest that it might be easier to estimate the maximum sag and assure that the probe is raised enough to maintain a lowest point at least above some clearance threshold.

The difficult in doing even that is that it becomes very complex when you are dealing with sloped beds.
I really question the value in having the firmware attempt to do this in real time. It seems much more practical to just perform the calculation off-line (or experimentally) and plug in an appropriate clearance offset.

@thinkyhead
Copy link
Member

With the new zigzag (V<3) this should be not a big problem.

…due to the shorter moves between adjacent rows.

I really question the value in having the firmware attempt to do this in real time

The firmware just divides up linear moves into smaller segments while printing on a delta. (See prepare_move_delta() function.) We could certainly just use the same method during leveling. The number of delta kinematic calculations won't differ, just the number of individual moves.

@boelle boelle added this to the Bug Fixing Round 9 milestone Jun 29, 2015
@clefranc
Copy link
Contributor

@BuzzBumbleBee Can you share your Configuration.h and Configuration_adv.h?

Have been trying to use my "new" probe on my delta to do some auto level without success. I'm using the latest Development branch.

Thank you!

@roboprint
Copy link

#1731
Duplicate :)

@clefranc
Copy link
Contributor

I forgot to say please!

@jbrazio
Copy link
Contributor

jbrazio commented Apr 23, 2016

Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.

@jbrazio jbrazio closed this as completed Apr 23, 2016
@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

9 participants