CURA 4.4 - 4.6.1 IDEX 1st layer unwanted x0 y0

[karabas2011]

Application version
CURA 4.4
WIN10

Cartesian dual ( IDEX ) printer Autopark /Full control

Problem only on 1st layer

START PRINTING:
1st extruder skirt and 1layer
2nd extruder skirt
then just before tool changing - G1 X0 Y0!!!!!! Why?

1st extruder
Starts with again X0 Y0!!!

It's not critical really but in my case nozzle strikes againt bed corner holder

Additional information
(Extra information relevant to the issue.)

G1 X112.315 Y78.171 E22.48454
G1 X112.772 Y78.132 E22.50742
G1 X113.093 Y78.123 E22.52344
G1 X113.205 Y78.121 E22.52903
G1 X162.225 Y78.121 E24.97465
G0 F600 X162.225 Y78.121 Z0.4
G0 F3600 X0.00 Y0.00
^^^^^^^^^^^^^^^^^^^^^^^^^^
;TIME_ELAPSED:304.804770
;LAYER:1
M140 S60
G1 F600 Z1.4
G92 E0
T0
G92 E0
M105
M109 S210
M106 S255
G1 F1500 E-0.5
;MESH:Object 3
G0 F4500 X0.00 Y0.00 Z1.4
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
G1 F600 Z0.4
G0 F4500 X112.21 Y82.73

[Ghostkeeper]

I'm not able to reproduce this. My reproduction steps:

• Add Custom FFF Printer.
• Set the number of extruders to 2.
• Load 2 cubes (10mm).
• Change the first cube to be printed with the second extruder.
• Let it slice and switch to layer view (making sure that travel moves are visualised).

I can see the initial travel move from the coordinate origin to the brim. For the rest there are no travel moves to 0,0.

I think this is particular to your settings? What settings are you using? Perhaps you can share a project file?

[AH-TNT]

Calibrator.zip
Calibrate(2).zip

Hello,
I'm using a custom coreXY dual heads and I'm experimented the same issue when the 2sd head is called (using Win7 or Win10, with Cura 4.4 or 4.5) :
G1 F600 Z1.6
;MESH:NONMESH
G0 F7200 X0.00 Y0.00 Z1.6
;TIME_ELAPSED:19.345117
;LAYER:3
G1 F1200 E-8.17722
G1 F600 Z1.8
G92 E0
T1
G92 E0
G1 F1500 E-6.5
;MESH:Upper.stl
G0 F7200 X0.00 Y0.00 Z1.8
G1 F600 Z0.8
G0 F7200 X124.814 Y130.335
G0 X124.814 Y131.214
G0 X125.13 Y141.13
G0 X125.2 Y141.2
;TYPE:WALL-OUTER

[c3D-Dan]

For me this occurs too. Seems to be related to the use of BRIM or RAFT

[Ghostkeeper]

Could you share a project file? That's under File -> Save..., just the STL is not sufficient to reproduce the issue.

[no-response]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[karabas2011]

The same in CURA 4.6.1
absM605s0_1mm_calibration.zip

[c3D-Dan]

Thank goodness. Issue definitely didn’t disappear

[karabas2011]

btw If I enable "Ooze shild" too the problem disappears.

[nallath]

@karabas2011 You added a custom printer definition that specifically sets the "machine_extruder_start_pos_x" and "machine_extruder_start_pos_y" so that this happens. Please contact whoever made this to update this.

[karabas2011]

Why it affects only 1st layer??
I wrote definitions myself and I didnot write these settings. Possibly they are in parent fdmextruders. I have searched definition and extruder folders for these and found in other printers not mine.
Is it possible that problem is in default settings and I need to set them in definitions? they depend from Tower.
But it means that nobody is able to set his custom dual extruder printer from Cura menu.

