Closed pbrgle1 closed 9 years ago
This sounds like it is something that is beyond the scope of a Marlin based printer. Can you be more explicit in describing the feature and how it would work?
well the dual x carrige mode is already implemented in marlin under configuration_adv.h (#define DUAL_X_CARRIAGE), and so is the x offset of the parked extruders. I would also like to see some feature that specifies the z offset of the nozzles. For eg. Tool 0 is on Z 0.00 when homed and Tool 1 has a -0.4 offset. So everytime the tool changes, there would be a Z lift or lowering according to the offset.
OK, I think I understand your request. You want a per-tool "height setting" when the carriages are operating as separate tools. Thus switching from one tool to another would not only change the X-stepper motor involved, but would change the Z-position so that the resulting nozzle is at the same height in the object space.
Exactly. So if Tool 0 is 0.5mm lower - before switching to Tool 1, perform a 0.5mm Z lift and vice versa. after parking the previous Tool offcourse.
I would approach it a little differently, but with the same effect.
Is there any chance for this to be implemented?
i just found this. https://ultimaker.com/en/community/view/16095-marlin-m218-extruder-offsetdocumented-as-only-x-y-but-the-code-says-also-z?page=1&sort=#reply-119605.
is there anything to it?
https://github.com/MarlinFirmware/MarlinDev/blob/master/Marlin_main.cpp#L4078 Try it. At this place we have the same code.
I set the Z offset for T1 to -0.5 and M114 Reports Z0,00 for tool 0 and Z0,50 for tool 1 even though the Z didnt move....what could be wrong? i did set #define min_software_endstops false
@pbrgle1 Which command did you use to set the Z offset?
M218 T1 Z-0.5
T1 F
F?
I don't know if you're using a host or direct command. The F in T command force the move when changing tool.
im using pronterface atm.
Still not moving?
hmm, no. the M114 does report the z change when i switch tools but the printer doesn't move Z...
If you set an X and Y offset for T1, do it move?
Sorry, I've not experience with dual carriage, looking at the code seems to indicate it's implemented.
Nope, there are no offsets. At least not with manual moves in pronterface
Can you paste your Configuration.h and Configuration_adv.h here (or create a branch in your repo with your config)?
hey. i dont know what happened... github thought i was abot
Hey! Welcome back.
I thought you solved your issue and kept the solution for yourself. :)
@KiteLab and I wanted you to try a G0 X0 Y0 Z0 after a tool change.
No reaction.
Not sure if this is completely relevant, but I think some people will find this when looking for my similar issue. I don't have a dual carriage, but I still need to be able to offset in Z.
To force this ability, you just have to comment out the conditional in three places in marlin_main.cpp:
//#if ENABLED(DUAL_X_CARRIAGE) and each corresponding //#endif
also posted on https://ultimaker.com/en/community/16095-marlin-m218-extruder-offsetdocumented-as-only-x-y-but-the-code-says-also-z
@nicksears What kind of extruder(s) are you using? Upcoming support for switching extruders will be adding a generalized Z offset as HOTEND_OFFSET_Z
.
I'm printing paste and a thermoplastic with HYREL's EMO-25 emulsifiable extruders. I'll post details when I publish :) but the paste extrusion part can be found here. Since I replace the entire extruder so often, zeroing the heads perfectly every time isn't feasible I'd rather get it close and measure the offset perfectly with a probe and webcam. I don't see a reason to implement a separate z offset methodology when it's already built in? Why not just have a "#define ALLOW_HOTEND_OFFSET_Z" and change the if statements to "#if ENABLED(DUAL_X_CARRIAGE || ALLOW_HOTEND_OFFSET_Z)"?
@nicksears Heck, we'll probably just make HOTEND_OFFSET_Z
standard in all cases, but leave it zeroed out by default.
Just a note about this. I don't know if the HOTEND_OFFSET_Z was supposed to make things better/more universal, but it broke what I was doing before. Now in RC7 I may be able to set a hotend offset, but it doesn't work as expected. It never seems to apply it.
I've made it work by defining as a switching_extruder since dual_x_carriage and switching_extruder seem to have a unique way of applying the offset during a tool change in marlin_main. I've had to tweak a lot of other things since I'm not actually using a switching extruder, (especially making the stepper behavior like normal in stepper_indirection.h) but it seems to work again. Does this sound right?
but it broke what I was doing before but it doesn't work as expected seem to have a unique way of applying the offset
These are awfully vague statements. What is the specific behavior you want, and what is the specific behavior you're getting instead? To get more details about the issue, you can enable DEBUG_LEVELING_FEATURE
and use the M111 S255
command to turn on verbose logging before doing testing.
If you try some things and report your results, we might actually be able to fix the bug instead of requiring users to implement clever hacks.
Before I was able to just comment out the if statements in M218 in marlin main to allow z_offset with M218 with no other major changes. I'm not sure if it was working completely correctly, though. The height readout would show the current position including the offset, and I thought the offset was supposed to be internal?
In RC7 it showed the correct height (no offset), but never actually applied any offset (moved up or down) just auto bed leveling compensation. Both SWITCHING_EXTRUDER and DUAL_X_CARRIAGE have sections in the tool change method that shift it to the new location (including z) but since those are the only cases that allow for an offset z, it seems that it wont apply the z offset unless you have one of those selected (even if I manually define an offset z). Also, the section after these for AUTO_BED_LEVELING_FEATURE no longer applies the offset in z? it just has a zero for that part of the array, not sure if that's relevant.
So I selected SWITCHING_EXTRUDER, commented any corresponding servo actions, commented the first part of the if statements in stepper_indirection.h that limits it to one motor that inverts direction, and lots of other small changes that caused errors.
I think it works now, but avoiding collisions is difficult. In practice it should never be a problem because my extruders are set wide apart, but until I have the logic figured out, I'm not confident.
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.
With the dual x-carriage, the tools can have a different Z since they move independently (not in duplication mode). I would like to request a feature that enables Z (and maybe also Y) offset right after tool change.