Cura: Extruder #2 off-center and doesn't extrude after upgrade

[cryoaura]

Application Version
4.0 Release

Platform
Windows 10 x64

Printer
BIBO 2 Touch

Steps to Reproduce
I installed Cura 4.0 alongside 3.6. When I first opened 4.0, it gave errors about printer not being defined. I copied my printer definition and it's extruders into the resources folders. I then loaded up a model, printed with extruder 1, worked great. When I tried printing with extruder 2, the print was unsuccessful.

Actual Results
When printing with extruder 1, everything is fine. When I print anything with extruder 2, the print is off-center to the left and the extruder 2 doesn't ever extrude while printing.

Expected results
The model should be printed at the origin and extrusion should happen like normal.

Additional Information
I attached the printer definition, project, and gcode.

3.6 still continues to work just fine.

After uploading this report, I will attempt to remove the printer and re-add it, followed by an additional test. This is my first ever GitHub bug report, so hopefully I did everything as helpful as possible.

Fails-gcode.zip
printer-definition.zip
Fails-project.zip

[cryoaura]

Noticed the printer name is blank in the menu, or maybe it's supposed to be that way in 4.0. Providing either way.
curaprinterblank.zip

[cryoaura]

Just deleted and re-added the printer. Now it shows up under local printers in the menu, however, end result is still the same. Print is to the left on the x-axis and never actually runs the extruder. Tested again in 3.6, no issues.

Hopefully this helps, looking to get used to Cura 4.0 as it looks nicer! For now I'll keep at 3.6 but happy to submit anything else someone would like to look at to try and fix this!

[rburema]

Perhaps related to #5484 though that reporter is way less willing to share any information :-/

[Ghostkeeper]

Noticed the printer name is blank in the menu, or maybe it's supposed to be that way in 4.0. Providing either way.

I think it's related to the Octoprint plug-in, since it gets listed as a network enabled printer but it doesn't show any build plate model.

The off-center bit could be caused by your printer settings. It looks like you've set the left extruder to be offset by [0.2, 0.1]. You can see that by going to Manage Printers -> Select your printer -> Machine Settings -> Tab that says "Left".

When I slice your model with the second extruder ("Left"), then the g-code looks fine. I don't know why it doesn't seem like it's extruding for you :( Maybe you need a prime routine before the print?

[cryoaura]

Reading the printer fixed the blank display, so good there. When I say off-center, I mean like several inches off-center. My mm offset is just a little cali ration and exists in 3.6 as well.

When I say not extruding, I mean the stepper is literally not running at all, so no issue with prime either.

Appreciate the comments and hopefully there's a good solution! Appreciate that this is an opensource product and the community/devs are willing to help around it!

[Ghostkeeper]

Your g-code indicates nice E values though, that should be interpreted by your firmware as "move dat stepper".

Maybe it's got something to do with your steps-per-mm calibration in the firmware?

[cryoaura]

Good thought, but the fact that 2.6 works leaves me thinking otherwise. What you said did make me want to look at the differences in the GCODE generated on 3.6 vs 4.0.

Where it sets the temperatures at the beginning of the code, lines 10 and 12, 3.6 explicitly calls out the tool.

3.6 = M104 T1 S190
4.0 = M104 S190

I also noticed in 3.6 it has 5 lines that 4.0 does not. All between the layer comment and the M107. In it an explicit call to the tool being used as well.

G1 F2400 E-16
G92 E0
T1
G92 E0
G92 E1.5

At first glance, I thought maybe the temperature was getting set to the wrong extruder since it wasn't explicitly getting called. I did check that as I could push the filament through. So this leaves me at the 5 lines above. I am no GCODE expert, but is it possible the explicit call to the tool in those is making this work properly in 3.6? If so, is there a dev decision as to removing the 5 lines due to some other issues or something?

While glancing at this I noticed something else. My extruder start GCODE of "G92 E1.5" is not appearing in 4.0. I see it in those 5 lines of 3.6, but I'm not sure where the 4 lines above it are coming from?

I thought maybe I'll explicitly call out the tool in my extruder start GCODE, but since that's not even appearing I'm assuming that's a lost cause. Appreciate the comments so far and hoping to a solution!

I've attached the 3.6 GCODE as well to see the differences.
B2T_CALIBRATION_TEST3.6.zip

[rburema]

Hi @cryoaura It seems your startcode (configurable for the printer) sets the toolchain explicitly to T0, which is the first extruder.

[Block137]

