Switching to Extruder 2 when at "Pysical Home" results in Head bumping into Endstop(s)
motwok opened this issue · comments
(Only tested in 1.1.9)
Description
Switching to Extruder 2 when at "Pysical Home" results in Head bumping into Endstop(s)
Steps to Reproduce
- Define a 2. Extruder with a 32 mm offset in X direction and upload firmware
- Home the carriage
- Activate Extruder 2
- Move to the "Left"
Now you here the sound when a motor is blocked because of the mechanical endstops.are in the way.
Expected behavior:
Head is not moving towards the endstops.
Actual behavior: [What actually happens]
Head is moving towards the endstops.
Additional Information
its clear that the 2. Extruder can not reach the physical "0" or "Home" Coordinate, the first Coordinate you can print with this extruder is at 32.0 / 0.0 (X/Y), for first fix it would be great when the Movement honors the "Physical" Home as minimum coordinate.
After taking a few more thoughts into it, i think it would be practical to add a option that sets the Offset to the maximum values definied in the Extruder Offsets.
This logic has been modified quite heavily in 2.0; can you test it there and confirm if the problem remains?
I am sure the logic has changed in some way…
In 1.1.9 i used:
#define HOTEND_OFFSET_X {0.0, -32.00}
to get the head moved to the correct possition.
In 2.0.x i used:
#define HOTEND_OFFSET_X {0.0, 32.00}
to get the head moved to the correct possition. (note the removed minus sign)
(after the bump against the Endstop it looked like it where the positive Value but this was wrong)
The same value.
I managed to avoid the bumping into the endstop by adding the offset mentioned in the opening post
The behaviour itself did not change, you can run into the endstop!
Please post your config
I have seen this behavior too, on 2.0.x (not tested on 1.1.9).
Hello Gmagican,
sorry for the late answer, i was busy a long time.
Here is my current config:
mo2000_Marlin_config.zip
As long you do not set a offset off X -32 the head runs into the endstop when changing to tool 1 (second tool) when not ad least at position X32
Meanwhile i did some tests over the Terminal... i doubt that we have a protection for running into Min Endstops. (This statement belongs to 2.0.x branch),
The big difference between last month and now is that i added the Extruder offset to the firmware instead to do it over Slic3r. May Slic3r do not write G Code that moves into the endstop.
May i noddged on something that does not exist in Marlin at all?
May this should better a feature request? -> something like "Protect Carriage not to leave defined Bed Area after Homing"?
Ok checking at code, with your cnf, there is no "inside limits" check.
Don't know if better not move at all and or move just as much as it can
From the "Usage" View it would be great if the head is moving as much it is possible. (Single Material Prints can be a bit larger)
But i doubt that this is programmable in a clean way.
there is no "inside limits" check.
Is there an define that can be activated?
If… then i didnt see it... trees… so much that i cant see the wood ;D
No define to be activated but code to be written.
One thing that may be dangerous is when you do some action like this during print. Some kind of "stop error" should be risen if new tool can't continue from same point.
I'm going to try to fix it
@thinkyhead I'm trying to fix this but I need some help to understand how things work.
Everywhere in code (G26, M48, G34, skew function) there are some fixed checks to ?_MIN_POS/?_MAX_POS but in cases like this, when you are using T2, limits has to shift of xdiff/ydiff amount (so X_MIN_POS will become X_MIN_POS+=xdiff). To fix this I have to create a new array and replace all above checks? This will increase memory due to non constant variable use and a lot of code to fix...maybe this is a little too big for me
For IDEX, we fixed this by adding individual limits per tool. For generic tool heads, proper machine design should have the hotend offset distance or more between 0 and the x endstop (See taz 6 carriage). This can be configured to act that way if you inset the 0 onto the bed a bit. Now if this is held, you should be able to define a generic T1 min position of 0 and set the soft endstops the same way IDEX does now.
@InsanityAutomation for index it's ok to have limits for each carriage but in this case we have only one carriage and limits will change the exact amount of hotends offset. One idea could be recycle IDEX dual limits and just copy in second limits set the first added by hotends offset...but this doesn't change the G26 that uses ?_MIN/MAX_POS as fixed limits unless G26 is limited to first tool.
I think that also IDEX has issues with it, please check position_is_reachable function. It checks only ?_MIN/MAX_POS but your carriage 1 has different X_MIN/MAX_POS than carriage 2 ... or is everything handled differently?
The update_software_endstops function called from tool change modified the positions, eg soft_endstop_min[X_AXIS] = X1_MIN_POS; position_is_reachable for idex checks active tool and compares these values as well. For Dual nozzle systems, it could be modified the same with a check on active extruder and take x_min + hotend x offset for t1. G26 logically should have no issue being limited to T0 and I believe thats been discussed before.
G26 logically should have no issue being limited to T0 and I believe thats been discussed before.
But it's not limited so damages may occurs
G26.cpp line 556 if (parser.seenval('T')) tool_change(parser.value_int());
... and also if for some reason soft endstops are not enabled all this doesn't work, even with IDEX machines. This protection should be indipendent of soft endstop enable (?_MIN/MAX_POS should prevent this)
@motwok problem solved?
as I know it is unfixed
that is why i asked @motwok, it could have been fixed and he just forgot to close the issue
@boelle: Still broken in 2.0.x.
Several things around this have been adjusted. Can @marcio-ao or @motwok confirm on their setups as well?
missing label
Actually can likely be closed. Several PR's worked to address this and no response from owners post changes likely means resolved.
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.