[karabas2011]

                "machine_extruder_start_pos_x": {
                    "settable_globally": "False", 
                    "children": {}, 
                    "type": "float", 
                    "settable_per_meshgroup": "False", 
                    "unit": "mm", 
                    "description": "The x-coordinate of the starting position when turning the extruder on.", 
                    "settable_per_extruder": "True", 
                    "default_value": "0", 
                    "label": "Extruder Start Position X", 
                    "settable_per_mesh": "False"

I unzip the above project. And see that settings. What I need to change? What layers will be affected?

[nallath]

This is what the UM3 does for example:

"machine_extruder_start_pos_abs": { "default_value": true },
"machine_extruder_start_pos_x": { "default_value": 213 },
"machine_extruder_start_pos_y": { "default_value": 189 },
"machine_extruder_end_pos_abs": { "default_value": true },
"machine_extruder_end_pos_x": { "default_value": 213 },
"machine_extruder_end_pos_y": { "default_value": 189 }

[Ghostkeeper]

Cura will not load the changes you make in the project file since it's unable to add a new printer definition during runtime (or modify them).

[Ghostkeeper]

Looks like the definition in the project file has machine_extruder_start_pos_abs set to False, so the 0,0 is correct and shouldn't actually go to 0,0.

However I can't actually reproduce your bug since the project file contains a definition that you modded in. Can you provide the files you modded? Like the definition, any extruders...

[karabas2011]

printr.zip
put them in the folders, restart Cura and open my project as a project.

[Ghostkeeper]

That works. When I run the project then, I'm getting this assertion failure and preceding log events:

2020-07-14 14:10:16,673 - DEBUG - [EngineErrorThread] UM.Backend.Backend._backendLog [110]: [Backend] [WARNING] Warning: Couldn't find previous extruder plan so as to set the standby temperature. Inserting temp command in earliest available layer.
2020-07-14 14:10:16,673 - DEBUG - [EngineErrorThread] UM.Backend.Backend._backendLog [110]: [Backend] [WARNING] Empty extruder plan detected! Discarding extrusion temperature command.
2020-07-14 14:10:16,673 - DEBUG - [EngineErrorThread] UM.Backend.Backend._backendLog [110]: [Backend] CuraEngine: /home/trin/Gedeeld/Projects/CuraEngine/src/LayerPlanBuffer.cpp:90: void cura::LayerPlanBuffer::addConnectingTravelMove(cura::LayerPlan*, const cura::LayerPlan*): Assertion `newest_layer->extruder_plans.front().extruder_nr == prev_layer->extruder_plans.back().extruder_nr' failed.

Assertions are only executed when CuraEngine is compiled in debug mode, so they wouldn't show up for you. Instead it plows through with broken state. This is most likely what's causing the move to 0,0.

This indicates that there is some programming error there. It seems that one extruder plan got discarded, probably because it is empty, and then the extruder plan afterwards is not sure of where to start. I've seen this issue before, but it's rare and a bit hard to solve. The issue stems from processing the layers in parallel; the next layer doesn't know that an extruder plan in the previous layer is deleted because the two layers are processed in parallel.

[mahtDFR]

I have created a ticket on the developer's backlog: CURA-7602

[AndreasALu]

I have the same issues with my IDEX machine (CraftBot Flow IDEX, I set it up as a custom FFF printer). It looks like it only happens if a prime tower or skirt is activated. After printing the 1st layer of Extruder 1, the skirt for Extruder 2 is printed. The G-code then issues a G0 to go to the position defined in the extruder settings (nozzle offset X and Y). It works for Extruder 1, but on IDEX machines Extruder 2 is offset from Extruder 1 and cannot reach all X positions that Extruder 1 can. For example: I set X offset -18 and Y offset -16. The print coordinates then match exactly with the printbed. The G-code generated by Cura for the dual colour 3D Benchy looks like this:

...
(printing the skirt of Extruder 2)
G1 X205.703 Y120.693 E0.01888
G1 X205.701 Y119.356 E0.0647
G1 X205.703 Y118.83 E0.02546
G1 F2400 E-0.8
G0 F600 X205.703 Y118.83 Z0.5
G0 F3600 X18 Y16 (This fails, as Extruder 2 cannot reach this position on IDEX machines)
;TIME_ELAPSED:228.811921
;LAYER:1
G1 F1200 E-4.2
G1 F600 Z2.5
T0
M105
M109 S205
M106 S63.8
G1 F1200 E4.2
;MESH:3DBenchy_-Dualprint-Hull_Box_Bridge_walls_Rod-holder_Chimney_v02-_3DBenchy.com.stl
G0 F5400 X18 Y16 Z2.5 (this works, as Extruder 1 can reach this position)
G1 F600 Z0.5
G0 F5400 X240.248 Y201.237
G0 X239.053 Y201.75
;TYPE:PRIME-TOWER
G1 F2400 E0.8
G1 F2250 X238.149 Y203.44 E0.06183
G1 X236.929 Y204.929 E0.0621
...

Extruder 2 cannot reach X18 Y16 and collides with Extruder 1. That leads to a layer shift and ruins the print. The temporary solution is to set X offset of both extruders to a value both extruders can reach (in my case X48) and all goes well.

I see two possible solutions:

Solution 1.) Set both extruders to the same offset and then add an "work area offset" or "IDEX offset" which should effect both sides, as Extruder 2 cannot reach all positions Extruder 1 can and vice versa.

Extruder 1 can reach all X positions from Nozzle offset to printbed X max minus "work area offset"
Extruder 2 can reach all X positions from Nozzle offset plus "work area offset" to printbed X max (please check if "plus" is actually a "minus", as offset is negative)

Solution 2.) Just don´t put the G0 command in as it really does nothing except mothing the heads to this position and then instantly moving on to another position. And it´s only done after the first layer.

Side note: even if "Build plate adhesion Extruder" is set to Extruder 1 on both extruders, it still prints a skirt with Extruder 2.

[AndreasALu]

If you have problems, you can get rid of the code by doing a Modify G-code Search/Replace Post Processing.

Search:
G0 F(\d*) X18 Y16(.*)

Replace:
;G0 F\1 X18 Y16\2

"Use Regular Expressions" must be checked

Please change the "X18 Y16" to the values in your G-code, for Example "X0.00 Y0.00"

[Ghostkeeper]

The disallowed areas on your build plate are supposed to be adjusted with the nozzle offset. You can see this happen with the Ultimaker 3. These are the disallowed areas when printing only with the left extruder (when it can't go all the way to the right side of the build plate):

These are the disallowed areas when printing only with the right extruder (when it can't go all the way to the left):

And these when both extruders are used (it can't go too far to either side):

The disallowed areas can also be made static by defining them in the nozzle_disallowed_areas setting. The disallowed areas defined by the limited volume can also be made static with the nozzle_offsetting_for_disallowed_areas metadata entry. These things are not available through the limited GUI for Custom FFF Printer though. You'd have to make an actual printer definition for them.

Of course the wrongful G0 command still stands and is still in our backlog.

[GregValiant]

I'm cleaning house.
Is this still an issue in current Cura versions (5.8.0 and up)? Can this be closed?

[AH-TNT]

Hi Greg, You can close it, Thank you. Regards, AH

…

On Fri, 22 Nov 2024 at 19:15, GregValiant ***@***.***> wrote: I'm cleaning house. Is this still an issue in current Cura versions (5.8.0 and up)? Can this be closed? — Reply to this email directly, view it on GitHub <#6859 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOBPJ4CXQGVDVUWYXCLRDVT2B57E5AVCNFSM6AAAAABSJ7ZVGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJUGYYTAMJSHA> . You are receiving this because you commented.Message ID: ***@***.***>

[GregValiant]

Thanks.