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

Switching tools moves head since #3620 #4000

Closed
Alex9779 opened this issue Jun 10, 2016 · 7 comments
Closed

Switching tools moves head since #3620 #4000

Alex9779 opened this issue Jun 10, 2016 · 7 comments
Labels
T: Question Questions, generally redirected to other groups.

Comments

@Alex9779
Copy link
Contributor

Alex9779 commented Jun 10, 2016

#3620 was meant to fix the feederate after a tool change but also introduced that switching the tool also moves the print head.

I think this is because of the tool offset which is applied to the current position when switching.

My question is wether this intended behaviour and just didn't work before that PR or not?

In previous versions up to RC6 switching tools didn't result in a move of the head. I have to say this is not good for my setup, I have a dock area where movement is limited, I move there always with T0 selected to be sure the movement doesn't crash the head anywhere. Otherwise it would have to use different docking sequences depending on which print head is active which is not practical...
But when I am in the dock area I am switching tool to purge nozzles and stuff. When the head moves because of the tool offset the head crashes...

@thinkyhead
Copy link
Member

intended behaviour and just didn't work

That is correct. This needed to be fixed, otherwise printing would start in the wrong place after a tool change.

So, the tool has to move when switching. But its movement is constrained, so it should never try to move past the set movement limits as defined by your *_MIN_POS and *_MAX_POS settings (i.e., the software endstops). It sounds to me like you just need to consider the tool offset and the currently-selected tool in your docking procedures.

Do you use the Z_PROBE_SLED and SLED_DOCKING_OFFSET options, or is your probe a standard type, but you also have a dock?

@thinkyhead thinkyhead added the T: Question Questions, generally redirected to other groups. label Jun 11, 2016
@Alex9779
Copy link
Contributor Author

It sounds to me like you just need to consider the tool offset and the currently-selected tool in your docking procedures.

is your probe a standard type, but you also have a dock

I think this is not possible for me, the tools are on the same head, the dock is in the back of the box but just as wide as one and a half of the print head.
bed_hotends_limits
Software endstops don't work here because Marlin only know the full X movement range but in the dock this is limited physically.
The procedure is like so I move to the head to the dock where I can prime and clean the nozzles. In the dock I have to switch tools on a tool change because I need to clean the old tool and prime the new tool.

I need a method to switch tools without moving the head.The coordinates can change I have no problem with that before moving out of the dock I select tool 0 again and position the head before the dock, then the normal print continues selecting the correct tool and moves the print head to the correct position able the print bed.

@thinkyhead
Copy link
Member

thinkyhead commented Jun 11, 2016

@Alex9779 Well if all we need is an option to keep the carriage where it is, then #4013 will do that. It allows you to add S1 to your tool-change command, and the carriage will stay in place. However, note that the current position, software endstops, etc., will be changed to the position of the new tool.

@Alex9779
Copy link
Contributor Author

Thanks. I will review that PR...

@Alex9779
Copy link
Contributor Author

@thinkyhead Ok by your wording I thought this was an existing PR but you created it again because of me? You are a freak ;-)
Unfortunately I can't verify at the moment, because I haven't made the config for RCBugFix yet.

@Alex9779
Copy link
Contributor Author

@thinkyhead ok I tested it and it seems to work. Though I have no idea what you tried to tell me with:

note that the current position, software endstops, etc., will be changed to the position of the new tool

That is fine so I think, the LCD updates to the new position, but I won't make moves with T1 activated in that area, before next XY move I switch back to T0 with S1 now.

But I found another problem, I am going to open an other issue for this...

@github-actions
Copy link

github-actions bot commented Apr 7, 2022

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 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
T: Question Questions, generally redirected to other groups.
Projects
None yet
Development

No branches or pull requests

2 participants