I also noticed in 3.6 it has 5 lines that 4.0 does not. All between the layer comment and the M107. In it an explicit call to the tool being used as well.

Very likely related to these
https://github.com/Ultimaker/Cura/issues/5486
https://github.com/Ultimaker/Cura/issues/5311
Their conclusion is to wait for 4.1. The fix didn't make it in time for 4.0

Since T1 is never called, the printer will keep using T0 (default tool) and not extrude / apply position offset to T1

[rburema]

@Block137 The gcode posted here does call T1, just before the 'start g-code'.

[Ghostkeeper]

It needs to call T1 before the starting g-code because the starting g-code can't be expected to know which extruder is going to be printed first.

[Block137]

@rburema It does for heating it up but not at toolchange

It does heat up before machine start code and T1 is called properly.
Then T0 is often added to start code because in case of multiple separate hotends, homing with tool offset applied causes a lot of problem.
In 3.6, Cura did call T1 again afterward but there's a bug in 4.0 that T1 won't show up so the print continue with T0.

[rburema]

@Block137 Yes, because we assume the hotend is still at T1 after the start-code, which isn't analyzed at all by us, but just inserted as-is. In general, start-code shouldn't be calling T at all. It's because we fixed a few bugs that this is now exposed. The old way worked 'by accident'.

We might just decide to fix this by adhering more strictly to that rule. (Or perhaps we could add a switch to the selected extruder _again_ right after the start-code is inserted, just to be sure, but that'll just mask the problem.)

[Block137]

@rburema My idea is to have "Default extruder" selected in machine settings. If the default extruder is not used at the start then execute its end code. Also possibly return to default extruder at the end of print (this will also solve issue https://github.com/Ultimaker/Cura/issues/4909 )

I am operating a custom multi-nozzle style printer (similar to Ultimaker3). The home position is defined by (0,0) position of T0 and T1 position offset is defined in firmware.
If I send (given that T1 is 20 mm to X+ from T0)
T1
G28 ; X0 Y0 loaded into current position
T0
The current position will be X-20 Y0 Z0.
*Just to show that T0 in start code is mandatory.

[Ghostkeeper]

How about using the nozzle offset parameter in the per-extruder tabs of the machine settings, then?

[rburema]

@Block137 Since a related issue came up; I forgot to mention that you _can_ select the initial extruder with T{initial_extruder_nr}. This still leaves the 'off' extruder unnacounted for (since there can be more than 2).

[cryoaura]

Thanks guys, I noticed that 4.1 came out and will try that tomorrow and report back. Been going at it hard with 3.6 the last few weeks.

@rburema I think I see what you're saying about explicitly calling T0 in my start code and that I shouldn't. What Block137 said though is true from what I remember, when I didn't call it, I had issues with printing. It could be that my printer merely doesn't adhere to a proper standard of code, which causes this requirement. I can't expect Cura to be designed around my printer, but if it requires some weird startup code I'm hopeful to be able to work around it.

Based on what you said recently, if I also add at the end of my start gcode something like this...
T{initial_extruder_nr}
G92 E0

That should work? In the case of printing with T1 it will actually call T1 and if T0 it will call T0? I will obviously try eliminating the T0 call entirely first, but if there truly is a reason I had to have it, I can try that if you are thinking it'll choose the right extruder.

I really appreciate everyone's help. Sounds like it's either resolved in 4.1 regardless, I need to remove erroneous start gcode, or I need to add some gcode. So I'll try these avenues and close once I have a check on what all worked.

[rburema]

@cryoaura Yes that's right. This isn't a new feature of 4.1, though.

[cryoaura]

@rburema I added in that command at the end and all is well. Sure enough as @Block137 also shared, I straight removed my T0 code and the 2nd extruder did not print in the center of the plate. My origin appears to be at 0 only if I call it from T0, otherwise it ended up shifted on the X axis by a good margin. So, what I'm doing is keeping my T0 call and then at the end of the start code doing T{initial_extruder_nr}
G92 E0. This works perfectly for me. I'm not sure if they implemented a recall of the initial extruder in 4.1 like 3.6 had which made it work, but either way my start code to just call the initial extruder has solved my issue.

Thanks for the help guys. I'm not sure whether the true issue is with Cura removing that recall or my printer not recalling itself or choosing proper origin without a T0 call. I'll close this out I suppose since there is a resolution and I'm not sure why Cura should need to change it's code back to an old style to make up with the oddities of Marlin and dual extruder heads. I hope this helps other people whom run across this in 4.x as well!