Closed Alex9779 closed 8 years ago
Ok this is strange, sometimes the head moves when switching to T1 but only in Y direction. I home with G28 then I set the offset with M218, head is at 0,0 with first tool, I switch with T1 and head moves in Y direction. Then if I switch back to T0 nothing happens only the Z axis seems to be adjusted because of the leveling. After that I don't get the head to move on a tool switch though I know that somehow it is possible because I saw it during a test print where I have several switches of tools in the code but also only in Y direction.
Maybe my "strange" setup has an influence on this? My limits are X-28 to X300 and Y0 to Y240, the second tool has an offset of X28 Y-18 when viewed from the to so it is in front and left of the first tool...
If you're using auto bed leveling it will help if you enable DEBUG_LEVELING_FEATURE
and use M111 S255
to enable all logging. Then we can see in gcode_T
whether the matrix compensation is being applied incorrectly.
The other thing to check is, where on the bed are you doing the tool change? If you are near the edges, it's probable that the movement during the tool-change is being constrained by the software endstops. Try moving the carriage to the middle of the bed before doing the tool-change and see if it works differently.
As I look at the code for gcode_T
it's pretty simple (apart from the bed leveling compensation).
if (tmp_extruder != active_extruder) {
float xydiff[2] = {
hotend_offset[X_AXIS][tmp_extruder] - hotend_offset[X_AXIS][active_extruder],
hotend_offset[Y_AXIS][tmp_extruder] - hotend_offset[Y_AXIS][active_extruder]
};
for (uint8_t i = X_AXIS; i <= Y_AXIS; i++) {
current_position[i] += xydiff[i];
position_shift[i] += xydiff[i];
update_software_endstops((AxisEnum)i);
}
active_extruder = tmp_extruder;
SYNC_PLAN_POSITION_KINEMATIC();
prepare_move_to_destination();
}
I updated to latest RCBugFix again and tried what you said. Here is the log:
Send: G28
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: X:0.00 Y:0.00 Z:0.00 E:0.00 Count X: 0 Y:0 Z:0
Recv: ok
[...]
Send: M218 T1 X30 Y30
Recv: echo:Hotend offsets: 0.00,0.00 30.00,30.00
Recv: ok
[...]
Send: G1 X150 Y100 F3000
Recv: ok
[...]
Send: T1
Recv: echo:Active Extruder: 1
Recv: ok
[...]
Send: T0
Recv: echo:Active Extruder: 0
Recv: ok
Switching extruders does not move the head as it did in previous RCBugFix since RC6 maybe a week ago or so... Also the numbers on the LCD do not change...
If I do this with RC6 I switch to T1, numbers on the LCD change, moving to the same spot as before does move the head... In last weeks (?) RCBugFix I had to use the new command you added T1 S1 or T0 S1 to stay at the position...
Here is my config if this helps:
Your configuration seems fine to me.
But oops! Can you do your logging of T0
/ T1
again? This time use M111 S255
to turn on debugging. (I had it wrong last time. It's M111
, not M115
.) This will show details of the leveling correction. It should show a change in the current XY corresponding to your hotend offset values.
The last thing the tool-change is supposed to do is move back to the old position from the updated position, so the newly-active nozzle is in the same spot as the previously-active one.
Since there is no move, I expect the leveling correction will be strange. But if it looks normal, then I will have to add more logging code to see what else might be going on.
Ok did it, here is the result:
I intentionally leveled the bed wrong so I see seem change better and I can confirm the bed moves when I switch tools but no offset is applied...
Ok @thinkyhead I found what causes this issue.
I looked through all merges I did to my RCBugFix branch and found a working version of 15.06.2016, then I found the commits causing the issue after that date and reverted them on the latest RCBugFix of today... With that compiled on my machine the tool change works as expected, Tx
moves the head according to the set tool offset, Tx S1
does not move but changes the coordinates on the LCD.
The PR was #4010. Reverting both commits of this PR makes it working again...
This worries me a bit because that PR got merged 17 days ago... Am I the only one in the community actually testing Marlin on a real machine with multiple extruders and MBL?
I think these are the problematic lines: https://github.com/MarlinFirmware/Marlin/blob/RCBugFix/Marlin/Marlin_main.cpp#L6624-L6628
if (mbl.active()) {
float xpos = current_position[X_AXIS] - home_offset[X_AXIS],
ypos = current_position[Y_AXIS] - home_offset[Y_AXIS];
current_position[Z_AXIS] += mbl.get_z(xpos + xydiff[X_AXIS], ypos + xydiff[Y_AXIS]) - mbl.get_z(xpos, ypos);
}
What is home_offset
?
You just calculate new values but you don't set current_position
.
I changed it to this:
if (mbl.active()) {
float xpos = current_position[X_AXIS] += xydiff[X_AXIS],
ypos = current_position[Y_AXIS] += xydiff[Y_AXIS];
current_position[Z_AXIS] += mbl.get_z(xpos - xydiff[X_AXIS], ypos - xydiff[Y_AXIS]) - mbl.get_z(xpos, ypos);
}
and this made it working.
But I have a question, why do you change the Z according to MBL? If you move the new extruder to the same spot then this does nothing, would only make sense if you don't move the nozzle with Tx S1
but this does disable all moves even Z so the display shows the new coordinates including the changed Z value but the bed does not move...
Aha. I thought you were using Automatic Bed Leveling. That would have given us more logging. But we don't have any logging added to the Mesh Bed Leveling part of gcode_T
.
I'm changing it to this…
#else // !AUTO_BED_LEVELING_FEATURE
#if ENABLED(MESH_BED_LEVELING)
if (mbl.active()) {
float xpos = current_position[X_AXIS] - home_offset[X_AXIS] - position_shift[X_AXIS],
ypos = current_position[Y_AXIS] - home_offset[Y_AXIS] - position_shift[Y_AXIS];
current_position[Z_AXIS] += mbl.get_z(xpos + xydiff[X_AXIS], ypos + xydiff[Y_AXIS]) - mbl.get_z(xpos, ypos);
}
#endif // MESH_BED_LEVELING
// The newly-selected extruder XY is actually at...
current_position[X_AXIS] += xydiff[X_AXIS];
current_position[Y_AXIS] += xydiff[Y_AXIS];
#endif // !AUTO_BED_LEVELING_FEATURE
The home_offset
indicates a shift to the coordinate system applied by M206
. I've also added position_shift
to the calculation. This variable indicates that the position was shifted at some point by G92
. We have to subtract these offsets to the coordinate system in order to get back to the coordinates that originate at the unmodified X_MIN_POS
, Y_MIN_POS
, and Z_MIN_POS
.
why do you change the Z according to MBL?
Because the active nozzle is now at a different XY position (before we execute the move back to the old position). So we need to adjust Z to account for mesh variation. MBL will continue to correct Z (most likely returning it to its previous value) once we move the active nozzle from its current position back to the old position.
Ok looks good there are the things I didn't understand ;)...
Still remains the question about the Z adjustment... Any thoughts on this? IMHO the non-move-logic has to be reworked because not moving is for X and Y but not for Z... At the moment this looks like another issue with the current implementation as I described above because the machine update the coordinates but does not adjust reality. Didn't test this further, I did no additional moves and see if the Z is corrected then, so I have no idea if this is a real issue
Ok strike some points of my last comment because I wrote and you answered at the same time... But what about if not moving? Will the Z be correct on the next move?
Ok I thought about this and I don't get why you calculate the positions you use to get the MBL spot differently than the change for the current positions... Sorry if bothering but I really try to understand what's going on...
I don't get why you calculate the positions you use to get the MBL spot differently
First, we need to get the "raw" current position that MBL can relate to. So we subtract all coordinate offsets that have been applied:
float xpos = current_position[X_AXIS] - home_offset[X_AXIS] - position_shift[X_AXIS],
ypos = current_position[Y_AXIS] - home_offset[Y_AXIS] - position_shift[Y_AXIS];
Now, we get Z at the new position…
mbl.get_z(xpos + xydiff[X_AXIS], ypos + xydiff[Y_AXIS])
…and the Z at the old position…
mbl.get_z(xpos, ypos)
…and we subtract the Z at the old position from Z at the new position. (Let's say the Z at the new XY position is 0.2mm higher, for our example.)
mbl.get_z(xpos + xydiff[X_AXIS], ypos + xydiff[Y_AXIS]) - mbl.get_z(xpos, ypos);
We add this difference to the current Z.
current_position[Z_AXIS] += mbl.get_z(xpos + xydiff[X_AXIS], ypos + xydiff[Y_AXIS]) - mbl.get_z(xpos, ypos);
Now we have Z set correctly (e.g., current_position[Z_AXIS] += 0.2
) for its new position.
We had forgotten to update current_position
when MBL was enabled. But now we do.
current_position[X_AXIS] += xydiff[X_AXIS];
current_position[Y_AXIS] += xydiff[Y_AXIS];
Sorry this explains what but not why... Why do we need to calculate that stuff to get an MBL correction value for the same spot on the bed? I still think this will never result in a move of the Z axis because the coordinates for the old extruder change, the coordinates for the new change but if you look at this from the bed the new nozzle is where the old was and we have only one mesh for all nozzles so the Z correction value must be the same.
In contrast if you do not move with Tx S1. Then the new nozzle stays where is was which is a different position on the bed and thus a different correction value...
The position always changes, at first. But it doesn't always move back to the old position.
Ok I think I got it, you calculate the Z difference for the new nozzle which is still in the different position. Then you set that to the Z axis. Some lines later you set the offsets to the X and Y axes too and again later you execute the moves. Because all this happens in literally no time you would not recognize it...
But why do you use home_offset and position_shift to get that positions for which you want the correction value and not just the xydiff values as when you set the new values to X and Y axes?
Oh well you are a bit too fast for me, I had a look at the PR and you changed other things too. That stuff has something to do with the MBL stuff... So looks good! Thanks for the quick fix and the explanations....
why do you use home_offset and position_shift to get that positions
Because MBL only works internally with unaltered positions. If your bed is 200x200, MBL recognizes positions from 0-200. If the coordinate system was shifted by 10 in the X (so your X now goes from 10 to 210) and you didn't un-shift it before querying MBL, you would get the wrong Z, and MBL wouldn't know at all what to do with positions like -10 or 210, which are outside of its mesh space.
Ya got it now.... Thanks for the explanations again...
Tested it, and seems to work now...
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.
I had a discussion recently about the tool offset and switching tool and got a feature introduced so a tool switch can be done with out moving but as for today's RCBugFix I can't get the machine to recognise the tool offset. I set the offset with
M218 T1 X28 Y-18
and then a switch from T0 to T1 should move the head but nothing happens. Moves after T1 is selected still position the first tool to the given coordinates... Another configuration error of me?