Tool G-Code (Tn) not always added for first extruder/tool in a multi extruder setup

thedevleon commented 5 years ago

Version

1.42.0-alpha5+win64

Operating system type + version

Windows 10, 64-Bit, build 17763

3D printer brand / version + firmware version (if known)

Heavily modded Ender 3 with Duet Wifi 2 and Y-Splitter for filament changing. As I'm running RepRapFirmware, the filament switching (unloading and loading) is taken care of, as long as the correct extruder/tool is selected with T0 or T1.

Current Behavior

I have a printer profile setup with two extruders and without the "single extruder multi material" option checked. When I freshly open slic3r, and I place one object on the plater and select either default or first extruder and export the G-Code, there are no T0 in the file and M104 does not contain a tool number. (Scenario 1)

When I select anything but the default or first extruder (so the second extruder), T1 is correctly added to the exported G-Code, as well as passed into M104. Temperatures for T0 and T1 are set and waited for, even if only one extruder is used. (Scenario 2)

If I switch back to the default or first extruder, again there are no T0s. (Scenario 1)

However, when I add another object, select different extruders for them and then remove one object (so only one object remaining), for everything that is sliced from now on, T0 is also generated when the extruder for that one object is set to default or 1. (Scenario 3)

So this seems to be a bug that works in my favor. However, I don't always want to add and remove a second object, just to get slic3r to generate T0s. It would be nice to have them there from the start on.

Expected Behavior

If there's only objects on the plater with the same extruder selected for all of them, generate Tn for that extruder (no matter if default, 1 or more). Also generate only one M104 Snnn Tn and M109 Snnn Tn for that extruder, instead of generating them for all. Could be useful for a printer with 2 seperate nozzles, as one nozzle doesn't need to be heated if not used at all.

Generated G-Code

Starting G-Code (Scenario 1)

M104 S190 ; set temperature
[...]
M109 S190 ; set temperature and wait for it to be reached

Starting G-Code (Scenario 2 and 3)

M104 S190 T0 ; set temperature
M104 S190 T1 ; set temperature
[...]
M109 S190 T0 ; set temperature and wait for it to be reached
M109 S190 T1 ; set temperature and wait for it to be reached
[...]
T0

thedevleon commented 5 years ago

Any update to this?

supermerill commented 5 years ago

There are "T[initial_tool]" in the prusa start g-code for mmu1. Did you test it? Or it doesn't work for you?

thedevleon commented 5 years ago

There are "T[initial_tool]" in the prusa start g-code for mmu1. Did you test it? Or it doesn't work for you?

I'm not using MMU1, but a self-built system with a Y-Splitter. I guess adding T[initial_tool] to the start g-code would be a workaround, but it would be nice if this could be generated from the start on.

This also doesn't solve the issue that when only one of two (or more) tools are selected (and T > 1), M104 and M109 are still generated for all tools, even if they are not used. Again, in a dual nozzle setup this would mean that the second nozzle (even when never used) is also heated up for the whole print and will ooze.

supermerill commented 5 years ago

I guess adding T[initial_tool] to the start g-code would be a workaround, but it would be nice if this could be generated from the start on.

Well, maybe it can broke some other kind of printer if it can't be disabled. I don't know. Putting it inside the start gcode is safer imo. See your problem with M104 and M109.

This also doesn't solve the issue that when only one of two (or more) tools are selected (and T > 1), M104 and M109 are still generated for all tools, even if they are not used.

I think it's because you didn't write any M104 and M109 in the "start g-code" area. If not, can you send your settings ? see https://github.com/prusa3d/Slic3r/issues/1417

bubnikv commented 5 years ago

I guess adding T[initial_tool] to the start g-code would be a workaround, but it would be nice if this could be generated from the start on.

I don't think this is really an issue. We have more important work to do than this. You may just satisfy your needs by the [initial_tool] macro.

We could handle the initial tool the same way we handle the M104 and M109: Enter it if no [initial_tool] is found in the custom start G-code.

IMHO it would be far more useful, if the community helped with documenting the current behavior, than to patch the code for various corner cases.

thedevleon commented 5 years ago

I don't fully unterstand the point you are trying to make. You are saying "this is not really an issue" and "we have more important work to do than this".

But then you argue to not just patch the code for various corner cases, which adding T[initial_tool], M104 and M109 into the start gcode is, no?

And as I have documented above, the behavior is simply not consistent for a printer with 2 or more tools. The outcome of scenario 1 and scenario 3 should be the same, and M104 and M109 should only be generated for tools that are actually used.

Maybe I have misunderstood the point you were trying to make, in that case, could you clear it up for me?

bubnikv commented 5 years ago

Maybe I have misunderstood the point you were trying to make, in that case, could you clear it up for me?

The day has 24 hours, I want to spend some time with my kids, walking my dog etc.

calston commented 2 years ago

I think this is a documentation problem, the "initial_tool" variable doesn't appear anywhere but does work.

lukasmatena commented 2 years ago

@calston It appears in the official documentation (https://help.prusa3d.com/en/article/list-of-placeholders_205643) and anyone creating a custom printer can take inspiration from e.g. Prusa MMU profiles, which also use it. That should IMHO suffice. Where else should it appear so you considered the documentation problem resolved?

prusa3d / PrusaSlicer